Session Description Protocol (SDP) Capability Negotiation
draft-ietf-mmusic-sdp-capability-negotiation-13

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 Capability Negotiation' to Proposed Standard

The IESG has approved the following document:

- 'SDP Capability Negotiation '
   <draft-ietf-mmusic-sdp-capability-negotiation-13.txt> as a Proposed Standard


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

The IESG contact persons are Robert Sparks and Gonzalo Camarillo.

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

Ballot Text

Technical Summary

This document defines a general SDP Capability Negotiation framework.  It
also specifies how to provide attributes and transport protocols as
capabilities and negotiate them using the framework.
          
Working Group Summary

The MMUSIC Working Group has consensus to publish this document as a
Proposed Standard.
          
Document Quality

This mechanism was specifically designed to allow some shortcomings seen
in the field that could help deploy secure RTP (SRTP).  See page 11 of the
document, these SDP extensions allow an SDP agent to offer both RTP and
SRTP as alternatives, with SRTP being the preferred option using the
Offer/Answer mechanism.

    
Personnel

The Proto Shepherd is Jean-Francois Mule, and the Responsible Area
Director is Robert Sparks. Cullen Jennings was the Responsible Area
Director for the majority of this document's IESG processing.

RFC Editor Note

  (These notes apply to version 13 of the document)

  Please delete the entire following paragraph from Section 3.10:

    The Transport Independent Application Specific Maximum (TIAS)
    bandwidth type as defined in [RFC3890] SHOULD NOT be used to try and
    alleviate bandwidth variability concerns due to different transport
    protocols, since there are some inconsistencies between [RFC3264]
    and [RFC3890]. More specifically, [RFC3264] defines the bandwidth
    parameter to apply to the receive direction for unicast streams,
    whereas [RFC3890] intends to use bandwidth in the send direction.
    Implementers are encouraged to look for an expected future solution
    to this.

  and remove the following Informative Reference:
   [RFC3890] M. Westerlund, "A Transport Independent Bandwidth Modifier
             for the Session Description Protocol (SDP).", RFC 3890,
             September 2004.

RFC Editor Note