Network Working Group J. Miller
Internet-Draft P. Saint-Andre
Expires: December 20, 2002 Jabber Software Foundation
T. Bamonti
Jabber, Inc.
June 21, 2002
XMPP CPIM Mapping
draft-miller-xmpp-cpim-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 20, 2002.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This document describes a mapping of the eXtensible Messaging and
Presence Protocol (XMPP) to the Common Presence and Instant Messaging
specification.
Miller, et al. Expires December 20, 2002 [Page 1]
Internet-Draft XMPP CPIM Mapping June 2002
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Conventions Used in this Document . . . . . . . . . . . . 3
1.4 Discussion Venue . . . . . . . . . . . . . . . . . . . . . 3
1.5 Intellectual Property Notice . . . . . . . . . . . . . . . 3
2. CPIM Gateway . . . . . . . . . . . . . . . . . . . . . . . 4
3. CPIM Mapping for Instant Messages . . . . . . . . . . . . 5
3.1 Identification of INSTANT INBOXes . . . . . . . . . . . . 5
3.2 The Message Operation . . . . . . . . . . . . . . . . . . 5
3.2.1 Message Parameters . . . . . . . . . . . . . . . . . . . . 5
3.2.2 Exceptions . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2.3 Message Delivery . . . . . . . . . . . . . . . . . . . . . 6
4. CPIM Mapping for Presence . . . . . . . . . . . . . . . . 8
4.1 Identification of PRESENTITIES . . . . . . . . . . . . . . 8
4.2 The Presence Service . . . . . . . . . . . . . . . . . . . 8
4.2.1 The Subscribe Operation . . . . . . . . . . . . . . . . . 8
4.2.1.1 Duration Parameter Considerations . . . . . . . . . . . . 9
4.2.1.2 Subscription Exceptions . . . . . . . . . . . . . . . . . 9
4.2.1.3 Completing the Subscribe Operation . . . . . . . . . . . . 10
4.2.2 The Notify Operation . . . . . . . . . . . . . . . . . . . 10
4.2.3 The Unsubscribe Operation . . . . . . . . . . . . . . . . 11
4.2.4 The Fetch Operation . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . 14
References . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 15
Full Copyright Statement . . . . . . . . . . . . . . . . . 17
Miller, et al. Expires December 20, 2002 [Page 2]
Internet-Draft XMPP CPIM Mapping June 2002
1. Introduction
1.1 Overview
Common Presence and Instant Messaging (CPIM) [1] describes an
abstract framework for interoperability of instant messaging and
presence systems compliant with RFC 2779 [2]. This document
describes how systems based on the eXtensible Messaging and Presence
Protocol (XMPP) map to the abstract CPIM model.
1.2 Terminology
This memo makes use of the vocabulary defined in RFC 2778 [3]. Terms
such as CLOSED, INSTANT INBOX, INSTANT MESSAGE, OPEN , PRESENCE
SERVICE, PRESENTITY, SUBSCRIPTION, and WATCHER are used in the same
meaning as defined therein. This memo also makes use of the
vocabulary defined in XMPP Core [4]. Terms such as ENTITY, JABBER
IDENTIFIER (JID), NODE IDENTIFIER, DOMAIN IDENTIFIER, RESOURCE
IDENTIFIER, MESSAGE ELEMENT, PRESENCE ELEMENT, and IQ ELEMENT are
used in the same meaning as defined therein.
1.3 Conventions Used in this Document
The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC
2119 [5].
1.4 Discussion Venue
The authors welcome discussion and comments related to the topics
presented in this document, preferably on the "jabber-
ietf@jabber.org" mailing list (archives and subscription information
are available at http://www.jabber.org/cgi-bin/mailman/listinfo/
jabber-ietf/).
1.5 Intellectual Property Notice
This document is in full compliance with all provisions of Section 10
of RFC 2026. Parts of this specification use the term "jabber" for
identifying URI schemes, namespaces, and other protocol syntax.
Jabber[tm] is a trademark of Jabber, Inc. If the IETF places this
document, or a successor document, on the standards track, then
Jabber, Inc. grants permission for use of the trademark "Jabber" in
association with that specification.
Miller, et al. Expires December 20, 2002 [Page 3]
Internet-Draft XMPP CPIM Mapping June 2002
2. CPIM Gateway
A common method for achieving interoperability between two disparate
systems or services is through the use of a "gateway" that interprets
the protocols of each system and translates them into the protocols
of the other. CPIM defines the common method of agreement to be used
for interoperability of instant messaging and presence systems/
services compliant with RFC 2779 [2]. This document describes the
manner in which an instant messaging and presence system based on
XMPP will interface to a gateway that supports the CPIM
specifications. As such, this document assumes no more about the
target instant messaging and presence system than that it also
complies with the abstract CPIM service definition.
+-------------+ +-------------+ +--------------+
| | | | | |
| XMPP | | CPIM | | CPIM- |
| Service | <----> | Gateway | <----> | Compliant |
| | | | | Service |
+-------------+ +-------------+ +--------------+
Miller, et al. Expires December 20, 2002 [Page 4]
Internet-Draft XMPP CPIM Mapping June 2002
3. CPIM Mapping for Instant Messages
This section describes how a CPIM compliant gateway MAY map instant
messages between an XMPP service and a CPIM service.
3.1 Identification of INSTANT INBOXes
There is a one-to-one relationship between an XMPP ENTITY and a CPIM
INSTANT INBOX. This relationship is made possible using a JABBER
IDENTIFER (JID) and conforming to RFC 2822 [7] (e.g., "node@domain")
where the "node" part maps to an XMPP NODE IDENTIFIER and is
interpreted and assigned semantics only by the DOMAIN IDENTIFIER
specified in the "domain" part.
3.2 The Message Operation
3.2.1 Message Parameters
When an XMPP service sends or receives an INSTANT MESSAGE it uses the
XMPP MESSAGE ELEMENT. The XMPP MESSAGE ELEMENT maps to the CPIM
service as follows:
When sending messages from XMPP to CPIM:
o The XMPP "from" attribute (node@domain) maps to the CPIM "message
source" field (im:node@domain). The CPIM gateway SHOULD append
the "im:" Instant Messaging URI scheme to the front of the
address.
o The XMPP "to" attribute (node@domain) maps to the CPIM
"destination" field (im:node@domain). The CPIM gateway SHOULD
append the "im:" Instant Messaging URI scheme to the front of the
address.
o The XMPP "id" attribute maps to the CPIM "TransID" field.
o The XMPP <body/> element maps to the CPIM "message" field.
When sending messages from CPIM to XMPP:
o The CPIM "message source" field (im:node@domain) maps to the XMPP
"from" attribute (node@domain). The CPIM gateway SHOULD remove
the "im:" Instant Messaging URI scheme from the front of the
address.
o The CPIM "destination" field (im:node@domain) maps to the XMPP
"to" attribute (node@domain). The CPIM gateway SHOULD remove the
"im:" Instant Messaging URI scheme to the front of the address.
Miller, et al. Expires December 20, 2002 [Page 5]
Internet-Draft XMPP CPIM Mapping June 2002
o The CPIM "TransID" field maps to the XMPP "id" attribute.
o The CPIM "message" field maps to the XMPP <body/> element.
3.2.2 Exceptions
During a message operation, an exception is encountered if:
o The source or destination does not refer to a valid INSTANT INBOX;
or
o Access control does not permit the application to request this
operation; or
o The service is unable to successfully deliver the message.
Exceptions between an XMPP service and a CPIM service are mapped as
follows:
o Messaging errors originating from XMPP to CPIM SHOULD translate to
a CPIM "response status" of failure.
o Messaging errors originating from CPIM to XMPP SHOULD translate to
an XMPP <error/> element of type code = 503 (Service Unavailable).
Since the CPIM service does not specify error codes to distinguish
between different error events, it is not possible to map context-
specific error information originating from the CPIM service back to
the XMPP service. However, it is expected that most real-world
instant messaging and presence service implementations will support
some level of contextual exception handling. In these cases, the
CPIM gateway would be designed in a fashion to map the contextual
error messages between interoperating systems. For the purpose of
this document, since all CPIM exceptions result in a generic status
of "failure", the associated mapping to the XMPP service SHOULD be to
the XMPP <error/> element of type code = 503 (Service Unavailable).
3.2.3 Message Delivery
By default, XMPP services operate on an "exception" basis. That is,
if an operation is successful, no status response is sent. If an
operation is unsuccessful, then an <error/> response is delivered.
This is by design to limit unnecessary network overhead.
When sending a message from CPIM to XMPP:
o If the XMPP service is able to successfully deliver the message,
Miller, et al. Expires December 20, 2002 [Page 6]
Internet-Draft XMPP CPIM Mapping June 2002
no status response will be delivered. If no response is received
by the CPIM gateway (i.e., no error message is delivered) after
delivering a message to an XMPP service, then a CPIM gateway
response operation having status "success" SHOULD be sent to the
CPIM service.
o If the XMPP service is unable to successfully deliver the message,
an XMPP <error/> message will be sent to the CPIM gateway. This
will result in a response operation having status "failure" sent
to the CPIM service. The XMPP "id" attribute returned with the
error message will be identical to the "transID" value of the
originating CPIM message. The CPIM gateway will map the XMPP "id"
to the CPIM "transID" parameter for delivery of the error message
to the CPIM service.
When sending a message from XMPP to CPIM:
o If the CPIM service is able to successfully deliver the message,
the "success" response SHOULD be silently dropped.
o If the CPIM service is unable to successfully deliver the message,
a response status message of type "failure" will be generated by
the CPIM service. This SHOULD result in the CPIM gateway sending
an XMPP <error/> message of type code = 503 (Service Unavailable)
to the XMPP service.
Miller, et al. Expires December 20, 2002 [Page 7]
Internet-Draft XMPP CPIM Mapping June 2002
4. CPIM Mapping for Presence
This section describes how a CPIM compliant gateway SHOULD map
presence information between an XMPP service and a CPIM service.
4.1 Identification of PRESENTITIES
There is a one-to-one relationship between an XMPP ENTITY and a CPIM
PRESENTITY using a JABBER IDENTIFER (JID) and conforming to RFC 2822
[7] (e.g., "node@domain") where the "node" part maps to an XMPP NODE
IDENTIFIER and is interpreted and assigned semantics only by the
DOMAIN IDENTIFIER specified in the "domain" part (e.g.,
"node@domain").
4.2 The Presence Service
4.2.1 The Subscribe Operation
This section describes how a "subscribe" operation will be performed
between an XMPP service and a CPIM service.
When an application wants to (periodically) receive the presence
information associated with a PRESENTITY, it invokes the subscribe
operation.
When an XMPP service performs a "subscribe" operation it uses the
XMPP PRESENCE ELEMENT. The XMPP PRESENCE ELEMENT maps to the CPIM
service as follows:
When sending a subscription request from XMPP to CPIM:
o The XMPP "from" attribute (node@domain) maps to the CPIM "watcher
parameter" field (pres:node@domain). The CPIM gateway SHOULD
append the "pres:" Presence URI scheme to the front of the
address.
o The XMPP "to" attribute (node@domain) maps to the CPIM "target
parameter" field (pres:node@domain). The CPIM gateway SHOULD
append the "pres:" Presence URI scheme to the front of the
address.
o There is no XMPP mapping for the CPIM "duration parameter". XMPP
subscriptions are active until they have been explicitly
"unsubscribed". See Duration Parameter Considerations (Section
4.2.1.1) below for further discussion regarding the "duration
parameter".
o The XMPP "id" attribute maps to the CPIM "TransID" field.
Miller, et al. Expires December 20, 2002 [Page 8]
Internet-Draft XMPP CPIM Mapping June 2002
o The XMPP "subscribe" attribute maps to the CPIM "subscribe"
operation field.
When sending a subscription request from CPIM to XMPP:
o The CPIM "watcher parameter" field (pres:node@domain) maps to the
XMPP "from" attribute (node@domain). The CPIM gateway SHOULD
remove the "pres:" Presence URI scheme from the front of the
address.
o The CPIM "target parameter" field (im:node@domain) maps to the
XMPP "to" attribute (node@domain). The CPIM gateway SHOULD remove
the "pres:" Presence URI scheme to the front of the address.
o The CPIM "TransID" field maps to the XMPP "id" attribute.
o The CPIM "subscribe" operation field maps to the XMPP "subscribe"
attribute.
4.2.1.1 Duration Parameter Considerations
The XMPP service assumes a subscription to be active until it is
explicitly unsubscribed. Handling/mapping of a subscription
"duration parameter" will be highly dependent on the implementation
and requirements of the associated instant messaging and presence
system represented in this document by the CPIM service. Since there
are no explicit requirements for supporting a "duration parameter"
specified in either RFC 2778 [3] or RFC 2779 [2], this would be an
implementation/service specific consideration that falls outside of
the scope of this document.
4.2.1.2 Subscription Exceptions
During a "subscribe" operation, one of the following exceptions MAY
be encountered:
o The watcher or target parameter ("from" or "to") does not refer to
a valid PRESENTITY (or Jabber Identifier).
o Access control MAY NOT permit the application to request this
operation.
o There MAY be a pre-existing subscription or in-progress subscribe
operation between the watcher and the target entities.
o The target PRESENTITY denies the subscription request.
Miller, et al. Expires December 20, 2002 [Page 9]
Internet-Draft XMPP CPIM Mapping June 2002
Exceptions between an XMPP service and a CPIM service are mapped as
follows:
o Messaging errors originating from XMPP to CPIM SHOULD translate to
a CPIM "response status" of failure.
o Messaging errors originating from CPIM to XMPP SHOULD translate to
an XMPP <error/> element of type code = 503 (Service Unavailable).
4.2.1.3 Completing the Subscribe Operation
If the subscribe request from the XMPP service to the CPIM service is
successful:
o The CPIM issues a "response status" = "success". This is mapped
to the XMPP PRESENCE ELEMENT attribute "type" = "subscribed" and
returned to the subscribing XMPP ENTITY.
o A notify operation, corresponding to the CPIM "target's" presence
information, is immediately invoked for the subscribing XMPP
ENTITY (see The Notify Operation (Section 4.2.2) below).
o Until the subscription is "unsubscribed", a notify operation is
invoked for the subscribing XMPP ENTITY every time the CPIM
"target's" presence information changes.
If the subscribe request from the CPIM service to the XMPP service is
successful:
o The XMPP service issues a PRESENCE ELEMENT response attribute
"type" = "subscribed". This is mapped to the CPIM "response
status" = "success" and returned to the subscribing CPIM
"watcher".
o A notify operation, corresponding to the XMPP ENTITY's presence
information, is immediately invoked for the subscribing CPIM
watcher (see The Notify Operation (Section 4.2.2) below).
o Until the subscription is "unsubscribed", a notify operation is
invoked for the subscribing CPIM watcher every time the XMPP
ENTITY's presence information changes.
4.2.2 The Notify Operation
This section describes how a "Notify" operation will be performed
between an XMPP service and a CPIM service.
Miller, et al. Expires December 20, 2002 [Page 10]
Internet-Draft XMPP CPIM Mapping June 2002
A notify operation is invoked whenever the presence information
associated with an XMPP ENTITY or a CPIM PRESENTITY changes and there
are subscribers to that information.
When an XMPP service performs a "notify" operation indicating a
change in presence, it uses the XMPP PRESENCE ELEMENT. The XMPP
PRESENCE ELEMENT maps to the CPIM service as follows:
When sending a presence notification from XMPP to CPIM:
o The XMPP "from" attribute (node@domain) maps to the CPIM "target
parameter" field (pres:node@domain). The CPIM gateway SHOULD
append the "pres:" Presence URI scheme to the front of the
address.
o The XMPP "to" attribute (node@domain) maps to the CPIM "watcher
parameter" field (pres:node@domain). The CPIM gateway SHOULD
append the "pres:" Presence URI scheme to the front of the
address.
o The XMPP "id" attribute maps to the CPIM "TransID" field.
o The XMPP "type" attribute maps to the CPIM "presence information"
field.
When sending a presence notification from CPIM to XMPP:
o The CPIM "target parameter" field (pres:node@domain) maps to the
XMPP "from" attribute (node@domain). The CPIM gateway SHOULD
remove the "pres:" Presence URI scheme from the front of the
address.
o The CPIM "watcher parameter" field (im:node@domain) maps to the
XMPP "to" attribute (node@domain). The CPIM gateway SHOULD remove
the "pres:" Presence URI scheme from the front of the address.
o The CPIM "TransID" field maps to the XMPP "id" attribute.
o The CPIM "presence information" operation field maps to the XMPP
"type" attribute.
4.2.3 The Unsubscribe Operation
This section describes how an "unsubscribe" operation will be
performed between an XMPP service and a CPIM service.
When an application wants to cancel a subscription associated with a
Miller, et al. Expires December 20, 2002 [Page 11]
Internet-Draft XMPP CPIM Mapping June 2002
PRESENTITY, it invokes the unsubscribe operation.
When an XMPP service performs an "unsubscribe" operation it uses the
XMPP PRESENCE ELEMENT. The XMPP PRESENCE ELEMENT maps to the CPIM
service as follows:
When sending an unsubscribe command from XMPP to CPIM:
o The XMPP "from" attribute (node@domain) maps to the CPIM "watcher
parameter" field (pres:node@domain). The CPIM gateway SHOULD
append the "pres:" Presence URI scheme to the front of the
address.
o The XMPP "to" attribute (node@domain) maps to the CPIM "target
parameter" field (pres:node@domain). The CPIM gateway SHOULD
append the "pres:" Presence URI scheme to the front of the
address.
o The XMPP "id" attribute maps to the CPIM "TransID" field.
o The XMPP "unsubscribe" attribute maps to the CPIM "unsubscribe"
field.
When sending an unsubscribe command from CPIM to XMPP:
o The CPIM "watcher parameter" field (pres:node@domain) maps to the
XMPP "from" attribute (node@domain). The CPIM gateway SHOULD
remove the "pres:" Presence URI scheme from the front of the
address.
o The CPIM "target parameter" field (im:node@domain) maps to the
XMPP "to" attribute (node@domain). The CPIM gateway SHOULD remove
the "pres:" Presence URI scheme from the front of the address.
o The CPIM "TransID" field maps to the XMPP "id" attribute.
o The CPIM "unsubscribe" operation field maps to the XMPP
"unsubscribe" attribute.
4.2.4 The Fetch Operation
This section describes how a "fetch" operation will be performed
between an XMPP service and a CPIM service.
The "fetch" operation is invoked when an application wants to
directly request presence information to be supplied immediately.
Miller, et al. Expires December 20, 2002 [Page 12]
Internet-Draft XMPP CPIM Mapping June 2002
When an XMPP service performs a "fetch" operation it uses the XMPP
PRESENCE ELEMENT. The XMPP PRESENCE ELEMENT maps to the CPIM service
as follows:
When sending a fetch request from XMPP to CPIM:
o The XMPP "from" attribute (node@domain) maps to the CPIM "watcher
parameter" field (pres:node@domain). The CPIM gateway SHOULD
append the "pres:" Presence URI scheme to the front of the
address.
o The XMPP "to" attribute (node@domain) maps to the CPIM "target
parameter" field (pres:node@domain). The CPIM gateway SHOULD
append the "pres:" Presence URI scheme to the front of the
address.
o The XMPP "id" attribute maps to the CPIM "TransID" field.
o The XMPP "probe" attribute maps to the CPIM "subscribe 0"
operation.
When sending a fetch request from CPIM to XMPP:
o The CPIM "watcher parameter" field (pres:node@domain) maps to the
XMPP "from" attribute (node@domain). The CPIM gateway SHOULD
remove the "pres:" Presence URI scheme from the front of the
address.
o The CPIM "target parameter" field (im:node@domain) maps to the
XMPP "to" attribute (node@domain). The CPIM gateway SHOULD remove
the "pres:" Presence URI scheme from the front of the address.
o The CPIM "TransID" field maps to the XMPP "id" attribute.
o The CPIM "subscribe 0" operation field maps to the XMPP "probe"
attribute.
Miller, et al. Expires December 20, 2002 [Page 13]
Internet-Draft XMPP CPIM Mapping June 2002
5. Security Considerations
XMPP places a high priority on security and provides mechanisms for
securing client-to-server and server-to-server communications,
including payload encryption, digital signatures, client-server
authentication, and server-server authentication. Details regarding
XMPP security are provided in XMPP Core [4] and XMPP IM [6]. Details
regarding CPIM security considerations can be found in Common
Presence and Instant Messaging (CPIM) [1].
Miller, et al. Expires December 20, 2002 [Page 14]
Internet-Draft XMPP CPIM Mapping June 2002
References
[1] Crocker, D., Diacakis, A., Mazzoldi, F., Huitema, C., Klyne, G.,
Rosenberg, J., Sparks, R. and H. Sugano, "A Common Profile for
Instant Messaging (CPIM)", November 2001.
[2] Day, M., Aggarwal, S., Mohr, G. and J. Vincent, "A Model for
Presence and Instant Messaging", RFC 2779, February 2000,
<http://www.ietf.org/rfc/rfc2779.txt>.
[3] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and
Instant Messaging", RFC 2778, February 2000, <http://
www.ietf.org/rfc/rfc2778.txt>.
[4] Miller, J. and P. Saint-Andre, "XMPP Core (draft-miller-jabber-
xmpp-core-00, work in progress)", June 2002.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[6] Miller, J. and P. Saint-Andre, "XMPP Instant Messaging (draft-
miller-jabber-xmpp-im-00, work in progress)", June 2002.
[7] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
Authors' Addresses
Jeremie Miller
Jabber Software Foundation
1899 Wynkoop Street, Suite 600
Denver, CO 80202
US
EMail: jeremie@jabber.org
URI: http://www.jabber.org/
Peter Saint-Andre
Jabber Software Foundation
1899 Wynkoop Street, Suite 600
Denver, CO 80202
US
EMail: stpeter@jabber.org
URI: http://www.jabber.org/
Miller, et al. Expires December 20, 2002 [Page 15]
Internet-Draft XMPP CPIM Mapping June 2002
T. Bamonti
Jabber, Inc.
1899 Wynkoop Street, Suite 600
Denver, CO 80202
US
EMail: tbamonti@jabber.com
URI: http://www.jabber.com/
Miller, et al. Expires December 20, 2002 [Page 16]
Internet-Draft XMPP CPIM Mapping June 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Miller, et al. Expires December 20, 2002 [Page 17]