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

Fleming,

thanks for taking into account the comments.

Just an small addition to the "consecutive numbering for acap" comment.
I forgot to mention that a similar explicit statement statement for the
potential configuration number 
would be good (as already reflected in the example of p.26)

Propose to add the following to the end of the 3rd last para on p. 20:
Numbering the values of <config-number> consecutively is NOT REQUIRED. 

Thanks 
Thomas

________________________________

	From: Flemming Andreasen [mailto:fandreas@cisco.com] 
	Sent: Monday, November 26, 2007 8:25 PM
	To: Stach, Thomas
	Cc: mmusic; Cullen Jennings; Jean-Francois Mule; Joerg Ott
	Subject: Re: [MMUSIC] WGLC:
draft-ietf-mmusic-sdp-capability-negotiation-07

	Stach, Thomas wrote: 

		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.

	ok

		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])."

	Thanks - what it should have said was 
	"... the attribute capability and <att-par> is an attribute
("a=") in its "<attribute>" or <attribute>:<value>" form (i.e. excluding
the "a=" part). 

		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" ?

	ok.

		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

	Your comment on 3.6.1 is correct, so there will not be any
change here on 3.4.2. 

		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"?

	We may need a native english writer for this one, but looking
into it relatively quickly, "bracket" seems to be a generic term
covering different styles of brackets. The term "angle bracket" seems to
refer to "<" and ">", whereas "[" and "]" go by various names, but there
seems to be consensus that "square bracket" refers to that style of
bracket, so I'll change it to that. 

		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

	ok.

		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.

	Good catch - I'll change the example. 

	The reason we disallowed multiple "tcap" attributes per media
description was for simplicyt; people did not like having multiple ways
of doing the same thing. 

		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.

	Another good catch - I agree with the change to align 3.5.2 with
3.6.2. 

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

	ok.

		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.

	Indeed. 

		That's all

	Thanks for the careful review and comments. 

	-- Flemming 

		Regards
		Thomas

			-----Original Message-----
			From: Joerg Ott [mailto:jo@netlab.tkk.fi] 
			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
			mmusic@ietf.org
			https://www1.ietf.org/mailman/listinfo/mmusic