SIMPLE H. Khartabil Internet-Draft Telio Expires: August 26, 2006 February 22, 2006 Instant Message Delivery and Read Receipts draft-khartabil-simple-im-receipts-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 26, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Instant Messaging (IM) refers to the transfer of messages between users in near real-time. This document extends Message/CPIM message format to enable endpoints to request, create and send a delivery receipt as well as a read receipt for a page-mode as well as session mode instant messages. This document also describes how SIP and MSRP entities behave using this extension. Khartabil Expires August 26, 2006 [Page 1] Internet-Draft IM Delivery and Read Receipts February 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Constructing Requests . . . . . . . . . . . . . . . . . . . . 3 3.1 Instant Message . . . . . . . . . . . . . . . . . . . . . 3 3.2 Delivery Receipt . . . . . . . . . . . . . . . . . . . . . 4 3.3 Read Receipt . . . . . . . . . . . . . . . . . . . . . . . 5 3.4 Identifying Messages . . . . . . . . . . . . . . . . . . . 6 4. Header Fields Formal Syntax . . . . . . . . . . . . . . . . . 6 5. Status Receipt XML Schema . . . . . . . . . . . . . . . . . . 6 5.1 Structure of XML-Encoded status-receipt . . . . . . . . . 6 5.2 MIME Type for status-receipt Document . . . . . . . . . . 7 5.3 The XML Schema . . . . . . . . . . . . . . . . . . . . . . 7 6. Transporting Message/CPIM messages using SIP . . . . . . . . . 7 6.1 Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . 7 6.1.1 Sending Requests . . . . . . . . . . . . . . . . . . . 7 6.1.2 Sending Responses . . . . . . . . . . . . . . . . . . 7 6.1.3 Receiving Requests . . . . . . . . . . . . . . . . . . 7 6.2 Intermediary Behaviour . . . . . . . . . . . . . . . . . . 8 7. Transporting Message/CPIM messages using MSRP . . . . . . . . 9 7.1 Endpoint Behaviour . . . . . . . . . . . . . . . . . . . . 9 7.1.1 Sending Requests . . . . . . . . . . . . . . . . . . . 9 7.1.2 Sending Responses . . . . . . . . . . . . . . . . . . 10 7.1.3 Receiving Requests . . . . . . . . . . . . . . . . . . 10 7.2 Intermediary Behaviour . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8.1 Forgery . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.2 Confidentiality . . . . . . . . . . . . . . . . . . . . . 11 8.3 Non-Repudiation . . . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9.1 message/status-receipt+xml MIME TYPE . . . . . . . . . . . 12 9.2 URN Sub-Namespace Registration for urn:ietf:params:xml:ns:status-receipt . . . . . . . . . . 13 9.3 Schema Registration . . . . . . . . . . . . . . . . . . . 13 9.4 Message/CPIM Header Field registration . . . . . . . . . . 13 9.5 Content-Disposition confirm . . . . . . . . . . . . . . . 13 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 11.1 Normative References . . . . . . . . . . . . . . . . . . . 14 11.2 Informative References . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . 16 Khartabil Expires August 26, 2006 [Page 2] Internet-Draft IM Delivery and Read Receipts February 2006 1. Introduction Message/CPIM [2] is a message format used to generate instant messages. SIP [9] can carry instant messages generated using message/CPIM in SIP MESSAGE requests [10]. The MSRP [11] SEND message can also be used to carry Message/CPIM messages. This document extends Message/CPIM message format to enable endpoints to request, create and send a delivery receipt as well as a read receipt for a page-mode as well as session mode instant messages. This document also describes how SIP and MSRP entities behave using this extension. 2. Conventions 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 [1] and indicate requirement levels for compliant implementations. 3. Constructing Requests 3.1 Instant Message A Message/CPIM formatted instant message is contructed using RFC 3862 [2]. The content-type header field indicates the MIME type of the request payload. In this extension, the Message/CPIM MUST contain a Message-ID header if a delivery or read receipt is requested. The Message-ID field is populated with a value that is unique in space and time. This header field enables the message sender to match any delivery and/or read receipts and need not be present if the instant message sender is not requesting any receipts. The sender can request two types of delivery receipts: a failure delivery receipt and a success delivery receipt. A failure delivery receipt is requested by including a Receipt-Request header field with value "negative-delivery". Similarly, a success receipt is requested by including a Receipt-Request header field with value "positive- delivery". Both types of receipts can be requested for the same message. The sender can also request a read receipt. It is requested by including a Receipt-Request header field with value "read". The absence of this header or the presence of the header with empty value indicates that the sender is not requesting any receipts. This aids receivers of instant messages that do not support this feature. Khartabil Expires August 26, 2006 [Page 3] Internet-Draft IM Delivery and Read Receipts February 2006 The Receipt-Request header fields can be comma separated. The default Content-Disposition of an instant message is "render". Therefore, the absence of such header indicates "render". If an endpoint sending an Instant message and has requested a positive-delivery, negative-delivery and/or read receipt, it MUST NOT start any timers waiting for the receipt. There are no time limits associated with when receipts may be received. The formal syntax of the Request-Receipt header field can be found in Section 4. The following in an example Message/CPIM instant message where the user requests positive and negative delivery receipts, but not read receipt: Content-type: Message/CPIM From: Alice To: Bob Message-ID: 34jk324j Receipt-Request: positive-delivery, negative-delivery Content-type: text/plain Content-length: 12 Hello World 3.2 Delivery Receipt A delivery receipt is constructed in a similar fashion as an instant message, using RFC 3862 [2]. For delivery receipts, the content-type MUST be of type "message/status-receipt". It is an XML document. The schema is described Section 5. The delivery receipt MUST contain a Content-Disposition header field with value "confirm". This indicates to the receiver that the contents of the message are a confirmation according to an earlier request for a receipt to an instant message. The recipient SHOULD render to the end user a message indicating such confirmation. The delivery receipt SHOULD NOT contain a Message-ID header field since it is used for matching an instant message with its receipt and no receipts are ever requested for receipts. The recipient of a delivery receipt MUST ignore the Message-ID header field if present. An example looks like the following: Khartabil Expires August 26, 2006 [Page 4] Internet-Draft IM Delivery and Read Receipts February 2006 Content-type: Message/CPIM From: Bob To: Alice Content-type: message/status-receipt+xml Content-Disposition: confirm Content-length: ... 34jk324j bob@example.com delivery 200 The message was successfully Delivered Request-Receipt header SHOULD NOT appear in a Message/CPIM messages that represents a delivery receipt. The recipient MUST ignore it if present 3.3 Read Receipt A read receipt is constructed in a similar fashion as the delivery receipt. See Section 3.2 for details. An example looks like the following: Content-type: Message/CPIM From: Bob To: Alice Content-type: message/status-receipt+xml Content-Disposition: confirm Content-length: ... 34jk324j bob@example.com read 200 The message has been read There are situations where the recipient user agent cannot determine if or when the message has been read. The recipient user agent in this case generates a read receipt with a value of "485". Khartabil Expires August 26, 2006 [Page 5] Internet-Draft IM Delivery and Read Receipts February 2006 3.4 Identifying Messages Message/CPIM messages are typically carried in a transport protocol like SIP [9]. In the case of a "message/cpim" body in the request of the transport protocol, the message is an instant message if the content-type header field present in the message/cpim body has a value that is not "message/status-receipt+xml". A Message/CPIM message is identified as a delivery receipt by examining its contents. In the case of a "message/cpim" body, the message is a delivery receipt if: the content-type header field present in the message/cpim body has a value of "message/ status-receipt+xml", the Content-Disposition header field has a value of "confirm", and the element in that xml body has a value of "delivery". An endpoint matches a delivery receipt to an instant message by matching the Message-ID header field value with the element value in the body of the delivery receipt. If the message was delivered to multiple recipients, the element in the XML body is used to identify the recipient. A Message/CPIM message request is identified as a read receipt and is matched to an instant message in a similar fasion as a delivery receipt. The difference is that the element in that xml body has a value of "read". 4. Header Fields Formal Syntax The following syntax specification uses the message header syntax as described in Section 3 of RFC3862 [2]. Receipt-Request = "Receipt-Request" ": " (receipt-req *(COMMA receipt-req)) receipt-req = "negative-delivery" / "positive-delivery" / "read" Message-ID = "Message-ID" ": " Token 5. Status Receipt XML Schema 5.1 Structure of XML-Encoded status-receipt A status-receipt is an XML document [7] 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 status-receipt documents MUST be based on XML 1.0 and MUST be encoded using UTF-8. The namespace identifier for elements defined by this specification Khartabil Expires August 26, 2006 [Page 6] Internet-Draft IM Delivery and Read Receipts February 2006 is a URN [4], using the namespace identifier 'ietf' defined by [5] and extended by [3]. This urn is: urn:ietf:params:xml:ns:status-receipt. This namespace declaration indicates the namespace on which the status receipt is based on. 5.2 MIME Type for status-receipt Document The MIME type for the status-receipt document is "message/ status-receipt+xml". The SIP [9] MESSAGE request [10] that is used to carry the status receipt that also carries payload type information MUST identify the payload as MIME type "simple- filter+xml" in the Content-Type header field. 5.3 The XML Schema 6. Transporting Message/CPIM messages using SIP 6.1 Endpoint Behaviour 6.1.1 Sending Requests A SIP MESSAGE request is constructed using RFC 3428 [10]. The content-type header field indicates the MIME type of the request payload. When using this extension, the content-type header field MUST be of MIME type "message/cpim" [2] for both Instant Messages and Receipts. The payload is contructed according to Section 3. A SIP MESSAGE request to multiple recipients is contracted in a similar manner as a SIP MESSAGE request to a single recipient. The differences are indicated in [13]. 6.1.2 Sending Responses An endpoint receiving a SIP MESSAGE request constructs a SIP response according to RFC3428 [10]. Of course, an endpoint will send a response to the MESSAGE request regardless of the receipt it has been asked for or the type of MESSAGE request it has received (instant message or receipt). 6.1.3 Receiving Requests 6.1.3.1 Instant Message A SIP MESSAGE request is identified as an instant message by Khartabil Expires August 26, 2006 [Page 7] Internet-Draft IM Delivery and Read Receipts February 2006 examining its contents according to Section 3.4. If an endpoint received a SIP MESSAGE request that is an IM and that contains a Messge/CPIM payload that requested a positive-delivery receipt, and that endpoint has constructed and sent a SIP 2xx class response, it MUST generate a positive-delivery receipt after making sure that the instant message has been delivered to the user or application (a GW, for example, can generate a 2xx response before it has been guaranteed that the final recipient has actually received the message). The positive-delivery receipt is constructed according to Section 3.2. The message/cpim message is then placed as the payload in a SIP MESSAGE request. If an endpoint received a SIP MESSAGE request that contains a Messge/ CPIM payload that requested a negative-delivery, and that endpoint has constructed and sent a 2xx class response, it MUST generate a negative-delivery receipt if it learnt that the final recipient or application did not receive the instant message (a GW, for example, can generate a 2xx response before it has been guaranteed that the final recipient has actually received the message). The negative- delivery receipt is constructed according to Section 3.3. The message/cpim message is then placed as the payload in a SIP MESSAGE request. If an endpoint received a SIP MESSAGE request that requested a negative-delivery receipt, and the endpoint has constructed and sent an error response, it MUST NOT generate a negative-delivery receipt. 6.1.3.2 Delivery Receipt A SIP MESSAGE request is identified as delivery receipt by examining its contents according to Section 3.4. 6.1.3.3 Read Receipt A SIP MESSAGE request is identified as read receipt by examining its contents according to Section 3.4. 6.2 Intermediary Behaviour An intermediary that behaves as an application server or a gateway needs to conform to this section. A SIP MESSAGE request to multiple recipients is forwarded according to [13]. If an intermediary generates a SIP 2xx class response to a SIP MESSAGE request it has received that is an instant message, it Khartabil Expires August 26, 2006 [Page 8] Internet-Draft IM Delivery and Read Receipts February 2006 examines if the body was of type "message/cpim". If so, it checks if there is the header Receipt-Request with a value "positive-delivery" and/or "negative-delivery". If so, it needs to send a delivery receipt as soon as it receives a transactional response for the instant message. The contruction of a delivery receipt is performed according to Section 3.2. If the Receipt-Request contains a value of "positive-delivery", the intermediary MUST NOT generate a delivery receipt if it receives a SIP 2xx class response for the sent instant message. This is in anticipation of a failure downstream after a 2xx response has been generated. If the Receipt-Request contains a value of "negative-delivery", the intermediary MUST generate a delivery receipt if it receives a SIP 4xx, 5xx or 6xx class final response for the sent instant message or if it has received a SIP 2xx class response followed by a negative- delivery receipt. The generation of such receipt is the same procedure as that for an endpoint (Section 3.2). The element of the XML body is populated with the URI of the instant message recipient. If an intermediary receives a SIP MESSAGE request carrying a read- receipt, it statelessly forwards that request. 7. Transporting Message/CPIM messages using MSRP 7.1 Endpoint Behaviour 7.1.1 Sending Requests An MSRP SEND request is constructed using [11]. The content-type header field indicates the MIME type of the request payload. When using this extension, the content-type header field MUST be of MIME type "message/cpim" [2] for both Instant Messages and Receipts. The payload is contructed according to Section 3. MSRP has built in delivery reports and therefore does not require delivery receipts as defined in this specification. Read Receipts and any other defined receipts, however, as still relevant. Therefore, an endpoint MUST NOT create MSRP SEND requests requiring a positive-delivery receipt or a negative-delivery receipt. For SEND requests that are receipts, the sender MUST NOT request a delivery report (an MSRP REPORT to a SEND request). I.e. It MUST populate the request with a Failure-Report header field with the value "no" and with a Success-Report header field with value "no" (or Khartabil Expires August 26, 2006 [Page 9] Internet-Draft IM Delivery and Read Receipts February 2006 alternatively leave out that header field since it defaults to "no"). The sender also MUST NOT request a receipt for a SEND request that is a receipt. An MSRP SEND request to multiple recipients is contracted in a similar manner as a SEND request to a single recipient. The differences are indicated in [12]. 7.1.2 Sending Responses An endpoint receiving an MSRP SEND request constructs an MSRP response according to [11] if needed. Section 7.2 of [11] describe when to send and when not to send an MSRP response. For SEND requests that are receipts, a response MUST NOT be generated. This is not a special case; for SEND requests that contain a Failure- Report header field with the value "no" and a Success-Report header field with value "no" the sender does not need to start a timer and the receiver does not send a transaction response. 7.1.3 Receiving Requests 7.1.3.1 Instant Message An MSRP SEND request is identified as an instant message by examining its contents according to Section 3.4. 7.1.3.2 Read Report An MSRP SEND request is identified as read receipt by examining its contents according to Section 3.4. The receiver MUST ignore any requests for delivery receipts, or any kind of receipts for a receipt. 7.2 Intermediary Behaviour An intermediary that behaves as an application server or a gateway needs to conform to this section. An MSRP SEND request to multiple recipients is forwarded according to [12]. MSRP has built in delivery reports and therefore does not require delivery receipts as defined in this specification. An MSRP intermediary does not react to receipt requests. 8. Security Considerations Instant Message receipts provide a fine-grained view of the activity Khartabil Expires August 26, 2006 [Page 10] Internet-Draft IM Delivery and Read Receipts February 2006 of the entity receiving the IM and thus deserves particularly careful confidentiality protection so that only the intended recipient of the receipt will receive the receipt message (in most cases, the intended recipient of the receipt is the sender of the IM). Since the receipt messages are carried by using the IM protocol itself, all security considerations of the underlying IM protocol also apply to the receipt messages. The following security considerations apply when using message receipts: 8.1 Forgery Message receipts may be forged as easily as ordinary Instant Message. User agents and intermediaries that wish to make automatic use of receipts should take appropriate precautions to minimize the potential damage from denial-of-service attacks. Security threats related to forged message receipts include the sending of a falsified receipt when the indicated disposition of the message has not actually ocurred. For example, read receipt could be forged to indicate that a IM recipient has read the instant message. Unsolicited receipts is also another form of forgery. 8.2 Confidentiality There may be cases where an instant message recipient does not wish to reveal the information that he has received or in fact read the instant message. In this situation, it is acceptable for the UA to silently ignore requests for a receipt. There are situations where a user sends an IM to a list who's member infomration is not disclosed and requesting receipts. In this situation, the sender will earn of the list members. The list server MUST only deliver one receipt indicating that all the members of the list have received on read the IM (by leaving out the element). Alternatively, the list server MAY reject the IM. An unencrypted receipt could reveal confidential information about an encrypted instant message. It is a MUST that the same level of security applied to an IM to be applied to its receipts. For example, if an IM is signed and encrypted, and receipt must also be signed and encrypted. 8.3 Non-Repudiation Message receipts cannot be relied on as a guarantee that an instant message was or was not seen by the recipient. Even if receipts are Khartabil Expires August 26, 2006 [Page 11] Internet-Draft IM Delivery and Read Receipts February 2006 not actively forged, they may be lost in transit. The receipt issuing mechanism may be bypassed in some manner by the recipient on the IM. . 9. IANA Considerations 9.1 message/status-receipt+xml MIME TYPE This document registers a new MIME type "message/status-receipt+xml", and registers a new XML namespace. This specification follows the guidelines of RFC3023 [6]. MIME media type: message MIME subtype name: status-receipt+xml Mandatory parameters: none Optional parameters: Same as charset parameter application/xml as specified in RFC 3023 [6]. Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [6]. Security considerations: See section 10 of RFC 3023 [6] and Section 8 of this document. Interoperability considerations: none. Published specification: This document. Applications which use this media type: This document type has been used to support SIP and MSRP based instant messaging. Additional information: None Magic number: None File extension: .cl or .xml Macintosh file type code: "TEXT" Personal and email address for further information: Hisham Khartabil (hisham.khartabil@telio.no) Intended Usage: COMMON Khartabil Expires August 26, 2006 [Page 12] Internet-Draft IM Delivery and Read Receipts February 2006 Author/change controller: The IETF . 9.2 URN Sub-Namespace Registration for urn:ietf:params:xml:ns:status-receipt This section registers a new XML namespace, as per guidelines in the IETF XML Registry [3]. URI: The URI for this namespace is urn:ietf:params:xml:ns:status-receipt. Registrant Contact: IETF, SIMPLE working group, Hisham Khartabil (hisham.khartabil@telio.no) . 9.3 Schema Registration This section registers a new XML schema per the procedures in [3]. URI: urn:ietf:params:xml:ns:status-receipt Registrant Contact: IETF, SIMPLE working group, Hisham Khartabil (hisham.khartabil@telio.no) The XML for this schema can be found as the sole content of Section 5.3. . 9.4 Message/CPIM Header Field registration This document registers the following message/cpim header fields in the cpim-headers registry: Message-ID - [RFCXXXX] Receipt-Request - [RFCXXXX] . 9.5 Content-Disposition confirm content-disposition confirm . 10. Acknowledgements The author would like to thank Paul Kyzivat, Ben Campbell, Adam Roach and Gonzalo Camarillo for their comments and support. 11. References Khartabil Expires August 26, 2006 [Page 13] Internet-Draft IM Delivery and Read Receipts February 2006 11.1 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging (CPIM): Message Format", RFC 3862, August 2004. [3] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004. [4] Moats, R., "The URN Syntax", RFC 2141, May 1997. [5] Moats, R., "The URN Namespace for IETF Documents", RFC 2648, August 1999. [6] Murata, M., "XML Media Types", RFC 3023, March 1997. [7] Bray, T., "Exensible Markup Language (XML) 1.0 (Second Edition)", W3C CR CR-xml11-20011006, October 2000. [8] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999. 11.2 Informative References [9] 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. [10] Campbell, B., "SIP Extension for Instant Messaging", RFC 3428, December 2002. [11] Campbell, B., "The Message Session Relay Protocol", draft-ietf-simple-message-sessions-10, February 2005. [12] Niemi, A., "Multi-part IM Sessions Using MSRP", draft-niemi-simple-chat-04, February 2006. [13] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE Requests in SIP", draft-ietf-sipping-uri-list-message-02, November 2004. Khartabil Expires August 26, 2006 [Page 14] Internet-Draft IM Delivery and Read Receipts February 2006 Author's Address Hisham Khartabil Telio P.O. Box 1203 Vika Oslo Norway Phone: +47 2167 3544 Email: hisham.khartabil@telio.no Khartabil Expires August 26, 2006 [Page 15] Internet-Draft IM Delivery and Read Receipts 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. Khartabil Expires August 26, 2006 [Page 16]