Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Terminology

["Stach, Thomas" <[e-mail]>]

Christer,

> -----Original Message-----
> From: Christer Holmberg [mailto:[e-mail]]
> Sent: Montag, 3. November 2014 13:21
> To: Stach, Thomas; Paul Kyzivat
> Cc: 'mmusic'
> Subject: RE: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 -
> Terminology
> 
> 
> Hi,
> 
> I started to go through BUNDLE, to look for the impacts due to changing "mid"
> to "tag".
> 
> The list below is not complete, but it does give a good picture of the
> impacts.
> 
> One question is whether we want to say "SDP 'mid' attribute identification-tag
> value" or just "SDP 'mid' attribute value".
 
Well, "SDP 'mid' attribute identification-tag value" is a bit lengthy.
Alternatively, you may just call it "identification-tag" and define the term 
in your terminology section. E.g. as

	Identification-tag: A unique token that is used to identify an m-line. 
	The SDP 'mid' attribute [RFC5888], associated to a "m=" line, carries 
	an unique identification-tag. The session-level SDP 'group' attribute 
	[RFC5888] carries a list of identification-tags that form the corresponding group.

You could then simplify the new text as proposed below 

> 
> Regards,
> 
> Christer
> 
> -----------------
> 
> 
> OLD:
> 
>		Offerer suggested BUNDLE mid: The first mid value in a given
>		SDP 'group:BUNDLE' attribute mid list in an offer.
> 
> NEW:
> 
>		Offerer suggested BUNDLE tag: The first value in a given
>		SDP 'group:BUNDLE' attribute identification-tag list in an offer.
> 
> 
> 
> OLD:
> 
>		Bundled "m=" line: An "m=" line, whose SDP 'mid' attribute value
>		is placed in a SDP 'group:BUNDLE' attribute mid value list in an
>		offer or answer.
> 
> NEW:
> 
> 		Bundled "m=" line: An "m=" line, whose SDP 'mid' attribute value
>		is placed in a SDP 'group:BUNDLE' attribute identification-tag list in an
>		offer or answer.	

		Bundled "m=" line: An "m=" line, whose identification-tag
		is placed in identification-tag list of a SDP 'group:BUNDLE' attribute.

... or you might also consider giving a bit more context 

		Bundled "m=" line: An "m=" line that shares the transport address with 
		other "m=" lines after a corresponding offer/answer negotiation. 
		The bundled "m=" line can be identified via the identification-tag in the 
		associated SDP 'mid' attribute. That identification-tag will also be found  
		in the identification-tag list of the SDP 'group:BUNDLE' attribute.

> 
> 
> OLD:
> 
> 		The BUNDLE extension is indicated using an SDP 'group' attribute
>		with a "BUNDLE" semantics value <xref> format="default" pageno="false"
>		target="RFC5888"/>. An SDP "mid" attribute is assigned to each
>		bundled "m=" line, and the "mid" attribute value is listed in the
>		'group:BUNDLE' attribute mid value list. Each "m=" line, whose mid
>		value is listed in the mid value list, is associated with a given BUNDLE
> 		group.
> 
> NEW:
> 
> 		The BUNDLE extension is indicated using an SDP 'group' attribute
> 		with a "BUNDLE" semantics value <xref> format="default" pageno="false"
>		target="RFC5888"/>. An SDP "mid:" attribute is assigned to each
>		bundled "m=" line, and the "mid" attribute identification-tag value is listed in the
>		'group:BUNDLE' attribute identification-tag list. Each "m=" line, whose identification-tag
>		value is listed in the identification-tag list, is associated with a given BUNDLE
> 		group.
Alt. NEW 

 		The BUNDLE extension is indicated using an SDP 'group' attribute
 		with the semantics field set to "BUNDLE" <xref> format="default" pageno="false"
		target="RFC5888"/>. An SDP "mid:" attribute is assigned to each
		bundled "m=" line, and each identification-tag is listed in the
		identification-tag list of the 'group' attribute. Each "m=" line, whose identification-tag
		is listed in the identification-tag list, is associated with a given BUNDLE group.	
> 
> 
> OLD:
> 		Place the SDP 'mid' attribute value <xref> target="RFC5888" pageno="false" format="default"/>
>		of each bundled "m=" line to the SDP 'group:BUNDLE' attribute mid value list; and
> 
> 
> NEW:
> 
>		Place the SDP 'mid' attribute identification-tag value <xref target="RFC5888" pageno="false" format="default"/>
>		of each bundled "m=" line to the SDP 'group:BUNDLE' attribute identification-tag list; and
Alt. New
		Include the identification-tag of each bundled "m=" line in the identification-tag list of SDP 'group' attribute; and
