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

From: Martin Thomson <[email-masked]>
Date: Fri, 12 Jul 2013 09:04:58 -0700

On 12 July 2013 00:35, Stefan Håkansson LK
<[email-masked]> 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.

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.

---

From: Stefan Håkansson LK <[email-masked]>
Date: Fri, 12 Jul 2013 17:27:43 +0000

> 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.

> to the chairs, that's not something I trust them to rule on at this

FWIW, I agree. This needs more discussion.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 12 Jul 2013 17:42:38 +0000

On Jul 12, 2013, at 9:04 AM, Martin Thomson <[email-masked]>
 wrote:

> With all respect

just to be clear, I don't think the RTCWeb chairs have done anything remotely close to a ruling on this. We have taken censuses calls on the use of 3264 O/A.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 12 Jul 2013 10:54:23 -0700

> just to be clear, I don't think the RTCWeb chairs have done anything remotely close to a ruling on this. We have taken censuses calls on the use of 3264 O/A.

I didn't mean to imply that a ruling has been made.  To a large
extent, we haven't even discussed the issue that no-plan represents.
That's a large part of where my concern derives from.

It's a tricky situation: chairs have to make rulings on the
appropriate venue for discussion, but when that ruling seems to be
predicated on having a technical decision, it creates a bind.

---

From: Emil Ivov <[email-masked]>
Date: Fri, 12 Jul 2013 20:28:18 +0200

Just to be clear: use of SDP O/A is precisely the intended topic of the
slot we are requesting.

--sent from my mobile
On Jul 12, 2013 7:42 PM, "Cullen Jennings (fluffy)" <[email-masked]>
wrote:

> just to be clear, I don't think the RTCWeb chairs have done anything
> remotely close to a ruling on this. We have taken censuses calls on the use
> of 3264 O/A.
>
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 12 Jul 2013 20:30:15 +0200

2013/7/12 Emil Ivov <[email-masked]>:
> Just to be clear: use of SDP O/A is precisely the intended topic of the slot
> we are requesting.

Do you mean "use or non-use of SDP O/A"?

--
Iñaki Baz Castillo
<[email-masked]>