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

Sounds good.

Thanks

-- Flemming

Stach, Thomas wrote:
> 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
>>>
>>>         
>>
>>       
>