Subject: [MMUSIC] msid-08 comments

From: Flemming Andreasen <[email-masked]>
Date: Thu, 19 Mar 2015 18:17:16 -0400

Greetings

I have taken a look at draft-ietf-mmusic-msid-08 and have some comments 
on it. Overall, I think there is still a bit of work required before we 
are ready for WGLC:

General comments:
- There aren't any examples in the document. It would be helpful to have 
some.

Section specific comments:

1) Section 2, second paragraph, " The value of the "msid" attribute 
consists of an identifier...".
It's unclear at this point whether it corresponds to a MediaStream or a 
MediaStreamTrack, which makes it somewhat difficult to follow some of 
the subsequent text.

2) Section 2, 8th paragraph
<quote>
The identifier is a string of ASCII characters that are legal in a
    "token", consisting of between 1 and 64 characters.  It MUST be
    unique among the identifier values used in the same SDP session.
</quote>

I suggest rephrasing to make it clear that you can use the same 
identifier value in different media descriptions.  What is somewhat 
unclear at this point then is when you use the same MSID identifier 
values and when you use different ones (for a given msid-semantic). This 
goes back to the confusion around MediaStream versus MediaStreamTrack

3) Section 2, 11th paragraph:
<quote>
There may be multiple msid attributes in a single media description.
</quote>

Can they have the same identifier value (clarify) ?

4) Section 3, 5th paragraph
<quote>
    An identifier of "*" is an indication that all "a=msid" lines in the
    SDP have this specific semantic.  If "*" is not used, each msid-id in
    the SDP MUST appear in one and only one "msid-semantic" line.
</quote>

Do you mean in one of a given msid-semantic or irrespective of 
msid-semantic ?

5) Section 3, ABNF
<quote>
msid-list = *(" " msid-id) / " *"
</quote>

I assume there is a SP (space) in those double-quotes, but it's hard to 
tell. Please modify the grammar to call out SP explicitly (if that is 
indeed what it is).

6) Section 3, after ABNF
<quote>
The semantic field holds values from the IANA registriy "Semantics
    for the msid-semantic SDP attribute" (which is defined in Section 6).
</quote>

What values are defined in this document and how are they used ? It 
turns out that Section 5 defines the value "WMS", however it's not clear 
at this point. More clarity up front about the fact that you are 
defining a generic mechamism first (incl. O/A procedures) and then 
specifics around its use with "WMS" later in the document would be helpful.

7) Section 4, first paragraph
Again, It would be helpful to clarify that more detailed procedures for 
the "WMS" semantic will be provided in Section 5.

8) Section 4.1
<quote>
An entity wishing to use an MSID semantic MUST add one or more "msid-
    semantic" attributes to its session level attributes, indicating the
    MSID semantic it wishes to have available..
</quote>

- Is "available" the same as "supports" (you mention "support" elsewhere) ?

- Also, there is nothing here in terms of specifiying "msid"; presumably 
that is also part of the general procedures.

9) Section 4.2
<quote>
  If an "msid-semantic" attribute is present in the offer, and the
    answerer wishes to use the indicated semantic, the offerer MUST
    follow the procedures described for that semantic.
</quote>

- Where are those procedures described (becomes clearer later for "WMS", 
but there seems to be an implied requirement for new semantics here that 
is not called out) ?

- Description is a bit too vague. Presumably it only applies to the 
media descriptions for which there are corresponding msid values (?)

- What happens if the answerer wants to do it for a subset or superset 
of those media descriptions ?

10) Section 4.3
<quote>
If the answerer does not
    wish to use one or more of the semantics indicated in the offer, the
    answerer MUST NOT include "msid-semantic" lines indicating these
    semantics in the answer.
</quote>

I don't follow; in the beginning of Section 4 you said the semantic is 
not negotiated and that each side just specifies what it will be using. 
Now you are saying it's effectively negotiated (?)

