Session Description Protocol (SDP) Media Capabilities Negotiation
RFC 6871

Note: This ballot was opened for revision 16 and is now closed.

(Gonzalo Camarillo) Yes

(Robert Sparks) Yes

Comment (2012-12-17 for -16)
No email
send info
Nits:

Do you want to explicitly say whether a range of 3-1 is semantically legal? It is syntactically valid, and the text doesn't require the number represented by the digits to the right of the hyphen to be greater than that to the left.

This (and several documents that have gone before it) use 1*10(DIGIT) for things like media-cap-num. That means
it would be syntactically valid to say things like

a=rmcap:1 PCMU/8000
and
a=rmcap:00001 PCMU/8000

Do those mean the same thing?

If someone included a pcfg with m=0001|0002 in an offer, and the answer had a acfg with m=1, should the offerer recognize that as the same as its 0001?

Would it be better to restrict the syntax to avoid this question?

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Benoît Claise) No Objection

(Ralph Droms) No Objection

Comment (2012-12-20 for -16)
No email
send info
Thank you for including the specific ways in which
this document updates RFC 5939:

   This document updates RFC 5939 [RFC5939] by updating the IANA
   Considerations.  All other extensions defined in this document are
   considered extensions above and beyond RFC 5939 [RFC5939].

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

Comment (2012-12-19 for -16)
No email
send info
- 3.3.5: Does the crypto field only ever contain symmetric key
material or initialisation values? If so, why only have a
SHOULD NOT for use of real key materials in a latent (or
potential?) configuration? I don't see why that is not a MUST
NOT. Actually, having a MUST for some known value would
maybe be even better, e.g. all zeros, so long as that didn't
break anything.  (Same thing if crypto can occur in an answer
as a latent value.)

(Brian Haberman) No Objection

(Russ Housley) No Objection

Barry Leiba No Objection

(Pete Resnick) No Objection

Comment (2012-12-19 for -16)
No email
send info
One minor question added to my original comments: The writeup does not indicate any implementation of this. Is that true? There are no implementations yet?

This stuff is well outside of my area of expertise. After a read through, I have found nothing *in* my area of expertise that is problematic. A couple of requirements language issues, but nothing that should stop the document unless other ADs think these problems could cause serious problems:

3.4.1.1:

The following happens elsewhere in the document, but this is a good example:

   Each potential configuration
   MUST include a config-number that is unique in the entire SDP...

That's ambiguous. What "MUST" be done here? Do you mean:

   Each potential configuration MUST include a config-number, which is
   unique in the entire SDP.

Or do you mean:

   The config-number of each potential configuration MUST be
   unique in the entire SDP.
   
Or do you mean:

   Each potential configuration MUST include a config-number, and
   each config-number MUST be unique in the entire SDP.
   
Which is it? They have 3 different meanings. The first is saying to the implementer, "You might not think the config number is required, but it is and you'll screw up the other side if you leave it out." The second is saying, "You might not think the config number needs to be unique, but it does and you'll screw up the other side if it's not." And the third is saying the combination of the first two.

It is probably worth reviewing 2119 usage throughout the document, as ambiguities in requirements is a bad thing. And even though this is ambiguous, the RFC Editor will likely not try to correct it because they always assume that things around requirements language were worded carefully. Please check them.

3.4.2.1:

   The answerer MUST first determine...

I very much doubt that this is an interoperability requirement. There are several instances of this sort. Please remove these MUSTs.

(Martin Stiemerling) No Objection

(Sean Turner) No Objection