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

From: Joerg Ott <[email-masked]>
Date: Fri, 02 Nov 2007 22:04:20 +0200

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 5 Nov 2007 18:17:58 -0600

Here is my first WGLC comment.

(clarified a previous email I've already sent).

MAJOR:

Comment 1: INCONSISTENCY IN TWO IDENTICAL EXAMPLES.
---------------------------------------------------

There is an example on p. 11 that includes the following Offer:

 Alice's offer includes RTP and SRTP as alternatives. RTP is the 
   default (actual configuration), but SRTP is the preferred one 
   (potential configuration): 

      v=0 
      o=- 25678 753849 IN IP4 192.0.2.1 
      s=  
      c=IN IP4 192.0.2.1 
      t=0 0 
      m=audio 53456 RTP/AVP 0 18  
      a=tcap:1 RTP/SAVP  <--------- ONLY RTP/SAVP is listed
      a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_32    
         inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32  
      a=pcfg:1 t=1 a=1   

   The "m=" line indicates that Alice is offering to use plain RTP with 
   PCMU or G.729.  The capabilities are provided by the "a=tcap" and 
   "a=acap" attributes. The transport capabilities ("a=tcap") indicate 
   that secure RTP under the AVP profile ("RTP/SAVP") is supported with 
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   an associated transport capability handle of 1. The "acap" attribute 
   provides an attribute capability with a handle of 1. The attribute 
   capability is a "crypto" attribute, which provides the keying 
   material for SRTP using SDP security descriptions [RFC4568]. The 
   "a=pcfg" attribute provides the potential configuration included in 
   the offer by reference to the capability parameters.  One 
   alternative is provided; it has a configuration number of 1 and it 
   consists of transport protocol capability 1 (i.e. the RTP/SAVP 
   profile - secure RTP), and the attribute capability 1, i.e. the 
   crypto attribute provided. Potential configurations are preferred 
   over the actual configuration included in the offer SDP, and hence 
   Alice is expressing a preference for using secure RTP. 

 On p. 50, the same nearly identical text, for the same example, but
with a 
 different SDP:

   Alice's offer includes RTP and SRTP as alternatives. RTP is the 
   default, but SRTP is the preferred one: 

      v=0 
      o=- 25678 753849 IN IP4 192.0.2.1 
      s=  
      c=IN IP4 192.0.2.1 
      t=0 0 
      m=audio 53456 RTP/AVP 0 18  
      a=tcap:1 RTP/SAVP RTP/AVP   <------- BOTH RTP/SAVP and RTP/AVP are
listed
                        ^^^^^^^
      a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_80              
         inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4  
         FEC_ORDER=FEC_SRTP 
      a=pcfg:1 t=1 a=1 
       
   The "m=" line indicates that Alice is offering to use plain RTP with 
   PCMU or G.729.  The capabilities are provided by the "a=tcap" and 
   "a=acap" attributes.  The "tcap" capability indicates that both 
   Secure RTP and normal RTP are supported. The "acap" attribute 
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   provides an attribute capability with a handle of 1. The capability 
   is a "crypto" attribute, which provides the keying material for SRTP 
   using SDP security descriptions [RFC4568]. The "a=pcfg" attribute 
   provides the potential configurations included in the offer by 
   reference to the capabilities.  A single potential configuration 
   with a configuration number of "1" is provided. It includes the 
   transport protocol capability 1 (RTP/SAVP, i.e. secure RTP) together 
   with the attribute capability 1, i.e. the crypto attribute provided.

   Note that attribute capability 1 is mandatory, and hence it must be 
   supported in order for the potential configuration to be used.  

I've highlighted the apparent description of the difference, but I don't

understand the difference. In both cases, SAVP is preferred, and AVP is 
the backup. Why do we have 2 examples of two apparently identical
scenarios,
but with a different Offer?

I'm requesting clarification in the document on what is the meaning of
using
both SAVP and AVP versus only SAVP in the tcap line.

> -----Original Message-----
> From: Joerg Ott [mailto:[email-masked]] 
> Sent: Friday, November 02, 2007 13:04
> To: mmusic
> Cc: Flemming Andreasen; Cullen Jennings; Jean-Francois Mule
> Subject: [MMUSIC] WGLC: 
> draft-ietf-mmusic-sdp-capability-negotiation-07
> 
> Folks,
>

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 05 Nov 2007 20:57:54 -0500

> Comment 1: INCONSISTENCY IN TWO IDENTICAL EXAMPLES.
There is no semantic difference between the two examples as shown. We 
can address this is one of two ways
1) Make the examples the same
2) Explain that they are semantically identical, even though they look 
different.

My preference is for 2), since it seems the functionality is causing 
some confusion. However removing it from an example does not remove it 
from the protocol, so probably best to just explain the second one better.