> 
> OLD:
> 
> 		If all of the criteria is not fulfilled, the answerer MUST select the next mid
>		value in the mid list, and perform the same criteria check for the "m=" line
>		associated with that mid value. If there are no more mid values in the mid list,
>		the answerer MUST NOT create the BUNDLE group.
> 
> NEW:
> 
> 		If all of the criteria is not fulfilled, the answerer MUST select the next
>		value in the identification-tag list, and perform the same criteria check for the "m=" line
>		associated with that value. If there are no more values in the identification-tag list,
>		the answerer MUST NOT create the BUNDLE group.

The proposed change looks good, but shouldn't the sentence start with 
"If one of the criteria is not fulfilled, ..."

> 
> OLD:
> 
>		In addition, in either case above, the answerer MUST NOT include a mid value, associated
>		with the moved "m=" line, in the SDP 'group:BUNDLE' attribute mid list associated
>		with the BUNDLE group.
> 
> 
> NEW:
> 
>		In addition, in either case above, the answerer MUST NOT include an SDP mid attribute identification-tag value, associated
>		with the moved "m=" line, in the SDP 'group:BUNDLE' attribute identification-tag list associated
>		with the BUNDLE group.
Alt. NEW
		In addition, in either case above, the answerer MUST NOT include the identification-tag, associated
		with the moved "m=" line, in the identification-tag list of the corresponding SDP 'group' attribute.

> 
> Etc etc etc.
Yes, there is more but from a simple search/replace for 
/mid value/SDP 'mid' attribute value/SDP "mid" attribute value/ --> /identification-tag/
I haven't found too much more editorial impact. At least section 13 seems to be straightforward.

Regards
Thomas

