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