Re: [MMUSIC] WGLC for SDP Media Capabilities Negotiation - end 8/20

[Ingemar Johansson S <[e-mail]>]

Hi

Some comments on SDPMedCapNeg = "SDP Media Capability Negotiation"

BTW. The link below clearly indicates that there is a clear need for SDP for Media Capabilities Negotiation.  
http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_60/Docs/S4-100562.zip
The doc proposed a new set of SDP parameters but I would say that "SDPCapNeg & son" is a better and more generic alternative.

Regards
/Ingemar

Minor question: This draft has the caption "CMED" in the header while SDPCapNeg has "SDP Capability Negotiation". For the sake of uniformity it is perhaps better to rename "CMED" to "SDP Media Capability Negotiation".

bcap: If I recall things correctly it was discussed at IETF 77 to move bcap back to this draft, this is however not the case as bcap is still in http://tools.ietf.org/html/draft-ietf-mmusic-sdp-misc-cap-00 . I have no problem with this if this is the final descision. I note however that bcap is mentioned mentioned in SDPMedCapNeg in one location (page 9), I guess this should be removed as SDP Misc Cap is not referenced.


Some more, mainly small nits. Give the comments the respect you believe they deserve: 

One problem (that I have with most specs) is that the normative parts are spread out across the entire doc, this is the case with this doc as well. In some cases I found that examples are normative text are mixed (see e.g 3.3.8) 

3.3.1: 
add "; defined in [RFC4566]" in ABNF (after token)

3.3.4.1:
 Title says "...(+m=)" while title for 3.4.4.2 says just "...(=pt)". I would believe that "+" is unnecessary

3.3.4.3: Precede ABNF part with "In ABNF:" (done in the previous sections)

3.3.5: "The use of the "+"
   prefix with a parameter indicates that the entire configuration must
   be ignored if the parameter is not understood; otherwise, the
   parameter itself may be ignored." Shouldn't it be MUST and MAY here ?

3.3.6.1: "For this reason, it seems advisable for the
   offerer to include most, if not all, potential and latent
   configurations in the initial offer." Why not use RECOMMENDED or SHOULD here?

3.3.6.3: "which case all base level attributes of the
   same type and payload type number will be ignored. Any media-
   specific attributes in the media block which refer to payload type
   numbers not used by the potential configuration will be ignored". Isn't MUST more appropriate than "will" ?

3.3.7: Is the substitution specified well enough ?. I understand it from reading the text, however the ABNF "% *DIGIT %" is embedded in the text.

3.3.8: "Use of session capability attributes requires that configuration
   numbers assigned to potential and latent configurations be unique
   across the entire session; " Isn't normative language needed here? 
 "Session capabilities MAY include latent capabilities as well." 
Normative text, can this be moved higher up in the section (before the examples). ?

"The choices of session capabilities may be based on processing load,
   total bandwidth, or any other criteria of importance to the
   communicating parties.  If the answerer supports media capabilities
   negotiation, and session configurations are offered, it must accept
   one of the offered configurations, or it must refuse the session.
   Therefore, if the offer includes any session capabilities, it should
   include all the session capabilities the offerer is willing to
   support". Some parts are clearly normative. Should perhaps be moved to beginning of section and upper case considered.

3.4.4: Modifying the session: Alice sends a SIP-INVITE to Bob. What happens if Bob moves his call to another device. Will all the acap,mcap etc follow when the call is moved?. I admit that I lack some SIP knowledge here.

4.1 Examples: Some of the examples use numbering while others don't, no big deal but it looks a bit non-uniform.

 





> Message: 1
> Date: Fri, 30 Jul 2010 07:54:26 -0600
> From: Jean-Francois Mule <[e-mail]>
> Subject: [MMUSIC] WGLC for SDP Media Capabilities Negotiation - end
> 	8/20
> To: "[e-mail]" <[e-mail]>
> Cc: "[e-mail]"
> 	<[e-mail]>
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset="us-ascii"
> 
> 
> This is to announce a WGLC for SDP Media Capabilities 
> Negotiation draft-ietf-mmusic-sdp-media-capabilities-10 to 
> progress as Proposed Standard.
> http://tools.ietf.org/html/draft-ietf-mmusic-sdp-media-capabilities-10
> 
> Please review and comment on the document by COB Friday 
> August 20, 2010.
> Send all editorial and technical comments to the authors and 
> the mmusic WG list.
> 
> Thank you,
> Jean-Francois.
> MMUSIC co-chair
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 
> <http://www.ietf.org/mail-archive/web/mmusic/attachments/20100
> 730/a51adbed/attachment.htm>
> 
> ------------------------------
> 
> Message: 2
> Date: Fri, 30 Jul 2010 08:15:38 -0600
> From: Jean-Francois Mule <[e-mail]>
> Subject: [MMUSIC] Confirming WG work item and scope for SDP misc-cap
> 	(bcap+icap but not ccap)
> To: "[e-mail]" <[e-mail]>
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset="us-ascii"
> 
> 
> Based on IETF#77's meeting notes and the WG chair slides 
> presented at IETF#78 this week, this note is to confirm on 
> the list that there is interest in defining SDP capability 
> negotiation extensions for the i= and b= lines as part of 
> what we've named SDP capneg misccap.
> 
> It should be noted that there is no consensus at this time on 
> the definition of ccap (section 3.1.2. of 
> http://tools.ietf.org/html/draft-ietf-mmusic-sdp-misc-cap-00).
>   This part should therefore be removed from the next 
> revision of the document.
> 
> Unless we hear any concerns of objections by Friday August 6 
> COB, we will propose a formal WG milestone for misc-cap 
> inline with the above scope.
> 
> Tom & Jean-Francois
> MMUSIC co-chairs.
> 
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
> 
> 
> End of mmusic Digest, Vol 75, Issue 12
> **************************************
>