Re: [rtcweb] New version of -overview posted

Harald Alvestrand <harald@alvestrand.no> Wed, 05 October 2011 12:06 UTC

Return-Path: <harald@alvestrand.no>
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 CB52821F8CC0 for <rtcweb@ietfa.amsl.com>; Wed, 5 Oct 2011 05:06:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.457
X-Spam-Level:
X-Spam-Status: No, score=-108.457 tagged_above=-999 required=5 tests=[AWL=2.142, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 4-61y3Q4jlJz for <rtcweb@ietfa.amsl.com>; Wed, 5 Oct 2011 05:06:23 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id E9B4221F8CBF for <rtcweb@ietf.org>; Wed, 5 Oct 2011 05:06:22 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5CABE39E0A7; Wed, 5 Oct 2011 14:09:30 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1BDwhtPrQVf; Wed, 5 Oct 2011 14:09:29 +0200 (CEST)
Received: from [172.16.41.139] (unknown [74.125.121.33]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 90CC939E048; Wed, 5 Oct 2011 14:09:29 +0200 (CEST)
Message-ID: <4E8C48F8.5060001@alvestrand.no>
Date: Wed, 05 Oct 2011 14:09:28 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15
MIME-Version: 1.0
To: Colin Perkins <csp@csperkins.org>
References: <4E830E89.3050400@alvestrand.no> <BECD8057-0C87-4B33-A6A9-74D5008BFA41@csperkins.org>
In-Reply-To: <BECD8057-0C87-4B33-A6A9-74D5008BFA41@csperkins.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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: Wed, 05 Oct 2011 12:06:23 -0000

On 10/04/2011 05:49 PM, Colin Perkins wrote:
> 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.
Will do. Thanks!
> 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".
I'll leave this to drafts that discuss codec negotiation, I think. The 
PeerConnection proposal for an API has no need to represent names or 
parameters of codecs independent of their SDP form; other proposals, 
such as the "Low level API" currently being discussed in WEBRTC, would 
have such a need.