SIPPING Working Group M. Garcia-Martin
Internet-Draft Nokia
Intended status: Standards Track G. Camarillo
Expires: March 5, 2007 Ericsson
September 1, 2006
Extensible Markup Language (XML) Format Extension for Representing
Capacity Attributes in Resource Lists
draft-ietf-sipping-capacity-attribute-01.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 March 5, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document specifies an XML extension to the resource list format
for qualifiying resources with the capacity in which they are
included in the resource list.
Garcia-Martin & Camarillo Expires March 5, 2007 [Page 1]
Internet-Draft Capacity in Resource Lists September 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Extension to the resource lists data format . . . . . . . . . 5
5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Carrying URI-lists in SIP . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9.1. Disposition Type Registration . . . . . . . . . . . . . . 10
9.2. XML Namespace Registration . . . . . . . . . . . . . . . . 11
9.3. XML Schema Registration . . . . . . . . . . . . . . . . . 12
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . . 12
11.2. Informational References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Garcia-Martin & Camarillo Expires March 5, 2007 [Page 2]
Internet-Draft Capacity in Resource Lists September 2006
1. Introduction
The Framework and Security Considerations for Session Initiation
Protocol (SIP) URI-List Services [9] describes a generic framework
for carrying Uniform Resource Identifier (URI)-lists in SIP [5]
messages. Specifically the document provides a common framework for
specific implementations of URI-list services, such as conferences
initiated with INVITE requests [10] or Multiple-recipient MESSAGE
requests [11].
Common to a multiple of URI-list services is the presence of a SIP
request that contains a collection of resources, typically expressed
as an XML resource list [7]. SIP requests carrying resource lists
can appear either in requests received by the URI-list server,
indicating the list of intended recipients; or in each of the
requests that the URI-list server sends to recipients, indicating the
list of recipients of the same SIP request.
Although the XML resource list [7] provides a powerful mechanism for
indicating list of resources, it is usually beneficial to indicate
the capacity in which a resource is receiving a SIP request. This is
similar to common e-mail where the sender can assign each recipient
the capacity of To, Cc, or Bcc, in which they are receiving an e-mail
message.
This document addresses this problem by providing an extension to the
XML resource list [7] that enables the sender to tag the capacity of
the recipients, as 'to', 'cc', or 'bcc'. Additionally, we provide
the sender with the capability of indicating in the URI-list that one
or more resources should be anonymized, so that their URIs are not
disclosed to the other recipients, but instead, they are replaced
with anonymous URIs.
The rest of this document is organized as follows: Section 2
introduces a few new terms. Section 3 gives an overview of
operation. Section 4 formally defines an extension to URI-lists.
The XML schema definition is provided in Section 5. Section 6 shows
examples of the URI-lists with the extensions defined in this
document. Section 7 discusses the implications of carrying URI-lists
in SIP messages.
2. 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
Garcia-Martin & Camarillo Expires March 5, 2007 [Page 3]
Internet-Draft Capacity in Resource Lists September 2006
compliant implementations.
URI-list service: SIP application service that receives a SIP
request containing a URI-list and sends a similar SIP request to
each URI in the list.
Intended recipient: The intended final recipient of the request to
be generated by URI-list service.
Capacity: The role assigned by the sender to a recipient. The
sender is able to tag recipients with the 'to', 'cc', and 'bcc'
capacity, which indicate, respectively, whether the recipients get
a primary, carbon copy, or blind carbon copy of the SIP request.
3. Overview
Figure 1 depicts a general overview of the operation of a URI-list
server. A SIP User Agent Client (UAC) issuer sends a SIP request
(F1) to a URI-list server. The URI-list server generates a SIP
request to each of the recipients, according to the specific method.
+--------+ +---------+ +--------+ +--------+ +--------+
|SIP UAC | | URI-list| |intended| |intended| |intended|
| issuer | | server | | recip. | | recip. | | recip. |
| | | | | 1 | | 2 | | n |
+--------+ +---------+ +--------+ +--------+ +--------+
| | | | |
| F1. SIP request | | | |
| ---------------->| | | |
| F2. 2xx response | | | |
|<---------------- | F3. SIP request | |
| | ------------->| | |
| | F4. SIP request | |
| | ------------------------>| |
| | F5. SIP request | |
| | ----------------------------------->|
| | F6. 2xx response | |
| |<------------- | | |
| | F7. 2xx response | |
| |<------------------------ | |
| | F8. 2xx response | |
| |<----------------------------------- |
| | | | |
| | | | |
| | | | |
Garcia-Martin & Camarillo Expires March 5, 2007 [Page 4]
Internet-Draft Capacity in Resource Lists September 2006
Figure 1: Example of operation
The URI-list mechanism allows a sender to specify multiple targets
for a SIP request by including an XML resource list [7] in the body
of the SIP request. This XML resource list includes the URIs of the
targets of the SIP request (the actual procedures are method specific
and outside the scope of this document). Each target URI may also be
marked to indicate in what capacity (or role) the recipient is
receiving the SIP request. The available capacities include 'to',
'cc', and 'bcc' (analogous to e-mail). Each target URI may also be
marked with the 'anonymize' attribute. This allows the sender of the
SIP request to indicate to the URI-list service that an intended
recipient should receive the SIP request, but his URI should not be
disclosed (for example, in a URI-list that the URI-list service could
send to the recipients of the SIP request).
When the URI-list server expands the request for each recipient, it
includes a new URI-list that contains only the targets originally
listed in the "to" and "cc" capacities, excludes those listed in the
'bcc' capacity. Further more, those URIs tagged with the 'anonymize'
attribute are replaced by an anonymous URI.
In case of multiple identical URIs the size of URI-list can be
compressed by adding a 'count' attribute to a URI. The 'count'
attribute indicates the number of repeated URIs. This is
particularly useful with anonymized URIs. It is not expected to have
value other than with anonymous URIs, although technically, it is
possible to include the 'count' attribute to any URI.
The presence of a URI-list in each of the expanded SIP requests
allows recipients to both see and reply to the non-anonymous "to" and
"cc" targets, but not to the "bcc" or anonymous targets. The default
capacity assumed, if one is not specified by the sender, is "bcc".
This is discussed in greater detailed in Section 4
4. Extension to the resource lists data format
This document defines an extension to the XML resource list data
format [7] that allows the sender to indicate the capacity or role in
which a recipient is receiving a message. We define a new 'capacity'
attribute to the <entry> element of the resource list document format
[7]. The 'capacity' attribute has similar semantics to the type of
destination address in e-mail systems. It can take the values "to",
"cc", and "bcc". A "to" value of the 'capacity' attribute indicates
that the resource is considered a primary recipient of the SIP
request. A "cc" value indicates that the resource receives a carbon
copy of the SIP request. A "bcc" value indicates that the resource
Garcia-Martin & Camarillo Expires March 5, 2007 [Page 5]
Internet-Draft Capacity in Resource Lists September 2006
receives a blind carbon copy of the SIP request, i.e., this URI is
not disclosed in a URI-list sent to the recipients. The default
'capacity' value is "bcc", that is, the absence of a 'capacity'
attribute MUST be treated as if the 'capacity' was set to "bcc".
URI-list servers can use URIs tagged with the "bcc" 'capacity'
attribute for routing SIP requests, but MUST delete them if the URI-
list service includes a URI-list in outgoing requests.
A new 'anonymize' attribute can be included in a <entry> element of
the resource list document format [7]. If set to a "true" value, it
provides an indication to the URI-list server for not disclosing the
URI itself in a URI-list sent to the recipient, but instead,
anonymize the URI. URI-list servers can use URIs tagged with the
'anonymize' attribute for routing SIP requests, but MUST convert them
to an anonymized URI (such as sip:anonymous@anonymous.invalid) if the
URI-list server includes a URI-list in outgoing requests. The
default value of the 'anonymize' attribute is "false".
Processing of URIs tagged with a "bcc" 'capacity' has higher
precedence of the 'anonymize' attribute, thus, if the 'capacity' of a
URI is set to "bcc", the URI-list service will remove the URI from
the list and the 'anonymize' attribute will be ignored. Therefore,
the 'anonymize' attribute is only useful for those URIs tagged with a
'capacity' of "to" or "cc".
A new 'count' attribute can be also included in a <entry> element of
the resource list document format [7]. It provides the number of
equal URIs. Typically URI-lists created by UACs will not have equal
(or duplicated) URI entries, thus, it is not expected to contain URIs
tagged with the 'count' attributes. However, URI-lists created by
URI-list servers can contain duplicated anonymized URIs, thus, it is
expected that URI-list created by URI-list servers will contain
'count' attributes. The default value of the 'count' attribute is
"1".
The 'capacity', 'anonymize', and 'count' attributes SHOULD be
included as modifiers of any of the child elements included in the
<list> element of a resource list (e.g., attribute of the <entry> or
<external> elements).
Section 5 describes the format of the 'capacity', 'anonymize', and
'count' attributes. Implementations according to this specification
MUST support this XML Schema.
Garcia-Martin & Camarillo Expires March 5, 2007 [Page 6]
Internet-Draft Capacity in Resource Lists September 2006
5. XML Schema
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:capacity"
xmlns="urn:ietf:params:xml:ns:capacity"
xmlns:rls="urn:ietf:params:xml:ns:resource-lists"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation>
<xs:documentation xml:lang="en">
Adds the capacity, anonymize, and count attributes
to URIs included in a resource list.
</xs:documentation>
</xs:annotation>
<xs:import namespace="urn:ietf:params:xml:ns:resource-lists"
schemaLocation="urn:ietf:params:xml:schema:resource-lists"/>
<xs:attribute name="capacity">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="to"/>
<xs:enumeration value="cc"/>
<xs:enumeration value="bcc"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="anonymize" type="xs:boolean" default="false"/>
<xs:attribute name="count" type="xs:nonNegativeInteger"
default="1"/>
</xs:schema>
Figure 2: XML Schema of the extension to the resource list format
6. Examples
This section shows two examples of URI-lists that can be included in
SIP requests. The first example in Figure 3 shows a URI-list that
the UAC sends to the URI-list server. This corresponds to a list
that will be included in the flow F2 in Figure 1. The list contains
a flat list according to the resource list data format [7]. Each
resource indicates the capacity of a resource. Some of the resources
are also attributed with the 'anonymize' attribute. This provides an
Garcia-Martin & Camarillo Expires March 5, 2007 [Page 7]
Internet-Draft Capacity in Resource Lists September 2006
indication to the URI-list service for not disclosing their URIs in a
URI-list. The last two <entry> elements are attributed with a "bcc"
'capacity'. This provides an indication to the URI-list service for
removing these URIs from the outgoing URI-lists.
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:cp="urn:ietf:params:xml:ns:capacity">
<list>
<entry uri="sip:bill@example.com" cp:capacity="to" />
<entry uri="sip:randy@example.net" cp:capacity="to"
cp:anonymize="true"/>
<entry uri="sip:eddy@example.com" cp:capacity="to"
cp:anonymize="true"/>
<entry uri="sip:joe@example.org" cp:capacity="cc" />
<entry uri="sip:carol@example.net" cp:capacity="cc"
cp:anonymize="true"/>
<entry uri="sip:ted@example.net" cp:capacity="bcc" />
<entry uri="sip:andy@example.com" cp:capacity="bcc" />
</list>
</resource-lists>
Figure 3: URI-list sent from the UAC to the URI-list server
Upon reception of the SIP request containing the URI-list of Figure 3
the URI-list service creates a SIP request for each of the URIs
listed in the URI-list (so, in our example, it creates 7 SIP
requests). Each outgoing SIP request contains a copy of the same
processed outgoing URI-list. The process is as follows: the URI-list
service creates a new URI-list, based on the received one, but with
changes. First it copies all the URIs (<entry> elements) tagged with
the "to" or "cc" 'capacity' which do not contain an 'anonymize'
attribute (or when the 'anonymize' attribute is set to "false").
Then all the URIs tagged with a 'capacity' attribute set to "to" and
'anonymize' set to "true" are replaced by an anonymous URI, such as
"sip:anonymous@anonymous.invalid". In this entry it also adds the
original 'capacity' attribute ("to" in our example), and it adds a
'count' attribute with the number of anonymous entries with this
capacity ("2" in our example). Then the URI-list service does the
same operation to the URIs tagged with the 'capacity' attribute set
to "cc" and 'anonymize' attribute set to "true", adding also the
'count' attribute containing the number of anonymous attributes with
this capacity ("1" in the example). Last, the URI-list service
completely removes URIs tagged with the "bcc" 'capacity'. The result
URI-list if shown in Figure 4.
Garcia-Martin & Camarillo Expires March 5, 2007 [Page 8]
Internet-Draft Capacity in Resource Lists September 2006
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:cp="urn:ietf:params:xml:ns:capacity">
<list>
<entry uri="sip:bill@example.com" cp:capacity="to" />
<entry uri="sip:anonymous@anonymous.invalid" cp:capacity="to"
cp:count="2"/>
<entry uri="sip:joe@example.org" cp:capacity="cc" />
<entry uri="sip:anonymous@anonymous.invalid" cp:capacity="cc"
cp:count="1"/>
</list>
</resource-lists>
Figure 4: URI-List sent from the URI-list server to each recipient
7. Carrying URI-lists in SIP
A SIP User Agent Client (UAC) that composes a SIP request can include
a URI-list with the extensions specified in this document to indicate
the list of intended recipients. On doing so, as specified in the
Framework and Security Considerations for SIP URI-List Services [9],
the UAC adds a Content-Disposition [2] header field set to the value
'recipient-list'. Typically UACs send these 'recipient-list' bodies
to URI-list services (this corresponds to flow F1 in Figure 1). A
body whose Content-Disposition type is 'recipient-list' contains a
URI-list with list of intended recipients of the SIP request. The
<entry> element in the URI-list MAY also include a 'capacity' and
'anonymize' attributes, as specified in Section 4.
To enable the capability of the intended recipients to become aware
of who else is receiving a copy of the SIP request, we define a new
mail disposition type to be included in a Content-Disposition [2]
header field of a SIP request. The value of this new disposition
type is 'recipient-list-history' and its purpose is to indicate a
list of recipients that a SIP request was sent to. A body whose
Content-Disposition type is 'recipient-list-history' contains a URI-
list with the visible (including anonymized) recipients of the SIP
request. The <entry> element in the URI-list MAY also include a
'capacity' and 'count' attributes, as specified in Section 4.
It is often desired that, if the intended recipient of the SIP
request does not support this specification, still the SIP request
does not fail. In order to provide the maximum probability of
success of those requests that include 'recipient-list-history'
bodies, User Agents (such as URI-list services) that build SIP
requests with the Content-Disposition header field set to 'recipient-
list-history' SHOULD add a 'handling' parameter [4] set to
Garcia-Martin & Camarillo Expires March 5, 2007 [Page 9]
Internet-Draft Capacity in Resource Lists September 2006
"optional".
8. Security Considerations
The Framework and Security Considerations for SIP URI-List Services
[9] discusses issues related to SIP URI-list services.
Implementations of this specification MUST follow the security-
related rules in the Framework and Security Considerations for SIP
URI-List Services [9]. These rules include mandatory authentication
and authorization of clients, and opt-in lists.
User Agent Clients SHOULD NOT hand SIP requests containing URI-list
services to unauthenticated and untrusted parties. This is to avoid
man-in-the-middle attacks or acquiring URI-lists for performing SPAM
attacks.
URI-lists may contain private information, such as SIP URIs. It is
therefore not desirable that these URI-lists are known by third
parties. Eavesdroppers are able to watch URI-lists contained in SIP
requests unless the SIP message was sent over a secured channel with
Transport Layer Security (TLS) [3] or unless the URI-list body itself
is encrypted with S/MIME [8]. Therefore, it is RECOMMENDED that URI-
list bodies are encrypted with S/MIME [8] or that the SIP request is
encrypted with TLS [3].
Note that this URI-list does not indicate the actual participants in
the session. It indicates only the URIs invited and that might
accept the request. It does not assert that these parties actually
exist, that they are reachable at the given URI, or that they have
accepted the invitation. No inferences about billing should be made
from this information. It is subject to spoofing by loading the list
with falsified content.
9. IANA Considerations
The following sections instruct the IANA to register: a new
disposition type, a new SIP option-tag, a new XML namespace, and a
new XML schema.
9.1. Disposition Type Registration
Section 7 defines a new 'recipient-list-history' value of the Mail
Content Disposition Values registry. This value should be registered
in the IANA registry of Mail Content Disposition Values with the
following registration data:
Garcia-Martin & Camarillo Expires March 5, 2007 [Page 10]
Internet-Draft Capacity in Resource Lists September 2006
+------------------------+------------------------------+-----------+
| Name | Description | Reference |
+------------------------+------------------------------+-----------+
| recipient-list-history | the body contains a list of | [RFCXXXX] |
| | URIs that indicates the | |
| | recipients of the SIP | |
| | request | |
+------------------------+------------------------------+-----------+
Table 1: Registration of the 'recipient-list-history' Mail Content
Disposition Value
Note to IANA and the RFC editor: replace RFCXXXX above with the RFC
number of this specification.
9.2. XML Namespace Registration
This section registers a new XML namespace in the XML registry, as
per the guidelines in RFC 3688 [6].
URI: The URI for this namespace is urn:ietf:params:xml:ns:capacity.
Registrant Contact: IETF, SIPPING working group, (sipping@ietf.org),
Miguel Garcia-Martin (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>Capacity Namespace</title>
</head>
<body>
<h1>Namespace for the Capacity Attribute Extension
in Resource Lists</h1>
<h2>urn:ietf:params:xml:ns:capacity</h2>
<p>See <a href="[URL of published RFC]">RFCXXXX
[NOTE TO IANA/RFC-EDITOR: Please replace XXXX with
the RFC number of this specification.]</a>.</p>
</body>
</html>
END
Garcia-Martin & Camarillo Expires March 5, 2007 [Page 11]
Internet-Draft Capacity in Resource Lists September 2006
9.3. XML Schema Registration
This section registers a new XML schema in the XML registry per the
procedures in RFC 3688 [6].
URI: urn:ietf:params:xml:schema:capacity
Registrant Contact: IETF, SIPPING working group, (sipping@ietf.org),
Miguel Garcia-Martin (miguel.an.garcia@nokia.com).
The XML for this schema can be found as the sole content of
Section 5.
10. Acknowledgements
Thanks to Dean Willis, Jari Urpalainen, Pekka Kuure, and Atsushi Sato
for reviewing this document and providing helpful comments.
11. References
11.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Troost, R., Dorner, S., and K. Moore, "Communicating
Presentation Information in Internet Messages: The Content-
Disposition Header Field", RFC 2183, August 1997.
[3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[4] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F.,
Watson, M., and M. Zonoun, "MIME media types for ISUP and QSIG
Objects", RFC 3204, December 2001.
[5] 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.
[6] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[7] Rosenberg, J., "Extensible Markup Language (XML) Formats for
Representing Resource Lists",
draft-ietf-simple-xcap-list-usage-05 (work in progress),
Garcia-Martin & Camarillo Expires March 5, 2007 [Page 12]
Internet-Draft Capacity in Resource Lists September 2006
February 2005.
[8] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", RFC 3851,
July 2004.
[9] Camarillo, G. and A. Roach, "Framework and Security
Considerations for Session Initiation Protocol (SIP) Uniform
Resource Identifier (URI)-List Services",
draft-ietf-sipping-uri-services-05 (work in progress),
January 2006.
11.2. Informational References
[10] Camarillo, G. and A. Johnston, "Conference Establishment Using
Request-Contained Lists in the Session Initiation Protocol
(SIP)", draft-ietf-sipping-uri-list-conferencing-05 (work in
progress), February 2006.
[11] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE
Requests in the Session Initiation Protocol (SIP)",
draft-ietf-sipping-uri-list-message-08 (work in progress),
September 2006.
Authors' Addresses
Miguel A. Garcia-Martin
Nokia
P.O.Box 407
NOKIA GROUP, FIN 00045
Finland
Email: miguel.an.garcia@nokia.com
Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: Gonzalo.Camarillo@ericsson.com
Garcia-Martin & Camarillo Expires March 5, 2007 [Page 13]
Internet-Draft Capacity in Resource Lists September 2006
Full 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.
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.
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).
Garcia-Martin & Camarillo Expires March 5, 2007 [Page 14]
