Draft:  draft-ietf-mmusic-sdp-media-content-05.txt
Reviewer: Robert Sparks [rjsparks@estacado.net]
Review Date: Friday 9/15/2006 1:13 PM
IETF LC Date: 9/12/2006

Summary:  
This draft is basically ready for publication, but has nits (one  
large) that should be fixed before publication

I normally follow mmusic's work, but did not follow this draft as it  
was developed, so I was able to review it from the "first time  
reader" perspective.

This draft creates a namespace, an IANA registry for that namespace,  
and registers the first few values in that namespace.

Primary Nit:
The draft does NOT define the semantics associated with any name in  
the namespace, but it is not immediately obvious that it is not  
trying to do so, and contains some language that assumes particular  
semantics for particular values.

There is no expectation, based on the contents of this draft, that  
two independent implementations that encounter a content description  
of "main" (or any other value) will do the same thing with the  
associated media stream. The registry section explicitly states "New  
values for the 'content' attribute should not describe things like  
what to do in order to handle a stream". Taking this to an absurd  
extreme, there is intentionally nothing in this draft that constrains  
an implementation such that it won't tag a stream carrying only  
RFC2833 tones with content:sl (sign language).

However, the current text seems to assume a common agreed semantic  
for values in places. I suggest the following modifications:

+ State more strongly in the abstract/introduction that this draft is  
ONLY creating the namespace, a registry, and some values and that it  
specifically does not associate semantics with the values

+ Change the wording in the first example of section 7 to "the  
conferencing system might automatically mix the video streams"  
instead of "the conferencing system automatically mixes the video  
streams"

+ In section 8, the sentence "By using the values of the 'content'  
attribute, this 'param' element can also be used to describe the  
media content in a globally interpretable way." could be read to mean  
that every implementation will do the same thing with a stream with a  
given content attribute value. I think the intent was to point out  
that using these values helps make it _possible_ to define such  
semantics. The sentence should be reworded to capture that without  
implying the semantics are already specified. The problem with the  
current text is in the ambiguity what "globally interpretable" means.  
I apologize for not having come up with alternate text to propose so  
far.

Smaller nits:

I can't follow the final paragraph in the motivation section,  
describing more complex situations. I think you're trying to convey  
that an application that doesn't know anything about auditoriums,  
especially the layout of this auditorium, could use this content  
attribute information to automatically decide how to treat each  
stream, reducing the amount of manual configuration a human operator  
would otherwise have to perform. (Again, this needs to be captured  
pointing out that this draft facilitates such automation, but does  
not define the semantics that would be needed to realize it).

In section 5, the sentence "The 'content' attribute contains a token,  
which MAY be attached to a media stream by a sending application"  
introduces potential confusion by trying to say two things at once. I  
suggest replacing and the sentence that follows it with "An  
application MAY attach a content attribute to any media stream it  
describes. That attribute contains one or more tokens describing the  
content of the transmitted medias stream to the receiving application."

Section 6: Point out that the content descriptors don't have to be  
the same for matching m-lines in an offer and an answer. (The second  
paragraph captures that the content description could occur only in  
an answer or offer, but not the case where one side decides to  
describe the stream as "main" and the other describes it as "alt".

It might be nice to reinforce in the security section that this  
document doesn't define the actions that changing/removing one of  
these descriptions would affect. Perhaps starting the second sentence  
with "Depending on how an implementation chooses to react to the  
presence or absence of a given content attribute, this could result  
in"...

Still smaller nits:

The online idnits checker complains about the 2119 boilerplate in  
this text.

There is a missing "an" (I'm guessing?) in the second paragraph on  
section 3 (it requires _an_ external document).