SIPPING                                                 S. Channabasappa
Internet-Draft                                                 CableLabs
Intended status: Standards Track                          J. Littlefield
Expires: May 19, 2008                                Cisco Systems, Inc.
                                                               S. Loreto
                                                          Ericsson, Inc.
                                                       November 16, 2007


  Extension to the ua-profile Event Package to Support the Application
                              Profile Type
            draft-channabasappa-sipping-app-profile-type-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 May 19, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   The SIP User Agent profile delivery framework describes how a User
   Agent can retrieve its data using a variety of protocols and defines
   a SIP event package for notifications of changes to those profiles.
   This document extends that event package to support the application



Channabasappa, et al.     Expires May 19, 2008                  [Page 1]

Internet-Draft          Application Profile Type           November 2007


   profile type.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Profile Type Definition . . . . . . . . . . . . . . . . . . . . 3
     3.1.  Parameter 'appids'  . . . . . . . . . . . . . . . . . . . . 3
     3.2.  Summary of Event Header . . . . . . . . . . . . . . . . . . 4
     3.3.  SUBSCRIBE Bodies  . . . . . . . . . . . . . . . . . . . . . 6
     3.4.  NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . . 6
   4.  Example Usage . . . . . . . . . . . . . . . . . . . . . . . . . 6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   8.  Normative References  . . . . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8
   Intellectual Property and Copyright Statements  . . . . . . . . . . 9
































Channabasappa, et al.     Expires May 19, 2008                  [Page 2]

Internet-Draft          Application Profile Type           November 2007


1.  Introduction

   The SIP [RFC3261] User Agent profile delivery framework
   [I-D.ietf-sipping-config-framework] describes how a User Agent (UA)
   can retrieve its data using a variety of protocols.  The framework
   also defines a SIP event package (ua-profile) for profile delivery,
   and notification of profile changes.  The ua-profile event package
   contains a parameter identified by 'profile-type' that can be used to
   request data specific to certain type of profiles.  This document
   extends the profile-type parameter to support an additional profile
   type, termed 'application'.  The 'application' profile type is used
   for delivery and change notification of profile content for the
   user's applications.


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

   This document also reuses the SIP terminology defined in [RFC3261]
   and [RFC3265], and specifies the usage of the following terms.



3.  Profile Type Definition

   This document specifies a new profile type for use with the SIP UA
   configuration framework.  The name of the profile type is
   'application'.  It is to be used in deployments where SIP UAs are
   provided with application specific configuration.  This document also
   defines an additional event header parameter for use with the
   application profile type.

3.1.  Parameter 'appids'

   The "appids" parameter describes the application profile being
   requested.  Its value is an identifier unique to the application, and
   defined by the application specification, along with the profile
   content.  This parameter value SHOULD be provided in the SUBSCRIBE
   request, along with the other three parameters (vendor, model and
   version) specified in [I-D.ietf-sipping-config-framework], only for
   the 'application' profile-type.  This parameter is useful to the PDS
   to affect the profile provided.






Channabasappa, et al.     Expires May 19, 2008                  [Page 3]

Internet-Draft          Application Profile Type           November 2007


   COMMENT:  The namespace for application identifiers must be defined
      in order to ensure uniqueness.  A likely choice is to make the
      appids value be a URN.  Examples in this document do not reflect
      likely application identifiers.

   The "appids" parameter describes the specific application, or the
   list of applications, for which the user agent desires a profile
   subscription.

   In the following ABNF defining the syntax, EQUAL and quoted-string
   are defined in [RFC3261]

      appids            = "appids=" list-of-app-ids
      list-of-app-ids   = DQUOTE app-id *("," app-id) DQUOTE
      app-id            = 1*(subset-print-chars)
      subset-print-chars= %x21 /%x23-25 / %x27-29 / %x2D-3C / %x3E-7E
                          ;All printable characters except ", =, &, *, +
                          ;comma or white-space characters.

          Note: Need to validate the above ABNF.


   The "appids" parameter may appear in the Event header of the NOTIFY
   request to specify the actual application the NOTIFY belongs to.  In
   the initial NOTIFY following a SUBSCRIBE, the appids parameter SHOULD
   list all applications obtained in the subscription, which may be a
   subset of the applications listed in the SUBSCRIBE.  The only case in
   which the "appids" parameter MAY be omitted from the initial NOTIFY
   is when only one application was listed in the SUBSCRIBE.  If the
   SUBSCRIBE included an "appids" parameter, the "appids" parameter of
   the initial NOTIFY MUST NOT list applications not present in the
   SUBSCRIBE.  If the parameter contains a list of applications, the
   order in the appids parameter MUST be the same as followed in the
   body (see below).  Subsequent NOTIFY requests on a single application
   subscription MAY omit the "appids", since the application context is
   implied by the subscription dialog.

3.2.  Summary of Event Header

   The following are example Event headers which may occur in SUBSCRIBE
   requests.  The examples are not intended to show complete SUBSCRIBE
   requests.









Channabasappa, et al.     Expires May 19, 2008                  [Page 4]

