RE: [MMUSIC] WGLC: draft-ietf-mmusic-sdp-capability-negotiation-07

["Stach, Thomas" <[e-mail]>]

Flemming,

here are my WGLC comments.

Section 3.3.2 - penultimate para

   When an entity does not support one or more required SDP Capability
   Negotiation extensions listed in the option tags, the entity MUST
   proceed as if the SDP Capability Negotiation attributes were not
   included in the first place, i.e. all the capability negotiation
   attributes should be ignored.  In that case, the entity SHOULD
   include a "csup" attribute listing the SDP Capability Negotiation
   extensions it actually supports.

Propose to use "recipient" instead of "entity" 
Propose to add "in the SDP answer" to the last sentence 
The text would read:

   When a 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 attributes were not
   included in the first place, i.e. all the capability negotiation
   attributes should be ignored.  In that case, the recipient SHOULD
   include a "csup" attribute in the SDP answer listing the 
   SDP Capability Negotiation extensions it actually supports.

Section 3.4.1, 

The examples omit the "a=" for <att-par>. 
However, the text on p. 16 still mentions the full  '<type>=<value>'
form 
--> " ... the attribute capability and <att-par> is an attribute ("a=")
in its full  '<type>=<value>' form (see
   [RFC4566])."


The example on page 26 shows that consecutive numbering of the potential
configuration is not required.
What about explicitly stating the same for the attribute capability
numbers by changing the 2nd para on p.17 to:
"Each occurrence of the "acap" attribute in the entire session
description MUST use a different value of <att-cap-num>. Numbering the
values of <att-cap-num> consecutively is NOT REQUIRED" ?

Section 3.4.2

Same comment as above about consecutive numbering of <trpr-cap-num>, in
case that multiple a=tcap lines are present.
--> see also comment on 3.6.1. below

Section 3.5.1, p.22, last para

The optional attribute capabilities are contained within a pair of angle
brackets ("[" and "]").
 --> aren't these only "brackets"?

Section 3.5.1, p.23

  o  "-m" is the delete-attributes
What about the following?
  o  "-m" indicates to delete all attributes from the media description
of the actual configuration

Section 3.6.1, p.30, 1st bullet
The following text  contradicts the example at page 26:
"... In either case, there MUST NOT be
      more than a single "a=tcap" attribute at the session-level and a
      single "a=tcap" attribute in each media description. If there is
      no need to indicate any transport protocols as transport protocol
      capabilities, then there will not be any "a=tcap" attributes
      either.  ... "
I don't remember why multiple a=tcap attributes are disallowed, but
would be fine with this restriction.
However the example on p.26 would have to be corrected. --> This
restriction would obsolete my comment on 3.4.2.

Section 3.6.2, p.37, 2nd para

" ... The "a=acfg" attribute MUST identify the
   configuration number for the selected potential configuration as
   well as the actual parameters that were used from that potential
   configuration; if the potential configuration included alternatives,
   the selected alternatives only MUST be included.  Only the known and
   supported parameters will be included. Unknown or unsupported
   parameters MUST NOT be included in the actual configuration
   attribute. In the case of attribute capabilities, only the known and
   supported capabilities are included; unknown or unsupported
   attribute capabilities MUST NOT be included."

This contradict the text from section 3.5.2, p.27, 1st bullet.

"o  A selected attribute configuration MUST include the delete-
      attributes and the selected alternative mo-att-cap-list (i.e.,
      containing all mandatory and optional capability numbers from the
      potential configuration, irrespective of whether the optional
      ones were supported or not)...."

I propose to change 3.5.2 that a=acfg: lists the mandatory plus the
chosen/used optional capability numbers.

Section 3.10, 1st para, last sentence --> spurious comma at the end

9 References:

RFC 3407 is stated as a normative reference. 
Shouldn't that  be informative as 3407 is no longer obsoleted and 3407
is not needed to implement 
capability negotiation.

That's all

Regards
Thomas


> -----Original Message-----
> From: Joerg Ott [mailto:[e-mail]] 
> Sent: Friday, November 02, 2007 9:04 PM
> To: mmusic
> Cc: Flemming Andreasen; Cullen Jennings; Jean-Francois Mule
> Subject: [MMUSIC] WGLC: 
> draft-ietf-mmusic-sdp-capability-negotiation-07
> 
> Folks,
> 
> this is to announce WGLC ending on 23 November 2007 for
> draft-ietf-mmusic-sdp-capability-negotiation-07.txt
> (three weeks because of the document size)
> 
> The document is targeted for publication as Proposed Standard.
> 
> Please send your WGLC comments to the MMUSIC list, the
> chairs, and the authors.
> 
> Joerg
> 
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mmusic
> 


_______________________________________________
mmusic mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mmusic