SIP WG J. Urpalainen
Internet-Draft Nokia
Intended status: Standards Track March 5, 2007
Expires: September 6, 2007
An Extensible Markup Language (XML) Configuration Access Protocol (XCAP)
Diff Event Package
draft-urpalainen-sip-xcap-diff-event-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 September 6, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document describes an "xcap-diff" SIP event package with the aid
of which the clients can receive partial changes of the Extensible
Markup Language (XML) Configuration Access Protocol (XCAP) resources.
The initial synchronization and document updates are based on using
the XCAP-Diff format. This document extends this format by allowing
subscriptions also to XCAP components.
Urpalainen Expires September 6, 2007 [Page 1]
Internet-Draft xcap diff event March 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. XCAP-Diff Event Package . . . . . . . . . . . . . . . . . . . 3
4.1. XCAP-Diff Processing . . . . . . . . . . . . . . . . . . . 3
4.2. Event Package Name . . . . . . . . . . . . . . . . . . . . 4
4.3. Event Package Parameters . . . . . . . . . . . . . . . . . 4
4.3.1. Path parameter . . . . . . . . . . . . . . . . . . . . 4
4.3.2. Diff-processing parameter . . . . . . . . . . . . . . 6
4.4. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 6
4.5. Subscription Duration . . . . . . . . . . . . . . . . . . 6
4.6. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 6
4.6.1. XML Schema for <xcap-node> element . . . . . . . . . . 7
4.6.2. The 'node-sel' attribute . . . . . . . . . . . . . . . 7
4.6.3. The 'exists' attribute . . . . . . . . . . . . . . . . 8
4.7. Notifier Generation of NOTIFY Requests . . . . . . . . . . 8
4.8. Subscriber Processing of NOTIFY Requests . . . . . . . . . 9
4.9. Handling of Forked Requests . . . . . . . . . . . . . . . 9
4.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 9
4.11. State Agents . . . . . . . . . . . . . . . . . . . . . . . 9
5. An Initial Example NOTIFY document . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6.1. Registration of the "xcap-diff" Event Package . . . . . . 11
6.2. URN sub-namespace registration for
'urn:ietf:params:xml:ns:xcap-component' . . . . . . . . . 11
6.3. XML Schema Registration . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Urpalainen Expires September 6, 2007 [Page 2]
Internet-Draft xcap diff event March 2007
1. Introduction
The SIP Events framework [2] describes subscription and notification
conventions for the SIP [1] protocol. The Extensible Markup Language
(XML) [10] Configuration Access Protocol (XCAP) [6] allows a client
to read, write and modify application usage data, stored with the XML
format on an HTTP/XCAP server.
This document describes an "xcap-diff" SIP event package where
clients can receive references to XCAP documents and also the partial
changes of XCAP resources. The initial retrieval of documents is
done with the HTTP protocol and the "xcap-diff" event package will
report only the document or XCAP component changes. In other words,
the contents of documents between the client and XCAP server can then
efficiently be kept in-sync. The notification information is based
on using the XCAP-Diff [7] format which is extended by this document
to allow subscriptions also to XCAP components.
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119, BCP 14
[5] and indicate requirement levels for compliant implementations.
3. Definitions
The following terms are used in this document:
XCAP Component: An XML element or an attribute, which can be updated
with the XCAP protocol.
Aggregating: While XCAP clients update only single XCAP components
at a time, several of these modifications can be aggregated
together with the XML-Patch-Ops semantics.
4. XCAP-Diff Event Package
4.1. XCAP-Diff Processing
When a client starts the "xcap-diff" subscription they may not be
aware of all the XCAP resources they are subscribing to. This may
for instance happen when the user subscribes to his/her collection of
some XCAP Application Usage. The initial notification will then
contain references to full documents the user is authorized to or in
Urpalainen Expires September 6, 2007 [Page 3]
Internet-Draft xcap diff event March 2007
other words, has <read> privilege to them. After receiving those
documents and resolving the initial synchronization stage, the client
starts applying the patches of documents received from the server.
While the initial document synchronization is based on separate HTTP
retrievals of full documents, XCAP components may be received "in-
band", that is within the <xcap-diff> notification format. This
document defines an extension element to XCAP-Diff [7] where the
content of, for example, an XML element can be fetched. This new
element has different semantics than XML-Patch-Ops [8] elements,
because these are not used for patching an XML document into another
new document but instead getting only the content of an XCAP
component without the need of a separate HTTP GET request. In
addition, this XCAP component is shown with its full content, there
is no conventions for patching this XCAP component. Therefore the
useful state information is whether a single, unique node exist in
the source document or not. With XML elements multiple nodes could
be found, which is an error case in XCAP and consequently also in
this event package. The notifier SHOULD signal this error with
'exists' attribute semantics described in Section 4.6.3. If during
the initial subscription stage the requested node can not be found,
there is not need for a result element either. Once it will be
created, the notify will contain this new component. And similarly,
the component removal will be reported for example after a successful
HTTP DELETE request. The subscriber will request this component with
the aid of the XCAP Node Selector. The result format follows XCAP
and XML-Patch-Ops conventions shown later in this document.
Furthermore, the "xcap-diff" subscriber MAY not need XML-Patching at
all. Indeed, the subscriber just wants to be informed whenever some
document changes. The XCAP-Diff [7] format will then only report
document creations, updates and removals. The usage of this use-case
is described in Section 4.3.2.
4.2. Event Package Name
The name of this event package is "xcap-diff". This package name is
carried in the Event and Allow-Events header, as defined in RFC3265
[2].
4.3. Event Package Parameters
4.3.1. Path parameter
The mandatory "path" parameter is used to select the set of XCAP
resources involved. The value is enclosed within double quotes and
it can contain several path values separated with a whitespace
character. The single value is usually a relative reference without
Urpalainen Expires September 6, 2007 [Page 4]
Internet-Draft xcap diff event March 2007
the XCAP Root URI as it is anticipated that subscription will be
routed to an XCAP server. An example of a subscription to the
changes of a resource-list document of a user:
Event: xcap-diff;
path="resource-lists/users/sip:joe@example.com/index"
Another example of a subscription to several resources:
Event: xcap-diff; path="resource-lists/global/index
resource-lists/users/sip:joe@example.com/"
The conventions applied here follow the WebDAV [11] semantics when
collections are being selected, i.e. the client MUST add the forward
slash "/" character to the end of the path segment.
An example about a subscription to an XML element:
Event: xcap-diff; path="resource-lists/users/sip:joe@example.com/
index/~~/resource-lists/list%5b@name='list'%5d"
The notification will include the result: the <list> element within
the <xcap-node> element once a unique node exists in the source
document. It should be noted that the path parameter value is in the
percent encoded form. As the result XML element is typically
namespace qualified, all needed namespace declarations MUST exist
within the <xml-diff> document. The possible local namespace
declarations within the result element exist unmodified as in the
source document, similar to XCAP conventions. Other namespace
references MUST be resolved from the context of the <xcap-node> or
its parent elements. The prefixes of qualified names (QName) [9] of
XML nodes also remain as they exist originally in the source
document.
The last example is about subscription to an XML attribute:
Event: xcap-diff; path="resource-lists/users/sip:joe@example.com/
index/~~/resource-lists/list%5b1%5d/@name"
The notification will include the result (once the 'name' attribute
exists): the 'name' attribute value within the child text node
content of the <xcap-node> element without attribute value separation
characters.
The formal grammar (RFC 4234 [4]) of the "path" parameter:
Urpalainen Expires September 6, 2007 [Page 5]
Internet-Draft xcap diff event March 2007
xcap-res = URI-reference *1("/~~/" node-selector)
; URI-reference from RFC3986 and node-selector from XCAP
path = "path" EQUALS DQUOTE xcap-res *(WSP xcap-res) DQUOTE
Although the node-selector of XCAP allows requesting all in-scope
namespaces of an element, it is disallowed to subscribe them with
this package.
4.3.2. Diff-processing parameter
The optional "diff-processing" parameter will tell the notifier how
to apply the "XML diffing process". The possible values are "no-xml-
patching", "aggregate". The "no-xml-patching" value means that only
document or XCAP component changes MUST be reported. The "aggregate"
value means that the notifier is free to aggregate several individual
XCAP component updates into a single one. If the subscription does
not contain this additional "diff-processing" parameter, the notifier
MUST send all individual changes so that the client receives the full
ETag change history of a document. In other words, "XML-Patching" is
the default mode but the notifier MUST not aggregate individual XCAP
component updates together.
An example for requesting of all document changes the user is
authorized to, or has <read> privilege:
Event: xcap-diff; path=""; diff-processing="aggregate"
The formal grammar (RFC4234 [4]) of the "diff-processing" parameter:
diff-processing = "diff-processing" EQUALS
DQUOTE ("aggregate" / "no-xml-patching") DQUOTE
4.4. SUBSCRIBE Bodies
Subscriptions to this event package will not contain bodies.
4.5. Subscription Duration
The default expiration time for subscriptions within this package is
3600 seconds. As per RFC 3265 [2], the subscriber MAY specify an
alternate expiration in the Expires header field.
4.6. NOTIFY Bodies
The NOTIFY bodies will follow the conventions of the XCAP-Diff format
[7] with the addition of the <xcap-node> element when the subscriber
is requesting the state or "value" of XCAP components.
Urpalainen Expires September 6, 2007 [Page 6]
Internet-Draft xcap diff event March 2007
4.6.1. XML Schema for <xcap-node> element
The XML schema for the <xcap-node> element. This element is included
within the <document> element of the XCAP-Diff format [7].
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema
targetNamespace="urn:ietf:params:xml:ns:xcap-component"
xmlns:tns="urn:ietf:params:xml:ns:xcap-component"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<!-- exists type definition -->
<xsd:simpleType name="exists">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="none"/>
<xsd:enumeration value="multiple"/>
</xsd:restriction>
</xsd:simpleType>
<!-- xcap-node element -->
<xsd:element name="xcap-node">
<xsd:complexType>
<xsd:complexContent mixed="true">
<xsd:restriction base="xsd:anyType">
<xsd:sequence>
<xsd:any processContents="lax" namespace="##any"
minOccurs="0" maxOccurs="1"/>
</xsd:sequence>
<xsd:attribute name="node-sel" type="xsd:string"
use="required"/>
<xsd:attribute name="exists" type="tns:exists"/>
</xsd:restriction>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
</xsd:schema>
4.6.2. The 'node-sel' attribute
The value of the mandatory 'node-sel' attribute is the percent
encoded XCAP Node Selector.
Urpalainen Expires September 6, 2007 [Page 7]
Internet-Draft xcap diff event March 2007
4.6.3. The 'exists' attribute
This optional attribute is used to signal the removal of an XCAP
component, i.e. if the notifier has provided before an XCAP component
within the subscription, the removal of such a component from the
XCAP source document is notified to the client by adding this
attribute with the value "none" into the <xcap-node> element. In an
error case where the selector value locates several elements, this
attribute value MUST be "multiple". The content of the <xcap-node>
element MUST be empty whenever it contains the 'exists' attribute.
4.7. Notifier Generation of NOTIFY Requests
During the initial subscription the notifier must first resolve the
requested XCAP resources. The XCAP-Diff format will include only
those resources where the authenticated user has <read> privilege and
what resources it has found. Note that for example, an XCAP
component which could not be located with XCAP semantics, does not
produce an error. Instead, the request remains in "pending" state,
that is, waiting for this resource to be created. Subscriptions to
collections have similar feature: once a new document is created into
the subscribed collection, the creation of a new resource is notified
with the next notify response. After the accessible XCAP resources
are known, the notifier will generate then the first full response.
At this time depending on the "diff-processing" parameter the
notifier typically starts also the follow-up of XCAP component
updates and unless otherwise directed, it reports all individual XCAP
component updates to the subscribed client. If the notifier process
receives then a re-subscription with diff-processing="aggregate" it
MUST re-send the current full XML-Diff content unless the content can
be suppressed with SubNot-Etags [13] semantics. The server will
continue in this "aggregate" mode, however.
It MAY happen in some corner cases that the notifier can not provide
patches with the XML-Patch-Ops [8] semantics. One example of this is
when the diff format produces larger content than the original
document is. When this happens and if the server has been in this
diff "aggregation" mode, it MUST fall back to sending all component
changes again for this resource.
It should be noted that the whole diff-processing is truly
implementation specific and in essence, also OPTIONAL. If the server
so desires, it MAY elect not to produce XML-diffing at all although
it is highly RECOMMENDED to implement it. Support for XCAP component
subscriptions is mandatory in the server, however.
Event packages like this require in practice a reliable transfer of
events as otherwise patching will typically fail. RFC 3265 [2]
Urpalainen Expires September 6, 2007 [Page 8]
Internet-Draft xcap diff event March 2007
proposes utilization of the "version" attribute information to state
deltas in chapter 4.4. Partial-PIDF-Notify [12] requires that
notifiers will not send a new request to the same dialog unless a
successful response (200 OK) has been received for the last request.
The latter is the proposed model for the "xcap-diff" event package.
If the NOTIFY request fails due to a timeout condition, the notifier
MUST remove the subscription.
4.8. Subscriber Processing of NOTIFY Requests
The initial NOTIFY will typically contain references to HTTP
resources including their strong ETag values. If the client does not
have similar locally cached versions, it will start an unconditional
HTTP GET request for those resources. During this retrieval time it
may receive also patches to these with the XCAP-Diff format. Once
all resources have been received with the HTTP protocol, the
subscriber can compare all the ETag values and resolve this initial
synchronization stage properly. Once each XCAP-Diff notification
contains both previous and new ETags of a resource, it is easy to
chain the notify list and possibly omit some of the patches based on
the received ETag (with HTTP) of a resource. After that the
subscriber MAY send a re-subscription to start the diff "aggregation"
on the server.
The subscriber can use CSeq values to keep track of possible missing
requests. These values can be used to detect missing events also if
there are no multiple usages in the current "xcap-diff" dialog. The
event bodies, i.e. failing patches and especially the consistent ETag
value changes MAY also be used to detect possible missing events.
Once the client detects an error it MUST renew the subscription.
4.9. Handling of Forked Requests
This specification only allows a single dialog to be constructed as a
result of emitting an initial SUBSCRIBE request.
4.10. Rate of Notifications
Notifiers of "xcap-diff" event package SHOULD NOT generate
notifications for a single user at a rate of more than once every
five seconds.
4.11. State Agents
State agents play no role in this package.
Urpalainen Expires September 6, 2007 [Page 9]
Internet-Draft xcap diff event March 2007
5. An Initial Example NOTIFY document
An example initial XCAP-Diff document provided by the initial NOTIFY.
The user has subscribed to a full resource-list document and a
service component.
Event: xcap-diff;
path="resource-lists/users/sip:joe@example.com/index rls-services/
users/sip:joe@example.com/index/~~/*/
service%5b@uri='sip:marketing@example.com'%5d"
<?xml version="1.0" encoding="UTF-8"?>
<xcap-diff xmlns="urn:ietf:params:xml:ns:xcap-diff"
xmlns:c="urn:ietf:params:xml:ns:xcap-component"
xcap-root="http://xcap.example.com/root">
<document new-etag="7ahggs"
doc-selector="resource-lists/users/sip:joe@example.com/index"
previous-etag="7ahggs"/>
<document
doc-selector="rls-services/users/sip:joe@example.com/index">
<c:xcap-node
xmlns="urn:ietf:params:xml:ns:rls-services"
xmlns:rl="urn:ietf:params:xml:ns:resource-lists"
node-sel="*/service%5b@uri='sip:marketing@example.com'%5d"
><service uri="sip:marketing@example.com">
<list name="marketing">
<rl:entry uri="sip:joe@example.com"/>
<rl:entry uri="sip:sudhir@example.com"/>
</list>
<packages>
<package>presence</package>
</packages>
</service></c:xcap-node>
</document>
</xcap-diff>
Note that the resource-list index document included equal previous
and new ETag values, as the document existed during the subscription
time. The ETags of rls-services index document were not reported,
however.
Urpalainen Expires September 6, 2007 [Page 10]
Internet-Draft xcap diff event March 2007
6. IANA Considerations
This memo calls for IANA to:
o register a new package name per [2].
o register a new XML namespace URN per [3].
o register a new XML Schema URN per [3].
6.1. Registration of the "xcap-diff" Event Package
This specification registers an event package, based on the
registration procedures defined in RFC 3265 [2]. The following is
the information required for such a registration:
Package Name: xcap-diff
Package or Template-Package: This is a package.
Published Document: RFCXXXX
Person to Contact: Jari Urpalainen, jari.urpalainen@nokia.com
6.2. URN sub-namespace registration for
'urn:ietf:params:xml:ns:xcap-component'
URI:
urn:ietf:params:xml:ns:xcap-component
Description:
This is the XML namespace for an extension XML element defined by
[[[RFCXXXX]]] to the 'application/xcap-diff+xml' content type.
Registrant Contact:
IETF, SIP working group, <sip@ietf.org>
Jari Urpalainen, <jari.urpalainen@nokia.com>
XML:
Urpalainen Expires September 6, 2007 [Page 11]
Internet-Draft xcap diff event March 2007
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Extension element for xcap-diff</title>
</head>
<body>
<h1>Namespace for an extension element of xcap-diff</h1>
<h2>urn:ietf:params:xml:ns:xcap-component</h2>
<p>See <a href="[[[URL of published RFC]]]">
RFCXXXX</a>.</p>
</body>
</html>
END
6.3. XML Schema Registration
This section registers a new XML Schema.
URI:
urn:ietf:params:xml:schema:xcap-component
Registrant Contact:
IETF, SIP working group, <sip@ietf.org>
Jari Urpalainen, <jari.urpalainen@nokia.com>
7. Security Considerations
The security considerations for this package are similar to those of
XCAP and any event package. The configuration data can contain
sensitive information, and both the client and the server need to
authenticate each other. XCAP provides basic authorization policy
for resources. Notifiers and subscribers MAY use S/MIME feature to
provide authentication and message integrity. This is described in
Section 23 of RFC 3261 [1].
8. Acknowledgments
The author would like to thank Jonathan Rosenberg for his valuable
comments and providing the initial event package and Pavel Dostal and
Krisztian Kiss for their valuable comments.
Urpalainen Expires September 6, 2007 [Page 12]
Internet-Draft xcap diff event March 2007
9. References
9.1. Normative References
[1] 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.
[2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[3] Mealling, M., "The IETF XML Registry", RFC 3688, BCP 81,
January 2004.
[4] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[6] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)",
draft-ietf-simple-xcap-12, October 2006.
[7] Rosenberg, J., "An Extensible Markup Language (XML) Document
Format For Indicating Changes in XML Configuration Access
Protocol (XCAP) Resources", draft-ietf-simple-xcap-diff-04,
October 2006.
[8] Urpalainen, J., "An Extensible Markup Language (XML) Patch
Operations Framework Utilizing XML Path Language (XPath)
Selectors", draft-ietf-simple-xml-patch-ops-02, March 2006.
[9] "Namespaces in XML (Second Edition)", W3C Recommendation REC-
xml-names-20060816 , August 2006.
[10] "Extensible Markup Language (XML) 1.0 (Fourth Edition)", W3C
Recommendation REC-xml-20060816 , August 2006.
9.2. Informative References
[11] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D.
Jensen, "HTTP Extensions for Distributed Authoring - WebDAV",
RFC 2518, February 1999.
[12] Lonnfors, M., Costa-Requena, J., Leppanen, E., and H.
Khartabil, "Session Initiation Protocol (SIP) extension for
Partial Notification of Presence Information",
Urpalainen Expires September 6, 2007 [Page 13]
Internet-Draft xcap diff event March 2007
draft-ietf-simple-partial-notify-08, July 2006.
[13] Niemi, A., "An Extension to Session Initiation Protocol (SIP)
Events for Issuing Conditional Subscriptions",
draft-niemi-sip-subnot-etags-03, March 2007.
Author's Address
Jari Urpalainen
Nokia
Itamerenkatu 11-13
Helsinki 00180
Finland
Phone: +358 7180 37686
Email: jari.urpalainen@nokia.com
Urpalainen Expires September 6, 2007 [Page 14]
Internet-Draft xcap diff event March 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).
Urpalainen Expires September 6, 2007 [Page 15]