Internet-Draft          Application Profile Type           November 2007


   Event: ua-profile;profile-type=application;
          vendor="vendor.example.com";model="Z100";version="1.2.3"

   Event: ua-profile;profile-type=application;
          vendor="vendor.example.com";model="Z100";version="1.2.3";
          appids="myapplication"

   Event: ua-profile;profile-type=application;
          vendor="vendor.example.com";model="Z100";version="1.2.3";
          appids="myapplication1","myapplication2","myapplication3"


   The following are example Event headers which may occur in NOTIFY
   requests.  These example headers are not intended to be complete
   NOTIFY requests.

   Event: ua-profile;profile-type=application

   Event: ua-profile;profile-type=application;appids="myapplication1"

   Event: ua-profile;profile-type=application;
          appids="myapplication2","myapplication3"



   The table shows the use of Event header parameters in SUBSCRIBE
   requests for the application profile type:

      profile-type || application
      ===========================
      appids        ||     o

      m - mandatory
      s - SHOULD be provided
      o - optional


   The table shows the use of Event header parameters in NOTIFY requests
   for the application profile type:

      profile-type || application
      ===========================================================
      appids        ||     o








Channabasappa, et al.     Expires May 19, 2008                  [Page 5]

Internet-Draft          Application Profile Type           November 2007


3.3.  SUBSCRIBE Bodies

   This draft defines an enhancement to
   the[I-D.ietf-sipping-config-framework] by specifying a use for the
   SUBSCRIBE request body.  If the appids parameter contained a list of
   applications, the body of the SUBSCRIBE SHOULD include appropriate
   bodies for each of the applications for which the user-agent is
   subscribing, in the same order in which they are listed in the appids
   parameter.  If present in the SUBSCRIBE request, the body SHALL be
   used by the each of the application specific PDSs to tailor the
   NOTIFY responses to the subscribing UA for each of the applications
   listed.

3.4.  NOTIFY Bodies

   The NOTIFY message body contains a content type specific to the
   requested application (this type must be listed in the Accept header
   of the SUBSCRIBE).  If the subscription is for multiple applications,
   the initial NOTIFY message body will contain a "multipart/mixed"
   content-type, and the ordering of the body-parts corresponds to the
   ordering of the "appids" application values.
   COMMENT:  An alternative to multipart/mixed content is to require all
      applications supporting multi-application subscription to conform
      to a common XML container schema, which in turn contains the
      application-specific profile content, or content-indirection
      information.


4.  Example Usage



   SUBSCRIBE sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB
             @example.com  SIP/2.0
   Event: ua-profile;profile-type=application;appids="sampleapplication"
   From: sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB
          @example.com;tag=1234
   To: sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB@example.com
   Call-ID: 3573853342923422@192.0.2.44
   CSeq: 2131 SUBSCRIBE
   Contact: sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB
            @example.com
      ;+sip.instance="<urn:uuid:00000000-0000-0000-0000-123456789AB0>"
   Via: SIP/2.0/TCP 192.0.2.41;
     branch=z9hG4bK6d6d35b6e2a203104d97211a3d18f57a
   Accept: message/external-body, application/x-z100-device-profile
   Content-Length: 0




Channabasappa, et al.     Expires May 19, 2008                  [Page 6]

Internet-Draft          Application Profile Type           November 2007


5.  IANA Considerations

   There is one consideration associated with this document.
   Specifically it registers a new profile type as specified in
   [I-D.ietf-sipping-config-framework].


            Profile Type                          Reference
            --------------                         ---------
            application                            [RFCXXXX]


            CONTACT:
            -------
            sumanth@cablelabs.com


   Note to RFC editor: Please replace RFCXXXX with the RFC number
   assigned to this document.


6.  Security Considerations

   This document is an extension to the SIP Configuration Framework and
   as such inherits the security considerations for profile delivery as
   listed in [I-D.ietf-sipping-config-framework].  In addition, the
   presence of application ids in the SUBSCRIBE and NOTIFY bodies plays
   an important role in how the profile data is received by the client.
   A man-in-the-middle who manipulates the application ids can
   effectively cause a disruption in application profile data delivery.
   (Editor's note: Need to add more security considerations, e.g., when
   is the presence of an app-id a threat.)


7.  Acknowledgements

   The authors appreciate the feedback received on the SIPPING WG so
   far, specifically Sam Ganesan from Motorola, Brett Tate from
   Broadsoft and Paul Kyzivat from Cisco.


8.  Normative References

   [I-D.ietf-sipping-config-framework]
              Channabasappa, S., "A Framework for Session Initiation
              Protocol User Agent Profile Delivery",
              draft-ietf-sipping-config-framework-13 (work in progress),
              October 2007.



Channabasappa, et al.     Expires May 19, 2008                  [Page 7]

Internet-Draft          Application Profile Type           November 2007


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

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


Authors' Addresses

   Sumanth Channabasappa
   CableLabs
   858 Coal Creek Circle
   Louisville, Co  80027
   USA

   Email: sumanth@cablelabs.com
   URI:   http://www.cablelabs.com/


   Josh Littlefield
   Cisco Systems, Inc.
   1414 Massachusetts Avenue
   Boxborough, MA  01719
   USA

   Email: joshl@cisco.com
   URI:   http://www.cisco.com/


   Salvatore Loreto
   Ericsson, Inc.
   Hirsalantie 11
   Jorvas,   02420
   Finland

   Email: Salvatore.Loreto@ericsson.com
   URI:   http://www.ericsson.com/









Channabasappa, et al.     Expires May 19, 2008                  [Page 8]

Internet-Draft          Application Profile Type           November 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).





Channabasappa, et al.     Expires May 19, 2008                  [Page 9]