Re: [MMUSIC] Updated MSID draft - version -06

[Flemming Andreasen <[e-mail]>]

On 6/28/14, 3:26 AM, Harald Alvestrand wrote:
> On 06/27/2014 07:02 PM, Paul Kyzivat wrote:
>> The following are my comments on the -06 version:
>>
>> Sections 2 & 2 (ABNF):
>>
>> There is an error in the ABNF:
>>
>>       identifier-list = (" " identifier)* / " *"
>>
>> should be
>>
>>       identifier-list = *(" " identifier) / " *"
>>
>> Also, to formally check ABNF that extends 4566 it is necessary to
>> merge the ABNFs. To facilitate this it would be good to ensure that
>> all the new ABNF names introduced are unique across 4566. And since
>> some implementers may need to merge many extensions, it would good to
>> avoid defining new names that are overly generic and prone to
>> collision. In particular, I suggest the following renamings would
>> improve things:
>>
>> identifier -> msid
>> appdata -> msid-data
>> semantic -> msid-semantic
>> identifier-list -> msid-list
>>
>> Note: I'm not saying that these currently cause any conflicts. I don't
>> think they do with 4566 itself, and I have no idea if they conflict
>> with other extensions to 4566. I'm suggesting this as a matter of
>> prudence and readability.
> I think this actually reduces readability, but that's a matter of taste.
I'm with Paul on this one and would prefer something along the lines of 
what he suggested.

> One of our failiures with ABNF is that we never implemented a
> modularization facility with official syntax for "identifier = <defined
> in other document>".
>
>> Section 3 says:
>>
>>     This attribute MUST be present if "a=msid" is used.
>>
>> This is true, but stronger constraints ought to be applied:
>>
>>     Every identifier mentioned in an msid-semantic line MUST also
>>     appear in at least one a=msid line.
>>
>>     The identifier in every a=msid line MUST be mentioned in
>>     *at least* (or perhaps *exactly*) one a=msid-semantic line.
> Not a bad idea. The wildcard identifier (*) counts as
>> Section 4.1:
>>
>> The section refers to "WebRTC entity", but AFAIK there is no
>> definition of this. I presume you don't mean to restrict this to
>> browsers. IIUC you probably mean any entity that supports
>> msid-semantic:WMS. Could you clarify the text?
> With the split in -overview recently into "WebRTC browsers" and "WebRTC
> devices", this is actually limited to WebRTC browsers, since the SDP in
> question only appears on the Javscript API, and implementing the
> Javascript API is only a requirement for browsers....
Are you suggesting any changes here (seems to me we shouldn't limit the 
mechanism to just browsers, which I think was Paul's point as well) ?
>> Section 4.2:
>>
>> This section should probably be called "Detailed Offer/Answer
>> procedures".
>>
>> The following:
>>
>>     These procedures ...
>>
>>     They are specifically applicable to the WMS semantic; other semantics
>>     will have their own consideration.
>>
>> Is this really true? ISTM that there are some basic O/A procedures
>> that apply to all msid-semantics. Specifically,
>>
>> - If a particular msid-semantic is mentioned in an offer, and it is
>>    supported by the answerer, then a corresponding msid-semantic
>>    MUST be mentioned in the answer. (The absence indicates that it
>>    is not supported.)
>>
>> So I think there is need of a "generic" set of O/A procedures. And
>> then there can be additional O/A procedures specific to WMS. The
>> existing sections 4.2.1 - 4.2.5 are just the WMS-specific ones.
> My problem is that I don't want to write the generic ones, because I
> don't have any idea what they should say.
>
> This is a generic problem with the generic mechanism - we can't define
> rules for what doesn't exist yet, and it's not possible to see what
> parts of the rules are true for any use of msid and what parts of the
> rules are true for WMS only before we start seeing a second usage.
>
> At the moment we have zero value to the generic mechanism, because we
> have zero potential usages of it. Writing something that has zero value
> does not appeal greatly to me.
For an MMUSIC document extending SDP, we do need O/A sections following 
the structure of RFC 3264. If you need help writing those, the chairs 
can try and find somebody to assist.

> I suggested earlier that we might instead rip out the whole generalized
> mechanism and go back to msid being WMS only. I got no responses on that
> suggestion (neither positive or negative - it was ignored).
>
> This suggestion of another set of for-now-useless sections in the
> document makes me reiterate that proposal. Can you comment on it?
My initial reaction for an MMUSIC document would be against that, but 
can you provide a pointer or resend the proposal so we can take another 
look and discuss it.

Thanks

-- Flemming

>> Section 4.2.1:
>>
>> This section should say something about msid-semantic. Some of the
>> text from section 4.1 might do the job:
>>
>>     If a WebRTC entity sends a description, it MUST include the msid-
>>     semantic:WMS attribute, even if no media streams are sent.
> Yes.
>
>> That covers everything I noticed.
>>
>>      Thanks,
>>      Paul
>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>