> 
> 
> -----Original Message-----
> From: Stach, Thomas [mailto:[e-mail]]
> Sent: 01 November 2014 11:00
> To: Paul Kyzivat; Christer Holmberg
> Cc: 'mmusic'
> Subject: RE: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 -
> Terminology
> 
> Paul,
> 
> > -----Original Message-----
> > From: Paul Kyzivat [mailto:[e-mail]]
> > Sent: Freitag, 31. Oktober 2014 19:31
> > To: Christer Holmberg; Stach, Thomas
> > Cc: 'mmusic'
> > Subject: Re: WGLC comments on
> > draft-ietf-mmusic-sdp-bundle-negotiation-12 - Terminology
> >
> > On 10/25/14 10:31 AM, Christer Holmberg wrote:
> > > Hi,
> > >
> > > I'd like to hear Paul's opinions on this, because he is the one who
> > > suggested the current terminology.
> >
> > Sorry to be so slow responding.
> >
> > I've looked back at the thread, and I am not entirely clear what the
> > proposal is. In part it is replacing "BUNDLE mid" with "BUNDLE-tag".
> >
> > Looking at where "BUNDLE mid" is used, it is mostly in constructs like:
> >
> >     In the offer, the address assigned to the "m=" line associated with
> >     the offerer suggested BUNDLE mid indicates the address that the
> >
> > Given the definition that Thomas proposed, that would still work with
> > the change, but ISTM the linkage from "mid" to "m=" line is a little
> > more obvious than from "tag" to "m=" line.
> My proposal to call that thing "tag" comes from the RFC5888 ABNF group-
> attribute = "a=group:" semantics *(SP identification-tag)
> mid-attribute   = "a=mid:" identification-tag
> Here "mid" is the name of an attribute, the values that we are talking about
> are carried in the "identification-tag"
> With this linkage to 5888, we would have a more precise definition.
> >
> > I don't know if Thomas was intending that there would still be
> > definitions for "Offerer suggested BUNDLE-tag" and "Answerer selected
> > BUNDLE-tag". I think we would still need those.
> [TS] I would have used just a single term and made the semantics of suggested
> vs. selected clear from the surrounding text in the remainder of the document.
> But that is already deep in the field of personal style and preferences.
> I would be ok with two terms, especially with the change to "Offerer suggested
> BUNDLE-tag/mid".
> The corresponding edits that Christer suggested make the text already much
> clearer.
> >
> > As an alternative, perhaps a definition of "BUNDLE mid" could be
> > added, that has much of the text from Thomas' definition of "BUNDLE-tag".
> Having such a definition would be good.
> In the proposed text, I tried to give some guidance to the reader how this
> thing is used in the remainder of the text.
> 
> Thanks
> Thomas
> >
> > 	Thanks,
> > 	Paul
> >
> > > Regards,
> > >
> > > Christer
> > >
> > > *From:*Stach, Thomas [mailto:[e-mail]]
> > > *Sent:* 24 October 2014 16:45
> > > *To:* Christer Holmberg
> > > *Cc:* 'mmusic'
> > > *Subject:* RE: WGLC comments on
> > > draft-ietf-mmusic-sdp-bundle-negotiation-12 - Terminology
> > >
> > > Hi,
> > >
> > > There has been many long discussions in order to come up with the
> > > terminology.
> > >
> > > */[TS] I know that much effort was already put into that. /*
> > >
> > > *//*
> > >
> > > Also,
> > >
> > > considering the number of editorial re-structures that have already
> > > taken place, and the impact this would have on the document, I would
> > > suggest to NOT do the change.
> > >
> > > */[TS] I understand that there is not much appetite for putting more
> > > editorial work into the document./*
> > >
> > > */Nevertheless, I still think that understanding the text is still
> > > unnecessarily cumbersome, /*
> > >
> > > */which in turn could lead to unnecessary misinterpretations during
> > > implementation./*
> > >
> > > */But maybe it is just me, who has this problem, in which case I
> > > probably just have to  improve my reading skills.  ;-) /*
> > >
> > > But, if you think the existing definitions can be clarified, we can
> > > discuss that.
> > >
> > > */[TS] Well, considering reuse of the RFC5888 terminology might be
> > > still
> > > worthwhile./*
> > >
> > > */That would e.g. include replacing  "mid attribute value" with
> > > "identification-tag", etc./*
> > >
> > > *//*
> > >
> > > Regards,
> > >
> > > Christer
> > >
> > > *From:*Stach, Thomas [mailto:[e-mail]]
> > > *Sent:* 23 October 2014 18:34
> > > *To:* Christer Holmberg
> > > *Cc:* 'mmusic'
> > > *Subject:* WGLC comments on
> > > draft-ietf-mmusic-sdp-bundle-negotiation-12
> > > - Terminology
> > >
> > > All
> > >
> > > Terminology
> > >
> > >     Offerer suggested BUNDLE mid: The first mid value in a given SDP
> > >
> > >     'group:BUNDLE' attribute mid list in an offer.
> > >
> > > and
> > >
> > >     Answerer selected BUNDLE mid: The first mid value in a given SDP
> > >
> > >     'group:BUNDLE' attribute mid list in an answer.
> > >
> > > These terms are not very intuitive and make the reading the related
> > > text quite cumbersome.
> > >
> > > Since you are talking about the identification-tags from RFC5888
> > >
> > > group-attribute = "a=group:" semantics *(SP identification-tag)
> > >
> > > mid-attribute   = "a=mid:" identification-tag
> > >
> > > may I suggest re-using that terminology and propose using a single,
> > > more pregnant term for both
> > >
> > > together with additional explanation?
> > >
> > > E.g.
> > >
> > > BUNDLE-tag: The first element in the list of identification-tags of
> > >
> > >              a 'group:' attribute [RFC5888] with BUNDLE semantics.
> > >
> > >              This tag has special significance in that it identifies
> > >
> > >              the m-line that carries the suggested or selected
> > > BUNDLE address.
> > >
> > >              The corresponding m-line will carry the same tag in a 'mid'
> > > attribute.
> > >
> > >              The offerer suggests a BUNDLE tag. The answerer
> > > preferably accepts
> > >
> > >              the suggested BUNDLE-tag, but could select a different
> > >
> > >              BUNDLE-tag, if necessary.
> > >
> > >              Example:
> > >
> > >              If we have e.g. 'a=group:BUNDLE foo bar', then 'foo'
> > > would be the
> > >
> > >              BUNDLE-tag and 'a=mid:foo' the m-line with the BUNDLE
> address.
> > >
> > > If there is appetite for changing that terminology, I understand
> > > that it would cause quite a few
> > >
> > > other editorial changes in the remainder of the document.
> > >
> > > In order to not delay progress of the draft, I can only offer to
> > > help in any editorial effort and would be happy to propose changed text.
> > >
> > > Regards
> > >
> > > Thomas
> > >