SIPPING J. Rosenberg
Internet-Draft dynamicsoft
Expires: April 18, 2005 G. Camarillo
Ericsson
D. Willis
dynamicsoft
October 18, 2004
A Framework for Consent-Based Communications in the Session
Initiation Protocol (SIP)
draft-ietf-sipping-consent-framework-00.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. 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 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 April 18, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
The Session Initiation Protocol (SIP) supports communications across
many media types, including real-time audio, video, text, instant
messaging, and presence. In its current form, it allows session
Rosenberg, et al. Expires April 18, 2005 [Page 1]
Internet-Draft Consent Framework October 2004
invitations, instant messages, and other requests to be delivered
from one party to another without requiring explicit consent of the
recipient. Without such consent, it is possible for SIP to be used
for malicious purposes, including spam and denial-of-service attacks.
This document identifies a framework for consent-based communications
in SIP.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Relays . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Reference Architecture . . . . . . . . . . . . . . . . . . . 4
5. Structure of a Permission . . . . . . . . . . . . . . . . . 5
6. Attempting Communication . . . . . . . . . . . . . . . . . . 6
7. Requesting a Permission . . . . . . . . . . . . . . . . . . 7
8. Waiting for Permissions . . . . . . . . . . . . . . . . . . 8
9. Granting a Permission . . . . . . . . . . . . . . . . . . . 8
9.1 Permission Servers . . . . . . . . . . . . . . . . . . . . 9
10. Retrying the Original Request . . . . . . . . . . . . . . . 9
11. Permission Revocation . . . . . . . . . . . . . . . . . . . 10
12. Installing Permissions in Advance . . . . . . . . . . . . . 10
13. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . 10
13.1 Basic Flow with No Permission Server . . . . . . . . . . 10
13.2 Basic Flow with a Permission Server . . . . . . . . . . 11
13.3 Third-Party Registration Authorization . . . . . . . . . 13
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
14.1 Normative References . . . . . . . . . . . . . . . . . . . 14
14.2 Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . 16
Rosenberg, et al. Expires April 18, 2005 [Page 2]
Internet-Draft Consent Framework October 2004
1. Introduction
The Session Initiation Protocol (SIP) [1] supports communications
across many media types, including real-time audio, video, text,
instant messaging and presence. This communication is established by
the transmission of various SIP requests (such as INVITE and MESSAGE
[2]) from an initiator to the recipient, with whom communication is
desired. Although a recipient of such a SIP request can reject the
request, and therefore decline the session, a SIP network will
deliver a SIP request to the recipient without their explicit
consent.
Receipt of these requests without explicit consent can cause a number
of problems in SIP networks. These include spam and DoS (Denial of
Service) attacks. These problems are described in more detail in a
companion requirements document [6].
This specification defines a basic framework for adding consent-based
communication to SIP.
2. Definitions
Recipient URI: The request-URI of an outgoing request sent by an
entity (e.g., a proxy) that has performed a translation operation.
Target URI: The request-URI of an incoming request that arrives to an
entity (e.g., a proxy) that will perform a translation operation.
Translation operation: Operation by which an entity (e.g., a proxy)
translates the request URI of an incoming request (i.e., the
target URI) into one or more URIs (i.e., recipient URIs) which are
used as the request URIs of one or more outgoing requests.
3. Relays
A central concept in this framework is that of a relay. A relay is
defined as any SIP server, be it a proxy, B2BUA (Back-to-Back User
Agent), or some hybrid, which receives a request and translates the
request URI into one or more next hop URIs to which it then delivers
a request. The request URI of the incoming request is referred to as
'target URI' and the destination URI of the outgoing requests is
referred to as 'recipient URIs', as shown in Figure 1.
Rosenberg, et al. Expires April 18, 2005 [Page 3]
Internet-Draft Consent Framework October 2004
+---------------+
| | recipient URI
| |---------------->
target URI | Translation |
-------------->| Operation | recipient URI
| |---------------->
| |
+---------------+
Figure 1: Translation operation
So, an essential aspect of a relay is that of translation. When a
relay receives a request, it translates the request URI into one or
more additional URIs. Or, more generally, it can create outgoing
requests to one or more additional URIs. The translation operation
is what creates the consent problem. Since the translation operation
can result in more than one URI, it is the source of amplification.
Servers that do not perform translations, such as outbound proxy
servers, do not cause amplification.
Since the translation operation is based on local policy or local
data (such as registrations), it is the vehicle by which a request is
delivered directly to an endpoint, when it would not otherwise be
possible to. In other words, if a spammer has the address of a user,
sip:user@example.com, it cannot deliver a MESSAGE request to the user
agent of that user without having access to the registration data
that maps sip:user@example.com to the UA on which that user is
present. Thus, it is the usage of this registration data, and more
generally, the translation logic, which must be authorized, in order
to prevent undesired communications.
4. Reference Architecture
The reference architecture is shown in Figure 2. In this
architecture, a UAC wishes to send a message to a request URI
representing a resource in domain A (sip:resource@A). This request
may pass through a local outbound proxy (not shown), but eventually
arrives at a server authoritative for domain A. This server, which
acts as a relay, performs a translation operation, translating the
target URI into one or more recipient URIs, which may or may not
belong to domain A. This relay may be, for instance, a proxy server
or a URI-list service.
Rosenberg, et al. Expires April 18, 2005 [Page 4]
Internet-Draft Consent Framework October 2004
+-------+
| |
>| UAS |
+-------+ / | |
| Rules | / +-------+
| DB | /
+-------+ /
| /
V /
+-----+ +-------+ / +-------+
| | | |/ | |
| UAC |------>| Relay |-------->| Proxy |
| | | |\ | |
+-----+ +-------+ \ +-------+
\
\ [...]
\
\
\ +-------+
\ | |
>| B2BUA |
| |
+-------+
Figure 2: Relay performing a translation
5. Structure of a Permission
This framework centers on the idea that a relay will only perform a
translation if a permission is in place authorizing that translation.
As such, the notion of a permission is another key part of this
framework. A permission is an object, represented in XML, that
contains several pieces of data:
Identity of the Sender: A URI representing the identity of the sender
for whom permissions are granted.
Identity of the Original Recipient: A URI representing the identity
of the original recipient, which is used as the input for the
translation operation. This is also called the target URI.
Identity of the Final Recipient: A URI representing the result of the
translation. The permission grants ability for the sender to send
requests to the target URI, and for a relay receiving those
requests to forward them to this URI. This is also called the
recipient URI.
Rosenberg, et al. Expires April 18, 2005 [Page 5]
Internet-Draft Consent Framework October 2004
Operations Permitted: A set of specific methods or qualifiers for
which the permission applies. For example, the permission may
only grant relaying for INVITE or MESSAGE, or for MESSAGE with
specific MIME types.
Signature: A digital signature over the rest of the permission,
signed by an entity that can identify itself as the recipient URI.
The signature is not always present.
Permissions are installed on a resource by resource basis. That is,
for each target URI to which a request is sent, there is a set of
permissions installed for that URI. Each permission has the content
described above.
A natural format for representing permissions appears to be the
common policy format [4]. This format is also used for presence
permissions.
6. Attempting Communication
When a UA sends a request to a target resource, the request
eventually arrives at a server that is authoritative for the domain
in the request URI. The server may require, as part of its
processing logic, the relaying of the request to one or more next
hops. If such relaying is required, the server first authenticates
the sender of the request. Such authentication can be done using the
SIP identity mechansim [5]. Once the sender is authenticated, the
server checks its permission database for that target resource. It
looks for permissions containing senders whose URI matches the
identity of the sender of the request. Of those that are found, the
server checks to see if the permitted translated URI matches the URIs
to which the server wishes to relay the request.
If at least one of the next hops to which the server wishes to relay
have not been permitted, the server rejects the request with a 470
(Consent Needed) response. The 470 response code indicates that the
request couldn't be relayed because at least one permission was not
present. The error response contains a body, which contains a list
of URIs for the translations for which permissions have not yet been
obtained. This is effectively an instruction for the sender to
obtain permissions from those URIs.
Some services may return a different status code than 470 (Consent
Needed) in the response with the list of URIs for the translations
for which permissions have not yet been obtained. For example, a
URI-list service which receives a request with a list of recipient
URIs may already have permissions for some of them. The URI-list
Rosenberg, et al. Expires April 18, 2005 [Page 6]
Internet-Draft Consent Framework October 2004
service may choose to perform the translations which it has
permissions for and return a 200 (OK) response with a list of URIs
for the translations for which permissions have not yet been
obtained.
The 470 (Consent Needed) response may carry a URI in a Call-Info
header field (wait-permission purpose) where the client can SUBSCRIBE
to using the wait-permission event package. This event package
models the state of the permission granted to the client for
communicating with the target URI. When a permission is granted, the
state changes, and the client receives a NOTIFY. This NOTIFY
contains the permission(s) that have been granted for the sender.
Usage of an event package has the benefit that the client can come
back at any time and do a query SUBSCRIBE to see if permissions were
granted, or it can wait for them to be granted, and find out when.
There is no requirement that the client use this event package to
wait. For some requests, it may not be important for the sender to
find out when permission is granted (e.g., a presence subscription).
7. Requesting a Permission
If the attempt to communicate was rejected with a 470 (Consent
Needed) response, the client knows that it must obtain some number of
permissions in order for the communications to take place. The error
response will include a list of URIs for which permission must be
obtained. To obtain permission, the client sends a CONSENT request
to each of the URIs it learned from the body of the error response.
These URIs typically route to the relay, which will forward them on
to the destinations whose permissions have not been obtained yet.
The CONSENT request carries a Consent-Methods header field which
indicates for which methods consent is being requested.
When the CONSENT request arrives at the relay, the relay adds a
Permission-Requested header field which contains a URI that the
receiver can use to download a description of the permission being
requested (e.g., an XML-based permission document). Then, the relay
forwards the request towards its destination.
If there are several relays between the sender and the final
destination, those CONSENT requests may also fail if permissions have
not yet been obtained, in which case the process recurses.
Eventually, the client will have sent a request to all of the relays
at the leaves of the translation tree between the sender and the
final destinations.
Rosenberg, et al. Expires April 18, 2005 [Page 7]
Internet-Draft Consent Framework October 2004
8. Waiting for Permissions
A CONSENT request is responded with a 202 (Accepted) response. As
stated earlier, if the client is interested in the status of the
permissions, it can SUBSCRIBE to the the wait-permission event
package using the URI received in the Call-Info header field
(wait-permission purpose) of the previously received 470 (Consent
Needed) response.
9. Granting a Permission
On reception of a CONSENT request, the user fetches the permission
being requested from the URI in the Permission-Requested header
field. This permission document includes the URI that the user needs
to use to upload the permissions that the user chooses to grant. So,
if the user wishes to grant a permission, XCAP is used, just as it is
today in presence. The owner of the target resource would use
contact this URI and use XCAP to place the permission into a document
containing the list of permissions for that target resource.
The owner of the target resource may choose to grant the
permissions requested or a superset of them. For example, a
CONSENT request may request permission to perform a given
translation on MESSAGE requests, and the target resource owner may
grant permission to perform the translation on any request (not
only on MESSAGE requests).
The relay that needs the permission needs to make sure that the
entity uploading the permission document is the same as the
destination of the CONSENT request. This can be done by having the
URIs returned in the 470 (Consent Needed) response route to the relay
itself. When the relay receives the CONSENT request, it inserts a
URI in the Permission-Requested header field which is long and random
enough so that it cannot be guessed. In addition, the URI that the
target resource owner will use to upload its permission should also
be unguessable. The CONSENT request is delivered to the user using a
SIPS URI. Then, the relay inserting such a URI relies on the SIP
routing infrastructure to deliver the CONSENT request to its proper
destination.
If the SIP routing infrastructure is compromised, it could route
the CONSENT request to an attacker so that the attacker could
authorize requests addressed to a victim. Nevertheless, if the
SIP routing infrastructure gets compromised, many types of attacks
much worse than this are possible. So, relaying on the SIP
routing infrastructure seems like a sensible choice.
Architectures with a key infrastructure in place may not need (in
Rosenberg, et al. Expires April 18, 2005 [Page 8]
Internet-Draft Consent Framework October 2004
some situations) to relay on the SIP routing architecture to ensure
that the entity uploading the permission document is the target
resource owner. The target resource owner can sign its permission
documents instead.
Using XCAP to grant permissions will require the definition of a new
application usage. We note that this usage appears to be a
generalization of the presence rules usage currently defined [7].
9.1 Permission Servers
We have just described how a user agent that receives a CONSENT
request can use XCAP to grant certain permissions. Nevertheless,
users are not on-line all the time and, so, sometimes are not able to
receive CONSENT requests.
This issue is also found in presence, where a user's status is
reported by a presence server instead of by the user's user agents,
which can go on and off-line. Similarly, we define permission
servers. Permission servers are network elements that act as SIP UAs
and handle CONSENT requests for a user.
Permission servers inform users about new CONSENT requests using the
"grant-permission" event package. The user associated with the
target URI SUBSCRIBEs to the "grant-permission" event package at the
permission server. This event package models the state of all
pending CONSENT requests for a particular resource, for which
permissions do not yet exist. When a new CONSENT request arrives for
which permissions have not been granted, a NOTIFY is sent to the
user. This informs them that permission is needed for a particular
sender. The NOTIFY contains information on the operation which was
requested.
There is a strong similarity between the watcherinfo event package
and the grant-permission event package. Indeed, the
grant-permission package is effectively a superset of watcherinfo.
Once in place, presentities could use the grant-permission event
package for presence in addition to all other services for which
opt-in is being provided.
10. Retrying the Original Request
The sender learns about permissions through the wait-permission event
package. Once it has obtained permissions for all of the resources
that were identified in the 470 (Consent Needed) response, the client
can retry the original request.
Rosenberg, et al. Expires April 18, 2005 [Page 9]
Internet-Draft Consent Framework October 2004
11. Permission Revocation
At any time, if a client wants to revoke any permission, it uses the
same URI as before to upload a new permission document. If a client
lost this URI for some reason, it would need to wait until it
received a new request and respond with a 470 (Consent Needed)
response. The client would get the URI in a new CONSENT request.
12. Installing Permissions in Advance
The previous sections described how a relay can request a target
resource owner to authorize a communication attempt. However, target
resource owners may want to authorize a particular translation in
advance. That is, before any communication attempt is performed.
To do so, the target resource owner sends a CONSENT request to the
target URI of the translation. This CONSENT request will trigger the
mechanisms described in the previous sections. The result is that
the target resource owner(s) will obtain a URI to upload a permission
document.
13. Use Cases
The following use cases exhibit how the framework works.
13.1 Basic Flow with No Permission Server
A Relay + XCAP Server B
|(1) MESSAGE list@relay | |
|-------------------------->| |
|(2) 470 Consent Needed | |
|Call-Info: 123@relay; | |
|purpose= wait-permission | |
|xyz@relay | |
|<--------------------------| |
|(3) CONSENT xyz@relay | |
|-------------------------->| |
| |(4) CONSENT B |
| |Permission-Requested: uri-req
| |-------------------------->|
| |(5) 202 Accepted |
| |<--------------------------|
|(6) 202 Accepted | |
|<--------------------------| |
|(7) SUBSCRIBE 123@relay | |
|-------------------------->| |
|(8) 200 OK | |
Rosenberg, et al. Expires April 18, 2005 [Page 10]
Internet-Draft Consent Framework October 2004
|<--------------------------| |
|(9) NOTIFY (no permission) | |
|<--------------------------| |
|(10) 200 OK | |
|-------------------------->| |
| |(11) XCAP uri-req |
| |Get Requested Permission |
| |<--------------------------|
| |(12) 200 OK |
| |Permission Document |
| |URI to Upload: uri-up |
| |-------------------------->|
| |(13) XCAP uri-up |
| |Permission Document |
| |<--------------------------|
| |(14) 200 OK |
| |-------------------------->|
|(15) NOTIFY (permission) | |
|<--------------------------| |
|(16) 200 OK | |
|-------------------------->| |
|(17) MESSAGE list@relay | |
|-------------------------->| |
| |(18) MESSAGE B |
| |-------------------------->|
Figure 3
13.2 Basic Flow with a Permission Server
A Relay + XCAP Server B's Permission B
Server
|(1) MESSAGE list@relay | |
|------------------>| | |
|(2) 470 Consent Needed | |
|Call-Info: 123@relay; | |
|purpose= wait-permission | |
|xyz@relay | | |
|<------------------| | |
|(3) CONSENT xyz@relay | |
|------------------>| | |
| |(4) CONSENT B | |
| |Permission-Requested: uri-req |
| |------------------>| |
| |(5) 202 Accepted | |
| |<------------------| |
Rosenberg, et al. Expires April 18, 2005 [Page 11]
Internet-Draft Consent Framework October 2004
|(6) 202 Accepted | | |
|<------------------| | |
|(7) SUBSCRIBE 123@relay | |
|------------------>| | |
|(8) 200 OK | | |
|<------------------| | |
|(9) NOTIFY (no permission) | |
|<------------------| | |
|(10) 200 OK | | |
|------------------>| | |
| |(11) XCAP uri-req | |
| |Get Requested Permission |
| |<------------------| |
| |(12) 200 OK | |
| |Permission Document| |
| |URI to Upload: uri-up |
| |------------------>| |
| | | |B logs in
| | |(13) SUBSCRIBE |
| | |grant-permission |
| | |<------------------|
| | |(14) 200 OK |
| | |------------------>|
| | |(15) NOTIFY |
| | |Permission Document|
| | |URI to Upload: uri-up
| | |------------------>|
| | |(16) 200 OK |
| | |<------------------|
| |(17) XCAP uri-up | |
| |Permission Document| |
| |<--------------------------------------|
| |(18) 200 OK | |
| |-------------------------------------->|
|(19) NOTIFY (permission) | |
|<------------------| | |
|(20) 200 OK | | |
|------------------>| | |
|(21) MESSAGE list@relay | |
|------------------>| | |
| |(22) MESSAGE B | |
| |-------------------------------------->|
Figure 4
Rosenberg, et al. Expires April 18, 2005 [Page 12]
Internet-Draft Consent Framework October 2004
13.3 Third-Party Registration Authorization
A REGISTER transaction binds an address of records
(Joe.Smith@example.com) with the current location of the user
(Joe@terminal-28.example.com). Effectively, the REGISTER transaction
is setting up a translation operation. The user wants to authorize
this translation before anybody tries to contact him on his address
of records. To do so, the user sends a CONSENT request to the target
URI of the translation (i.e., Joe.Smith@example.com). The registrar
adds a Permission-Requested header field to the CONSENT request and
forwards it to the current location of the user
(Joe@terminal-28.example.com). Now, the user can upload a permission
document for the translation (e.g., this translation is authorized
for any incoming request).
Joe@ example.com Registrar Joe@
terminal12 terminal28
|(1) REGISTER Joe.Smith@example.com |
|To:Joe@terminal28.example.com |
|-------------------------->| |
|(2) 200 OK | |
|<--------------------------| |
|(3) CONSENT Joe.Smith@example.com |
|-------------------------->| |
| |(4) CONSENT Joe@terminal28.example.com
| |Permission-Requested: uri-req
| |-------------------------->|
| |(5) 202 Accepted |
| |<--------------------------|
|(6) 202 Accepted | |
|Call-Info: 123@registrar; | |
|purpose= wait-permission | |
|<--------------------------| |
|(7) SUBSCRIBE 123@registrar| |
|-------------------------->| |
|(8) 200 OK | |
|<--------------------------| |
|(9) NOTIFY (no permission) | |
|<--------------------------| |
|(10) 200 OK | |
|-------------------------->| |
| |(11) XCAP uri-req |
| |Get Requested Permission |
| |<--------------------------|
| |(12) 200 OK |
| |Permission Document |
| |URI to Upload: uri-up |
Rosenberg, et al. Expires April 18, 2005 [Page 13]
Internet-Draft Consent Framework October 2004
| |-------------------------->|
| |(13) XCAP uri-up |
| |Permission Document |
| |<--------------------------|
| |(14) 200 OK |
| |-------------------------->|
|(15) NOTIFY (permission) | |
|<--------------------------| |
|(16) 200 OK | |
|-------------------------->| |
Figure 5
14. References
14.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] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and D.
Gurle, "Session Initiation Protocol (SIP) Extension for Instant
Messaging", RFC 3428, December 2002.
14.2 Informative References
[3] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work
in progress), January 2003.
[4] Schulzrinne, H., "A Document Format for Expressing Privacy
Preferences", draft-ietf-geopriv-common-policy-01 (work in
progress), July 2004.
[5] Peterson, J., "Enhancements for Authenticated Identity
Management in the Session Initiation Protocol (SIP)",
draft-ietf-sip-identity-02 (work in progress), May 2004.
[6] Rosenberg, J., "Requirements for Consent-Based Communications in
the Session Initiation Protocol (SIP)",
draft-rosenberg-sipping-consent-reqs-00 (work in progress), July
2004.
[7] Rosenberg, J., "Presence Authorization Rules",
draft-ietf-simple-presence-rules-00 (work in progress), May
2004.
Rosenberg, et al. Expires April 18, 2005 [Page 14]
Internet-Draft Consent Framework October 2004
Authors' Addresses
Jonathan Rosenberg
dynamicsoft
600 Lanidex Plaza
Parsippany, NJ 07054
US
Phone: +1 973 952-5000
EMail: jdrosen@dynamicsoft.com
URI: http://www.jdrosen.net
Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
EMail: Gonzalo.Camarillo@ericsson.com
Dean Willis
dynamicsoft
5100 Tennyson Parkway
Suite 1200
Plano, TX 75028
USA
EMail: dean.willis@softarmor.com
Rosenberg, et al. Expires April 18, 2005 [Page 15]
Internet-Draft Consent Framework October 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.
Rosenberg, et al. Expires April 18, 2005 [Page 16]