Re: [rtcweb] Draft agenda for IETF 87

Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> Sat, 13 July 2013 18:39 UTC

Return-Path: <stefan.lk.hakansson@ericsson.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 865AD21F9DDC for <rtcweb@ietfa.amsl.com>; Sat, 13 Jul 2013 11:39:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.425
X-Spam-Level:
X-Spam-Status: No, score=-3.425 tagged_above=-999 required=5 tests=[AWL=-1.126, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
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 zEbxFh-z9QMx for <rtcweb@ietfa.amsl.com>; Sat, 13 Jul 2013 11:39:21 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id DA0A821F9DED for <rtcweb@ietf.org>; Sat, 13 Jul 2013 11:39:20 -0700 (PDT)
X-AuditID: c1b4fb38-b7f456d000002e83-8f-51e19ed4b7c8
Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 1B.32.11907.4DE91E15; Sat, 13 Jul 2013 20:39:16 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0328.009; Sat, 13 Jul 2013 20:39:16 +0200
From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
To: Peter Thatcher <pthatcher@google.com>
Thread-Topic: [rtcweb] Draft agenda for IETF 87
Thread-Index: AQHOflbnoSh5pMdyC0qq6yOZjrenEA==
Date: Sat, 13 Jul 2013 18:39:16 +0000
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C3134DB@ESESSMB209.ericsson.se>
References: <CA+9kkMBuCTdFsUMtmuBz6BnrSJMpHywEZU+x+m8ARnGprvzDzA@mail.gmail.com> <CAPvvaa+dyYmvsareEy1a9+7ketEFjNarsnRLXkpT_YHPTYni2w@mail.gmail.com> <C5E08FE080ACFD4DAE31E4BDBF944EB1135D31FD@xmb-aln-x02.cisco.com> <CABkgnnU9r9OT+XW=Ewf=25yBJGCEZxCVnu_r1D=Eu=f9wrV4Kg@mail.gmail.com> <1447FA0C20ED5147A1AA0EF02890A64B1C311367@ESESSMB209.ericsson.se> <CAJrXDUGg0mVgZMzYWkD7gfRrTVczf9zk6+LLvyZ8Vkci1Qn9Zw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.148]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyM+Jvre6VeQ8DDd6cNbXomMxmce3MP0aL a8tfs1qs/dfO7sDiMeX3RlaPnbPusnss2FTqsWTJT6YAligum5TUnMyy1CJ9uwSujOsv/zAX 3NKveLjhIVsD41rVLkZODgkBE4neh2dZIWwxiQv31rN1MXJxCAkcZZTYefwuO4SziFHi/p8T TCBVbAKBElv3LWADsUUENCUmT24G62YWaGWUWHRFsYuRg0NYQE9iTkMkiCkioC/xebMxRLWe RP+BTcwgNouAqsTFnm9gnbwCvhIP/p9hhVi1hlniyNQZjCAJRqCDvp9awwQxXlzi1pP5TBCH Ckgs2XOeGcIWlXj5+B/UA0oSjUueQJ2jJ3Fj6hQ2CFtbYtnC18wQywQlTs58wjKBUXQWkrGz kLTMQtIyC0nLAkaWVYwcxanFSbnpRgabGIERc3DLb4sdjJf/2hxilOZgURLn3aJ3JlBIID2x JDU7NbUgtSi+qDQntfgQIxMHp1QDIzvXN8UkCdN9Npvfrlr/YRqfTdt3w8YWDeVHkdu4bJyn aGcKP51RKSmp2h8b1/PtpfW0hHNZjDWeNQtuKZ/ax15aWDJphSfb6h+qHa5L3C9eupLmarWp 2ujNevHC6DP3r4bLi/JvnZT0W2qSVv/5K2wn2l477/O0TmlX9tCdoix42/dsYdgbJZbijERD Leai4kQAL4tXCGYCAAA=
Cc: "Cullen Jennings (fluffy)" <fluffy@cisco.com>, "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Draft agenda for IETF 87
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: Sat, 13 Jul 2013 18:39:26 -0000

