The Session Description Protocol (SDP) Grouping Framework
Note: This ballot was opened for revision 04 and is now closed.
(Cullen Jennings) Yes
(Jari Arkko) No Objection
(Ron Bonica) No Objection
(Ross Callon) No Objection
(Ralph Droms) No Objection
(Lisa Dusseault) No Objection
(Lars Eggert) No Objection
(Pasi Eronen) No Objection
(Adrian Farrel) (was Discuss) No Objection
(Russ Housley) (was Discuss) No Objection
(Alexey Melnikov) (was Discuss) No Objection
6. Use of "group" and "mid" All the "m" lines of a session description that uses "group" MUST be identified with a "mid" attribute whether they appear in the group line(s) or not. If a session description contains at least one "m" line that has no "mid" identification the application MUST NOT perform any grouping of media lines. The last sentence: is there any interaction with draft-ietf-mmusic-sdp-capability-negotiation-10.txt here? 9.1.1. Example [Example omitted] Since alignment of "m" lines is performed based on matching of nth lines, the first stream had "mid:1" in the INVITE and "mid:2" in the 200 OK. Therefore, the application MUST ignore every "mid" and "group" lines contained in the SDP. Last sentence: is this done because of use in SIP, or because of "mid" mismatch in the 200 OK response?
(Tim Polk) No Objection
(Dan Romascanu) (was Discuss) No Objection
1. I am unconfortable with the following statement in the section that describes changes relative to RFC 3388. Given a semantics value, [RFC3388] used to restrict "m" line identifiers to only appear in a single group using that semantics. That restriction has been lifted. From conversations with implementers, it seems that the lifting of this restriction is unlikely to cause backwards compatibility problems. The authors fail to make a crisp statement that no backwards compatibility problems would appear. This seems to be not an implementation but a deployment issue, and it is not clear what is the recommendation here for an operator. If compatibility problems do show up what are the symptoms or the impact? It may be a 'corner' situation but more clarity in the text could help. The OPS-DIR review by Mehmet Ersue raised a couple of issues which are non-blocking but still may be considered: 2. Chapter 5. Group Attribute It is unclear to me what the following statement actually means: "Further semantics MUST be defined in a standards-track document." The document in review _is_ a standards-track document and if necessary the further semantics can be defined in this document. 3. I support Alexey's DISCUSS at #3. I also think that it is not appropriate to point to an IANA registry established by a RFC obsoleted by this document. The document should include the original IANA considerations from RFC3388 and a note that this has already been done.
(Robert Sparks) (was Discuss) No Objection
There are uses of 2119 words to constrain other documents here that should be edited out (The MUST in section 5, leading to Dan's question, is a good example). I _think_ the MUST in the example section 9.1.1 (which let to Alexey's comment) is another example, but I'm not sure if this is attempting to note a consequence of some other requirement or to actually state a new requirement. If it's the former, where is the actual requirement? If the latter, it's in the wrong place.