[MMUSIC] draft-ietf-mmusic-sdp-new-15.txt

[Colin Perkins <[e-mail]>]

I've just submitted draft-ietf-mmusic-sdp-new-15.txt to address IESG 
concerns and other comments raised on the mailing list. Changes since 
-14 include:

- Update references:
         RFC 1889 -> RFC 3550
         RFC 1890 -> RFC 3551
         draft-ietf-mmusic-sdp4nat-05.txt -> RFC 3605
- Clarify that b= may be duplicated
- Clarify that multiple addresses or "c=" lines can only be specified if
   they provide multicast addresses for different layers
- Clarify use of b= with layered coding:
         When using the CT modifier with RTP, if several RTP sessions are
         part of the conference, the conference total refers to total
         bandwidth of all RTP sessions.
- Clarify which ports are associated with an m= line when layered coding
   is used
- Remove extra ")" from the definition of m1 in the ABNF
- Add reference to RFC2396 in definition of u=
- Add MIME registration to the IANA Considerations section, and note 
that
   this draft updates RFC 2327
- In the description of "k=", note that S/MIME email and TLS protected 
HTTP
   and SIP might be appropriate secure transports for SDP. Also note 
that it
   is necessary to "ensure that the secure channel is with the party 
that is
   authorized to join the session, not an intermediary" and "If a caching
   server is used, there ought to be a way to keep the server from 
accessing
   the key"
- The recommendation that systems "SHOULD NOT deliver the user into an
   interactive multimedia session without the user being aware that this
   will happen" in the Security Considerations section was strengthened 
to
   "MUST NOT deliver the user into an interactive multimedia session 
unless
   the user has explicitly pre-authorized such action"
- A comment in the ABNF for "token-char" allowed a larger set of 
characters
   than the actual definition. The comment has been removed, leaving the 
set
   of allowed characters as specified in the ABNF
- Clarify that UTF-8 normalization is not needed because comparisons are
   not done on fields with UTF-8.
- Clarify that k= is NOT RECOMMENDED and give pointers to the 
sdescriptions
   and key-mgmt drafts.
- Clarify that k= does not include an algorithm identifier, key type, or
   any other information about the key.
- Clarify that k= does not support the transfer of two keys
- Remove reference to RFC 3551/1890 from the description of k=, since 
that
   nowhere specified how k= was used.
- Note that a session description may contain URIs which may be 
dereferenced.
   This makes the SDP non-self contained.
- Remove "Changes from RFC 2327" section, since it was very inaccurate 
and
   outdated.

Feedback on these changes would be appreciated.

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