SIPPING                                                        D. Petrie
Internet-Draft                                                SIPez LLC.
Expires: September 21, 2006                               March 20, 2006


 Extensions to the Session Initiation Protocol (SIP) User Agent Profile
  Delivery Change Notification Event Package for the Extensible Markup
         Language Language Configuration Access Protocol (XCAP)
                 draft-ietf-sipping-xcap-config-00.txt

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 September 21, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

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 XCAP (XML
   Configuration Access Protocol).





Petrie                 Expires September 21, 2006               [Page 1]


Internet-Draft          SIP UA Profiles via XCAP              March 2006


Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.   Requirements Terminology . . . . . . . . . . . . . . . . . .   3
   3.   New Event Package Parameters . . . . . . . . . . . . . . . .   3
   4.   Relationship of XCAP with the Data Model . . . . . . . . . .   5
   5.   Example Usage  . . . . . . . . . . . . . . . . . . . . . . .   6
   6.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .   7
   7.   Security Considerations  . . . . . . . . . . . . . . . . . .   7
   8.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . .   8
   9.   Normative References . . . . . . . . . . . . . . . . . . . .   8
        Author's Address . . . . . . . . . . . . . . . . . . . . . .   9
        Intellectual Property and Copyright Statements . . . . . . .  10






































Petrie                 Expires September 21, 2006               [Page 2]


Internet-Draft          SIP UA Profiles via XCAP              March 2006


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 [RFC3265] for notifications of changes to
   those profiles.  This document extends that event package to support
   XCAP (XML Configuration Access Protocol) [I-D.ietf-simple-xcap].

   XCAP is a usage of HTTP (HyperText Transfer Protocol) [RFC2616] which
   defines structure of the HTTP URI (Uniform Resource Identifier) to
   represent a specific document hierarchy.  XCAP URIs consist of the
   document root, the Application Unique ID (AUID), the XCAP User
   Identifier (XUI), plus additional optional elements for selecting XML
   nodes within an XML document.  The mandatory components point to a
   specific XCAP document.  For example:

   http://xcap.example.com/root/resource-lists/users/joe
   |-------------v-------------||------v------||---v---|
          document root               AUID        XUI

   This document extends the UA profile change event package with two
   new Event header parameters.  These allow a UA to subscribe to change
   notification for a specific XCAP AUID or document.

2.  Requirements Terminology

   Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
   "MAY" that appear in this document are to be interpreted as described
   in [RFC2119].

3.  New Event Package Parameters

   This document extends the event package defined in Section 7 of
   [I-D.ietf-sipping-config-framework] with the following two new
   parameters for the Event header: "document" and "auid".  These
   parameters are for use in both SUBSCRIBE and NOTIFY requests.  The
   motivation for these new parameters is in support of XCAP, but they
   may be used with other suitable protocols.

   The "document" parameter is used to specify a relative URI for a
   specific profile document that the user agent wishes to retrieve and
   for which it wishes to receive change notification.  It can be used
   with any of the profile-types.  The document parameter is useful for
   profile content like XCAP [I-D.ietf-simple-xcap] where there is a
   well defined URI schema and the user agent knows the specific content
   that it wants.  This provides a filtering mechanism to restrict the
   content to be retrieved and for which change notification is to be



Petrie                 Expires September 21, 2006               [Page 3]


Internet-Draft          SIP UA Profiles via XCAP              March 2006


   received.  (The size of the content is important in limited bandwidth
   environments.)  The "document" parameter value syntax is a quoted
   string.  The values for the "document" parameter are defined as part
   of the profile data format, which is out of scope for this document.
   To use the "document" parameter, the profile data format, must also
   define a URI path schema.  For more details on the use of this
   package and the "document" parameter with XCAP see Section 4.  The
   "document" parameter MAY be set in SUBSCRIBE requests for any of the
   profile types.  It is ignored in all other messages.  In the
   following ABNF EQUAL and quoted-string are defined in [RFC3261].

   Document     =  "document" EQUAL quoted-string

   The "auid" parameter MAY be set when the "profile-type" parameter
   value is "application".  The "auid" indicates that the user agent
   wishes to retrieve the profile data or URI and change notification
   for the application profile data for the specific application
   indicated in the value of the "auid" parameter.  Like the "document"
   parameter, the "auid" parameter provides a filtering mechanism on the
   profile content.  The "auid" parameter value is a quoted string.  The
   values for the "auid" parameter are defined as part of the profile
   data format to be used with XCAP (see [I-D.ietf-simple-xcap] ), which
   is out of scope for this document.  The "auid" parameter has meaning
   only in SUBSCRIBE requests when the "profile-type" Event header
   parameter is set to "application".  When used with XCAP it is not
   necessary to set both the "document" and "auid" parameters in a
   SUBSCRIBE request as the document path will also include the
   application auid.  The "auid" parameter is ignored if it conflicts
   with the parameter "document" path.  The "auid" parameter is ignored
   in all other messages.

   AUID       =  "auid" EQUAL quoted-string


   SUBSCRIBE request Event header example:
   Event: ua-profile;profile-type="user";
      document="user-aor/";
      vendor="premier";model="trs8000";version="5.5"

   The following table shows the use of these new Event header
   parameters in SUBSCRIBE requests for the four profile types:










