Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-capability-negotiation-01.txt

From: [email-masked]
Date: Mon, 29 Jan 2007 15:50:02 -0500

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.

	Title		: SDP Capability Negotiation
	Author(s)	: F. Andreasen
	Filename	: draft-ietf-mmusic-sdp-capability-negotiation-01.txt
	Pages		: 29
	Date		: 2007-1-29
	
The Session Description Protocol (SDP) was intended for describing 
        multimedia sessions for the purposes of session announcement, session 
        invitation, and other forms of multimedia session initiation. SDP was 
        not intended to provide capability indication or capability 
        negotiation, however over the years, SDP has seen widespread adoption 
        and as a result it has been gradually extended to provide limited 
        support for these. SDP and its current extensions however do not have 
        the ability to negotiate one or more alternative transport protocols 
        (e.g. RTP profiles) which makes it particularly difficult to deploy 
        new RTP profiles such as secure RTP or RTP with RTCP-based feedback.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-capability-negotiation-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-mmusic-sdp-capability-negotiation-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-sdp-capability-negotiation-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Colin Perkins <[email-masked]>
Date: Wed, 31 Jan 2007 15:30:52 +0000

> capability-negotiation-01.txt

This draft is in very good shape. I do have some minor and editorial  
comments, though, to follow on from the discussions in the conference  
call yesterday:

The "Conventions Used in this Document" section needs to be located  
after the Introduction, before the current Section 2.

As I mentioned in the call, I find "a=ctrpr" difficult to read and  
remember. It would be easier if all capability attributes had a  
common style, perhaps "a=capar" for attributes, "a=ctpar" for  
transport, and "a=cmpar" for media; or maybe "a=acap", "a=tcap", and  
"a=mcap"?

I was surprised white space was permitted before the <option-tag- 
list> in "a=csup:" and "a=creq". That seems inconsistent with typical  
SDP practice.

In Section 2.2.2 the paragraph starting "When an entity generates an  
SDP..." says the "a=creq" attribute "MUST be included..., unless".  
Maybe "SHOULD be included..., unless" is intended?

In Section 2.3.1, it would be helpful if the grammar for "a=capar:"  
could be expressed as ABNF, presumably referencing the "attribute"  
element from RFC 4566. Similar comments apply to Section 2.3.2 and  
2.4.1.

In Section 2.3.1, is white space allowed between "a=capar:" and the  
<att-cap-num> field? I recommend not, for consistency with other SDP  
attributes. This will mean the examples later in the draft need to be  
updated. Similar comments apply for the other new attributes, and the  
later examples.

In Section 2.3.1, can we make the range of <att-cap-num> be  
1...2^31-1 (both included)? That's still more space than we'll need,  
and it makes things more efficient for users of a certain programming  
language. Also in Section 2.3.2 and 2.4.1.

In Section 2.3.1, second paragraph on page 12, <app-cap-num> should  
be <att-cap-num>?

In Section 2.3.1, note that the lines of the examples have been  
wrapped to fit the page, and are single lines in SDP.

In Section 2.4.1, the "|" character is invalid ABNF, "/" is used to  
specify alternatives. Similar in Section 2.4.2.

In Section 3.1, I suggest the example omit the second potential  
configuration, to show the simplest case, and have a second example  
with both configurations listed. More examples in general would be  
helpful.

The idnits tool also finds a number of nits (the boilerplate will  
presumably need fixing, or the secretariat will bounce the next  
version).

idnits 1.124

draft-ietf-mmusic-sdp-capability-negotiation-01.txt:

   Checking nits according to http://www.ietf.org/ID-Checklist.html:

     Checking conformance with RFC 3978/3979 boilerplate...

   - This document has ISOC Copyright according to RFC 3978, instead  
of the
     newer IETF Trust Copyright according to RFC 4748.  You should  
consider
     updating it; the new Copyright statement will be required from  
February 1st,
     2007
   - This document has an original RFC 3978 Section 5.5 Disclaimer,  
instead of
     the newer disclaimer which includes the IETF Trust according to  
RFC 4748.
     You should consider updating it; the new disclaimer will be  
required from
     February 1st, 2007
   * There are 463 instances of too long lines in the document, the  
longest one
     being 5 characters in excess of 72.
   * There are 16 instances of lines with non-RFC3330-compliant IPv4  
addresses
     in the document.  If these are example addresses, they should be  
changed.

   Checking nits according to http://www.ietf.org/ietf/1id- 
guidelines.txt:
   - The page length should not exceed 58 lines per page, but there  
was 29
     longer pages, the longest (page 1) being 60 lines

   Miscellaneous warnings:
     None.

   Experimental warnings:
   - Missing Reference: 'Section 8' is mentioned on line 930, but not  
defined
   - Missing Reference: ' doing so is' is mentioned on line 930, but  
not defined
   - Unused Reference: 'RFC2234' is defined on line 1138, but not  
referenced
   - Unused Reference: 'RFC3407' is defined on line 1146, but not  
referenced
   - Unused Reference: 'RFC3605' is defined on line 1149, but not  
referenced
   - Unused Reference: 'RFC2046' is defined on line 1161, but not  
referenced
   - Unused Reference: 'RFC2327' is defined on line 1165, but not  
referenced
   - Unused Reference: 'RFC3388' is defined on line 1172, but not  
referenced
   - Unused Reference: 'RFC3851' is defined on line 1184, but not  
referenced
   - Unused Reference: 'RFC4091' is defined on line 1188, but not  
referenced
   - Unused Reference: 'BESRTP' is defined on line 1212, but not  
referenced
   - Unused Reference: 'SDPCapNegRqts' is defined on line 1221, but not
     referenced
   - Unused Reference: 'MIKEY' is defined on line 1228, but not  
referenced

-- 
Colin Perkins
http://csperkins.org/