On 7/12/13 7:19 PM, Peter Thatcher wrote:
>
>
>
> On Fri, Jul 12, 2013 at 12:35 AM, Stefan Håkansson LK
> <stefan.lk.hakansson@ericsson.com
> <mailto:stefan.lk.hakansson@ericsson.com>> wrote:
>
>     On 7/11/13 9:38 PM, Martin Thomson wrote:
>      > On 11 July 2013 12:04, Cullen Jennings (fluffy) <fluffy@cisco.com
>     <mailto:fluffy@cisco.com>>
>      > wrote:
>      >> On Jul 11, 2013, at 10:35 AM, Emil Ivov <emcho@jitsi.org
>     <mailto:emcho@jitsi.org>>
>      >>> In you last mail on the subject you mentioned that we will be
>      >>> discussing No Plan in Berlin together with plans A and B. Could
>      >>> we please add this to the agenda?
>      >>
>      >> No. We believe that conversation needs to happen in the W3C WebRTC
>      >> WG. I expect to see a message from W3C chairs on this at some
>      >> point.
>      >
>      > I'm a little nervous about this.  Where does the decision on the
>      > separation of responsibilities (API vs. SDP) get made?
>
>     (I have not been able to confer with any of the other chairs, so this is
>     just my personal opinion):
>
>     To me it seems pretty straightforward to a certain point:
>
>     * The SDP (if we opt to continue using SDP for this purpose) that goes
>     on the signaling wire between the browsers is defined by IETF (and by
>     the rtcweb WG I presume even though MMUSIC seems to have some stake)
>
>     * JS APIs to:
>     ** Apply an SDP (e.g. received on the signaling channel) to the browser
>     ** Hand an SDP generated by the browser over to the application (for
>     transmission over the signaling wire presumably)
>     ** Influencing/modifying the contents of the SDP
>     * All belongs to the W3C WebRTC
>
>
> Would it make sense to change this list to say the following?
>
> * JS APIs to:
> ** Apply a SessionDescription (created by SDP; eg received on the
> signaling channel or built by JS) to the browser
> ** Hand a SessionDescription (serializable to SDP) generated by the
> browser over to the application (for
> transmission over the signaling wire presumably or for immediately
> applying with setLocalDescription for some local effect)
> ** Influencing/modifying the contents of the SessionDescription (and
> thus, SDP, when serialized to SDP)
> * All belongs to the W3C WebRTC

That might well be a better way to put it.

>
>
> My changes highlight a few things:
> 1.  The API (setLocalDescripiton, setRemoteDescription, creatOffer, etc)
> doesn't work with SDP directly.  It works with RTCSessionDescription
> objects.  It just happens to be that currently the only way to interact
> with RTCSessionDescription objects is through SDP.  I think it's worth
> remembering that distinction.
>
> 2.  SDP does not necessarily go over the wire.   It only necessarily
> goes through the API between JS and browser.   I think it's worth
> remembering that distinction.
>
> 3.  Calling setLocalDescription with a new SessionDescription object can
> have purely local effects that don't need to be sent over the wire.  I
> think it's worth remembering those cases.
>
>
>     What seems unclear to me is where we define what modifications to the
>     SDP that are allowed - and when. Even though the ambition is to have
>     APIs that makes SDP mangling an exception, we will still see that
>     happening.
>
>
> I think advanced JS apps are going to use every control knob they can
> get to, whether it's anticipated and well-supported or not.    I think
> there's a good chance that a a popular WebRTC web app will use some SDP
> mangling that wasn't anticipated, but happened to work, but then the
> browser can't remove it because it will break certain websites.  It
> could get even worse if someone writes a popular WebRTC wrapper library
> that uses tricky SDP mangling that is then used by lots of websites.
>   Certain SDP mangling techniques might end up becoming a defacto
> standard API that can't be removed, even if it was originally a bug.  Or
> worse, one browser will have to implement the SDP mangling or even the
> bugs of another, because WebRTC apps have come to rely on them.
>
> In fact, it's already the case that Chrome and Firefox support far
> different SDP manglings.  I don't think any web apps rely on that yet,
> but it's only a matter of time before someone figures out "hey, if I
> mangle the SDP on this browser this way and on that browser that way, I
> can do things I couldn't do otherwise".  Or worse, an advanced web app
> developer says "hey, I can make this work well on browser X via SDP
> mangling, but not on browser Y, so I'll put a 'best used with Browser X'
> icon on my website". Then that someone writes an abstraction on top of
> that, and then maybe shares that with others, and it goes from there.
>
> I think we're in a race with web developers to see if they'll figure out
> SDP mangling before we provide a way to avoid SDP mangling.   Who do you
> think moves faster?

Let's go over to the public-webrtc W3C space and work on this.

>
>
>
>
>
>
>
>
>      > _______________________________________________ rtcweb mailing list
>      > rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>     https://www.ietf.org/mailman/listinfo/rtcweb
>      >
>
>     _______________________________________________
>     rtcweb mailing list
>     rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>     https://www.ietf.org/mailman/listinfo/rtcweb
>
>