Petrie                 Expires September 21, 2006               [Page 4]


Internet-Draft          SIP UA Profiles via XCAP              March 2006


   profile-type || device | user | application | local-network
   ===========================================================
   document     ||   o    |  o   |      o      |        o
   auid         ||        |      |      o      |

   m - mandatory
   s - SHOULD be provided
   o - optional
   Non-specified means that the parameter has no meaning and
   should be ignored.


4.  Relationship of XCAP with the Data Model

   The UA profile delivery framework [I-D.ietf-sipping-config-framework]
   describes a rough data model with profile types that can correspond
   to profile information related to the local-network, devices, users,
   and applications.  Because XCAP defines a specific hierarchy for how
   documents are organized, it is necessary to discuss how that
   organization relates to the data model described in the profile
   delivery framework.

   When a user or device enrolls with a SUBSCRIBE request, the request
   URI will contain identifying information for that user or device.
   This identity is mapped to an XCAP User ID (XUID) based on an
   implementation specific mapping.  The "profile-type" along with the
   "auid" Event header parameters specify the specific XCAP application
   usage.

   In particular, when the Event header parameter "profile-type" is
   "application", the "auid" MAY be included to contain the XCAP
   Application Unique ID (AUID).  When the "profile-type" is
   "application", but the "auid" parameter is absent, this specifies
   that the user wishes to SUBSCRIBE to all documents for all
   application usages associated with the user in the request-uri.  This
   provides a convenient way for a single subscription to be used to
   obtain all application data.  The XCAP root is determined by a local
   mapping.

   When the "profile-type" is "device", or "user" or "local-network",
   this maps to an AUID and document selector for representing device,
   user and local-network data, respectively.  The mapping is a matter
   of local policy.  This allows different providers to use different
   XCAP application usages and document schemas for representing these
   profiles, without having to configure the device with the specific
   AUID which is being used.

   Furthermore, when the "document" attribute is present and used with



Petrie                 Expires September 21, 2006               [Page 5]


Internet-Draft          SIP UA Profiles via XCAP              March 2006


   XCAP, it identifies a specific document that is being requested.  The
   "document" attribute specifies a relative path from the XCAP root
   [I-D.ietf-simple-xcap].  That is the "document" attribute is an XCAP
   Document Selector expressed as a relative path to the XCAP root.

5.  Example Usage

   For example, consider a phone with an instance ID of
   urn:uuid:00000000-0000-0000-0000-0003968cf920.  To obtain its device
   profile, it generates a SUBSCRIBE that contains the following
   Request-Line and Event header:  (Note that line folding of the
   Request-URI is illegal in SIP.  The Request URI is shown broken
   across the first 3-lines here only due to formatting limitations of
   IETF documents.)


   SUBSCRIBE
    sip:urn%3auuid%3a00000000-0000-0000-0000-0003968cf920@example.com
    SIP/2.0
   Event: ua-profile;profile-type=device;Vendor="vendor2"
    ;Model="1";Version="2.2.2"

   If the profile data is stored in an XCAP server, the profile delivery
   server maps the "device" profile to an application usage and document
   selector based on local policy.  The user ID, in the case of a device
   profile, could be the device ID which is identified in the user part
   of the SUBSCRIBE URI.  Assume the XCAP server uses an XCAP root
   directory of: http://xcap.example.com/root.  Local policy provides a
   mapping for the AUID "vendor2-device-data" based upon the "vendor"
   parameter and a document called "index" within the user directory,
   the corresponding HTTP URI for the document would be: (Note that this
   URI is only one line; it is split across lines due to formatting
   limitations of IETF documents.)


   http://xcap.example.com/root/vendor2-device-data/
    urn%3auuid%3a00000000-0000-0000-0000-0003968cf920/index

   The returned user profile would typically specify the user identity
   (as a SIP AOR) and his or her application-usages.  From that, the
   device can enroll to learn about its application data.  To learn
   about all of the data, the UA sends a subscription with the
   application profile-type and no AUID:


   SUBSCRIBE sip:alice@example.com SIP/2.0
   Event: ua-profile;profile-type=application;Vendor="vendor2";
    Model="1";Version="2.2.2"



Petrie                 Expires September 21, 2006               [Page 6]


