Re: [rtcweb] New version of -overview posted
Colin Perkins <csp@csperkins.org> Tue, 04 October 2011 15:46 UTC
Return-Path: <csp@csperkins.org>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4125921F8C71 for <rtcweb@ietfa.amsl.com>; Tue, 4 Oct 2011 08:46:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.539
X-Spam-Level:
X-Spam-Status: No, score=-103.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbKTXmPcmeqd for <rtcweb@ietfa.amsl.com>; Tue, 4 Oct 2011 08:46:34 -0700 (PDT)
Received: from anchor-msapost-2.mail.demon.net (anchor-msapost-2.mail.demon.net [195.173.77.165]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD5021F8C6F for <rtcweb@ietf.org>; Tue, 4 Oct 2011 08:46:28 -0700 (PDT)
Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by anchor-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1RB7FM-0004e0-ko; Tue, 04 Oct 2011 15:49:32 +0000
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <4E830E89.3050400@alvestrand.no>
Date: Tue, 04 Oct 2011 16:49:31 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <BECD8057-0C87-4B33-A6A9-74D5008BFA41@csperkins.org>
References: <4E830E89.3050400@alvestrand.no>
To: Harald Alvestrand <harald@alvestrand.no>
X-Mailer: Apple Mail (2.1084)
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] New version of -overview posted
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Oct 2011 15:46:35 -0000
Harald, On 28 Sep 2011, at 13:09, Harald Alvestrand wrote: > I've just posted version -02 of the -overview document. > I'll just paste the change log from the document here: > >> A.6. Changes from draft-ietf-rtcweb-overview -01 to -02 >> >> Added pointers to use cases, security and rtp-usage drafts (now WG >> drafts). >> >> Changed description of SRTP from mandatory-to-use to mandatory-to- >> implement. >> >> Added the "3 principles of negotiation" to the connection management >> section. >> >> Added an explicit statement that ICE is required for both NAT and >> consent-to-receive. > > Comments are always welcome, and version numbers are cheap! A minor editorial point: the 3rd bullet in section 7 suggests that SDP for new codecs is specified by MMUSIC. This is inaccurate: the SDP is done by PAYLOAD, as an algorithmic mapping from the parameters of the new media type. Suggest changing: 3. When a new codec is specified, and the SDP for the new codec is specified in the MMUSIC WG, no other standardization would should be required for it to be possible to use that in the web browsers. Adding new codecs which might have new SDP parameters should not change the APIs between the browser and javascript application. As soon as the browsers support the new codecs, old applications written before the codecs were specified should automatically be able to use the new codecs where appropriate with no changes to the JS applications. to 3. When a new codec is specified, and the media type parameters for the new codec are specified in the PAYLOAD WG, no other standardization would should be required for it to be possible to use that in the web browsers. Adding new codecs which might have new media type parameters should not change the APIs between the browser and javascript application. As soon as the browsers support the new codecs, old applications written before the codecs were specified should automatically be able to use the new codecs where appropriate with no changes to the JS applications. You might also want to add something like "The representation of codec names and their parameters in the web browsers must be algorithmically derivable from the media type name and parameters defined in the RTP payload format specification for the codec. This can be done by using the media type name and its parameters directly; by using the existing encoding of that name and parameters into SDP; or by defining an algorithmic mapping from the media type name and parameters onto a new signalling format". Colin -- Colin Perkins http://csperkins.org/
- Re: [rtcweb] New version of -overview posted Colin Perkins
- [rtcweb] New version of -overview posted Harald Alvestrand
- Re: [rtcweb] ICE for dual stacks (new topic) Olle E. Johansson
- Re: [rtcweb] ICE for dual stacks (new topic) Roman Shpount
- Re: [rtcweb] New version of -overview posted Harald Alvestrand