Will that address your comment ?

-- Flemming

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 5 Nov 2007 20:02:59 -0600

I will be happy with either proposal.
 
My personal preference would be to make the example the same, and define
a rule for which to use when a UAC is sending an offer: either always
repeat or never repeat. Don't have a preference either way.
 
And on the UAS side, accept both reapeated or not as meaning the same.
 
This is to avoid people imagining differences when there are none.
 
Also, provided that we agree on the 2-offer answer issue (see next
posting), then we could completely remove one of the redundant examples,
since they would be indentical. Would simplify the document.

________________________________

	From: Flemming Andreasen [mailto:[email-masked]] 
	Sent: Monday, November 05, 2007 17:58
	To: Audet, Francois (SC100:3055)
	Cc: mmusic; Joerg Ott; Jean-Francois Mule
	Subject: Re: WGLC:
draft-ietf-mmusic-sdp-capability-negotiation-07: Comment 1

	Francois Audet wrote: 

		MAJOR:

		There is an example on p. 11 that includes the following
Offer:
		
		 Alice's offer includes RTP and SRTP as alternatives.
RTP is the 
		   default (actual configuration), but SRTP is the
preferred one 
		   (potential configuration): 
		
		      v=0 
		      o=- 25678 753849 IN IP4 192.0.2.1 
		      s=  
		      c=IN IP4 192.0.2.1 
		      t=0 0 
		      m=audio 53456 RTP/AVP 0 18  
		      a=tcap:1 RTP/SAVP  <--------- ONLY RTP/SAVP is
listed
		      a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_32    

		   The "m=" line indicates that Alice is offering to use
plain RTP with 
		   PCMU or G.729.  The capabilities are provided by the
"a=tcap" and 
		   "a=acap" attributes. The transport capabilities
("a=tcap") indicate 
		   that secure RTP under the AVP profile ("RTP/SAVP") is
supported with 
	
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
		   an associated transport capability handle of 1. The
"acap" attribute 
		   provides an attribute capability with a handle of 1.
The attribute 
		   capability is a "crypto" attribute, which provides
the keying 
		   material for SRTP using SDP security descriptions
[RFC4568]. The 
		   "a=pcfg" attribute provides the potential
configuration included in 
		   the offer by reference to the capability parameters.
One 
		   alternative is provided; it has a configuration
number of 1 and it 
		   consists of transport protocol capability 1 (i.e. the
RTP/SAVP 
		   profile - secure RTP), and the attribute capability
1, i.e. the 
		   crypto attribute provided. Potential configurations
are preferred 
		   over the actual configuration included in the offer
SDP, and hence 
		   Alice is expressing a preference for using secure
RTP. 
		
		 On p. 50, the same nearly identical text, for the same
example, but
		with a 
		 different SDP:
		
		   Alice's offer includes RTP and SRTP as alternatives.
RTP is the 
		   default, but SRTP is the preferred one: 
		
		      v=0 
		      o=- 25678 753849 IN IP4 192.0.2.1 
		      s=  
		      c=IN IP4 192.0.2.1 
		      t=0 0 
		      m=audio 53456 RTP/AVP 0 18  
		      a=tcap:1 RTP/SAVP RTP/AVP   <------- BOTH RTP/SAVP
and RTP/AVP are
		listed
		                        ^^^^^^^
		      a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_80

		   The "m=" line indicates that Alice is offering to use
plain RTP with 
		   PCMU or G.729.  The capabilities are provided by the
"a=tcap" and 
		   "a=acap" attributes.  The "tcap" capability indicates
that both 
		   Secure RTP and normal RTP are supported. The "acap"
attribute 
		   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
		   provides an attribute capability with a handle of 1.
The capability 
		   is a "crypto" attribute, which provides the keying
material for SRTP 
		   using SDP security descriptions [RFC4568]. The
"a=pcfg" attribute 
		   provides the potential configurations included in the
offer by 
		   reference to the capabilities.  A single potential
configuration 
		   with a configuration number of "1" is provided. It
includes the 
		   transport protocol capability 1 (RTP/SAVP, i.e.
secure RTP) together 
		   with the attribute capability 1, i.e. the crypto
attribute provided.
		
		   Note that attribute capability 1 is mandatory, and
hence it must be 
		   supported in order for the potential configuration to
be used.  
		
		I've highlighted the apparent description of the
difference, but I don't
		
		understand the difference. In both cases, SAVP is
preferred, and AVP is 
		the backup. Why do we have 2 examples of two apparently
identical
		scenarios,
		but with a different Offer?
		
		I'm requesting clarification in the document on what is
the meaning of
		using
		both SAVP and AVP versus only SAVP in the tcap line.

	There is no semantic difference between the two examples as
