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]