11) Section 4.4
<quote>
If an "msid-semantic" attribute is present in the answer, and the
    offerer wishes to use the indicated semantic, the offerer MUST follow
    the procedures described for that semantic.  The offerer MUST follow
    the procedures for all semantics that were indicated in its offer and
    were also present in the answer.
</quote>

I'm not sure what that means without a discussion around pairing up msid 
values (media descriptions).  This again seems to suggest there is 
actually some negotiation taking place, but the beginning of Section 4 
said there was not.

12) Section 5, first paragraph
<quote>
This section creates a new semantic for use with the framework
    defined in Section 2
</quote>

Section 3 is where you defined msid-semantic, which seems to be what 
this is about (?).

13) Section 5, 6th paragraph
<quote>
If two different m-lines have MSID attributes with the same value for
    identifier and appdata, it means that these two m-lines are both
    intended for the same MediaStreamTrack.
</quote>

I believe you mean that the two identifier values are the same and the 
two appdata values are the same, however it's ambiguous, especially when 
saying "value" in singular.

14) Section 5, last bullet in bullet list
<quote>
    o  When a description is updated to no longer list the msid attribute
       on a specific media description, the recipient can signal to its
       application that the corresponding MediaStreamTrack has ended.
</quote>

Do you mean "identifier and appdata value" instead of "attribute" ?

15) Section 5, second last paragraph
<quote>
Changing the direction of the media section (by
    setting "sendonly", "recvonly" or "inactive" attributes) will not
    close the MediaStreamTrack.
</quote>

This begs the question of whether MediaStream and MediaStreamTrack 
identifiers are unidirectional ? If they are not, then how can these 
values be declarative (i.e. not negotiated per Section 4). Needs 
clarification.

16) Section 5.2.1, first paragraph
<quote>
  For each media section in the offer,...
</quote>

Do you mean "media description" instead of "media section" (note; shows 
up in other places too) ?

17) Section 5.2.2, heading
Change to "Answerer Processing of the Offer" for consistency with 
Section 4.2 (?)

18) Section 5.2.2, bullet list
The order of the bullets suggest you create MediaStreamTracks before 
MediaStreams. I would have though it was the other way around (?)

19) Section 6.2, first paragraph
Per RFC 5226, when we have "Expert Review" policy, we should specify the 
required documentation and review criteria for use by the Designated 
Expert. I don't see that here.

20) Appendix A, first paragrahp
It says the appendix should be deleted before publication. Why not keep 
it ? Alternatively, if we do want to delete it (but not now), we should 
add a "Note to RFC Editor".

Let me know if you'd like to discuss any of these further (e.g. in 
Dallas) and/or would like help in updating any of the text in the 
document to address them. I'll send an annotated version of the document 
with the above comments off-line as well.

Thanks

-- Flemming

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 20 Mar 2015 12:20:47 +0100

On 03/19/2015 11:17 PM, Flemming Andreasen wrote:
> Greetings
>
> I have taken a look at draft-ietf-mmusic-msid-08 and have some 
> comments on it. Overall, I think there is still a bit of work required 
> before we are ready for WGLC:

Some fixes, some pushbacks.
>
>
> General comments:
> - There aren't any examples in the document. It would be helpful to 
> have some.

There are example values in section 2 and section 3.

I will insert an example in section 5 showing a complete usage with 
MediaStreamTracks.
> It's unclear at this point whether it corresponds to a MediaStream or 
> a MediaStreamTrack, which makes it somewhat difficult to follow some 
> of the subsequent text.

Pushback.

It is impossible to say anything about this in section 2, since the 
concept of MediaStream / MediaStreamTrack is introduced in section 5.

> values and when you use different ones (for a given msid-semantic). 
> This goes back to the confusion around MediaStream versus MediaStreamTrack

Clarification needed.

As before, this section *cannot* refer to that difference.

The important normative text is in paragraph 10:

"The identifier uniquely identifies a group within the scope of an SDP 
description."