shown. We can address this is one of two ways
	1) Make the examples the same
	2) Explain that they are semantically identical, even though
they look different. 
	
	My preference is for 2), since it seems the functionality is
causing some confusion. However removing it from an example does not
remove it from the protocol, so probably best to just explain the second
one better. 

	-- Flemming 

		

			-----Original Message-----
			From: Joerg Ott [mailto:[email-masked]] 
			Sent: Friday, November 02, 2007 13:04
			To: mmusic
			Cc: Flemming Andreasen; Cullen Jennings;
Jean-Francois Mule
			Subject: [MMUSIC] WGLC: 
			
			Folks,
			
			this is to announce WGLC ending on 23 November
2007 for 

			The document is targeted for publication as
Proposed Standard.
			
			Please send your WGLC comments to the MMUSIC
list, the 
			chairs, and the authors.
			
			Joerg

---

From: "Stach, Thomas" <[email-masked]>
Date: Thu, 22 Nov 2007 14:33:39 +0100

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

> Sent: Friday, November 02, 2007 9:04 PM
> To: mmusic

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 26 Nov 2007 10:02:39 +0000

A few late comments (apologies if already submitted by others):

1. In 3.3.2:
"Support for the basic negotiation framework 
   is implied by the presence of an "a=pcfg" attribute (see Section 
   3.5.1. ) and hence there is no need to include the "a=creq" 
   attribute with the base option-tag ("cap-v0"). Still, it is allowed 
   to do so."
I found this rather strange, because it talks about support yet it is in
the section on required extensions. The point that should be made is
that any recipient that understands the a=creq attribute would indeed
support at least cap-v0, so there is no point in including it.

2. In 3.6.1:
"One or more transport protocol capability attributes ("a=tcap") 
      as defined in Section 3.4.2. with values for each transport 
      protocol that needs to be indicated as a capability in the offer."
This is preceded by a MUST before the start of the bullets. Yet later in
this bullet it says there need not be any a=tcap parameters - seems to
be a contradiction.

3. "One or more extension capability attributes (as outlined in 
      Section 3.4.3. ) for each extension capability that is referenced 
      by a potential configuration."
Again, there is a MUST before the bullets.
I have two problems with this text. Can there be zero extension
capability attributes? Reading it literally, I guess there could be zero
extension capabilities that need to be referenced, and hence zero
extension capability attributes. However, with this interpretation there
could be more than one extension capability attribute for each extension
capability, and I am not sure that is the intention.

4. In 3.6.2 (an extremely long section!) I had a problem in that an
answerer could identify a "valid potential configuration" according to
all the considerations listed there, but basically these considerations
just seem to take into account whether the offer is well-formed and
whether all the capabilities in a configuration are supported. What if
all the capabilities in a given configuration are supported, making it a
valid configuration, but nevertheless are not available at the present
time? I found one statement:
"In the case of attribute capabilities, support 
   implies that the attribute name contained in the capability is 
   supported and it can (and will) be used successfully in the 
   negotiation process with the value provided."
This probably covers my concern for attributes, but I couldn't find a
similar statement for transports and extensions. For example, what if a
UA like a gateway has limited SRTP resources? It may support RTP/SAVP
for some calls, but when all resources are exhausted it may be unable to
support RTP/SAVP (but still support RTP/AVP).

John

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 26 Nov 2007 14:25:19 -0500

>    SDP Capability Negotiation extensions it actually supports.
ok

> in its full  '<type>=<value>' form (see
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).

> values of <att-cap-num> consecutively is NOT REQUIRED" ?
ok.

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

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

> of the actual configuration
ok.
> 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.

> 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.
> is not needed to implement 
Indeed.
> That's all

Thanks for the careful review and comments.

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 26 Nov 2007 14:39:19 -0500

> support at least cap-v0, so there is no point in including it.
I'll move the support part to Section 3.3.1 on the "csup" attribute and 
add your point about the "creq" attribute itself in Section 3.3.2.

> this bullet it says there need not be any a=tcap parameters - seems to
The latter part that says "....that needs to be indicated as a 
capability in the offer" should imply that if you don't have a need to 
indicate any transport capability, then there won't be any transport 
capability either (but you are still satisfying the MUST). Maybe that 
writing style is inclear and we should rather have the MUST included 
explicitly in each bullet in this list ?

> extension capability attributes.
Exactly.
>  However, with this interpretation there
I'll rephrase the bullet list to have an explict MUST per bullet.
> support RTP/SAVP (but still support RTP/AVP).
I can add a similar statement for transports, but I'm reluctant to do it 
for extensions. Consider media capabilities, where we may have two 
codecs, A and B, as part of a potential configuration. Normal 
offer/answer rules would deem negotiation successful if we can support 
just one of them, and I wouldn't want to change that here. I can add a 
general statement about extensions saying they need to specificy 
additional rules for when they constitute a valid configuration - would 
that address your concern ?

