Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-26.txt

From: [email-masked]
Date: Wed, 25 Jan 2006 18: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: Session Description Protocol
	Author(s)	: M. Handley, et al.
	Filename	: draft-ietf-mmusic-sdp-new-26.txt
	Pages		: 49
	Date		: 2006-1-25
	
This memo defines the Session Description Protocol (SDP).  SDP is
   intended for describing multimedia sessions for the purposes of
   session announcement, session invitation, and other forms of
   multimedia session initiation.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-26.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-new-26.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-new-26.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: Thu, 26 Jan 2006 00:35:39 +0000

> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-26.txt

This version is intended to address the GenART comments received  
during IESG review (http://www.alvestrand.no/ietf/gen/reviews/draft- 
ietf-mmusic-sdp-new-25-dawkins.txt). In addition the discussion of  
sharing ports between "m=" lines has been removed from section 5.14,  
since there was no consensus on that approach.

A complete list of changes is as follows:

- Fix reference to H.332 ([15] -> [25])
- Section 1: clarify that this obsoletes RFC 2327 and RFC 3266, rather
   than just updating RFC 2327.
- Section 3: mention that SDP is used by SIP/RTSP use before mentioning
   its use with SAP.  No longer comment that SAP is "commonly used", and
   remove the mention of SAP when discussing use of SDP with email/WWW.
- Section 4: clarify that sessions need not be continually active.
- Section 4.1: explain why it it NOT RECOMMENDED to redefine the  
semantics
   of the destination address/port. Correct use of RFC 2119 terms.
- Section 4.2: add cross reference to section 5.9
- Section 4.3: grammar fixes
- Section 4.5: add cross reference to "a=cat:" in section 6
- Section 5: correct use of RFC 2119 terms in penultimate paragraph  
(`the
   presence of the "a=charset" attribute MAY force' -> `...may  
force...')
- Section 5.2: clarify what is meant by "A local IP address MUST NOT be
   used in any context where the SDP description might leave the  
scope in
   which the address is meaningful"
- Section 5.9: simply note that permanent sessions are discouraged,  
rather
   than giving different degrees of discouragement for differing  
durations
- Section 5.10: simply state that the "s" unit specification  
character is
   allowed for completeness, rather than also stating that its use is  
"NOT
   RECOMMENDED" (the RFC 2119 term is too strong here).
- Section 5.12: clarify that "k=uri:" often uses SSL/TLS-protected HTTP
   (i.e. "https:") and not secure HTTP [RFC2660].
- Section 5.12: remove last sentence of the section, which confused
   operational security with protocol security.
- Section 5.14: remove discussion of sharing ports between "m=" lines,
   and instead not that the semantics of this are currently undefined,
   and that no implicit grouping is implied; add reference to RFC 3388
- Section 6: note that neither "a=cat:" nor "a=keywds:" have a central
   registry of legal values.
- Section 7 (1st paragraph): s/agree/agree on/. Note that SAP is no
   longer frequently used.
- Section 7 (2nd paragraph): clarify the security issues with using  
an SDP
   file obtained via an untrusted transport
- Section 7 (6th paragraph): clarify interactions with intermediary  
systems
   that parse SDP contained in signalling messages

I believe this is now ready to go to the RFC Editor.

Colin