Re: Existing missmatch between SDP mux and BUNDLE

On 9/26/17 2:04 PM, Christer Holmberg wrote:
>>> 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.

4566bis is currently in WGLC - can you provide that feedback to the WGLC 
thread (as well as any other comments you may have on 4566bis) ?

Thanks

-- Flemming


> 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