Thanks

-- Flemming

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 26 Nov 2007 21:46:26 +0000

Flemming,

Thanks for considering my comments. See below.

John 

> Sent: 26 November 2007 19:39
> To: Elwell, John
> Cc: [email-masked]; [email-masked]; Jean-Francois Mule; Cullen Jennings
> Subject: Re: [MMUSIC] WGLC: 
[JRE] I think the support bit is already covered in 3.3.1 with the
following text:
"Inclusion of the base option tag is 
   OPTIONAL; support for the base framework can be inferred from 
   presence of the "a=pcfg" attribute defined in Section 3.5.1."
So I think you only need to fix 3.3.2 concerning creq.

> explicitly in each bullet in this list ?
[JRE] I guess what I really had in mind was to say "Zero or more
transport protocol capability attributes..."

> I'll rephrase the bullet list to have an explict MUST per bullet.
[JRE] Alternatively, could we say "Zero or more extension capability
atttributes..."?

> that address your concern ?
[JRE]Yes

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 26 Nov 2007 17:02:31 -0500

I agree with your comments below John, so I think we are in sync at this 
point.

Thanks for the review and feedback.

-- Flemming

Elwell, John wrote:
>>>    attribute with the base option-tag ("cap-v0"). Still, it 
>>>       
>> is allowed 
>>     
>>>    to do so."
>>> I found this rather strange, because it talks about support 
>>>       
>> yet it is in
>>     
>>> that any recipient that understands the a=creq attribute 
>>>       
>> would indeed
>>     
>>>       protocol that needs to be indicated as a capability 
>>>       
>> in the offer."
>>     
>>> This is preceded by a MUST before the start of the bullets. 
>>>       
>> Yet later in
>>     
>>> this bullet it says there need not be any a=tcap parameters 
>>>       
>> - seems to
>>     
>>> be a contradiction.
>>>   
>>>       
>>>       Section 3.4.3. ) for each extension capability that 
>>>       
>> is referenced 
>>     
>>> capability attributes? Reading it literally, I guess there 
>>>       
>> could be zero
>>     
>>> could be more than one extension capability attribute for 
>>>       
>> each extension
>>     
>>> answerer could identify a "valid potential configuration" 
>>>       
>> according to
>>     
>>> all the considerations listed there, but basically these 
>>>       
>> considerations
>>     
>>> whether all the capabilities in a configuration are 
>>>       
>> supported. What if
>>     
>>> all the capabilities in a given configuration are 
>>>       
>> supported, making it a
>>     
>>> valid configuration, but nevertheless are not available at 
>>>       
>> the present
>>     
>>> This probably covers my concern for attributes, but I 
>>>       
>> couldn't find a
>>     
>>> similar statement for transports and extensions. For 
>>>       
>> example, what if a
>>     
>>> UA like a gateway has limited SRTP resources? It may 
>>>       
>> support RTP/SAVP
>>     
>>> for some calls, but when all resources are exhausted it may 
>>>       
>> be unable to
>>

---

From: "Stach, Thomas" <[email-masked]>
Date: Tue, 27 Nov 2007 18:32:35 +0100

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:[email-masked]] 
	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,

		
		   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.

		   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.

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

		
		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.

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

	-- Flemming 

		Regards
		Thomas

			-----Original Message-----
			From: Joerg Ott [mailto:[email-masked]] 
			Sent: Friday, November 02, 2007 9:04 PM
			To: mmusic
			Cc: Flemming Andreasen; Cullen Jennings;
Jean-Francois Mule
			Subject: [MMUSIC] WGLC: 
			
			Folks,

			

			Joerg

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 27 Nov 2007 12:51:43 -0500

Sounds good.

Thanks

-- Flemming

Stach, Thomas wrote:
> I forgot to mention that a similar explicit statement statement for 
> the potential configuration number
>     ------------------------------------------------------------------------
>     *From:* Flemming Andreasen [mailto:[email-masked]]
>     *Sent:* Monday, November 26, 2007 8:25 PM
>     *To:* Stach, Thomas
>     *Cc:* mmusic; Cullen Jennings; Jean-Francois Mule; Joerg Ott
>     *Subject:* Re: [MMUSIC] WGLC:
>     "... the attribute capability and <att-par> is an attribute ("a=")
>     in its "<attribute>" or <attribute>:<value>" form (i.e. excluding
>     the "a=" part).
>
>     Your comment on 3.6.1 is correct, so there will not be any change
>     here on 3.4.2.
>
>
>     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
>>
>     description was for simplicyt; people did not like having multiple
>     ways of doing the same thing.
>