Internet-Draft          SIP UA Profiles via XCAP              March 2006


   The server maps the SIP Request URI to an XUI (alice, for example)
   and the xcap root based on local policy.  If there are two AUIDs,
   "resource-lists" [I-D.ietf-simple-xcap-list-usage] and "rls-services"
   [I-D.ietf-simple-xcap-list-usage], this would result in a
   subscription to all documents within:


   http://xcap.example.com/root/rls-services/alice
   http://xcap.example.com/root/resource-lists/alice

   The user would not be subscribed to the global data for these two
   application usages, since that data is not important for users.

   However, the user/device could be made aware that it needs to
   subscribe to a specific document.  In that case, its subscribe would
   look like:


   SUBSCRIBE sip:user-aor@example.com SIP/2.0
   Event: ua-profile;profile-type=application;auid="resource-lists";
    Vendor="vendor2";Model="1";Version="2.2.2"

   this would result in a subscription to the single global document for
   resource-lists.

   In some cases, these subscriptions are to a multiplicity of
   documents.  In that case, the notification format will need to be one
   which can indicate what document has changed.  This includes content
   indirection, but also the xcap diff format [I-D.ietf-simple-xcap-
   diff].

6.  IANA Considerations

   This specification registers two new Event header parameters and
   updates the corresponding event package as defined in [RFC3265].  The
   following information required for this registration:

      Package Name: ua-profile
      Published Document: RFC XXXX (Note to RFC Editor: Please fill in
      XXXX with the RFC number of this specification).
      Person to Contact: Daniel Petrie dan.ietf AT SIPez DOT com
      Additional event header parameters: document, auid

7.  Security Considerations

   Profiles may contain sensitive data such as user credentials and
   personal information.  The security considerations of this document
   are identical to those of the framework [I-D.ietf-sipping-config-



Petrie                 Expires September 21, 2006               [Page 7]


Internet-Draft          SIP UA Profiles via XCAP              March 2006


   framework].  Implementors should also carefully read the security
   considerations of XCAP [I-D.ietf-simple-xcap] as well.

   Subscribers implementing this specification MUST implement either
   HTTP or HTTPS.  Subscribers also MUST implement the hash verification
   scheme described in SIP content indirection [I-D.ietf-sip-content-
   indirect-mech].  SIP profile delivery servers MUST implement both
   HTTP and HTTPS, and SHOULD implement a SIP Authentication Service as
   described in the SIP Identity mechanism [I-D.ietf-sip-identity].  All
   SIP entities are already required to implement SIP Digest
   authentication [RFC3261].

8.  Acknowledgements

   Thanks to Rohan Mahy for editorial work on this document.

9.  Normative References

   [I-D.ietf-simple-xcap]
              Rosenberg, J., "The Extensible Markup Language (XML)
              Configuration Access Protocol (XCAP)",
              draft-ietf-simple-xcap-08 (work in progress),
              October 2005.

   [I-D.ietf-simple-xcap-diff]
              Rosenberg, J., "An Extensible Markup Language (XML)
              Document Format for Indicating A Change  in XML
              Configuration Access Protocol (XCAP) Resources",
              draft-ietf-simple-xcap-diff-02 (work in progress),
              October 2005.

   [I-D.ietf-simple-xcap-list-usage]
              Rosenberg, J., "Extensible Markup Language (XML) Formats
              for Representing Resource Lists",
              draft-ietf-simple-xcap-list-usage-05 (work in progress),
              February 2005.

   [I-D.ietf-sip-content-indirect-mech]
              Burger, E., "A Mechanism for Content Indirection in
              Session Initiation Protocol (SIP)  Messages",
              draft-ietf-sip-content-indirect-mech-05 (work in
              progress), October 2004.

   [I-D.ietf-sip-identity]
              Peterson, J. and C. Jennings, "Enhancements for
              Authenticated Identity Management in the Session
              Initiation  Protocol (SIP)", draft-ietf-sip-identity-06
              (work in progress), October 2005.



Petrie                 Expires September 21, 2006               [Page 8]


Internet-Draft          SIP UA Profiles via XCAP              March 2006


   [I-D.ietf-sipping-config-framework]
              Petrie, D., "A Framework for Session Initiation Protocol
              User Agent Profile Delivery",
              draft-ietf-sipping-config-framework-07 (work in progress),
              July 2005.

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

   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
              RFC 2246, January 1999.

   [RFC2396]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifiers (URI): Generic Syntax", RFC 2396,
              August 1998.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC2617]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
              Leach, P., Luotonen, A., and L. Stewart, "HTTP
              Authentication: Basic and Digest Access Authentication",
              RFC 2617, June 1999.

   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

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


Author's Address

   Daniel Petrie
   SIPez LLC.
   34 Robbins Rd
   Arlington, MA  02476
   US

   Phone: "+1 617 273 4000
   Email: dan.ietf AT SIPez DOT com
   URI:   http://www.SIPez.com/




Petrie                 Expires September 21, 2006               [Page 9]


Internet-Draft          SIP UA Profiles via XCAP              March 2006


Intellectual Property Statement

   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.

   The IETF has been notified of intellectual property rights claimed in
   regard to some or all of the specification contained in this
   document.  For more information consult the online list of claimed
   rights.


Disclaimer of Validity

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


Copyright Statement

   Copyright (C) The Internet Society (2006).  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.





Petrie                 Expires September 21, 2006              [Page 10]


Internet-Draft          SIP UA Profiles via XCAP              March 2006


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.















































Petrie                 Expires September 21, 2006              [Page 11]