One document matched: draft-ietf-sip-xcap-config-00.txt
SIP D. Petrie
Internet-Draft SIPez LLC.
Expires: April 17, 2007 October 14, 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-sip-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 April 17, 2007.
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 April 17, 2007 [Page 1]
Internet-Draft SIP UA Profiles via XCAP October 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 . . . . . . . . . . . 6
5. Example Usage . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Use of the XCAP Diff Format with ua-profile Event Package . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
10. Change History . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Changes from draft-ietf-sipping-xcap-config-00.txt . . . 10
11. Normative References . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Petrie Expires April 17, 2007 [Page 2]
Internet-Draft SIP UA Profiles via XCAP October 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" and a new
profile type: "application" for the "profile-type" parameter. These
new 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
Petrie Expires April 17, 2007 [Page 3]
Internet-Draft SIP UA Profiles via XCAP October 2006
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
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
The profile-type Event header parameter is extended to have the
additional profile type "application". Specifying "application" type
profile indicates the desire for the profile data (URI when content
indirection is used) and change notification of the profile content
for the user's applications. Specifying the "application" type
profile also implies the use of XCAP. If the profile-type is
"application" in the SUBSCRIBE request and the profile delivery
server does not support XCAP, a 439 Invalid Event Parameter Value
MUST be sent and profile-type=application MUST be added to the
Invalid-Parameters-Values response header field as described in
[I-D.dpetrie-sip-event-param-err]. The SUBSCRIBE request URI SHOULD
be discovered and constructed in the same way the "user" type
Petrie Expires April 17, 2007 [Page 4]
Internet-Draft SIP UA Profiles via XCAP October 2006
profiles described in Section 7 of [I-D.ietf-sipping-config-
framework].
profile-types = "device" / "user" / "application" / "local-network"
The following is a SUBSCRIBE request Event header example:
Event: ua-profile;profile-type="application";
document="user-aor/";
vendor="premier";model="trs8000";version="5.5"
The following table shows the use of Event header parameters in
SUBSCRIBE requests for the four profile types:
profile-type || device | user | application | local-network
===========================================================
vendor || m | m | m | m
model || m | m | m | m
version || m | m | m | m
network-user || s | | | s
effective-by || | | |
document || | | o |
auid || | | o |
m - mandatory
s - SHOULD be provided
o - optional
Non-specified means that the parameter has no meaning and
should be ignored.
The following table shows the use of Event header parameters in
NOTIFY requests for the four profile types:
profile-type || device | user | application | local-network
===========================================================
vendor || | | |
model || | | |
version || | | |
network-user || s | | | s
effective-by || o | o | o | o
document || | | o/m |
auid || | | o/m |
o/m - mandatory if provided in the SUBSCRIBE request
Petrie Expires April 17, 2007 [Page 5]
Internet-Draft SIP UA Profiles via XCAP October 2006
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. XCAP MAY be used as the profile delivery and
management mechanism for the UA profile delivery framework. 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.
The "profile-type", "document" and "auid" can be thought of as
filters for determining which profile(s) are desired. When the
profile-type is "application" and the "document" and "auid"
parameters are not present, the XCAP operation to perform is to
select all AUID in the home and global paths. When the "auid" and/or
"document" parameters are present, the operation is to further filter
the profiles by the "auid" and/or "document" parameter values for the
global and user scope. If the filtering operations result in no
profiles being selected, a 404 response SHOULD be sent to the
SUBSCRIBE request.
Furthermore, when the "document" attribute is present and used with
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. The
"document" attribute MUST refer to a whole document.
The "document" cannot refer to an XCAP query or path that results
in a partial document. The reason for this is that changes which
occur and get notified require the context of the full document to
Petrie Expires April 17, 2007 [Page 6]
Internet-Draft SIP UA Profiles via XCAP October 2006
be unambiguous. For example if the "document" path refered to an
element of an list, deleting the element from the list entirely is
indistiguishable from moving the order in which the element occurs
in the list.
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";
Petrie Expires April 17, 2007 [Page 7]
Internet-Draft SIP UA Profiles via XCAP October 2006
Model="1";Version="2.2.2"
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. Use of the XCAP Diff Format with ua-profile Event Package
The XCAP diff format [I-D.ietf-simple-xcap-diff] is meant to be used
with an event package for the purposes of indicating changes in a
document. This section provides guidelines for its usage with the
us-profile or any event package defined for that purpose.
Upon receipt of an initial SUBSCRIBE request, the client may have a
cached version of some documents. However, the server does not know
which instances of each document (where each instance is identified
by an etag) the client currently posessses, if any. Indeed, upon
initial startup, the client will not have any documents. The initial
NOTIFY in this case MUST include a <document> element for each
document associated with the subscription. The "previous-etag"
Petrie Expires April 17, 2007 [Page 8]
Internet-Draft SIP UA Profiles via XCAP October 2006
attribute MUST be absent, and the "new-etag" attribute MUST be
present and contain the entity tag for the current version of that
document resource. An XCAP diff document structured this way is
called a "reference" XCAP diff document. It establishes the baseline
etags and document URIs for the documents covered by the
subscription.
Upon receipt of this document, the client can determine whether its
local instance documents, if any, match the etags in the XCAP diff
document. If they do not match, the client SHOULD perform a
conditional GET for each document. The document URI is constructed
by appending the XCAP root in the "xcap-root" attribute of the <xcap-
diff> element to the escape coded "doc-selector" from each <document>
element. The request is made conditional by including an If-Match
header field, with the value of the etag from each <document>
element. So long as the documents haven't changed between the NOTIFY
and the GET, the client will obtain the reference versions that the
server will use for subsequent notifications.
If the conditional GET should fail, the client SHOULD wait for the
next NOTIFY and retry the conditional GET with the etag from the new
NOTIFY.
This is because the the document was changed between the time that
the NOTIFY was sent and the time that the GET was received. In
this situation there should be another NOTIFY, for the change that
occurred, with the newer etag that the client can use to try
again.
Once the client has obtained the versions of the documents identified
in the reference XML diff, it can process NOTIFY requests on that
subscription. To process the NOTIFY requests, it makes sure that its
current version matches the version in the "previous-etag" attribute
of the <document> element. If not, the client can then fetch the
updated document from the server. If they do match, the client has
the most current version.
7. 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
Petrie Expires April 17, 2007 [Page 9]
Internet-Draft SIP UA Profiles via XCAP October 2006
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 SIP Event header parameters: document, auid
The document and auid parameters do not have predefined values.
The following table illustrates the additions to the IANA SIP Header
Field Parameters and Parameter Values:
Predefined
Header Field Parameter Name Values Reference
---------------------------- --------------- --------- ---------
Event document No [RFCXXXX]
Event auid No [RFCXXXX]
8. 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-
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].
9. Acknowledgements
Thanks to Rohan Mahy for editorial work on this document.
10. Change History
[[RFC Editor: Please remove this entire section upon publication as
an RFC.]]
10.1. Changes from draft-ietf-sipping-xcap-config-00.txt
Petrie Expires April 17, 2007 [Page 10]
Internet-Draft SIP UA Profiles via XCAP October 2006
Clarified constraint that "document" path MUST refer to a whole
document.
Moved "application" profile type definition here from:
draft-ietf-sipping-config-framework-08.
Defined concept of filtering using Event header parameters.
Cleaned up IANA section.
Profile delivery server SHOULD send 438 Invalid Event Parameter
Value for profile-type=application if XCAP is not supported. Also
reference draft-petrie-sip-event-param-err.
Moved section on xcap-diff usage in an event package from xcap-
diff to this document.
11. Normative References
[I-D.dpetrie-sip-event-param-err]
Petrie, D., "Session Initiation Protocol Response Code for
Invalid Event Parameter Values",
draft-petrie-sip-event-param-err-00 (work in progress),
October 2006.
[I-D.ietf-simple-xcap]
Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)",
draft-ietf-simple-xcap-11 (work in progress), May 2006.
[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-03 (work in progress),
October 2006.
[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
Petrie Expires April 17, 2007 [Page 11]
Internet-Draft SIP UA Profiles via XCAP October 2006
(work in progress), October 2005.
[I-D.ietf-sipping-config-framework]
Petrie, D., "A Framework for Session Initiation Protocol
User Agent Profile Delivery",
draft-ietf-sipping-config-framework-09 (work in progress),
October 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[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.
Petrie Expires April 17, 2007 [Page 12]
Internet-Draft SIP UA Profiles via XCAP October 2006
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/index.html?id=xcap-config
Petrie Expires April 17, 2007 [Page 13]
Internet-Draft SIP UA Profiles via XCAP October 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.
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Petrie Expires April 17, 2007 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-22 23:01:28 |