The Session Description Protocol (SDP) Content Attribute
RFC 4796
Yes
No Objection
Note: This ballot was opened for revision 06 and is now closed.
Lars Eggert (was Discuss) No Objection
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.)
(Cullen Jennings; former steering group member) Yes
(Bill Fenner; former steering group member) No Objection
(Brian Carpenter; former steering group member) No Objection
(Dan Romascanu; former steering group member) No Objection
(David Kessens; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Jon Peterson; former steering group member) No Objection
(Lisa Dusseault; former steering group member) No Objection
(Magnus Westerlund; former steering group member) (was Discuss) No Objection
(Mark Townsley; former steering group member) No Objection
(Ross Callon; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Sam Hartman; former steering group member) No Objection
(Ted Hardie; former steering group member) No Objection
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