The Session Description Protocol (SDP) Content Attribute
draft-ietf-mmusic-sdp-media-content-06

People are looking for advice in the document along lines of

First look at type of media , then this attribute in deciding what to do

Add note to registry indicating what type of media types this label might be appropriate for

Explain that tags have meaning only to the applications that understand them

Work with Lars on how to resolve the semantics of these labels

[Ballot discuss]
Section 6:

I think the document does not consider the issues with "content" and
directonality. If an offerer declares a media stream to be sign language
and that stream is "sendrecv" then it knows what it plans to send, but not
what the other end will send to its ports. The most interesting case is
recvonly streams where the declaring entity can't be certain of the
content properties of the stream the other entity sends. Thus I think
there is need to clarify the usage and the relation to the directionality
attributes. I think tying the content attribute hard to what one intends
to transmitt is the only way to avoid advanced rules for responding and
the issues with deployement. However some rules on recommendation in
regards to offers with content attribute is probably good. That way one
can avoid ending up with the same media streams for different purpose.

[Ballot discuss]
Section 6:

I think the document does not consider the issues with "content" and directonality. If an offerer declares a media stream to be sign language and that stream is "sendrecv" then it knows what it plans to send, but not what the other end will send to its ports. The most interesting case is recvonly streams where the declaring entity can't be certain of the content properties of the stream the other entity sends. Thus I think there is need to clarify the usage and the relation to the directionality attributes. I think tying the content attribute hard to what one intends to transmitt is the only way to avoid advanced rules for responding and the issues with deployement. However some rules on recommendation in regards to offers with content attribute is probably good. That way one can avoid ending up with the same media streams for different purpose.

[Ballot comment]
Section 6., paragraph 1:
>    level.  The fact that the peer endpoint does not understand the
>    'content' attribute does not keep the media session from being
>    established.  The only consequence is that end user interaction on

  s/does not keep/SHOULD NOT keep/


Section 6., paragraph 3:
>    The 'content' attribute can also be used in scenarios where SDP is
>    used in a declarative style.  For example, 'content' attributes can

  s/can also be used/MAY be used/


Section 10., paragraph 7:
>    Allowed attribure values: "slides", "speaker", "sl", "main", "alt",

  Nit: s/attribure/attribute/


Section 10., paragraph 12:
>    As per the terminology in RFC 2434 [4], the registration policy for
>    new values for the 'content' parameter shall be 'Specification
>    Required'.

  If the WG agrees with my DISCUSS, they may want to consider an
  additional "Expert Review" step here, to make sure the restriction of
  content types to sets of media types make sense. (If they don't, then
  ignore this comment.)

[Ballot discuss]
Section 5., paragraph 10:
>    All these values can be used with any media type.  The application
>    can make decisions on how to handle a single media stream based on
>    both the media type and the value of the 'content' attribute.
>    Therefore the situation where one value of 'content' attribute occurs
>    more than once in a single session descriptor is not problematic.

  DISCUSS: That any values can be used with any media type seems overly
  simplistic. What is the meaning of "sl", "slides" or "speaker" for an
  audio stream? It may be worth considering to at least allow content
  types to be restricted to a subset of media types.

[Ballot comment]
Frankly, the initial set of values doesn't point uniformally to what I would consider content; sign language may be an attribute of the content, but "slides" is so vague that I seriously considered
asking for an update.  Given that there is an extension mechanism with a relatively low bar, though, I guess this will take care of itself if that turns out to be true.

Semi-nit: The document says:

  An application MAY attach a content attribute to any media stream it describes.

Of course, it won't make sense to assign "sign language" to an audio stream, and the
application is responsible for making sure that it isn't a nonsense association

IANA Last Call Comment:


Upon approval of this document, the IANA will create a new table
in the following registry "Session Description Protocol (SDP)
Parameters "located at http://www.iana.org/assignments/sdp-parameters
Initial contents of this table will be:

Registration Procedure: Specification Required
Type SDP Name Description Reference
---- --------- --------------- ---------
content
slides Presentation slides [RFC-mmusic-sdp-media-content-
05.txt]
speaker Image from the speaker [RFC-mmusic-sdp-media-content-
05.txt]
sl Sign language [RFC-mmusic-sdp-media-content-
05.txt]
main Main media stream [RFC-mmusic-sdp-media-content-
05.txt]
alt Alternative media stream [RFC-mmusic-sdp-media-content-
05.txt]


We understand the above to be the only IANA Actions for this document.

Can the authors please address the Gen Art and Security area reviews and lf any changes are needed, let me know. If they are very minimal we can do then with and RFC Editor note but if there are a bunch, just putting in a new revision would like be the fastest way.

From the security comments, I think it sounds like a good idea to mention that there are several ways integrity might be provided including stuck things as S/MIME, SIPS, and Identity and removing the other things MAY be used and just phrasing things such that this is true. I suspect we need to add a little clarification text to resolve RJS big NIT. If a new version of the document ins being done, we might as well fix all the small nits too thought they could be dealt with at later stage.

