Re: [rtcweb] codec and connection negotiation

Bernard Aboba <bernard_aboba@hotmail.com> Tue, 09 August 2011 17:17 UTC

Return-Path: <bernard_aboba@hotmail.com>
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 028FB21F8CD2 for <rtcweb@ietfa.amsl.com>; Tue, 9 Aug 2011 10:17:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Level:
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 V+iVrS9fxjyE for <rtcweb@ietfa.amsl.com>; Tue, 9 Aug 2011 10:17:53 -0700 (PDT)
Received: from blu0-omc3-s37.blu0.hotmail.com (blu0-omc3-s37.blu0.hotmail.com [65.55.116.112]) by ietfa.amsl.com (Postfix) with ESMTP id F309B21F8CC4 for <rtcweb@ietf.org>; Tue, 9 Aug 2011 10:17:52 -0700 (PDT)
Received: from BLU152-W45 ([65.55.116.74]) by blu0-omc3-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Aug 2011 10:18:22 -0700
Message-ID: <BLU152-W4535B24419D30E60FB9F3793200@phx.gbl>
Content-Type: multipart/alternative; boundary="_7c5e39c7-f338-48c9-872c-bec902cec30f_"
X-Originating-IP: [74.92.226.89]
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: pkyzivat@alum.mit.edu
Date: Tue, 09 Aug 2011 10:18:21 -0700
Importance: Normal
In-Reply-To: <4E41634B.2000001@alum.mit.edu>
References: <4E3C377A.5090105@skype.net> <4E3C3C2C.4020808@skype.net>, <4E3FE002.4060006@alvestrand.no>, <4E40335A.3090204@alum.mit.edu> <BLU152-W814CABC63B3BA452802C193200@phx.gbl>, <4E41634B.2000001@alum.mit.edu>
MIME-Version: 1.0
X-OriginalArrivalTime: 09 Aug 2011 17:18:22.0072 (UTC) FILETIME=[57037F80:01CC56B8]
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] codec and connection negotiation
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, 09 Aug 2011 17:17:55 -0000

Paul Kyzivat said: 
> Certainly it would be possible to provide an API that had something 
> semantically equivalent to SDP while using a different syntax. But thata 
> comes at the price of having to then track future extensions to SDP.
> 
> An alternative is to profile/subset SDP and then perhaps develop a new 
> representation semantically equivalent to that. The trouble with that is 
> interoperation with things that don't fit the subset. Going that way 
> will probably require making it pretty easy to extend the subset when 
> things that had been excluded are found to be needed.
> 
> (It gets worse if you decide to "add a few things" to the API that 
> aren't part of standard SDP.)

[BA]  Given the discussion of IETF 81, my concern is that the API is based on  an SDP and ICE profile that is implicit and not explicit.    In a number of cases, it would appear that this implicit profile may ignore normative requirements (including MUSTs) in RFC 3264, 5245 and other relevant RFCs.  
The danger in continuing down that road is  that different implementations will make different assumptions about the profile, and the result will be implementations that are not only incompatible with each other, but also with existing implementations of the wire protocols.