Return-Path: 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 C697321F8C1D for ; Tue, 9 Aug 2011 17:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] 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 PDwlvNv8YbEF for ; Tue, 9 Aug 2011 17:59:13 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 14A3221F8B37 for ; Tue, 9 Aug 2011 17:59:13 -0700 (PDT) Received: by ywm21 with SMTP id 21so413214ywm.31 for ; Tue, 09 Aug 2011 17:59:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type; bh=ZC1NlugxOxQhzzYBpneqNW2xl6BXEzRVUaagfUr3nnU=; b=weYBABN4JBYTRzdLtfgDgClbrTCOjDr270GDYie5q9MGVJfFcOG4HggR99jBR0vybJ ZhoCN9XmkbrXdRKQyyudrUuXehMhE1Y6QsK2xSZ+LHy1PBDn5LRh2A/UOiLI82RyJwqN kYVjuAgC8czPHUSeiwopXSAKFrTLAv1uwlSjo= Received: by 10.150.13.16 with SMTP id 16mr7882249ybm.279.1312937983028; Tue, 09 Aug 2011 17:59:43 -0700 (PDT) Received: from [192.168.15.2] (cpe-76-184-227-249.tx.res.rr.com [76.184.227.249]) by mx.google.com with ESMTPS id g16sm307890ybi.8.2011.08.09.17.59.39 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 09 Aug 2011 17:59:40 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Tue, 09 Aug 2011 19:59:38 -0500 From: Henry Sinnreich To: Bernard Aboba , Message-ID: Thread-Topic: [rtcweb] codec and connection negotiation Thread-Index: AcxW+McmCOtuablVfE2IM81ihE8z5w== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3395764779_2078863" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 00:59:13 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3395764779_2078863 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Leaving all the problems behind mentioned here for SDP (in full agreement), the bigger picture is that apps may have so many other types of data to exchange, besides codecs. For example numbers, sizes and types of screens, keyboard/touch devices to optimize user experience, data for mashup parts of the screen, say surround sound(?), etc. Folks not wedded to SDP use metadata to exchange app info. Why should RTC continue to inhabit a world of its own, even in the browser? Na=EFve question: Does this separate use of SDP to convey RTC metadata not contradict the target universality of apps in the browser? Thanks, Henry On 8/9/11 12:18 PM, "Bernard Aboba" wrote: > Paul Kyzivat said: >=20 >> > Certainly it would be possible to provide an API that had something >> > semantically equivalent to SDP while using a different syntax. But tha= ta >> > comes at the price of having to then track future extensions to SDP. >> >=20 >> > 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. >> >=20 >> > (It gets worse if you decide to "add a few things" to the API that >> > aren't part of standard SDP.) >=20 > [BA] Given the discussion of IETF 81, my concern is that the API is base= d 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. >=20 > The danger in continuing down that road is that different implementation= s > 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. > =20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --B_3395764779_2078863 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [rtcweb] codec and connection negotiation Leaving all the problems behind mentioned here for SDP (in full agreement)= , the bigger picture is that apps may have so many other types of data to ex= change, besides codecs.
For example numbers, sizes and types of screens, keyboard/touch devices to = optimize user experience, data for mashup parts of the screen, say surround = sound(?), etc.
Folks not wedded to SDP use metadata to exchange app info. Why should RTC c= ontinue to inhabit a world of its own, even in the browser?

Naïve question:
Does this separate use of SDP to convey RTC metadata not contradict the tar= get universality of apps in the browser?

Thanks, Henry


On 8/9/11 12:18 PM, "Bernard Aboba" <bernard_aboba@hotmail.com> wrote:

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 tha= ta
> 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 <= BR> > 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 AP= I that
> aren't part of standard SDP.)

[BA]  Given the discussion of IETF 81, my concern is that the API is b= ased on  an SDP and ICE profile that is implicit and not explicit. &nbs= p;  In a number of cases, it would appear that this implicit profi= le may ignore normative requirements (including MUSTs) in RFC 3264, 5245 and= other relevant RFCs.  

The danger in continuing down that road is  that different implementat= ions 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.   
       

___________________= ____________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org= /mailman/listinfo/rtcweb
--B_3395764779_2078863--