One document matched: draft-garcia-simple-xcap-directory-00.txt
SIMPLE Working Group M. Garcia-Martin
Internet-Draft Nokia
Expires: December 8, 2004 June 9, 2004
An Extensible Markup Language (XML) Configuration Access Protocol
(XCAP) Usage for XML Documents Directory
draft-garcia-simple-xcap-directory-00.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
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 December 8, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
The general assumption of XCAP is that a client selects a document in
a XCAP server in order to manipulate data. This requires the XCAP
client to know the path of the XCAP-manipulatable XML document stored
in the XCAP server. This specification allows an XCAP client to
retrieve its directory of XCAP-manipulatable XML documents from an
XCAP server.
Garcia-Martin Expires December 8, 2004 [Page 1]
Internet-Draft XCAP directory June 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Overview of operation . . . . . . . . . . . . . . . . . . . 5
6. The XCAP Directory . . . . . . . . . . . . . . . . . . . . . 6
7. Example Document . . . . . . . . . . . . . . . . . . . . . . 7
8. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 7
9. Usage with XCAP . . . . . . . . . . . . . . . . . . . . . . 8
9.1 Application Unique ID . . . . . . . . . . . . . . . . . . 9
9.2 MIME Type . . . . . . . . . . . . . . . . . . . . . . . . 9
9.3 XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 9
9.4 Additional Constraints . . . . . . . . . . . . . . . . . . 9
9.5 Data Semantics . . . . . . . . . . . . . . . . . . . . . . 9
9.6 Naming Conventions . . . . . . . . . . . . . . . . . . . . 9
9.7 Data Interdependencies . . . . . . . . . . . . . . . . . . 10
9.8 Authorization Policies . . . . . . . . . . . . . . . . . . 10
10. Example of operation . . . . . . . . . . . . . . . . . . . . 10
11. Security Considerations . . . . . . . . . . . . . . . . . . 11
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11
12.1 XCAP Application Usage ID . . . . . . . . . . . . . . . 11
12.2 application/directory+xml MIME Type . . . . . . . . . . 12
12.3 URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:xcap-directory . . . . . . . . . 12
12.4 XCAP Directory Schema Registration . . . . . . . . . . . 13
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
14.1 Normative References . . . . . . . . . . . . . . . . . . . 14
14.2 Informational References . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . 16
Garcia-Martin Expires December 8, 2004 [Page 2]
Internet-Draft XCAP directory June 2004
1. Introduction
XCAP [7] defines a model whereby an XCAP client can create, read,
write and modify application configuration data stored in XML format
on an XCAP server. XCAP is a modular protocol that allows a
particular XCAP application usage to define the way in which a
particular application makes usage of XCAP. XCAP operates on a
single XML document basis: XCAP selects a document or an XML element
within a document and operates on it.
Each XCAP application typically allows XCAP operations to take place
in a number of different XML documents. For instance, the XML
Resource List [9] allows an XCAP client to create one or more
resource lists. A watcher may classify their contacts by their
relation to the watcher, so the watcher may create a resource list
that includes their list of friends, another resource list that
includes their list of coworkers and another resource list that
includes the members of their family. This approach allows the
watcher to subscribe to each of these lists individually.
In another scenario it is envisioned that a user might be able to
manipulate a number of XML documents stored in the XCAP server and
pertaining to different XCAP application usages. For example, a user
may be manipulating XML resource list documents [9], a PIDF
manipulation documents [10], a presence authorization rules documents
[11], etc. Each of those constitute a different XCAP application
usage.
While XCAP allows the XCAP to manipulate the documents, giving that
the XCAP client is provisioned with the URI that points to the XML
document, XCAP is not able to provide a directory of the documents
that the XCAP client is able to manipulate. This specification
provides a solution that allows XCAP clients to find out the list of
XML documents stored in the XCAP server that the user can manipulate
with XCAP.
2. Motivation
XCAP assumes that an XCAP client that is willing to manipulate an XML
document is provisioned with a URI that points to the XCAP document
or element that the user wants to manipulate. XCAP defines rules to
build the URI that points to a specific XML document or node within a
document. This XCAP URI is created from the concatenation of the
following elements: the XCAP services root URI, (which includes the
HTTP URI of the XCAP server), the XCAP Application Usage ID (AUID),
the "global" or "users" directory for that application, the name of
the XML document to be manipulated, and a node selector within that
document.
Garcia-Martin Expires December 8, 2004 [Page 3]
Internet-Draft XCAP directory June 2004
XCAP does not define how to provision the above portions of the XCAP
URI. In particular, it is assumed that the XCAP root services URI
(including the HTTP URI of the XCAP server) is provisioned in the
XCAP client or learnt by some means outside the scope of the XCAP
specification. XCAP also assumes that the AUID is configured or
known by the XCAP client, so is the name of the XML document that the
user wants to manipulate. Specifically, XCAP does not provide the
means for an XCAP client to find out the name of the XML documents
that the user owns for a particular application usage, nor it
provides the means for the XCAP client to find a list of XML
documents belonging to other XCAP application usages.
While we recognize that all these elements can be configured or
provisioned in a particular XCAP client, however, factors such as the
increasing number of XCAP application usages or the multiplicity of
resource lists may create a burden for the users. The issue is
significant when a user tries to manipulate data from an XCAP client
that is not their usual XCAP client. For instance, a user may be
logged in terminal at an airport or just using a friend's mobile
device. In all these cases the user should provide the full URI to
each of the documents he is willing to manipulate. This requires the
user to remember the name of the XML documents (e.g., resource lists)
stored in the XCAP server.
3. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, RFC 2119 [1] and indicate requirement levels for
compliant implementations.
4. Requirements
What is required is a mechanism that minimizes the configuration of
XCAP clients and allows users to get the URI of XCAP-manipulatable
XML documents stored in a XCAP server. The formal expression of the
requirements is:
REQ-1: An XCAP client MUST be able to retrieve the directory of
XCAP-manipulatable XML documents stored in an XCAP server.
REQ-2: The mechanism SHOULD require a minimum configuration in the
XCAP client.
Garcia-Martin Expires December 8, 2004 [Page 4]
Internet-Draft XCAP directory June 2004
REQ-3: The response from the server MUST contain all the required
information that allows the XCAP client to manipulate XML
document listed in the directory.
REQ-4: The response from the server MUST contain all the required
information that allows the user to decide whether to it is
needed to retrieve a fresh copy of any of the documents is up
to date.
REQ-5: It MUST be possible to return the list of XCAP-manipulatable
documents pertaining to different XCAP application usages.
REQ-6: The XCAP client MUST be able to search for the directory of
documents pertaining to a specific XCAP application usage.
5. Overview of operation
We define a new XCAP application usage named "directory". The
"directory" XCAP application usage has its own namespace identifier,
XML schema, XCAP AUID and MIME-type. We also define the conventions
to access the XCAP hierarchy.
An XCAP client that wants to retrieve the directory of XML documents
that are stored in the server for the user does an XCAP Fetch
operation (HTTP GET method) on the directory document. The XCAP
server returns an XCAP directory document built according to the XML
schema defined in this specification. The directory XML document
contains a list of all the other XML documents under the user's path
hierarchy stored in that XCAP server.
A user can typically read their own XCAP directory document. We
disallow user operations to manipulate the XCAP directory document
since the kind of information included in an XCAP directory document
is meant to be read by the user rather than written by the user. We
define a model where the XCAP directory document of a user changes
whenever another user-related XML document changes in the XCAP
server. We model the XCAP server as being authorized to do write
operations on the XCAP directory documents of its users. Of course,
we don't intend to mandate any specific implementation, but just try
to define the logical model. For example, an implementation may
decide to create XCAP directory documents "on the fly", e.g., at the
time an XCAP fetch operation of the XCAP directory document is
invoked. Other implementations may decide to keep a static document
that is updated whenever other documents are created, deleted, or
updated. Both implementations are possible and in both cases the
result is the same: the directory of XCAP-manipulatable documents
that a user can manipulated in an XCAP server is sent to the user.
Garcia-Martin Expires December 8, 2004 [Page 5]
Internet-Draft XCAP directory June 2004
6. The XCAP Directory
An XCAP-directory is an XML [8] document that MUST be well-formed and
SHOULD be valid. XCAP directory documents MUST be based on XML 1.0
and MUST be encoded using UTF-8. This specification makes use of XML
namespaces for identifying XCAP directory documents and document
fragments. The namespace URI for elements defined by this
specification is a URN [2], using the namespace identifier 'ietf'
defined by RFC 2648 [4] and extended by RFC 3688 [6]. This URN is:
urn:ietf:params:xml:ns:xcap-directory
An XCAP directory document begins with the root element tag
<xcap-directory>. It contains an optional <mandatory-ns> element
(required by and defined in XCAP [7]) followed by a number of <entry>
elements, each of which identifies an XCAP-manipulatable XML
document.
There are three attributes associated to the <entry> element:
uri: contains a URI pointing to the document stored in the XCAP
server. This URI MUST be an HTTP URI identifying an XCAP
resource.
auid: contains the XCAP Application Usage ID of the XML document.
etag: contains the server computed etag of the current instance of
the XML document. This allows the XCAP client to determine
whether the local cached copy of a document is up-to-date.
last-modified: this optional attribute contains the date and time
when the document was last modified. This allows the user to
determine whether a document has changed recently or not.
size: this optional attribute contains the size, expressed in octets,
of the XML document. This allows the user to determine whether it
wants to refresh a copy or not based on the length of the document
(for instance, the user might be connected to a low bandwidth
link).
id: this optional attribute contains a unique identifier generated by
the XCAP server. The 'id' attribute MUST be unique amongst all
the other 'id' elements of the same parent.
For extensibility purposes, the <entry> element can contain
attributes imported from other namespaces.
The <entry> element can contain a <display-name> element. This
Garcia-Martin Expires December 8, 2004 [Page 6]
Internet-Draft XCAP directory June 2004
element provides a UTF-8 encoded string, meant for consumption by the
user, that describes the resource. For extensibility purposes, other
elements from other namespaces MAY be included.
7. Example Document
The following is an example of an <xcap-directory> document that
shows three XCAP-manipulatable XML documents. Two are presence
lists, the last one is a presence authorization rules. The two
presence lists indicate the size of the document and date and time
when the last modification took place.
<?xml version="1.0" encoding="UTF-8"?>
<xcap-directory xmlns="urn:ietf:params:xml:ns:xcap-directory"
xmlns:xcap="urn:ietf:params:xml:ns:xcap-must-understand"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:xcap-directory">
<entry uri="http://xcap.example.com/services/resource-lists/users/
bill/friends.xml"
auid="resource-lists"
etag="opd19dm"
last-modified="2004-06-09T08:07:11.000+03:00"
size="109"
id="dj2kdlkd">
<display-name>My list of friends</display-name>
</entry>
<entry uri="http://xcap.example.com/services/resource-lists/users/
bill/family.xml"
auid="resource-lists"
etag="9c9byuu"
last-modified="2004-06-06T11:44:23.000+03:00"
size="234"
id="39dnlcma">
<display-name>My list of family members</display-name>
</entry>
<entry uri="http://xcap.example.com/services/rules/users/bill/
presence-rules.xml"
auid="rules"
etag="zsaeiw7"
id="ab319dndjo"/>
</xcap-directory>
8. XML Schema
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:xcap-directory"
Garcia-Martin Expires December 8, 2004 [Page 7]
Internet-Draft XCAP directory June 2004
xmlns:xcap="urn:ietf:params:xml:ns:xcap-must-understand"
xmlns="urn:ietf:params:xml:ns:xcap-directory"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:import
namespace="urn:ietf:params:xml:ns:xcap-must-understand"/>
<xs:element name="xcap-directory">
<xs:complexType>
<xs:sequence>
<xs:element ref="xcap:mandatory-ns" minOccurs="0"/>
<xs:element name="entry" type="entryType"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:complexType name="entryType">
<xs:sequence>
<xs:element name="display-name" type="xs:string"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="uri" type="xs:anyURI" use="required"/>
<xs:attribute name="auid" type="xs:string" use="required"/>
<xs:attribute name="etag" type="xs:string" use="required"/>
<xs:attribute name="last-modified" type="xs:dateTime"
use="optional"/>
<xs:attribute name="size" type="xs:nonNegativeInteger"
use="optional"/>
<xs:attribute name="id" type="xs:string" use="optional"/>
<xs:anyAttribute namespace="##other"/>
</xs:complexType>
</xs:schema>
9. Usage with XCAP
XCAP-directory documents can be manipulated with XCAP. Note,
however, that we don't expect other type of manipulation that XCAP
fetch operations executed on the whole document or a selection of
elements. Especially, it is not intended that XCAP clients modify or
delete other XML documents by doing XCAP delete or modify operations
on the XCAP-directory document. It is RECOMMENDED that XCAP servers
implement policy to disallow delete and modify operations on the XCAP
directory document. The rest of this section provides the details
for the XCAP usage of XCAP-directory documents.
Garcia-Martin Expires December 8, 2004 [Page 8]
Internet-Draft XCAP directory June 2004
9.1 Application Unique ID
XCAP requires application usages to define a unique application usage
ID (AUID) in either the IETF tree or vendor tree. This
specifications defines the "directory" AUID within the IETF tree via
the IANA registration in Section 12.
9.2 MIME Type
The MIME type for this document is "application/directory+xml".
9.3 XML Schema
The XML Schema for this document is defined as the sole content of
Section 8.
9.4 Additional Constraints
None.
9.5 Data Semantics
Semantics for the document content are provided in Section 6.
9.6 Naming Conventions
This XCAP application tries to minimize the configuration of XCAP
clients. Still, the XCAP services root URI has to be configured in
the XCAP client and we don't provide a mechanism to get around this
configuration. Without further intervention, the name of the
XCAP-directory document still has to be configured, since XCAP
requires to select a particular document before it can be retrieved.
Since there is only one XCAP-directory document per user we can
easily minimize the configuration in XCAP clients by defining a
convention for naming the XCAP-directory document.
An XCAP server SHOULD assign XCAP-directory documents the name
"directory.xml".
OPEN ISSUE: or shall we define an empty document or the "/" name
and leave at the discretion of the XCAP server to return the
appropriate document? This will be similar to HTTP servers that
return the "index.html" file when "/" is the file name specified
in the GET request.
Therefore, an XCAP client that tries to find the user's XCAP
directory will send an HTTP GET request to http://[xcap root services
uri]/directory/users/[username]/directory.xml.
Garcia-Martin Expires December 8, 2004 [Page 9]
Internet-Draft XCAP directory June 2004
9.7 Data Interdependencies
None.
9.8 Authorization Policies
An XCAP-Directory document is meant to be created and modified by an
XCAP server itself. The XCAP server does write operations whenever
any other XCAP-manipulatable XML document is created or deleted.
However, it is not the intention of this XCAP application to allow
users itself to do any other than fetch operations on this document.
Therefore, XCAP servers SHOULD NOT allow the user to modify and
SHOULD allow the user to fetch their own XCAP-directory documents.
By default, only the user is able to read their own XCAP-directory
document. A user may provide permissions for other users to fetch
the XCAP-directory document or part of it. A future application
usage will define which users are allowed to read the XCAP-directory
document of a particular user.
10. Example of operation
The following is an example of an XCAP fetch operation for the whole
XCAP directory document invoked on a user by name "bill".
GET http://xcap.example.com/services/directory/users/
bill/directory.xml HTTP/1.1
and as a result it gets the following response:
Garcia-Martin Expires December 8, 2004 [Page 10]
Internet-Draft XCAP directory June 2004
HTTP/1.1 200 OK Etag: "79se2dmb"
Content-Type: application/directory+xml
<?xml version="1.0" encoding="UTF-8"?>
<xcap-directory xmlns="urn:ietf:params:xml:ns:xcap-directory"
xmlns:xcap="urn:ietf:params:xml:ns:xcap-must-understand"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:xcap-directory">
<entry uri="http://xcap.example.com/services/resource-lists/users/
bill/presence-list.xml"
auid="resource-lists"
last-modified="2002-12-08T11:44:23.000+03:00"
size="312"
etag="39csk2"
id="1029238193">
<display-name>My presence list</display-name>
</entry>
<entry uri="http://xcap.example.com/services/rules/users/bill/
presence-rules.xml"
auid="rules"
etag="38s812"
id="789282894"/>
</xcap-directory>
Then Bill's XCAP client may decide to fetch any of the listed
documents based on the HTTP URI of the XCAP resource. The 'etag'
attribute may play a role to help Bill's XCAP client to decide
whether a locally cached copy is up-to-date or not. Additionally,
Bill may not have a local cached copy of his presence resource list,
but since it has not changed for long time, he may decide not to
fetch it.
11. Security Considerations
The configuration data defined by this application may be sensitive.
As indicated by the XCAP specification [7] clients SHOULD use TLS [3]
when communicating with XCAP servers.
12. IANA Considerations
This specification has the following IANA considerations.
12.1 XCAP Application Usage ID
According to the procedures defined in the XCAP specification [7],
this specification register a new XCAP Application Usage ID (AUID).
Garcia-Martin Expires December 8, 2004 [Page 11]
Internet-Draft XCAP directory June 2004
Name of the AUID: directory
Description: An XCAP directory is an application that allows an
XCAP client to fetch the list of XCAP-manipulatable XML documents
stored in the XCAP server.
12.2 application/directory+xml MIME Type
MIME media type name: application
MIME subtype name: directory+xml
Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 [5].
Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [5].
Security considerations: See Section 10 of RFC 3023 [5] and
Section 11 of this specification.
Interoperability considerations: none.
Published specification: this document.
Applications which use this media type: this document type is used
to support the directory of XCAP-manipulatable documents.
Magic Number: none
File Extension: .xml
Macintosh file type code: "TEXT"
Personal and e-mail address for further information: Miguel
Garcia, miguel.an.garcia@nokia.com
Author/Change controller: the IETF.
12.3 URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:xcap-directory
This section registers a new XML namespace, as per the guidelines in
RFC 3688 [6].
Garcia-Martin Expires December 8, 2004 [Page 12]
Internet-Draft XCAP directory June 2004
URI: urn:ietf:params:xml:ns:xcap-directory
Registrant contact: IETF, SIMPLE working group, (simple@ietf.org),
Miguel Garcia (miguel.an.garcia@nokia.com).
XML
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>XCAP directory Namespace</title>
</head>
<body>
<h1>Namespace for XCAP directory</h1>
<h2>application/directory+xml</h2>
<p>See <a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
</body>
</html>
END
12.4 XCAP Directory Schema Registration
This section registers an XML schema per the procedures in RFC 3688
[6].
URI: [please assign]
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
Miguel Garcia (miguel.an.garcia@nokia.com).
The XML for this schema can be found as the sole content of
Section 8.
13. Acknowledgements
The author would like to thank Jari Urpalainen for his advice in the
schema design.
14. References
Garcia-Martin Expires December 8, 2004 [Page 13]
Internet-Draft XCAP directory June 2004
14.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Moats, R., "URN Syntax", RFC 2141, May 1997.
[3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[4] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
August 1999.
[5] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC
3023, January 2001.
[6] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January
2004.
[7] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)", draft-ietf-simple-xcap-02
(work in progress), February 2004.
[8] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,
"Extensible Markup Language (XML) 1.0 (Second Edition)", W3C
FirstEdition REC-xml-20001006, October 2000.
14.2 Informational References
[9] Rosenberg, J., "An Extensible Markup Language (XML)
Configuration Access Protocol (XCAP) Usage for Presence
Lists", draft-ietf-simple-xcap-list-usage-02 (work in
progress), February 2004.
[10] Isomaki, M., "An Extensible Markup Language (XML) Configuration
Access Protocol (XCAP) Usage for Manipulating Presence
Document Contents",
draft-ietf-simple-xcap-pidf-manipulation-usage-00 (work in
progress), May 2004.
[11] Rosenberg, J., "Presence Authorization Rules",
draft-ietf-simple-presence-rules-00 (work in progress), May
2004.
Garcia-Martin Expires December 8, 2004 [Page 14]
Internet-Draft XCAP directory June 2004
Author's Address
Miguel A. Garcia-Martin
Nokia
P.O.Box 407
NOKIA GROUP, FIN 00045
Finland
EMail: miguel.an.garcia@nokia.com
Garcia-Martin Expires December 8, 2004 [Page 15]
Internet-Draft XCAP directory June 2004
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 (2004). 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.
Garcia-Martin Expires December 8, 2004 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-23 04:22:16 |