Subject: [rtcweb] On transports and bundles

From: Adam Roach <[email-masked]>
Date: Thu, 26 Mar 2015 18:38:07 -0500

If we factor out all of the W3C API conversations from what was said 
today, I think the only real point of contention turns on this 
statement; not because it's wrong, but because it's incomplete (and 
creates ambiguity as a result):

    A receiving implementation MUST be able to receive media and data in
    all these configurations.

If we're going to make this statement, then we need to also say 
something about receiving bundle configurations that are more advanced 
than the two that we must be able to send.

I would argue that anything short of saying that we MUST support any 
valid description as described by 
draft-ietf-mmusic-sdp-bundle-negotiation would be creating a profile of 
bundle, and I believe that would be harmful. To that end, I think we 
either say that implementations MUST be able to handle any bundle 
configuration that is valid per the bundle draft, or we omit the 
statement I cite above and leave it to bundle to make statements around 
what it means to implement the protocol it defines.

I slightly prefer the latter approach.

/a

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 26 Mar 2015 16:51:40 -0700

I agree that the fundamental question is about what SDP the browser
accepts.  I would state the question thus: does SetLocalDescription and
SetRemoteDescription allow multiple BUNDLE groups?

In the spirit of "let's just finish 1.0", I'd be happy to throw multiple
BUNDLE groups out of 1.0.  But I realize I might be in the minority.

On Thu, Mar 26, 2015 at 4:38 PM, Adam Roach <[email-masked]> wrote:

> today, I think the only real point of contention turns on this statement;
> not because it's wrong, but because it's incomplete (and creates ambiguity
> as a result):
>
> If we're going to make this statement, then we need to also say something
> about receiving bundle configurations that are more advanced than the two
> that we must be able to send.
>
> I would argue that anything short of saying that we MUST support any valid
> description as described by draft-ietf-mmusic-sdp-bundle-negotiation
> would be creating a profile of bundle, and I believe that would be harmful.
> To that end, I think we either say that implementations MUST be able to
> handle any bundle configuration that is valid per the bundle draft, or we
> omit the statement I cite above and leave it to bundle to make statements
> around what it means to implement the protocol it defines.
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Adam Roach <[email-masked]>
Date: Thu, 26 Mar 2015 21:46:00 -0500

On 3/26/15 18:51, Peter Thatcher wrote:
> accepts.  I would state the question thus: does SetLocalDescription 
> and SetRemoteDescription allow multiple BUNDLE groups?
>
> In the spirit of "let's just finish 1.0", I'd be happy to throw 
> multiple BUNDLE groups out of 1.0.

The issue I have with that is that you're saying "we're doing bundle, 
*except*..." -- which means you're making a profile of it, making it 
only partially compatible with the protocol as specified. That's bad for 
interop with more advanced devices, and it's bad for forwards 
compatibility with whatever we do with later APIs.

/a

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 26 Mar 2015 21:27:37 -0700

On Thu, Mar 26, 2015 at 7:46 PM, Adam Roach <[email-masked]> wrote:

> BUNDLE groups out of 1.0.
>
>
> *except*..." -- which means you're making a profile of it, making it only
> partially compatible with the protocol as specified. That's bad for interop
> with more advanced devices, and it's bad for forwards compatibility with
> whatever we do with later APIs.
>

I believe what Martin said Firefox does right now is still interoperable
and forwards compatible:  unbundle the bundle groups other than the first.
 ​

​It's just not optimal for particular advanced use cases which can be
addresses separately after 1.0.  And I'm OK with that.

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 27 Mar 2015 16:41:08 +0100

On 03/27/2015 12:38 AM, Adam Roach wrote:
> draft-ietf-mmusic-sdp-bundle-negotiation would be creating a profile
> of bundle, and I believe that would be harmful. To that end, I think
> we either say that implementations MUST be able to handle any bundle
> statement I cite above and leave it to bundle to make statements

"Support any valid configuration" can be read two ways:

A - The bundling proposal MUST result in the bundling the offerer suggested
B - The bundling proposal MUST result in a state that is legal by BUNDLE
rules

I think we're all in agreement that we want to mandate support in sense B.

When I wrote the text, I was intending sense A for the fully-bundled and
fully-unbundled cases.

I don't think this creates a profile of BUNDLE.
I think we agree on the state we want, it's just a matter of getting the
text to say that...

-- 
Surveillance is pervasive. Go Dark.

---

From: Adam Roach <[email-masked]>
Date: Fri, 27 Mar 2015 11:03:51 -0500

> I think we're all in agreement that we want to mandate support in sense B.

Yes, what I'm asking for is B.

> I think we agree on the state we want, it's just a matter of getting the

Right. I agree that what you've described in this email makes sense, and 
we just need to turn that sentiment into document prose.

/a

---

From: Peter Thatcher <[email-masked]>
Date: Fri, 27 Mar 2015 11:21:59 -0500

> Yes, what I'm asking for is B.

I believe B is the same as allowing the browser to unbundle the bundle
groups other than the first.  Is that correct?

Would it also allow a browser to say "BUNDLE everything or BUNDLE nothing"
by unbundling everything if it sees SDP with more than one bundle group?