The referenced text was inserted during earlier discussions of 
uniqueness - but it seems to be just adding confusion, so I'm deleting it.

> Can they have the same identifier value (clarify) ?

This is part of the semantics. The rules for WMS are in section 5, and 
are clearly "yes". This section of the specification should not forbid 
other semantics that require them not to have the same value.

> Do you mean in one of a given msid-semantic or irrespective of 

One and only one "msid-semantic" line. All "msid-semantic" lines are 
"msid-semantic" lines, irrespective of the value of the msid-semantic 
field. I don't know how to write this any clearer; if you have specific 
text suggestions, please suggest away.

> I assume there is a SP (space) in those double-quotes, but it's hard 
> to tell. Please modify the grammar to call out SP explicitly (if that 
> is indeed what it is).

Viewing I-Ds with fixed font helps a lot in distinguishing spaces.
Grammar switched to use of SP.

> turns out that Section 5 defines the value "WMS", however it's not 
> clear at this point. More clarity up front about the fact that you are 

Pushback.

I have this nice thing up front called a "table of content".

There's also the following text in section 1:

    Section 1.2 gives the background on why a new mechanism is needed.

    Section 2 gives the definition of the new mechanism.

    Section 3 gives the definition of the msid-semantic field, which
    gives the possibility of using MSIDs with different semantics in the
    same SDP message.

    Section 5 gives the application of the new mechanism for providing
    necessary semantic information for the association of
    MediaStreamTracks to MediaStreams in the WebRTC API
    [W3C.WD-webrtc-20120209].

I'm making the assumption that people who are reading section 3 will 
have read section 1.
If you think there should be more text in section 1, please say so.

> Again, It would be helpful to clarify that more detailed procedures 
> for the "WMS" semantic will be provided in Section 5.

