Session Description Protocol (SDP) Capability Negotiation
RFC 5939

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

(Cullen Jennings) (was Discuss, Yes) Yes

Alexey Melnikov (was Discuss) Yes

Comment (2010-02-16)
No email
send info
This is a very detailed document, which I really like.

3.4.2. Transport Protocol Capability Attribute

   The "tcap" attribute by itself can only specify transport protocols
   as defined by <proto> in [RFC4566], however full specification of a
   media stream requires further qualification of the transport
   protocol by one or more media format descriptions, which themselves
   often depend on the transport protocol.  As an example, [RFC3551]
   defines the "RTP/AVP" transport for use with audio and video codecs
   (media formats), whereas [RFC4145] for example defines the "TCP"
   transport protocol which may be used to negotiate, e.g. image/t38,
   application/iptv_rtsp, etc. In a non-SDP context, some of these

Using application/iptv_rtsp example here is not good idea, because
this media type registration request is not yet approved by IESG.
There is some debate on whether it will actually be approved.

   media formats could be viewed as transports themselves (e.g. T.38)
   however in the context of SDP and SDP Capability Negotiation, they
   are not. If capability negotiation is required for such media
   formats, they MUST all either be valid under the transport protocol
   indicated in the "m=" line included for the media stream
   description, or a suitable extension must be used, e.g. SDP Media
   Capabilities [SDPMedCap].



3.3.2. Required Capability Negotiation Extensions Attribute

 [...]

   A recipient that receives an SDP and does not support one or more of 
   the required extensions listed in a "creq" attribute, MUST NOT 

I might be confused here. Is this MUST NOT ...

   perform the SDP Capability Negotiation defined in this document. For 
   non-supported extensions provided at the session-level, this implies 
   that SDP Capability Negotiation MUST NOT be performed at all. For 
   non-supported extensions at the media-level, this implies that SDP 
   Capability Negotiation MUST NOT be performed for the media stream in 
   question.  

     An entity that does not support the SDP Capability Negotiation 
     framework at all, will ignore these attributes (as well as the 
     other SDP Capability Negotiation attributes) and not perform any 
     SDP Capability Negotiation in the first place. 

   When an SDP recipient does not support one or more required SDP 
   Capability Negotiation extensions listed in the option tags, the 
   recipient MUST proceed as if the SDP Capability Negotiation 

... the same as this MUST?

   attributes were not included in the first place, i.e. all the 
   capability negotiation attributes should be ignored.  In that case, 
   if the SDP recipient is an SDP answerer [RFC3264], the recipient 
   SHOULD include a "csup" attribute in the resulting SDP answer 
   listing the SDP Capability Negotiation extensions it actually 
   supports.

Magnus Westerlund (was Discuss) Yes

Comment (2009-06-03)
No email
send info
section 3.3.1

   att-value         = option-tag-list 
      option-tag-list   = option-tag *("," option-tag) 
      option-tag        = token    ; defined in [RFC4566] 

   A special base option tag with a value of "cap-v0" is defined for 
   the basic SDP Capability Negotiation framework defined in this 
   document. Entities can use this option tag with the "a=csup" 
   attribute to indicate support for the SDP Capability Negotiation 
   framework specified in this document.  

   The following examples illustrate use of the "a=csup" attribute with 
   the "cap-v0" option tag and two hypothetical option tags, "foo" and 
   "bar" (note the lack of white space): 

      a=csup:cap-v0 

      a=csup:foo 

      a=csup:bar 

      a=csup:cap-v0,foo,bar 

This construction disallows white spaces between option tags. I think this is likely to fail. Why was spaces disallowed? At a minimum I think the "note" should be strengthen to directly say that white space are not allowed.

Section 3.4.1:

When the attribute capability contains session-level attributes, the 
   "acap" attribute can only be provided at the session level. 
   
Is the english in the first sentence really clear. Shouldn't it be clearer if the sentence said: When the attribute capability contain a session-level attribute, the "acap" attribute can only be provided at the session level. 

Section 3.5.1:

Why isn't the handling of already present attributes in the actual configuration discussed in the overview. Now you have read a particular paragraph in section 3.5.1 until you learn about this capability.

   Each attribute configuration list can optionally begin with 
   instructions for how to handle attributes that are part of the 
   actual configuration SDP (i.e., the "a=" lines present in the 
   original SDP). By default, such attributes will remain as part of 
   the configuration in question. However, if delete-attributes 
   indicates "-m", then all attribute lines within the media 
   description in question will be deleted (i.e., all "a=" lines under 
   the "m=" line in question). If delete-attributes indicates "-s", 
   then all attribute lines at the session-level will be deleted (i.e., 
   all "a=" lines before the first "m=" line). If delete-attributes 
   indicates "-ms", then all attribute lines within this media 
   description ("m=" line) and all attribute lines at the session-level 
   will be deleted.  

I would suggest including some overview explanation of how to handle attributes in the actual configuration that are not desired in an alternative one.

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Ralph Droms) No Objection

Comment (2009-06-03 for -)
No email
send info
Minor editorial point: I think the acronym SDP is overloaded, to mean both Session Description Protocol, and a specific SDP session configuration; for example as in this text from the third paragraph in section 1:

   This offer SDP is sent to the answerer, [...]

Is there another expansion for SDP that could be included in the text to clarify this use of the acronym, or some explanation that could be given about this use of the acronym?

(Lisa Dusseault) No Objection

(Lars Eggert) No Objection

(Adrian Farrel) No Objection

(Russ Housley) (was Discuss) No Objection

(Tim Polk) No Objection

Comment (2009-06-04 for -)
No email
send info
Section 5, paragraph 6

suggest referencing 3.11 as well as 3.1 in the discussion of DOS through inclusion
of a large number of offers...

(Dan Romascanu) No Objection

(Robert Sparks) (was Discuss) No Objection

Comment (2009-06-04)
No email
send info
1) Support the suggestion to say "the SDP message" instead of 
   "the SDP" when that's what's meant.

2) The last paragraph of 3.6.1 has a mixed use of "SHOULD" and "should". 
   Both instances probably should be SHOULD.

3) Please double-check the last example (on page 69). There are two
   instances of a=pcfg:1 in that message (which I think is wrong).
   Also, the example of using -m makes sence for the given m=audio
   stream, but in the m=video stream the overall set of attributes
   is exactly the same after deleting and adding the rtpmap. I would
   prefer not to suggest that this is the right thing to do when you
   are not changing the description at all.

4) (Very minor) The last paragraph could be misconstrued as
   permission to "play out garbage". The intent was to say that
   the offerer might not be able to render received media correctly
   until the answer arrives. There are a few other instances of
   "playing garbage" that would be better said "playing the received
    media incorrectly".