SIP                                                         J. Rosenberg
Internet-Draft                                                     Cisco
Intended status: Standards Track                            July 9, 2007
Expires: January 10, 2008


     A Session Initiation Protocol (SIP) Media Feature Tag for MIME
                         Application Sub-Types
                  draft-rosenberg-sip-app-media-tag-01

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 10, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

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



Rosenberg               Expires January 10, 2008                [Page 1]


Internet-Draft          Application Sub-Type Tag               July 2007


   of stream types, and provides insufficient granularity as a
   capability.  This specification allows a UA to indicate which
   application sub-types the agent supports.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   3.  'sip.app-subtype Media Feature Tag' . . . . . . . . . . . . . . 4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 6
   Intellectual Property and Copyright Statements  . . . . . . . . . . 8


































Rosenberg               Expires January 10, 2008                [Page 2]


Internet-Draft          Application Sub-Type Tag               July 2007


1.  Introduction

   The caller preferences specification [7] for the Session Initiation
   Protocol (SIP) [5] 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 [3].
   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 [8].  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 they are automata
   or not (the sip.automata tag), their class (the sip.class tag),
   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 protocol capabilities, including the
   schemes supported by the agent (sip.schemes), the methods
   (sip.methods), and the event packages [6] (sip.events).

   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



Rosenberg               Expires January 10, 2008                [Page 3]


Internet-Draft          Application Sub-Type Tag               July 2007


   for call preferences.  The specific application sub-type needs to be
   indicated as well.

   To remedy this, this specification defines a new media feature tag
   that indicates which application sub-types 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 [1].


3.  'sip.app-subtype Media Feature Tag'

   The 'sip.app-subtype' media feature tag is of type token with a case-
   sensitive equality relationship.  Its value can be any registered or
   private MIME application sub-type.  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 sub-type is supported if the user agent would be capable
   of processing an Session Description Protocol (SDP) [4] offer [2]
   that contained that sub-type 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 UAC to be connected to a UAS
   which can support, or cannot support respectively, streaming using
   that application sub-type.

   A consequence of this is that, as new streaming applications are
   defined (such as multiplayer games, whiteboard sessions, and so on,
   they SHOULD be defined using the SDP application stream, and utilize
   a MIME application sub-type.

   The following is an example SIP REGISTER message fragment indicating
   usage of this media feature tag:












Rosenberg               Expires January 10, 2008                [Page 4]


Internet-Draft          Application Sub-Type Tag               July 2007


        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="greatgame,wboard"



4.  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 which 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.


5.  IANA Considerations

   This specification adds a new media feature tag to the SIP Media
   Feature Tag Registration Tree defined in RFC 3840 [3].

   Media feature tag name:  sip.app-subtype

   ASN.1 Identifier:  1.3.6.1.8.4.22

   Summary of the media feature indicated by this tag:  This feature tag
      indicates the MIME application sub-types supported by the agent
      for purposes of streaming media.

   Values appropriate for use with this feature tag:  Token.

   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.



Rosenberg               Expires January 10, 2008                [Page 5]


Internet-Draft          Application Sub-Type Tag               July 2007


   Examples of typical use:  Routing a call to a phone that can support
      a multiplayer game.

   Related standards or documents:  RFC XXXX [[Note to IANA: Please
      replace XXXX with the RFC number of this specification.]]

   Security Considerations:  Security considerations for this media
      feature tag are discussed in Section 4 of RFC XXXX .  [[Note to
      IANA: Please replace XXXX with the RFC number of this
      specification.]]


6.  References

6.1.  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
        Session Description Protocol (SDP)", RFC 3264, June 2002.

   [3]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User
        Agent Capabilities in the Session Initiation Protocol (SIP)",
        RFC 3840, August 2004.

   [4]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
        Description Protocol", RFC 4566, July 2006.

6.2.  Informative References

   [5]  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.

   [6]  Roach, A., "Session Initiation Protocol (SIP)-Specific Event
        Notification", RFC 3265, June 2002.

   [7]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
        Preferences for the Session Initiation Protocol (SIP)",
        RFC 3841, August 2004.

   [8]  Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag
        Registration Procedure", BCP 31, RFC 2506, March 1999.







Rosenberg               Expires January 10, 2008                [Page 6]


Internet-Draft          Application Sub-Type Tag               July 2007


Author's Address

   Jonathan Rosenberg
   Cisco
   Edison, NJ
   US

   Email: jdrosen@cisco.com
   URI:   http://www.jdrosen.net










































Rosenberg               Expires January 10, 2008                [Page 7]


Internet-Draft          Application Sub-Type Tag               July 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Rosenberg               Expires January 10, 2008                [Page 8]