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, 4 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/