Session Initiation Protocol (SIP) INFO Method and Package Framework
RFC 6086

Approval announcement
Draft of message to be sent after approval:

From: The IESG <>
To: IETF-Announce <>
Cc: Internet Architecture Board <>,
    RFC Editor <>,
    sipcore mailing list <>,
    sipcore chair <>
Subject: Protocol Action: 'Session Initiation Protocol (SIP) INFO Method and Package Framework' to Proposed Standard

The IESG has approved the following document:
- 'Session Initiation Protocol (SIP) INFO Method and Package Framework'
  <draft-ietf-sipcore-info-events-10.txt> as a Proposed Standard

This document is the product of the Session Initiation Protocol Core
Working Group.

The IESG contact persons are Robert Sparks and Gonzalo Camarillo.

A URL of this Internet Draft is:

    Technical Summary

      This document defines a SIP method, INFO, along with a framework
      for the ways in which various applications can make use of
      this method. It obsoletes the previous definition of INFO,
      provided by RFC 2976, while including backwards-compatibility
      considerations that allow those applications based on RFC
      2976 to continue to operate.

    Working Group Summary

      One of the recurring topics over the course of the development
      of a package mechanism for INFO was whether such a mechanism
      provides any true value.

      RFC 2976 originally defined the SIP INFO method in a scant 9
      pages (including boilerplate). Over time, its use as a catch-all
      for non-standard user-to-user data became recognized as a key
      barrier to interoperability.  For example, many vendors have
      defined their own, proprietary INFO-based mechanism for
      conveying DTMF ("TouchTone") information. However, none of
      these mechanisms have been published (in the IETF, in other
      standards bodies, or even in non-SDO documents), leading to
      severe fragmentation in the ability to convey this type of

      At the same time, many of the uses of INFO were recognized
      as being shortcuts to more appropriate and flexible mechanisms.
      For example, the conveyance of DTMF cited above is better
      suited to the mechanism defined in RFC 4733 when treated as
      an audio component, while the problem of general key-press
      conveyance is better handled by the mechanisms of RFC 4730.

      As a result of the foregoing, the working group spent significant
      discussion time over many years coming to agreement on whether
      it was more appropriate to fix INFO (by defining a registration
      mechanism for the ways in which it was used) or to deprecate
      it altogether (with the usage described in RFC 3398 being
      grandfathered as the sole legitimate usage).

      Although it required substantial consensus building and
      concessions by those more inclined to completely deprecate
      INFO, the eventual direction of the working group was to
      publish a framework for registration of INFO packages -- if
      for no other reason than to finally conclude the seven-year
      long argument and move on to other issues.

    Document Quality

      The document has been reviewed for quality by several SIPCORE
      participants during the Working Group Last Call period; an
      earlier version of the document received a particularly
      thorough review by Vijay Gurbani.

      It should be noted that the document itself does not directly
      describe a mechanism that can be implemented. It defines a
      framework that requires additional specification before it
      can be implemented. At the time of this publication request,
      no such specifications are under development within the IETF
      (even as individual documents); and the document shepherd is
      not aware of any such specifications under development outside
      the IETF.