Re: [rtcweb] division of responsibilities (was: Draft agenda for IETF 87)

Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> Fri, 12 July 2013 17:27 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 5F09521F9E40 for <rtcweb@ietfa.amsl.com>; Fri, 12 Jul 2013 10:27:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.213
X-Spam-Level:
X-Spam-Status: No, score=-5.213 tagged_above=-999 required=5 tests=[AWL=0.736, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
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 Zu9JzjRXAmfH for <rtcweb@ietfa.amsl.com>; Fri, 12 Jul 2013 10:27:48 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id AC28C21F9FEA for <rtcweb@ietf.org>; Fri, 12 Jul 2013 10:27:47 -0700 (PDT)
X-AuditID: c1b4fb25-b7f826d000001766-df-51e03c8f0e14
Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id DD.3B.05990.F8C30E15; Fri, 12 Jul 2013 19:27:43 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0328.009; Fri, 12 Jul 2013 19:27:43 +0200
From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= <stefan.lk.hakansson@ericsson.com>
To: Martin Thomson <martin.thomson@gmail.com>
Thread-Topic: division of responsibilities (was: Draft agenda for IETF 87)
Thread-Index: AQHOfxmP+iu/sYlzgUm8j1W7o4aRzQ==
Date: Fri, 12 Jul 2013 17:27:43 +0000
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C3128C7@ESESSMB209.ericsson.se>
References: <CABkgnnUBdarwAoz=41_Nz1WSdYJ8gXUjxkggwFomHiC-efiN_w@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.146]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyM+JvrW6/zYNAg1P9ShYdk9ksrp35x2ix 9l87uwOzx5TfG1k9ds66y+6xZMlPpgDmKC6blNSczLLUIn27BK6M7r/WBf8EK1b8u8fawLib r4uRg0NCwERixkqjLkZOIFNM4sK99WxdjFwcQgKHGSV2Xb4B5SxilJjfsoUFpIpNIFBi674F bCC2iICuxKKzD9hBbGaBKIkdm3qYQGxhAU+JZ3+eMUHUeEls+dvCDmHrSeyaMo8ZxGYRUJVY OeM8I4jNK+Ar0XPqKiuILSQQILFxzgOw+YxAF30/tYYJYr64xK0n85kgLhWQWLLnPDOELSrx 8vE/VghbSeLHhkssEPV6EjemTmGDsLUlli18zQyxS1Di5MwnLBMYRWchGTsLScssJC2zkLQs YGRZxciem5iZk15utIkRGBsHt/xW3cF455zIIUZpDhYlcd7NemcChQTSE0tSs1NTC1KL4otK c1KLDzEycXBKNTCmmfxK/H3jju5kvksuu1YoGjqeuLnjauir80w/Fl6byG/Ifydo1c7i5OnC 2RK7TuTtM8vQbChLz75z+s/jBkEttm0OFtLWu7NXWK3762Ge8SH12L8o1v67Uw+JNOSy9qRp Vk2fXxqTsatu9poAWd3s6bmGf8/EBzDtq5++9Xgrh92n/T9+3t6qxFKckWioxVxUnAgArBh1 bVsCAAA=
Cc: "Cullen Jennings \(fluffy\)" <fluffy@cisco.com>, "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: Re: [rtcweb] division of responsibilities (was: 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: Fri, 12 Jul 2013 17:27:54 -0000

On 7/12/13 6:04 PM, Martin Thomson wrote:
> On 12 July 2013 00:35, Stefan Håkansson LK
> <stefan.lk.hakansson@ericsson.com> wrote:
>> 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
>>
>> 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 can see how you would reach that conclusion, but it's only simple at
> the most superficial level.
>
> There needs to be a clear understanding about what information is
> carried in SDP and what information is supplied by the application.  I
> have observed that there is an assumption implicit in a lot of the
> work that says that SDP carries everything it can possibly carry.
> I'll note that this has been implicit, never explicit.  And the mere
> existence of no-plan highlights the fact that there is a fundamental
> disagreement on this point.

This is a very good point IMO. You have brought it up before, and I 
think it is very valid. We need to decide what info is carried over

* in SDP (if SDP is kept)
* in RTP/RTCP
* in any other means we standardize

and what is supplied by the application.

>
> We've been building a consensus that is based on an assumption.  I'd
> rather we had consensus than an untested assumption.  With all respect
> to the chairs, that's not something I trust them to rule on at this
> point.

FWIW, I agree. This needs more discussion.

>