Subject: [MMUSIC] Draft new version: BUNDLE-40

From: Christer Holmberg <[email-masked]>
Date: Mon, 20 Nov 2017 11:12:00 +0000

Ladies and Gentlemen,

I have submitted a new version (-40) of BUNDLE.

The new version contains a number of editorial changes (based on the PRs that have been announced on the list). It also introduces the “BUNDLE transport” concept. And, it clarifies that an m- section can not be directly moved from one group to another.

I know there are still editorial changes that people would have liked to done. But, we can’t go on doing editorial changes forever, so my suggestion is that we now do the publication request, and then we’ll deal with whatever changes are to be done based on the IESG reviews etc.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 Nov 2017 17:58:13 -0500

On 11/20/17 6:12 AM, Christer Holmberg wrote:
> The new version contains a number of editorial changes (based on the PRs 
> that have been announced on the list). It also introduces the “BUNDLE 
> transport” concept. And, it clarifies that an m- section can not be 
> directly moved from one group to another.
> 
> I know there are still editorial changes that people would have liked to 
> done. But, we can’t go on doing editorial changes forever, so my 
> suggestion is that we now do the publication request, and then we’ll 
> deal with whatever changes are to be done based on the IESG reviews etc.

I was intimidated by the volume of changes in this version. But while 
that makes re-reviewing it more difficult I am generally happy with the 
results.

I'm fine with new editorial changes being handled during post 
publication request processing. I offer the following to be handled 
whenever:

* Section 8.3.1:

    If all of the criteria above are fulfilled, the answerer MUST select
    the address assigned to the "m=" section as the offerer BUNDLE
    address.  In the answer, the answerer BUNDLE-tag represents the "m="
    section, and the address assigned to the "m=" section in the offer
    becomes the offerer BUNDLE address.

I'm having trouble following this. It feels to me that it doesn't quite 
say what I think it intends/needs to say. How about the following:

    If all of the criteria above are fulfilled, the answerer MUST accept
    the address assigned to that "m=" section as the offerer BUNDLE
    address.  In the answer, the answerer BUNDLE-tag MUST identify the
    corresponding "m=" section in the answer.

There is still a bit of semantic trouble with this. The problem is that 
(as defined in the terminology section) the Offerer BUNDLE-tag and 
Offerer BUNDLE address are defined solely by the offer. But when the 
answerer is processing the offer, it may reject the section associated 
with those and choose a different tag and address as the Offerer 
BUNDLE-tab and Offerer BUNDLE address. There really is no terminology 
for those.

Effectively the offerer supplies a list of tags that serve as a priority 
list for which tag and address will become the Offerer BUNDLE-tag and 
Offerer BUNDLE address. But it is the answered who makes the final 
decision, and then signals it back to the offerer via the Answerer 
BUNDLE-tag. This also impacts the language in section 8.4.

A way to alter the text to say this simply doesn't come to me right now.

* Section 8.5:

In the case of sections that were bundle-only in the initial offer, 
should bundle-only still be included in the new offer? (Section 6 says 
that they are not required, but doesn't ban them.)

In general it is unclear to me when/how bundle-only is to be used in 
subsequent o/a exchanges.

- It seems that it may be appropriate when sending an offer that adds a 
new m= section.

- Perhaps when offering a change in BUNDLE address, if in this case 
unique addresses are used for some/all of the bundled m= sections.

Are those the only cases when it should be used?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 Nov 2017 13:09:31 +0000

Hi Paul,

...

>(as defined in the terminology section)
> the Offerer BUNDLE-tag and Offerer BUNDLE address are > defined solely
>by the offer. But when the answerer
> is processing the offer, it may reject the section associated with those
>and choose a different tag and address as
> the Offerer BUNDLE-tab and Offerer BUNDLE address. There really is no
>terminology for those.
>
>list for which tag and address will become the
> Offerer BUNDLE-tag and Offerer BUNDLE address. But it is the answered
>who makes the final decision, and then
> signals it back to the offerer via the Answerer BUNDLE-tag. This also
>impacts the language in section 8.4.
>

------------

>should bundle-only still be included in
> the new offer? (Section 6 says that they are not required, but doesn't
>ban them.)
>

It has been suggested that, in subsequent offers, each bundled m- section
(except the one carrying the BUNDLE address) would use bundle-only. That
way we would not have to talk about "shared address² - we would simply say
that the "BUNDLE address" is assigned to the m= section associated with
the identification-tag.

After all, many SDP attributes are only placed in that m= section, so why
should the address and port be any different.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Nov 2017 10:02:02 -0500

> should the address and port be any different.

That is an interesting idea.

But would that prevent you from moving an m= section out of a bundle 
group after it has been accepted into the group?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 Nov 2017 15:08:16 +0000

Hi,

>group after it has been accepted into the group?

Yes. You would simply send a new offer, where you assign a unique address
to that m= section, and assign the BUNDLE address to another m= section
within the BUNDLE group.

Of course, even with bundle-only, you still assign the address to the m=
section, but with a zero port value.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 27 Nov 2017 13:03:16 +0000

Hi Paul,

I realised that I forgot to address the issue below in version -41.

>    corresponding "m=" section in the answer.

Maybe something like:

"If all of the criteria above are fulfilled, the answerer MUST accept
    the address assigned to that "m=" section as the offerer BUNDLE
    address.  In the answer, the answerer MUST assign the answerer BUNDLE
Address to the corresponding ³m=³ section, and the answerer BUNDLE-tag
MUST identify that ³m=³ section."

Šwhich makes me wonder whether we really need section 8.3.2. At least the
first paragraph is covered by the second sentence above, in my opinion.

>A way to alter the text to say this simply doesn't come to me right now.

One way would be to say that the answerer must either accept the offerer
BUNDLE address, or reject the BUNDLE group.

That way the offerer is able to choose what address to use if the BUNDLE
group is created, and the procedures would be more simply. Whether it¹s
too restrictive, I don¹t know...

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 28 Nov 2017 10:55:49 +0000

Hi,

I created a small PR, which hopefully clarifies the offerer/answerer
BUNDLE address selection procedure.

https://github.com/cdh4u/draft-sdp-bundle/pull/46

Regards,

Christer

On 27/11/17 15:03, "mmusic on behalf of Christer Holmberg"
<[email-masked] on behalf of [email-masked]>
wrote:

>_______________________________________________
>mmusic mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mmusic