The Session Description Protocol (SDP) Content Attribute
draft-ietf-mmusic-sdp-media-content-06
Yes
(Cullen Jennings)
No Objection
(Bill Fenner)
(Brian Carpenter)
(Dan Romascanu)
(David Kessens)
(Jari Arkko)
(Jon Peterson)
(Lisa Dusseault)
(Magnus Westerlund)
(Mark Townsley)
(Ross Callon)
(Russ Housley)
(Sam Hartman)
Note: This ballot was opened for revision 06 and is now closed.
Cullen Jennings Former IESG member
Yes
Yes
()
Unknown
Bill Fenner Former IESG member
No Objection
No Objection
()
Unknown
Brian Carpenter Former IESG member
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
David Kessens Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
()
Unknown
Jon Peterson Former IESG member
No Objection
No Objection
()
Unknown
Lars Eggert Former IESG member
(was Discuss)
No Objection
No Objection
(2006-10-11)
Unknown
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.)
Lisa Dusseault Former IESG member
No Objection
No Objection
()
Unknown
Magnus Westerlund Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Mark Townsley Former IESG member
No Objection
No Objection
()
Unknown
Ross Callon Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Sam Hartman Former IESG member
No Objection
No Objection
()
Unknown
Ted Hardie Former IESG member
No Objection
No Objection
(2006-10-09)
Unknown
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