One document matched: draft-khartabil-simple-im-receipts-00.txt
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 <im:alice@example.com>
To: Bob <im:bob@example.com>
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 <im:bob@example.com>
To: Alice <im:alice@example.com>
Content-type: message/status-receipt+xml
Content-Disposition: confirm
Content-length: ...
<status-receipt>
<message-id>34jk324j</message-id>
<recipient-uri>bob@example.com</recipient-uri>
<type>delivery</type>
<status>200</status>
<note lang="en">The message was successfully Delivered</note>
</status-receipt>
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 <im:bob@example.com>
To: Alice <im:alice@example.com>
Content-type: message/status-receipt+xml
Content-Disposition: confirm
Content-length: ...
<status-receipt>
<message-id>34jk324j</message-id>
<recipient-uri>bob@example.com</recipient-uri>
<type>read</type>
<status>200</status>
<note lang="en">The message has been read</note>
</status-receipt>
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 <status> 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 <type> 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
<message-id> element value in the body of the delivery receipt. If
the message was delivered to multiple recipients, the <recipient-uri>
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 <type> 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 <recipient-uri> 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 <recipient-uri>
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]
| PAFTECH AB 2003-2026 | 2026-04-23 09:41:56 |