Pushback, as above.
> - Is "available" the same as "supports" (you mention "support" 

No.

"have available for use later in the SDP description" is the intended 
reading.
"Supports" is used in section 3 for describing how a receiver interprets 
the presence of an empty list of identifiers in an incoming SDP description.

Version -07 had "supports" in this section, and got pushback on that 
because the sender might actually support a given semantic but not wish 
to use it for some reason; "have available" was suggested as an alternative.

>
> - Also, there is nothing here in terms of specifiying "msid"; 
> presumably that is also part of the general procedures.

Clarification / pushback.

What do you mean by "specifying msid" here?
I don't see how there can be generic procedures for msid, given that 
their usage is semantic dependent.

I find text that just says "and then you insert msid according to the 
rules for the semantic" to be so vacous as to be a waste of the time of 
both the writer and the reader.

> - Where are those procedures described (becomes clearer later for 
> "WMS", but there seems to be an implied requirement for new semantics 
> here that is not called out) ?

Pushback.
That is up to the semantic. Expert review will have to form an opinion 
on that if it ever happens.

> media descriptions for which there are corresponding msid values (?)

Pushback.
This is part of what the procedures have to define. Given that there is 
only one example (WMS), and that the procedures for WMS are clear, I 
don't want to constrain that any more.

> of those media descriptions ?

Pushback.
If that's allowed by the procedures, you follow the procedures.
If it's not, it's not.
> not negotiated and that each side just specifies what it will be 
> using. Now you are saying it's effectively negotiated (?)

This was also added between version -07 and -08, in response to a review 
comment.

Semantically, this text just repeats the caveat: If you don't intend to 
do it, don't say that you will do it.

> I'm not sure what that means without a discussion around pairing up 
> msid values (media descriptions).  This again seems to suggest there 
> is actually some negotiation taking place, but the beginning of 
> Section 4 said there was not.

This is also a change from -07 to -08, in response to that review round.

In the case where the answerer indicates that it doesn't intend to obey 
the rules of whatever semantic the offerer is sending, there may be 
cases where the offerer wishes to take other action, which may not be in 
conformance with the rules for the semantic it originally suggested.

This statement allows that, but states it in the negative - that if it 
has promised to follow a semantic, and the answerer, by also including 
that semantic, indicates that it understands what has been promised, it 
has to follow the semantic that it promised.

> Section 3 is where you defined msid-semantic, which seems to be what 

Additional reference inserted. The framework is still described in 
section 2.

> two appdata values are the same, however it's ambiguous, especially 
> when saying "value" in singular.

Changed to use "msid-id" and "msid-appdata" since the ABNF names have 
changed, and using the plural form of "value".
> Do you mean "identifier and appdata value" instead of "attribute" ?

I mean "msid attribute with WMS semantic". Changed to say that.

The media description will stay associated with its MediaStreamTrack 
until it is disassociated. This allowance allows the MediaStreamTrack 
identifier values to change, if needed.

> values be declarative (i.e. not negotiated per Section 4). Needs 

Pushback.

MediaStreams and MediaStreamTracks are unidirectional. This is part of 
their definition, which is outside the scope of this document.

Setting a media description's direction attribute has been suggested as 
a means of pausing a track; this paragraph says that the association 
between media description and track is NOT affected by this.

> Do you mean "media description" instead of "media section" (note; 
> shows up in other places too) ?

Global search/replace done.
> Change to "Answerer Processing of the Offer" for consistency with 

Done.
> MediaStreams. I would have though it was the other way around (?)

You could do it either way, implementor's choice.
Any order of actions that achieves the same result is a  valid 
implementation. Do I need to say that every time?

> Per RFC 5226, when we have "Expert Review" policy, we should specify 
> the required documentation and review criteria for use by the 
> Designated Expert. I don't see that here.

The rather flip statement "Usage of the registry is expected to be low, 
so the expert should feel free to consult widely if a new request ever 
comes in." is indicative of the value I see in spending time worrying 
about what the required documentation and review criteria are - ie value 
= very close to zero.
> It says the appendix should be deleted before publication. Why not 
> keep it ? Alternatively, if we do want to delete it (but not now), we 
> should add a "Note to RFC Editor".

The purpose was to document rejected alternatives. I'm fine with keeping 
it, so I deleted the first paragraph.
> document to address them. I'll send an annotated version of the 
> document with the above comments off-line as well.

I've pushed a change, diff visible at this location:

https://github.com/alvestrand/rtcweb-msid/compare/fandreas-review?expand=1

Let's talk in Dallas.

>
> Thanks
>
> -- Flemming
>
>
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 20 Mar 2015 10:57:15 -0400

Trimming to focus on one point:

On 3/20/15 7:20 AM, Harald Alvestrand wrote:
...
> concept of MediaStream / MediaStreamTrack is introduced in section 5.
...
> other semantics that require them not to have the same value.
...
> both the writer and the reader.
...
> If that's allowed by the procedures, you follow the procedures.
...
> about what the required documentation and review criteria are - ie value

I tried to trim the above down to the set of things mentioned for which 
the answer is "defined by the semantic". There are quite a lot of them.

ISTM that there ought to be a section that describes the minimum set of 
things that a new semantic must specify. It could include at least this set.

And the definition of WMS could set an example by explicitly addressing 
everything in this list.

The way the draft is currently structured suggests that a new semantic 
would need to specify a lot things. Some things in section 5 are unique 
to WMS, but others are not. For instance, all the O/A procedures are in 
section 5, and so are unique to WMS. So another semantic definition 
would need to define its own set of O/A procedures. Even the O/A 
procedures for a=msid-semantic are in section 5, so in principle there 
could be different O/A procedures for msid-semantic when the semantic 
value is something other than WMS. (I would think that the O/A 
procedures for both a=msid-semantic and a=msid would be independent of 
the semantic, though the significance, and reasons for including would 
differ.)

An alternative is to simply reduce the scope, so that this is only 
applicable for WMS, and eliminate the need for a registry and an expert.

	Thanks,
	Paul

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 20 Mar 2015 16:30:35 +0100

On 03/20/2015 03:57 PM, Paul Kyzivat wrote:
> ISTM that there ought to be a section that describes the minimum set
> of things that a new semantic must specify. It could include at least
> this set.
>
> And the definition of WMS could set an example by explicitly
> addressing everything in this list.
>
> would need to specify a lot things. Some things in section 5 are
> unique to WMS, but others are not. For instance, all the O/A
> procedures are in section 5, and so are unique to WMS. So another
> semantic definition would need to define its own set of O/A
> procedures. Even the O/A procedures for a=msid-semantic are in section
> 5, so in principle there could be different O/A procedures for
> msid-semantic when the semantic value is something other than WMS. (I
> would think that the O/A procedures for both a=msid-semantic and
> a=msid would be independent of the semantic, though the significance,
> and reasons for including would differ.)
>
I've suggested removing the extensibility several times, and never had a
comment back on it, neither positive or negative.

Since the extensibility was added at the explicit instruction of the
MMUSIC WG's chairs, I'm reluctant to take it out without acknowledgement
that it's OK to do so by the MMUSIC WG's chairs; editors should not
override what the chairs have declared to be WG consensus.

If I get that instruction, I'm happy to do so (in which case I'll take
out msid-semantic too).

