Re: Existing missmatch between SDP mux and BUNDLE

>>Actually, the PR suggests “m= section”. That is used in JSEP, but in 4566 there is “media description” and “media-level section”. I am 
>>not really sure that the difference is.
>
>"Media description" and "media-level section" are the same thing, by definition. My PR defines "m=" section as another shorthand, 
>mainly since this is a phrase JSEP uses heavily. But I'd gladly just use "media description", "media-level section" or "media section".

I'd like 4566bis to use ONE definition, and then we use the same elsewhere.

Regards,

Christer




On Sep 26, 2017, at 1:13 PM, Christer Holmberg <[email protected]> wrote:

Hi,
 
>I have one question, which actually makes a practical difference to the on-the->wire SDP of BUNDLE.
> 
>For a session- and media-level attribute which has the common pattern that the >session-level value provides a default for the media level, a non-overridden>session-level attribute is arguably “associated” with a media description, but it >clearly isn’t “included” in it.
> 
>Should this be permitted?
 
Not sure I understand. Should what be permitted? :)

If BUNDLE says that an attribute of this type “MUST be associated with a media description”, is it sufficient to have the attribute specified at the session level?


 
Regards,
 
Christer
 
 
 
On Sep 25, 2017, at 10:52 PM, Eric Rescorla <[email protected]> wrote:
 
I am in favor of the changes that Taylor proposes. 
 
-Ekr
 
 
On Mon, Sep 25, 2017 at 7:38 PM, Flemming Andreasen <[email protected]> wrote:
I much prefer use of the term "media description" as well since this is well-defined in 4566. 

Having said that, I wholeheartedly agree with Christer's point about terminology change - we need people to agree to this before entertaining yet another update on this front. 

So folks, please speak up and let us know if you are for, against, or indifferent in terms of said terminology change. 

Thanks 

-- Flemming 
 
On 9/22/17 4:08 PM, Taylor Brandstetter wrote:
Right. I can only think of one possible interpretation of "add attribute to media description". RFC4566 uses the following phrases:
• "attributes ... may be added" 
• "attribute ... in the media description" 
• "attribute is present" 
• "a media description may have any number of attributes" 
• "attribute fields can ... be added" 
• "specifying the attribute" 
• "session description containing such attributes" 
• "attribute MUST be included" 
So, the following would be consistent with the defined terminology:
• "The offerer MUST add the foo attribute to the media description." 
• "The foo attribute MUST be [present|contained|specified|included] in the media description."
• "The media description MUST have the foo attribute."
But "foo attribute MUST be associated with the m-line"? Not so much.
 
On Fri, Sep 22, 2017 at 9:51 PM, Christer Holmberg <[email protected]> wrote:
Hi,

>> It depends on how we interpret "associated with"
>
> That's why I purged "associated with" from the BUNDLE spec: https://github.com/taylor-b/draft-sdp-bundle/pull/1 
>
> It almost always can be interpreted in multiple ways. Unfortunately this never got integrated, I assume because I was too late.

No, you were not :) I have been looking at your CR, and have been considering to integrate it, but I lately I have been so busy with draft-dtls-sdp etc.

Having said that, we have changed the terminology in bundle a number of times already - we really need to stop at some point.

The history of "associated" is when people commented that one cannot add an attribute, address etc to an m- line (because attributes, c- lines and m- lines are separate SDP properties). So, instead of talking about adding those to an m- line talk about associating those with an m- line.

Now, if I remember the changes in your PR correctly, you are talking about "media descriptions", which would be an "envelope" containing the m- line, the address and attributes associated with that m- line. Then you could say "add attribute to the media description", etc. Right?

Regards,

Christer
 
 

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


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

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