Internet DRAFT - draft-wang-sip-brs
draft-wang-sip-brs
Network Working Group Xiao. Wang
Internet-Draft Huawei Technologies
Expires: August 17, 2006 February 13, 2006
A method to Batch Subscriptions Refreshments
draft-wang-sip-brs-00
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 August 17, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document presents an extension to the Session Initiation
Protocol (SIP)-Specific Event Notification mechanism for refreshing
batch subscriptions by a message. Subscriber send a message to
refresh many subscriptions, and these subscriptions may be in a
dialog or in several different dialogs.
Wang Expires August 17, 2006 [Page 1]
Internet-Draft A method to bsr February 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview of BSR . . . . . . . . . . . . . . . . . . . . . . . 6
4. Operation BSR . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Batch Subscriptions Refreshment Message . . . . . . . . . 7
4.2. Negotiation of Support for BSR . . . . . . . . . . . . . . 7
4.3. BSRM Body . . . . . . . . . . . . . . . . . . . . . . . . 7
4.4. Subscriber Processing of BSR . . . . . . . . . . . . . . . 8
4.5. Notifier Processing of BSR . . . . . . . . . . . . . . . . 9
4.6. Processing of Expires Header . . . . . . . . . . . . . . . 9
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. XML Schema for BSR . . . . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8.1. New SIP Option Tag: batchrefresh . . . . . . . . . . . . . 16
8.2. New MIME type for BRMS Body . . . . . . . . . . . . . . . 16
8.3. URN Sub-Namespace . . . . . . . . . . . . . . . . . . . . 16
9. Normative References . . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 20
Wang Expires August 17, 2006 [Page 2]
Internet-Draft A method to bsr February 2006
1. Introduction
The SIP-specific event notification mechanism [1] allows a user (the
subscriber) to request to be notified of changes in the state of a
particular resource. This is accomplished by having the subscriber
generate a SUBSCRIBE request for the resource, which is processed by
a notifier that represents the resource. SUBSCRIBE request creates
subscription between subscriber and notifier, if SUBSCRIBE request
send in a dialog then the subscription associated with the dialog,
otherwise SUBSCRIBE request will create a new dialog. Subscription
is installed using a soft-state mechanism, in order to keep
subscription effective during subscription, subscriber needs to send
a SUBSCRIBE request to notifier refresh the timer on subscription. A
SUBSCRIBE request MAY include an "id" parameter in its "Event" header
to allow differentiation between multiple subscriptions in the same
dialog.
There are two methods to get resource, one is RFC3265 SAID that
subscribe single resource by SUBSCRIBE request, the other is event
list mechanism [2] In many cases, a subscriber often has a list of
resources they are interested in. If using the first method, this
will require the subscriber to generate a SUBSCRIBE request for each
resource about which they want information, and subscriber need to
generate SUBSCRIBE refresh for each individual subscription. For
environments in which bandwidth is limited, such as wireless
networks, subscribing to each resource individually is problematic.
To solve these problems, SIMPLE defines a extension to RFC3265 [1]
that allows for requesting and conveying notifications for lists of
resources. A resource list is identified by a URI and it represents
a list of zero or more URIs. Each of these URIs is an identifier for
an individual resource for which the subscriber wants to receive
information. The resource list is not restricted to be inside the
domain of the subscriber. RLS [2] will act as a subscriber to
subscribe non-local resources specified by the list resource.
RLS serve to a lot of subscribers, and subscribers may have part of
non-local resources in the list resource, RLS will send SUBSCRIBE
requests for each non-local resources, so RLS will have a lot of
subscriptions with other notifier.
For security reason etc., some resources inside domain will not allow
to be subscribed directly by non-local domain users. The non-local
domain SUBSCRIBE requests must be send a server which send new
SUBSCRIBE requests to resource server. Therefore, the server will
have a lot of subscriptions with resource server inside domain.
Application Server serves to users need information of user register,
such as welcome message when user register. Application Server can
Wang Expires August 17, 2006 [Page 3]
Internet-Draft A method to bsr February 2006
subscribe event package for registration of users, so Application
Server will have a lot of subscriptions with registrar.
As said, the scenario may be existent that between subscriber and
notifier have a lot of subscriptions, especially between servers. In
this case, subscriber individually refreshes each subscription is
waste to bandwidth and processing capacity of server.
This document presents an extension to the Session Initiation
Protocol (SIP)-Specific Event Notification mechanism for refreshing
batch subscriptions through a message, called batch subscription
refresh. Subscriptions which will be refreshed by a message may be
in a same dialog or multiple different dialogs.
Wang Expires August 17, 2006 [Page 4]
Internet-Draft A method to bsr February 2006
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 and
indicate requirement levels for compliant implementations.
The following terms are used throughout the remainder of this
document.
BSR:Batch Subscriptions Refreshment. It is a mechanism provided to
improve efficiency of many subscriptions between subscriber and
notifier need be refreshed.
BSRM:Batch Subscriptions Refreshment Message. It is used to refresh
many subscriptions with in subscriber and notifier.
BSRL:Batch Subscriptions Refreshment List. A logic construct with in
a subscriber that represent subscriptions and subscriptions associate
dialogs. For each Batch Subscriptions Refreshment List, its lifetime
with in BSRM transaction and be associated with a BSRM.
Wang Expires August 17, 2006 [Page 5]
Internet-Draft A method to bsr February 2006
3. Overview of BSR
This section provides an overview of the typical mode of operation of
this extension. It is not normative.
When subscriber wishes to use BSR, he need to create BSRM and fill
the notifer's SIP URI to BSRM's Request-URI. BSRM body contains
dialog's CALL-ID and subscription's id, refer to [5.3].
BSR accords with SIP-specific event notification mechanism [1]], and
don't conflict to single subscription refresh. In other words,
subscriber MAY use BSR to some subscriptions and use single
subscription refresh to others subscriptions, subscriber MAY also use
BSR to particular subscriptions first and later convert to use single
subscription refresh, vice versa. Even subscriber uses BSR and
single subscription refresh to same subscription at one time will not
conflict.
If a subscriber wishes to perform a subscription refresh with event
filters [3] that need to be placed in the body of a request, the
mechanism here cannot be used. Rather, the subscriber should perform
a normal single subscription refresh using SUBSCRIBE.
Wang Expires August 17, 2006 [Page 6]
Internet-Draft A method to bsr February 2006
4. Operation BSR
4.1. Batch Subscriptions Refreshment Message
BSRM MAY be SUBSCRIBE or a new defined message for BSR. RFC3265 [1]
presents that notifier MUST send a NOTIFY message immediately after
successfully accepting or refreshing a subscription. However the
NOTIFY message to BSR is no significance, so RECOMMENDED notifier
doesn't send NOTIFY for BSR.
BSRM MAY be sent inside dialog or out of dialog. If BSRM is sent
inside a subscription creating dialog, it MAY occur that in the
notifier side the dialog has be freed. According RFC3261 [4]
presents that notifier must return 481 response. It is no matter to
single dialog, but to multiple dialogs that subscriber refreshes
though BSRM is a matter. If subscriber receives a 481 response of
BSRM and refreshing subscriptions inside multiple dialog, subscriber
MUST send a new BSRM inside another subscription dialog or a new BSRM
out of dialog. Subscriber sends BSRM out of dialog, fill the
notifer's SIP URI to BSRM's Request-URI.
The subscriber MUST NOT send a new BSRM request for the same Request-
URI until it has received a final response from the notifier for the
previous one or the previous BSRM request has timed out.
4.2. Negotiation of Support for BSR
This specification uses the SIP option tag mechanism for negotiating
support for the extension defined herein. Refer to RFC3261 [4] for
the normative description of processing of the "Supported" and
"Require" header fields and the 421 (Extension Required) response
code. Including "batchrefresh" in a "Require" header field in a BSRM
request.
4.3. BSRM Body
A BSRM body contains refreshing subscriptions' id and associated
dialogs' Call-ID.
A BSRM body is an XML document [5] that MUST be well-formed and MUST
be valid according to schemas, including extension schemas, available
to the validater and applicable to the XML document. The BSRM body
documents MUST be based on XML 1.0 and MUST be encoded using UTF-8.
The namespace identifier for elements defined by this specification
is a URN [6], using the namespace identifier 'ietf' defined by [7]
and extended by [8]. This urn is: urn:ietf:params:xml:ns:bsr.
The MIME type for the BRMS Body document is "application/bsr+xml".
Wang Expires August 17, 2006 [Page 7]
Internet-Draft A method to bsr February 2006
The root element of the BSRM body is <bsr>. The <bsr> element
contains the namespace definition mentioned above. The <bsr> element
contains one or more <dialog> elements.
The <dialog> element is used to specify a particular dialog of
refreshing subscriptions associated. The <dialog> element has a
"callid" attribute. The value of the "callid" attribute is CALL-ID
header field's value that <dialog> element presents dialog.
The <dialog> element contains zero or more <id> elements. The value
of the <id> element is subscription's id in the Event header field of
normal SUBSCRIBE message. The <id> element has a optional "reason"
attribute. The "reason" attribute only includes 200 response of
BSRM, indicate the reason of refreshing subscription failure with
<id> element.
The subscriptions that the <id> elements match will be refreshed by
BSRM request. If the <dialog> element contains nothing in BSRM
request, that all subscriptions inside the dialog that the <dialog>
element matches will be refreshed.
If the <dialog> element contains <id> elements in BSRM successful
response, that the notifier hasn't matched <id> elements with local
subscription or deal with matched subscription failure, so the
subscriptions that the <id> elements match in subscriber are
invalided and need to free. Another <id> elements that BSRM request
contains and BSRM successful response not contains are valid id that
SHOULD match subscriber local subscriptions and refresh.
4.4. Subscriber Processing of BSR
When subscriber wishes to use BSR, he need create BSRM and fill the
notifer's SIP URI to BSRM's Request-URI. We may get the notifer's
SIP URI by configuring or other method. Including "batchrefresh" in
Require header field in BSRM, and making Content-Type header field in
BSRM contains "application/bsr+xml".
Filling the dialog CALL-ID header field's value and subscription's id
in BSRM body as presenting[5.2] that subscriber want to refresh. At
the same time, create BSRL and fill the same content that just put in
BSRM body in BSRL. Pay attention to, all subscriptions that will be
refreshed together are base on same package type, such as "presence".
When receiving 200 response of BSRM, subscriber parses 200 response
body, and takes out <dialog> elements and <id> elements. Subscriber
uses each <dialog> elements that just take out to match the same
elements in BSRL, if the BSRL has <dialog> elements that aren't
matched, free the <dialog> associated local dialog. To matching
Wang Expires August 17, 2006 [Page 8]
Internet-Draft A method to bsr February 2006
<dialog> elements, taking out the <id> elements in the particular
<dialog> element in response, and match the <id> elements to local
subscriptions and free the matching subscriptions, delete the same
<id>]]> elements in the particular <dialog> in BSRL, and refreshing
the remainder <id> elements in BSRL matching subscriptions.
4.5. Notifier Processing of BSR
Notifier checks Require header field in BSRM request, if the header
contains "batchrefresh", but notifier doesn't support BSR, return 421
response. If supported, notifier construct 200 response message of
BSRM, and take out <dialog> elements and <id> elements from BSRM
body. Notifier uses each <dialog> elements to match local dialog,
put suited <dialog> elements in 200 response body, and matching the
<id> elements in particular <dialog> that matched to local
subscriptions, refreshing the suited subscriptions, put the <id>
elements that unmatched and refreshing failing in 200 response body.
4.6. Processing of Expires Header
In the BSRM, the value of Expires header field applies to all
subscriptions that present in BSRM body. Notifier MUST deal with all
subscriptions for this BSRM using the same value of Expires header
field in BSRM according to RFC3265 [1]. if Expires header field value
equal to 0, this meaning that the subscriber want to free
subscriptions for this BSRM, the operation of this case according to
RFC3265 [1].
Wang Expires August 17, 2006 [Page 9]
Internet-Draft A method to bsr February 2006
5. Example
This section gives an example BSR flow. It is not normative. If a
conflict arises between this flow and the normative behavior
described in this or any other document, the normative descriptions
are to be followed.
In this particular example, Local RLS act as subscriber to subscribe
some of resources on the Other RLS, the resources are presence event
package of Alice, Rocky and Wing. We assume that Local RLS and Other
RLS have built three dialogs, and each dialog associates a
subscription. We use SUBSCRIBE as BSRM.
The Other RLS's address-of-record is "sip:other.rls.com", and Local
RLS subscribe resources' address-of-record are
"sip:Alice@other.rls.com", "sip:Rocky@other.rls.com",
"sip:Wing@other.rls.com".
Wang Expires August 17, 2006 [Page 10]
Internet-Draft A method to bsr February 2006
Local RLS Other RLS
(local.rls.com) (other.rls.com)
| |
| SUBSCRIBE |
| sip: Alice@other.rls.com |
| Call-ID: dB3hdgss@Alice |
| Event: presence; id=gg78hs |
|<================dialog1====================>|
| |
| SUBSCRIBE |
| sip: Rocky@other.rls.com |
| Call-ID: fG32iert8s@Rocky |
| Event: presence; id=grti6yq |
|<================dialog2====================>|
| |
| SUBSCRIBE |
| sip: Wing@other.rls.com |
| Call-ID: rttuW65ie@Wing |
| Event: presence; id=5ty77eer |
|<================dialog3====================>|
| |
| 1. SUBSCRIBE sip:other.rls.com |
| Require: batchrefresh |
| Event: presence |
| Content-Type: application/bsr+xml |
|-----------------SUBSCRIBE------------------>|
| |
| 2. 200 OK sip: local.rls.com |
| Content-Type: application/bsr+xml |
|<----------------200 OK----------------------|
| |
| |
1. Local RLS constructs a BSRM request to refresh three
subscriptions on Other RLS. In the body, there have three <dialog>
elements and in each <dialog> element has a <id> element.
Wang Expires August 17, 2006 [Page 11]
Internet-Draft A method to bsr February 2006
SUBSCRIBE sip: other.rls.com SIP/2.0
Via: SIP/2.0/TCP local.rls.com;branch=z9hG4bKwYb6QREiCL
Max-Forwards: 70
To: <sip: other.rls.com>
From: <sip: local.rls.com>;tag=ie4hbb8t
Call-ID: cdB34qLToC
CSeq: 322723822 SUBSCRIBE
Contact: <sip: local.rls.com>
Event: presence
Expires: 7200
Require: batchrefresh
Accept: application/bsr+xml
Content-Type: application/bsr+xml
Content-Length: ...
<?xml version="1.0" encoding="UTF-8"?>
<bsr xmlns="urn:ietf:params:xml:ns:bsr"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<dialog callid="dB3hdgss@Alice">
<id>gg78hs</id>
</dialog>
<dialog callid="fG32iert8s@Rocky">
<id>grti6yq</id>
</dialog>
<dialog callid="rttuW65ie@Wing">
<id>5ty77eer</id>
</dialog>
</bsr>
2.Other RLS take out the <dialog> elements in BSRM request body, all
the <dialog> elements match dialog on Other RLS, so Other RLS put all
the <dialog> elements in 200 response body of BSRM. Because each the
<id> elements in <dialog> can match subscription, so the <dialog>
elements in 200 response body of BSRM have no <id> elements.
Wang Expires August 17, 2006 [Page 12]
Internet-Draft A method to bsr February 2006
SIP/2.0 200 OK
Via: SIP/2.0/TCP other.rls.com;branch=z9hG4bKwYb6QREiCL
To: <sip: local.rls.com>;tag=zpNctbZq
From: <sip: other.rls.com>;tag=ie4hbb8t
Call-ID: cdB34qLToC
CSeq: 322723822 SUBSCRIBE`
Contact: <sip: other.rls.com>
Expires: 7200
Content-Type: application/bsr+xml
Content-Length: ...
<?xml version="1.0" encoding="UTF-8"?>
<bsr xmlns="urn:ietf:params:xml:ns:bsr"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<dialog callid="dB3hdgss@Alice"/>
<dialog callid="fG32iert8s@Rocky"/>
<dialog callid="rttuW65ie@Wing"/>
</bsr>
Wang Expires August 17, 2006 [Page 13]
Internet-Draft A method to bsr February 2006
6. Security Considerations
This specification relies on the Session Initiation Protocol (SIP)-
Specific Event Notification mechanism [1].
There may be a vicious user or Server that forge or juggle BSRM, and
making the value of Expires header field equal to 0, injecting BSRM
body a lot of actual subscriptions. The notifier receive such BSRM
may mistaken to think that subscriber want to free the subscriptions,
so notitier free the subscriptions according to RFC3265 [1]. This
will make a lot of subscriptions on notifier to be wrongfully freed.
It is RECOMMENDED that TLS be used between subscriber to notifier hop
by hop confidentially protection for BSR. Furthermore, S/MIME MAY be
used for integrity and authenticity of BSRM requests. This is
described in Section 23 of RFC 3261. The notifier should have the
ability to selectively reject BSRM based on the subscriber identity
(based on access control lists), using standard SIP authentication
mechanisms.
Wang Expires August 17, 2006 [Page 14]
Internet-Draft A method to bsr February 2006
7. XML Schema for BSR
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:bsr"
xmlns="urn:ietf:params:xml:ns:bsr"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:annotation>
<xs:documentation xml:lang="en">
XML Schema Definition for SIP Batch Subscriptions Refreshment.
</xs:documentation>
</xs:annotation>
<xs:element name="bsr" type="BSRType"/>
<xs:complexType name="BSRType">
<xs:sequence>
<xs:element name="dialog" type="DialogType"
minOccurs="1" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="DialogType">
<xs:sequence>
<xs:element name="id" type="IdType"
minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="callid" type="xs:string" use="required"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<xs:complexType name="IdType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="reason" type="xs:string"
use="optional"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:schema>
Wang Expires August 17, 2006 [Page 15]
Internet-Draft A method to bsr February 2006
8. IANA Considerations
8.1. New SIP Option Tag: batchrefresh
This section defines a new option tag for the registry established by
section 27.1 of RFC3261 [4].
Option Tag Name: batchrefresh
Description: Extension to allow refreshing many subscriptions by a
message.
Published specification: RFC xxxx [[Note to RFC editor: replace xxxx
with the RFC number of this document when published]]
8.2. New MIME type for BRMS Body
MIME Media Type Name: application
MIME subtype name: bsr+xml
Required parameters: None
Optional parameters: charset
See RFC3023 [9] for a discussion of the charset parameter on XML-
derived MIME types. Since this MIME type is used exclusively in SIP,
the use of UTF-8 encoding is strongly encouraged.
Encoding considerations: 8-bit text
Security considerations: Security considerations specific to uses of
this this MIME type are discussed in RFC xxxx [[Note to RFC editor:
replace xxxx with the RFC number of this document when published]].
RFC1874 [10] and RFC3023 [9] discuss security issues common to all
uses of XML.
8.3. URN Sub-Namespace
URI: urn:ietf:params:xml:ns:bsr
Description: This is the XML namespace URI for XML elements defined
by [RFCXXXX] to describe information about refreshing many
subscriptions by a message. It is used in the application/bsr+xml
body type.
Registrant Contact:
Wang Expires August 17, 2006 [Page 16]
Internet-Draft A method to bsr February 2006
Name: Xiao Wang
E-Mail: wangsmile@huawei.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=utf-8"/>
<title>Namespace for SIP Batch Subscriptions Refreshment</title>
</head>
<body>
<h1>Namespace for SIP Batch Subscriptions Refreshment</h1>
<h2>application/bsr+xml</h2>
<p>See <a href="[[[URL of published RFC]]]">
RFCXXXX</a>.</p>
</body>
</html>
END
9. Normative References
[1] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[2] Roach, A., Campbell, B., and J. Rosenberg et al., "A Session
Initiation Protocol (SIP) Event Notification Extension for
Resource Lists", Draft draft-ietf-simple-event-list-07,
December 2004.
[3] Khartabil, H., "An Extensible Markup Language (XML) Based
Format for Event Notification Filtering",
Draft draft-ietf-simple-filter-format-05, March 2005.
[4] Rosenberg et al., J., Shulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. Schooler,
"SIP: Session Initiation Protocol", RFC 3261, June 2002.
[5] Bray, T., "Exensible Markup Language (XML) 1.0 (Second
Edition)", W3C CR CR-xml11-20011006, October 2000.
Wang Expires August 17, 2006 [Page 17]
Internet-Draft A method to bsr February 2006
[6] Moats, R., "The URN Syntax", RFC 2141, May 1997.
[7] Moats, R., "The URN Namespace for IETF Documents", RFC 2648,
August 1999.
[8] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004.
[9] Murata, M., Laurent, St., and S. Kohn, "XML Media Types",
RFC 3023, January 2001.
[10] Levinson, E., "SGML Media Types", RFC 1874, December 1995.
Wang Expires August 17, 2006 [Page 18]
Internet-Draft A method to bsr February 2006
Author's Address
Xiao Wang
Huawei Technologies
Bantian
Shenzhen, Longgang 518129
China
Phone: +86 755 28788996
Email: wangsmile@huawei.com
Wang Expires August 17, 2006 [Page 19]
Internet-Draft A method to bsr February 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.
Wang Expires August 17, 2006 [Page 20]