Chairs?

-- 
Surveillance is pervasive. Go Dark.

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 24 Mar 2015 12:25:02 -0400

Thanks for the responses Harald; further feedback below.

On 3/20/15 7:20 AM, Harald Alvestrand wrote:
>> comments on it. Overall, I think there is still a bit of work 
>> required before we are ready for WGLC:
>
Ok.
> concept of MediaStream / MediaStreamTrack is introduced in section 5.
Ok - I think it would help if you explained upfront how you have a 
general mechanism and then a MediaStream/MediaStreamTrack specific 
instantion of that mechanism later in the document (the whole "general 
framework vs. specific extension" point which is not obvious when you 
read the document initially).

> uniqueness - but it seems to be just adding confusion, so I'm deleting it.
I don't think deleting it is the right solution. There is some confusion 
(on my part at least) around how the identifier values are constructed 
and used and we just need to make that clearer here.
> other semantics that require them not to have the same value.
I'm not sure I follow this. The "msid" attribute as defined does not 
change its meaning based on a particular msid-semantic, right ? You have 
a general "msid" attribute that defines some sort of grouping mechanism 
for RTP media streams and then you have various msid-semantics that can 
use that grouping mechanism ? The grouping framework itself doesn't 
change for these, right ?

> field. I don't know how to write this any clearer; if you have 
> specific text suggestions, please suggest away.
>
I was just checking. How about adding "(irrespective of msid-semantic 
value)" at the end  to make it clear ?
> Grammar switched to use of SP.
Ok
>> clear at this point. More clarity up front about the fact that you 
>> are defining a generic mechamism first (incl. O/A procedures) and 
>> then specifics around its use with "WMS" later in the document would 
>> be helpful.
>
> Pushback.
>
I think there should. It would be helpful to clarify that you are 
defining a generic mechanism with generic procedures first and then a 
"WMS" specific instance/extension of that mechanism with more detailed 
procedures later.
>> for the "WMS" semantic will be provided in Section 5.
See above.
> "Supports" is used in section 3 for describing how a receiver 
> interprets the presence of an empty list of identifiers in an incoming 
> SDP description.
>
> because the sender might actually support a given semantic but not 
> wish to use it for some reason; "have available" was suggested as an 
> alternative.
>
Ok - I think it would be helpful to clarify that distinction.
> their usage is semantic dependent.
If that is true, then I don't see how you have a generic mechanism. 
There must be some general rules around what to do with "msid". 
Presumably there is some notion of wanting to define groups of RTP media 
streams and for each media description that you want to be part of that 
group, assign the same msid-identifier value (or did I get that wrong - 
the identifier rules are still unclear to me in the general case ?)

