Re: [rtcweb] Draft agenda for IETF 87

Stefan Håkansson LK <> Fri, 12 July 2013 07:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5350C21F9E3F for <>; Fri, 12 Jul 2013 00:35:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.234
X-Spam-Status: No, score=-5.234 tagged_above=-999 required=5 tests=[AWL=0.715, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SZQimfZpYhZ9 for <>; Fri, 12 Jul 2013 00:35:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8146F21F9E3C for <>; Fri, 12 Jul 2013 00:35:02 -0700 (PDT)
X-AuditID: c1b4fb30-b7ef76d000004bbc-9e-51dfb1a4bb6c
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 11.B0.19388.4A1BFD15; Fri, 12 Jul 2013 09:35:01 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.02.0328.009; Fri, 12 Jul 2013 09:35:00 +0200
From: Stefan Håkansson LK <>
To: Martin Thomson <>
Thread-Topic: [rtcweb] Draft agenda for IETF 87
Thread-Index: AQHOflbnoSh5pMdyC0qq6yOZjrenEA==
Date: Fri, 12 Jul 2013 07:35:00 +0000
Message-ID: <>
References: <> <> <> <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+Jvre7SjfcDDdYvYrHomMxmce3MP0aL tf/a2R2YPab83sjqsXPWXXaPJUt+MgUwR3HZpKTmZJalFunbJXBlvHl3kb1gE1/F43+zWRoY 73F3MXJySAiYSHycNJkFwhaTuHBvPVsXIxeHkMBhRolbb1awQziLGCXurO5iA6liEwiU2Lpv AZgtIqArsejsA3YQm1kgSmLHph6mLkYODmEBPYk5DZEgpoiAvsTnzcYQ1XoS/Qc2MYPYLAKq Ej9n3AObwivgK9H0fxsTxKqFTBJ/3vUzgiQYgQ76fmoNE8R4cYlbT+YzQRwqILFkz3lmCFtU 4uXjf6wQtpLEjw2XWCDq9SRuTJ3CBmFrSyxb+JoZYpmgxMmZT1gmMIrOQjJ2FpKWWUhaZiFp WcDIsoqRPTcxMye93HwTIzA6Dm75bbCDcdN9sUOM0hwsSuK8m/XOBAoJpCeWpGanphakFsUX leakFh9iZOLglGpglFLhD3R5xOUk5Do1capvmvjmjpKIp3NqurXdFF2fSB4WdxPvXsVruMuj 7P5st1Wvhd59atA1SWGdcTb5ro3ghZaPYWqNL4s3aat1Jv3knvd95peA7D0Hp3Ob+qftDp5+ rWb3uTMMvxu71h65yfAt3Vews5fRYvHE/Zu2forZ5JsTxPJacN15JZbijERDLeai4kQASc8E j1wCAAA=
Cc: "Cullen Jennings (fluffy)" <>, "<>" <>
Subject: Re: [rtcweb] Draft agenda for IETF 87
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: Fri, 12 Jul 2013 07:35:12 -0000

On 7/11/13 9:38 PM, Martin Thomson wrote:
> On 11 July 2013 12:04, Cullen Jennings (fluffy) <>
> wrote:
>> On Jul 11, 2013, at 10:35 AM, Emil Ivov <>
>>> 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

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

> _______________________________________________ rtcweb mailing list