doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

diff --git a/doc/rfc/rfc5688.txt b/doc/rfc/rfc5688.txt
new file mode 100644
index 0000000..5609ad7
--- /dev/null
+++ b/doc/rfc/rfc5688.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                      J. Rosenberg
+Request for Comments: 5688                                         Skype
+Category: Standards Track                                   January 2010
+ISSN: 2070-1721
+
+
+     A Session Initiation Protocol (SIP) Media Feature Tag for MIME
+                          Application Subtypes
+
+Abstract
+
+   The caller preferences specification for the Session Initiation
+   Protocol (SIP) allows a caller to express preferences that the call
+   be routed to a User Agent (UA) with particular capabilities.
+   Similarly, a specification exists to allow a UA to indicate its
+   capabilities in a registration.  Amongst those capabilities are the
+   type of media streams the agent supports, described as top-level MIME
+   types.  The 'application' MIME type is used to describe a broad range
+   of stream types, and it provides insufficient granularity as a
+   capability.  This specification allows a UA to indicate which
+   application subtypes the agent supports.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc5688.
+
+Copyright Notice
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+
+
+
+
+Rosenberg                   Standards Track                     [Page 1]
+
+RFC 5688                Application Subtype Tag             January 2010
+
+
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
+   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+   3.  sip.app-subtype Media Feature Tag . . . . . . . . . . . . . . . 3
+   4.  Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
+   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
+   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
+     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
+
+1.  Introduction
+
+   The caller preferences specification [RFC3841] for the Session
+   Initiation Protocol (SIP) [RFC3261] allows a user to express
+   preferences for the routing of SIP requests.  These preferences are
+   expressed as a set of desired capabilities and characteristics of a
+   receiving agent.  When a user agent registers to the SIP network, it
+   includes, as part of its registration, its own capabilities and
+   characteristics [RFC3840].  These capabilities are stored as part of
+   the registration, and then made available to the proxy in the
+   network.  When a request arrives at the proxy with caller
+   preferences, the preferences in the request are compared with the
+   supported characteristics and capabilities stored in the
+   registrations, and the result is used to select the target user
+   agents for the request.
+
+   RFC 3840 makes use of media feature tags [RFC2506].  Each tag has a
+   name and a type.  The tags defined in RFC 3840 describe some of the
+   basic characteristics of user agents, including whether or not they
+   are automata (the sip.automata tag), their class (the sip.class tag),
+
+
+
+Rosenberg                   Standards Track                     [Page 2]
+
+RFC 5688                Application Subtype Tag             January 2010
+
+
+   whether they support media in one or both directions (the
+   sip.duplex), and whether they are a conference focus (sip.isfocus).
+   These tags also include SIP capabilities, including the schemes
+   supported by the agent (sip.schemes), the methods (sip.methods), and
+   the event packages (sip.events) [RFC3265].
+
+   RFC 3840 also defines media feature tags for multimedia stream types.
+   There is a media feature tag defined for each top-level media type --
+   sip.audio for audio streams, sip.video for video streams, and so on.
+   The primary use case for this is to correctly deliver multimedia
+   sessions to the user agent that supports that media type.  Consider a
+   caller on a videophone that wants to have a video call with another
+   user.  That user has two devices -- a mobile phone that only supports
+   audio and a videophone.  We'd like to deliver the videophone call to
+   the videophone as a first priority, and only 'ring' the mobile device
+   for an audio-only call if the user is not present on the videophone.
+
+   RFC 3840 defines media feature tags for each and every top-level
+   media type, including 'application'.  This media type covers an
+   extremely broad range of subtypes -- multiplayer games of all sorts,
+   shared whiteboards and application sharing, and so on.  With audio
+   and video, where there is often a common codec supported by agents
+   (i.e., a common subtype).  Consequently, if a caller wants an audio
+   session, routing the request to any user agent that supports audio is
+   likely to result in successful communications.  However, with
+   application streams, just routing a request to an agent that supports
+   *some* application stream isn't useful; application streams for
+   different applications are wildly different.  Consequently, the
+   application media feature tag does not provide sufficient granularity
+   for call preferences.  The specific application subtype needs to be
+   indicated as well.
+
+   To remedy this, this specification defines a new media feature tag
+   that indicates which application subtypes are supported by the agent
+   for streaming.  The name of this media feature tag is 'sip.app-
+   subtype'.
+
+2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+3.  sip.app-subtype Media Feature Tag
+
+   The 'sip.app-subtype' media feature tag is of type token with a case-
+   insensitive equality relationship.  Its value can be any registered
+   or private MIME application subtype compliant to the subtype-name
+
+
+
+Rosenberg                   Standards Track                     [Page 3]
+
+RFC 5688                Application Subtype Tag             January 2010
+
+
+   grammar defined in [RFC4288].  When included in the Contact header
+   field of a REGISTER request, an agent SHOULD include all application
+   subtypes that it can support as streaming formats.  An application
+   subtype is supported if the user agent would be capable of processing
+   a Session Description Protocol (SDP) [RFC4566] offer [RFC3264] that
+   contained that subtype as a format in the m-line of the SDP.
+
+   When included in the Accept-Contact or Reject-Contact header field,
+   it indicates a desire on the part of a User Agent Client (UAC) to be
+   connected to a User Agent Server (UAS) that can support or cannot
+   support, respectively, streaming using that application subtype.
+
+   It is important to note that this media feature tag is only
+   indicating the streaming media types that a user agent is capable of
+   supporting.  It says nothing about the functionality provided by the
+   user agent itself or the MIME types that the agent can send or
+   receive in SIP messages or emails.  For example, let us assume that a
+   SIP user agent is capable of supporting a chess game.  The game is
+   played by each user sending chess moves as binary objects over UDP
+   between a pair of user agents.  Those objects have a MIME type of
+   "application/example".  When a UA includes the sip.app-subtype media
+   feature tag in a Contact header field with a value of "example", it
+   means that the UA can handle a SIP INVITE that contained an SDP with
+   an application media line and format of "example".  It does not mean
+   that the SIP user agent is a chess application, or that the user
+   agent can accept SIP requests that include bodies of type
+   "application/example".  To indicate that a user agent can accept SIP
+   requests that include bodies of type "application/example", the agent
+   would utilize the "type" media feature tag as defined in [RFC3840].
+
+   A consequence of this is that, as new streaming media type formats
+   are defined (such as game stream formats, whiteboard session formats,
+   and so on), they SHOULD be defined using the SDP application stream
+   and utilize a MIME application subtype.
+
+4.  Example
+
+   The following is an example SIP REGISTER message fragment indicating
+   usage of this media feature tag.  The REGISTER indicates that the UA
+   can participate in application media sessions utilizing exchange of
+   objects of type "application/example".
+
+
+
+
+
+
+
+
+
+
+Rosenberg                   Standards Track                     [Page 4]
+
+RFC 5688                Application Subtype Tag             January 2010
+
+
+   REGISTER sip:example.com SIP/2.0
+   To: sip:Y@example.com
+   Contact: <sip:Y1@pc.example.com>
+    ;methods="INVITE,ACK,OPTIONS,BYE,CANCEL"
+    ;uri-user="<Y1>"
+    ;uri-domain="example.com"
+    ;audio
+    ;schemes="sip"
+    ;mobility="fixed"
+    ;class="personal"
+    ;+sip.app-subtype="example"
+
+   Such a registration indicates that an INVITE of the following form:
+
+   INVITE sip:Y@example.com SIP/2.0
+   To: sip:Y@example.com
+   Content-Type: application/sdp
+   Content-Length: ...
+
+   v=0
+   o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
+   c=IN IP4 192.0.1.2
+   t=0 0
+   m=audio 49170 RTP/AVP 0
+   m=application 8493 udp example
+
+   would be accepted by the UA.  The SDP in the INVITE indicates an
+   audio session and an application session that runs over UDP and
+   exchanges "application/example" object formats.
+
+5.  Security Considerations
+
+   When present in a REGISTER request, this media feature tag gives
+   information on the set of supported application media streams.  It is
+   possible that this information is sensitive, providing insight into
+   the capabilities of a product.  These considerations are already
+   discussed in RFC 3840, and those considerations apply here as well.
+   Applications that utilize this media feature tag SHOULD provide a
+   means for ensuring its integrity.  Similarly, the media feature tag
+   should only be trusted as valid when it comes from the user or user
+   agent described by the feature tag.  As a result, mechanisms for
+   conveying the feature tag SHOULD provide a mechanism for guaranteeing
+   authenticity.
+
+6.  IANA Considerations
+
+   This specification adds a new media feature tag to the SIP Media
+   Feature Tag Registration Tree defined in RFC 3840 [RFC3840].
+
+
+
+Rosenberg                   Standards Track                     [Page 5]
+
+RFC 5688                Application Subtype Tag             January 2010
+
+
+   Media feature tag name:  sip.app-subtype
+
+   ASN.1 Identifier:  1.3.6.1.8.4.24
+
+   Summary of the media feature indicated by this tag:  This feature tag
+      indicates the MIME application subtypes supported by the agent for
+      purposes of streaming media.
+
+   Values appropriate for use with this feature tag:  Token (equality
+      relationship).
+
+   The feature tag is intended primarily for use in the following
+      applications, protocols, services, or negotiation mechanisms:
+      This feature tag is most useful in a communications application,
+      for describing the capabilities of a device, such as a phone or
+      PDA.
+
+   Examples of typical use:  Routing a call to a phone that can support
+      a multiplayer game.
+
+   Related standards or documents:  RFC 5688
+
+   Security Considerations:  Security considerations for this media
+      feature tag are discussed in Section 5 of RFC 5688.
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
+              with Session Description Protocol (SDP)", RFC 3264,
+              June 2002.
+
+   [RFC3840]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
+              "Indicating User Agent Capabilities in the Session
+              Initiation Protocol (SIP)", RFC 3840, August 2004.
+
+   [RFC4288]  Freed, N. and J. Klensin, "Media Type Specifications and
+              Registration Procedures", BCP 13, RFC 4288, December 2005.
+
+   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+              Description Protocol", RFC 4566, July 2006.
+
+
+
+
+
+
+Rosenberg                   Standards Track                     [Page 6]
+
+RFC 5688                Application Subtype Tag             January 2010
+
+
+7.2.  Informative References
+
+   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
+              A., Peterson, J., Sparks, R., Handley, M., and E.
+              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
+              June 2002.
+
+   [RFC3265]  Roach, A., "Session Initiation Protocol (SIP)-Specific
+              Event Notification", RFC 3265, June 2002.
+
+   [RFC3841]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
+              Preferences for the Session Initiation Protocol (SIP)",
+              RFC 3841, August 2004.
+
+   [RFC2506]  Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag
+              Registration Procedure", BCP 31, RFC 2506, March 1999.
+
+Author's Address
+
+   Jonathan Rosenberg
+   Skype
+   Monmouth, NJ
+   USA
+
+   EMail: jdrosen@jdrosen.net
+   URI:   http://www.jdrosen.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg                   Standards Track                     [Page 7]
+