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

[Harald Alvestrand <[e-mail]>]

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.

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....

>
> 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.

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?

>
> 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


-- 
Surveillance is pervasive. Go Dark.