I am the assigned GenArt reviewer for draft-ietf-mmusic-sdp-media-
content-05
For background on Gen-ART, please see the FAQ at <http://
www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>
Please handle these comments along with any other Last Call comments
you have received.
(I apologize again for being a few days tardy with this input)
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).
Thanks,
RjS
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