From:   magnus@rsasecurity.com
Subject: Review of draft-ietf-mmusic-sdp-media-content-05
Date: September 12, 2006 7:14:48 AM PDT
To:   iesg@ietf.org, secdir@mit.edu
Cc:   jf.mule@cablelabs.com, Jani.Hautakorpi@ericsson.com, Gonzalo.Camarillo@ericsson.com, jo@acm.org, csp@csperkins.org
Reply-To:   magnus@rsasecurity.com

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the security area directors, but are copied to the document's editors and the WG chairs for their information and to allow them to address any issues raised.

Background:
-----------
Draft-ietf-mmusic-sdp-media-content-05 describes an extension of SDP to allow a party to annotate the declaration of a media stream with additional, machine-interpretable information, such as if a video stream is of a presenter or her slides.

General:
--------
The document is written in a clear style although I suggest that it be
reviewed by a native english speaker as there are a number of minor grammatical errors, e.g. "The downside of this approach is that it requires external document."

Security-related:
-----------------
The security considerations section is very brief, and I have the following comments on it:

- Integrity protection of the (SIP/SDP stream in general, and the) new
  content attribute (in particular) is discussed, but not anything about the
  potential need for confidentiality. I could imagine that - possibly also
  with new content attribute values - that such needs may arise. It would
  be nice if the document at least contained a discussion about this.

- The document states that "S/MIME is the natural choice" (for e2e
  integrity protection) - but not all SIP endpoints are capable of this -
  e.g. the scenario with a local entity only having mutual trust with a
  local gateway and the same situation on the receiving end. In this case a
  hop-by-hop security service such as that provided by TLS could be used
  instead, and I think this should be reflected in the document.

- The statement "Other applications MAY use different form of integrity
  protection" does not add much value (or information) IMHO. Better to
  specify what these other forms could be - or not state anything.

Best regards,
-- Magnus

From:   rjsparks@estacado.net
Subject: Genart LC review draft-ietf-mmusic-sdp-media-content-05.txt
Date: September 15, 2006 11:12:59 AM PDT
To:   rjsparks@estacado.net
Cc:   Gonzalo.Camarillo@ericsson.com, jani.hautakorpi@ericsson.com, mmusic-chairs@tools.ietf.org, mmusic-ads@tools.ietf.org, gen-art@ietf.org

I am the assigned GenArt reviewer for draft-ietf-mmusic-sdp-media-content-05
For background on Gen-ART, please see the FAQ at
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

I'm still not clear what a device that receives the txp parameter should do. It seems to indicate human turn taking is required. The user-floor seems to indicate that human level turn taking is required. I don't understand the difference. A possible solution to progress this  would be to move txp to a separate draft.

I would like to see concrete advice about what type of future things are allowed in the registry and what is not.

It is not clear when a device that sends RTP should includes txp or user-floor or how a device receiving them might use them. The semantics of txp and user-floor need to be clarified.

It is not clear what is appropriate to add to the IANA registry and what is not.  The document needs to define this when the registry is created.

It would be nice to have an example show a content line with more than one attribute.

I'm glad to work with folks to try and craft text for this but I would prefer not to have to write it.

PROTO Write-up

1.a) Have the chairs personally reviewed this version of the ID and
do they believe this ID is sufficiently baked to forward to the
IESG for publication?

Yes.

1.b) Has the document had adequate review from both key WG members
and key non-WG members? Do you have any concerns about the
depth or breadth of the reviews that have been performed?

The document has had adequate review; I have no concerns.

1.c) Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, etc.)?

No. During working group last call it was suggested that this draft
might need review from the MIME community, accordingly a request for
review was made to the ietf-types list on 13th April 2006 (no
comments were received).

1.d) Do you have any specific concerns/issues with this document
that you believe the ADs and/or IESG should be aware of? For
example, perhaps you are uncomfortable with certain parts of
the document, or have concerns whether there really is a need for
it, etc. If your issues have been discussed in the WG and the
WG has indicated it wishes to advance the document anyway, note
if you continue to have concerns.

I have no concerns.

1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is solid consensus.

1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise what are they upset about.

No.

1.g) Have the chairs verified that the document adheres to _all_ of
the ID nits? (see http://www.ietf.org/ID-Checklist.html).

Yes (idnits 1.90 erroneously reports that the draft doesn't include
RFC 2119 boilerplate).

1.h) Does the document a) split references into normative/
informative, and b) are there normative references to IDs,
where the IDs are not also ready for advancement or are otherwise in
an unclear state? (Note: the RFC editor will not publish an RFC
with normative references to IDs, it will delay publication
until all such IDs are also ready for publication as RFCs.)

References have been split. The only normative reference to an
internet-draft is to sdp-new, which is with the RFC Editor.

1.i) For Standards Track and BCP documents, the IESG approval
announcement includes a writeup section with the following
sections:


* Technical Summary

This document defines a new Session Description Protocol (SDP)
media-level attribute, 'content'. The 'content' attribute defines the
content of the media stream in more detailed level than the media
description line. The sender of an SDP session description can
attach the 'content' attribute to one or more media streams. The
receiving application can then treat each media stream differently
(e.g., show it on a big screen or small screen) based on its
content.

* Working Group Summary

The draft is a product of the MMUSIC working group.

* Protocol Quality

The draft received thorough review by Tom Taylor. The draft was
brought to the attention of the ietf-types list, which raised no concerns.