> rules for the semantic" to be so vacous as to be a waste of the time 
> of both the writer and the reader.
>
See above; I think they need to be part of the procedures.

> on that if it ever happens.
You are defining a general framework. Part of the extensibility 
mechanism is to define the rules for how you properly new values and I'm 
simply missing something that tells authors of new msid-semantics what 
they need to do. I don't think you can rely on an expert reviewer to 
simply decide on this.

> This is part of what the procedures have to define. Given that there 
> is only one example (WMS), and that the procedures for WMS are clear, 
> I don't want to constrain that any more.
>
Ok - see above.
>>
>> - What happens if the answerer wants to do it for a subset or 
>> superset of those media descriptions ?
>
> Pushback.
Is it allowed for "WMS" ? My point is that without calling out these 
cases, authors of future extensions may not think about them (and that's 
why a general framework needs to call out such things).

>> I don't follow; in the beginning of Section 4 you said the semantic 
>> is not negotiated and that each side just specifies what it will be 
> This was also added between version -07 and -08, in response to a 
> review comment.
>
> Semantically, this text just repeats the caveat: If you don't intend 
> to do it, don't say that you will do it.
>
Ok - can you clarify that point so it's clear that there is no 
negotiation here. It's still a unidirectional feature declared 
independently by each side (?).
> In the case where the answerer indicates that it doesn't intend to 
> obey the rules of whatever semantic the offerer is sending, there may 
> be cases where the offerer wishes to take other action, which may not 
> be in conformance with the rules for the semantic it originally suggested.
Ok - you are now again effectively saying it's negotiated.
> that semantic, indicates that it understands what has been promised, 
> it has to follow the semantic that it promised.
>
That seems reasonable, but you are saying more than that per above, and 
it seems internally inconsistent:
- What does it mean for the offerer to include an "msid-semantic" in an 
offer ?
- What does it mean for an answerer to include an "msid-semantic" in an 
answer (whether it was offered or not) ?
- Does the offerer and/or answer change any of its behavior for a given 
"msid-semantic" based on what the other side included in its offer or 
answer ?

> Additional reference inserted. The framework is still described in 
Ok.
>> I believe you mean that the two identifier values are the same and 
>> the two appdata values are the same, however it's ambiguous, 
>> especially when saying "value" in singular.
>
Ok.
> identifier values to change, if needed.
Ok
> their definition, which is outside the scope of this document.
Might be helpful to clarify that here nevertheless.
> Setting a media description's direction attribute has been suggested 
> as a means of pausing a track; this paragraph says that the 
> association between media description and track is NOT affected by this.
>
Really ? That seems inconsistent with normal O/A behavior.

If you mean the track is not closed, then I'm ok. If you are saying 
direction attributes are not honored, then I think we have a problem 
(per RFC 3264).

> Global search/replace done.
ok
>> Change to "Answerer Processing of the Offer" for consistency with 
ok
> implementation. Do I need to say that every time?
No - conceptually it just seemed backwards, but ok.
> The rather flip statement "Usage of the registry is expected to be 
> low, so the expert should feel free to consult widely if a new request 
> ever comes in." is indicative of the value I see in spending time 
> worrying about what the required documentation and review criteria are 
> - ie value = very close to zero.
Maybe so, but that doesn't negate the need for it per RFC 5226.

> The purpose was to document rejected alternatives. I'm fine with 
> keeping it, so I deleted the first paragraph.
Ok.
> https://github.com/alvestrand/rtcweb-msid/compare/fandreas-review?expand=1
Sounds good - probably easiest to go over the above in person (but 
others are of course welcome to chime in).

Thanks

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 24 Mar 2015 16:52:09 -0400

I don't think that's something the chairs can or should decide without 
input from the WG. In general, we try to define general mechanism though 
and not just focus on one specific use case and I think the current 
draft is aligned with that (it just needs a few updates to make that 
clearer and perhaps beef up the "general" part of the overall mechanism).

Thanks

-- Flemming (as MMUSIC co-chair)