Skip to main content

SDP: Session Description Protocol
draft-ietf-mmusic-sdp-new-26

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    mmusic mailing list <mmusic@ietf.org>, 
    mmusic chair <mmusic-chairs@tools.ietf.org>
Subject: Protocol Action: 'SDP: Session Description Protocol' to 
         Proposed Standard 

The IESG has approved the following document:

- 'SDP: Session Description Protocol '
   <draft-ietf-mmusic-sdp-new-27.txt> as a Proposed Standard

This document is the product of the Multiparty Multimedia Session Control 
Working Group. 

The IESG contact persons are Jon Peterson and Cullen Jennings.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-27.txt

Ballot Text

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

In particular, this document provides a new version of SDP that incorporates
fixes and extensions that have been designed in the MMUSIC WG since the
publication of the original SDP specification, RFC2327. This document is not
SDPng, which fundamentally re-examines the problem space of SDP and arrives
at a new solution. Rather, this document collects increment fixes to SDP
that are critical to its proper operation, and merit inclusion in the core
standard.
 
Working Group Summary
 
The MMUSIC working group supported publication of this document.
 
Protocol Quality
 
This document was reviewed by Allison Mankin and Jon Peterson.

RFC-Editor Note

Please append to the start of Section 9:

OLD: 

9.  SDP Grammar

NEW:

9.  SDP Grammar
   
   This section provides a grammar for SDP.  It uses a variant of
   ABNF [4].  In this variant, contrary to section 2.3 of [4], strings
   are *not* case-insensitive, and must match exactly the case specified.

Security Considerations, last paragraph:

OLD:

   Use of the "k=" field poses a significant security risk, since it
   conveys session encryption keys in the clear.  SDP MUST NOT be used
   to convey key material, unless it can be guaranteed that the channel
   over which the SDP is delivered is both private and authenticated.

NEW:

   Use of the "k=" field poses a significant security risk, since it
   conveys session encryption keys in the clear.  SDP MUST NOT be used
   to convey key material, unless it can be guaranteed that the channel
   over which the SDP is delivered is both private and authenticated.
   Moreover, the k= line provides no way to indicate or negotiate 
   cryptographic key algorithms, and as it provides for only a single 
   symmetric key, rather than separate keys for confidentiality and 
   integrity, its utility is severely limited. Use of the k= line is 
   NOT RECOMMENDED, and any usage of the k= line MUST address these 
   shortcomings.

RFC Editor Note