draft-ietf-sipping-uri-list-message-02.txt   draft-ietf-sipping-uri-list-message-03.txt 
SIPPING Working Group M. Garcia-Martin SIPPING Working Group M. Garcia-Martin
Internet-Draft Nokia Internet-Draft Nokia
Expires: May 31, 2005 G. Camarillo Expires: October 10, 2005 G. Camarillo
Ericsson Ericsson
November 30, 2004 April 8, 2005
Multiple-Recipient MESSAGE Requests in the Session Initiation Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol
Protocol (SIP) (SIP)
draft-ietf-sipping-uri-list-message-02 draft-ietf-sipping-uri-list-message-03.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 31, 2005. This Internet-Draft will expire on October 10, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document specifies how to request a SIP URI-list service to send This document specifies how to request a SIP URI-list service to send
a copy of a MESSAGE to a set of destinations. The client sends a SIP a copy of a MESSAGE to a set of destinations. The client sends a SIP
MESSAGE request with a URI-list to the MESSAGE URI-list service, MESSAGE request with a URI-list to the MESSAGE URI-list service,
which sends a similar MESSAGE request to each of the URIs included in which sends a similar MESSAGE request to each of the URIs included in
the list. the list.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. URI-List document . . . . . . . . . . . . . . . . . . . . . 5 4. URI-List document . . . . . . . . . . . . . . . . . . . . . 5
4.1 Extension to the resource lists data format . . . . . . . 6 4.1 Extension to the resource lists data format . . . . . . . 6
4.2 URI-list example . . . . . . . . . . . . . . . . . . . . . 7 4.2 URI-list example . . . . . . . . . . . . . . . . . . . . . 7
5. Procedures at the User Agent Client . . . . . . . . . . . . 8 5. Option-tag . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Procedures at the MESSAGE URI-List Service . . . . . . . . . 9 6. Procedures at the User Agent Client . . . . . . . . . . . . 8
6.1 Determining the intended recipient . . . . . . . . . . . . 9 7. Procedures at the MESSAGE URI-List Service . . . . . . . . . 9
6.2 Creating an outgoing MESSAGE request . . . . . . . . . . . 9 7.1 Determining the intended recipient . . . . . . . . . . . . 9
6.3 Composing bodies in the outgoing MESSAGE request . . . . . 10 7.2 Creating an outgoing MESSAGE request . . . . . . . . . . . 9
7. Procedures at the UAS . . . . . . . . . . . . . . . . . . . 12 7.3 Composing bodies in the outgoing MESSAGE request . . . . . 10
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Procedures at the UAS . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . 16 10. Security Considerations . . . . . . . . . . . . . . . . . . 15
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16
12. Change control . . . . . . . . . . . . . . . . . . . . . . . 16 11.1 Disposition Type Registration . . . . . . . . . . . . . 16
12.1 Changes from 11.2 Option-Tag Registration . . . . . . . . . . . . . . . . 16
draft-ietf-sipping-uri-list-message-01.txt . . . . . . . 16 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
12.2 Changes from 13. Change control . . . . . . . . . . . . . . . . . . . . . . . 16
13.1 Changes from
draft-ietf-sipping-uri-list-message-02.txt . . . . . . . 16
13.2 Changes from
draft-ietf-sipping-uri-list-message-01.txt . . . . . . . 17
13.3 Changes from
draft-ietf-sipping-uri-list-message-00.txt . . . . . . . 17 draft-ietf-sipping-uri-list-message-00.txt . . . . . . . 17
12.3 Changes from 13.4 Changes from
draft-ietf-sipping-message-exploder-00.txt to draft-ietf-sipping-message-exploder-00.txt to
draft-ietf-sipping-uri-list-message-00.txt . . . . . . . 17 draft-ietf-sipping-uri-list-message-00.txt . . . . . . . 17
12.4 Changes from 13.5 Changes from
draft-garcia-simple-message-exploder-00.txt to draft-garcia-simple-message-exploder-00.txt to
draft-garcia-sipping-message-exploder-00.txt . . . . . . 17 draft-garcia-sipping-message-exploder-00.txt . . . . . . 18
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
13.1 Normative References . . . . . . . . . . . . . . . . . . . 18 14.1 Normative References . . . . . . . . . . . . . . . . . . 18
13.2 Informational References . . . . . . . . . . . . . . . . . 19 14.2 Informational References . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . 20
1. Introduction 1. Introduction
SIP [6] can carry instant messages in MESSAGE [9] requests. The SIP [6] can carry instant messages in MESSAGE [9] requests. The
Advanced Instant Messaging Requirements for SIP [13] mentions the Advanced Instant Messaging Requirements for SIP [13] mentions the
need for sending a MESSAGE request to multiple recipients: need for sending a MESSAGE request to multiple recipients:
"REQ-GROUP-3: It MUST be possible for a user to send to an ad-hoc "REQ-GROUP-3: It MUST be possible for a user to send to an ad-hoc
group, where the identities of the recipients are carried in the group, where the identities of the recipients are carried in the
message itself." message itself."
One possibility to fulfill the above requirement is to establish a One possibility to fulfill the above requirement is to establish a
session of instant messages with an instant messaging conference session of instant messages with an instant messaging conference
server. While this option seems to be reasonable in many cases, in server. While this option seems to be reasonable in many cases, in
other situations the sending user just want to send a small other situations the sending user just want to send a small page-mode
pager-mode instant message to an ad-hoc group, without entering the instant message to an ad-hoc group, without entering the burden of
burden of setting up a session. This document focuses on sending a setting up a session. This document focuses on sending a page-mode
pager-mode instant message to a number of intended recipients. instant message to a number of intended recipients.
To meet the requirement with a pager-mode instant message, we allow To meet the requirement with a page-mode instant message, we allow
SIP MESSAGE requests carry URI-lists in body parts whose SIP MESSAGE requests carry URI-lists in body parts whose Content-
Content-Disposition [2] is 'recipient-list', as specified in Disposition [2] is 'recipient-list', as specified in the Framework
Framework and Security Considerations for SIP URI-List Services [12]. and Security Considerations for SIP URI-List Services [12]. A SIP
A SIP MESSAGE URI-list service, which is a specialized application MESSAGE URI-list service, which is a specialized application service,
service, receives the request and sends a similar MESSAGE request to receives the request and sends a similar MESSAGE request to each of
each of the URIs in the list. Each of these MESSAGE requests the URIs in the list. Each of these MESSAGE requests contains a copy
contains a copy of the body included in the original MESSAGE request. of the body included in the original MESSAGE request.
The Advanced Instant Messaging Requirements for SIP [13] also The Advanced Instant Messaging Requirements for SIP [13] also
includes a requirement that allows to provide a "Reply-to-All" includes a requirement that allows to provide a "Reply-to-All"
functionality: functionality:
"REQ-GROUP-4: It MUST be possible for the recipient of a group IM "REQ-GROUP-4: It MUST be possible for the recipient of a group IM
to send a message to all other participants that received the same to send a message to all other participants that received the same
group IM (i.e., Reply-To-All)." group IM (i.e., Reply-To-All)."
To meet this requirement, we provide a mechanism whereby the MESSAGE To meet this requirement, we provide a mechanism whereby the MESSAGE
skipping to change at page 4, line 29 skipping to change at page 4, line 29
(Back-To-Back-User-Agents). A server providing MESSAGE URI-list (Back-To-Back-User-Agents). A server providing MESSAGE URI-list
services can also offer URI-list services for other methods, services can also offer URI-list services for other methods,
although this functionality is outside the scope of this document. although this functionality is outside the scope of this document.
In this document we only discuss MESSAGE URI-list services. In this document we only discuss MESSAGE URI-list services.
Incoming MESSAGE request: A SIP MESSAGE request that a UAC creates Incoming MESSAGE request: A SIP MESSAGE request that a UAC creates
and addresses to a MESSAGE URI-list service. Besides the regular and addresses to a MESSAGE URI-list service. Besides the regular
instant message payload, an incoming MESSAGE request contains a instant message payload, an incoming MESSAGE request contains a
URI-list. URI-list.
Outgoing MESSAGE request: A SIP MESSAGE request that a MESSAGE Outgoing MESSAGE request: A SIP MESSAGE request that a MESSAGE URI-
URI-list service creates and addresses to a UAS (User Agent list service creates and addresses to a UAS (User Agent Server).
Server). It contains the regular instant message payload. It contains the regular instant message payload.
Intended recipient: The intended final recipient of the request to be Intended recipient: The intended final recipient of the request to be
generated by MESSAGE URI-list service. generated by MESSAGE URI-list service.
3. Overview 3. Overview
A UAC creates a MESSAGE request that contains a multipart body A UAC creates a MESSAGE request that contains a multipart body
including a list of URIs (intended recipients) and an instant including a list of URIs (intended recipients) and an instant
message. The UAC sends this MESSAGE request to the MESSAGE URI-List message. The UAC sends this MESSAGE request to the MESSAGE URI-List
service. On reception of this incoming MESSAGE request, the MESSAGE service. On reception of this incoming MESSAGE request, the MESSAGE
skipping to change at page 5, line 49 skipping to change at page 5, line 49
support 'capacity' extension. support 'capacity' extension.
A MESSAGE URI-list service receiving a URI-list with more information A MESSAGE URI-list service receiving a URI-list with more information
than what has just been described MAY discard all the extra than what has just been described MAY discard all the extra
information. information.
Additionally, this document defines a new mail disposition type value Additionally, this document defines a new mail disposition type value
to be included in a Content-Disposition [2] header field of a SIP to be included in a Content-Disposition [2] header field of a SIP
MESSAGE request. The value of this new disposition type is MESSAGE request. The value of this new disposition type is
'recipient-list-history' and its purpose is to indicate a list of 'recipient-list-history' and its purpose is to indicate a list of
recipients that a MESSAGE was sent to. A body whose recipients that a MESSAGE was sent to. A body whose Content-
Content-Disposition type is 'recipient-list-history' contains a Disposition type is 'recipient-list-history' contains a URI-list with
URI-list with the visible recipients of the MESSAGE. The <entry> the visible recipients of the MESSAGE. The <entry> element in the
element in the URI-list MAY also include a 'capacity' attribute, as URI-list MAY also include a 'capacity' attribute, as specified in
specified in Section 4.1. MESSAGE URI-list services MUST implement Section 4.1. MESSAGE URI-list services MUST implement support for
support for this Content-Disposition type. User Agent Servers (UAS) this Content-Disposition type. User Agent Servers (UAS) MAY
MAY implement support for the resource-list document format [10] and implement support for the resource-list document format [10] and the
the 'recipient-list-history' Content-Disposition type. 'recipient-list-history' Content-Disposition type.
4.1 Extension to the resource lists data format 4.1 Extension to the resource lists data format
This document defines an extension to indicate the capacity of a This document defines an extension to indicate the capacity of a
resource. We define a new 'capacity' attribute to the <entry> resource. We define a new 'capacity' attribute to the <entry>
element. The 'capacity' attribute has similar semantics to the type element. The 'capacity' attribute has similar semantics to the type
of destination address in e-mail systems. It can take the values of destination address in e-mail systems. It can take the values
"to", "cc" and "bcc". A "to" value of the 'capacity' attribute "to", "cc" and "bcc". A "to" value of the 'capacity' attribute
indicates that the resource is considered the recipient of the indicates that the resource is considered the recipient of the
MESSAGE request. A "cc" value indicates that the resource receives a MESSAGE request. A "cc" value indicates that the resource receives a
skipping to change at page 8, line 18 skipping to change at page 8, line 5
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<list> <list>
<entry uri="sip:bill@example.com" cp:capacity="to" /> <entry uri="sip:bill@example.com" cp:capacity="to" />
<entry uri="sip:joe@example.org" cp:capacity="cc" /> <entry uri="sip:joe@example.org" cp:capacity="cc" />
<entry uri="sip:ted@example.net" cp:capacity="bcc" /> <entry uri="sip:ted@example.net" cp:capacity="bcc" />
</list> </list>
</resource-lists> </resource-lists>
Figure 2: URI-List Figure 2: URI-List
5. Procedures at the User Agent Client 5. Option-tag
This document defines the 'recipient-list-message' option-tag for use
in the Require and Supported SIP header fields.
User agent clients generating a MESSAGE with a recipient-list body,
as described in previous sections, MUST include this option-tag in a
Require header field. User agents that are able to receive and
process MESSAGEs with a recipient-list body, as described in previous
sections, SHOULD include this option-tag in a Supported header field
when responding to OPTIONS requests.
6. Procedures at the User Agent Client
A UAC that wants to create a multiple-recipient MESSAGE request MUST A UAC that wants to create a multiple-recipient MESSAGE request MUST
create a MESSAGE request according to RFC 3428 [9] Section 4. The create a MESSAGE request according to RFC 3428 [9] Section 4. The
UAC SHOULD populate the Request-URI with the SIP or SIPS URI of the UAC SHOULD populate the Request-URI with the SIP or SIPS URI of the
MESSAGE URI-list service. In addition to the regular instant message MESSAGE URI-list service. In addition to the regular instant message
body, the UAC SHOULD add a URI-list body whose Content-Disposition body, the UAC SHOULD add a URI-list body whose Content-Disposition
type is 'recipient-list', specifed in the Framework and Security type is 'recipient-list', specifed in the Framework and Security
Considerations for SIP URI-list Services [12]. This body contains a Considerations for SIP URI-list Services [12]. This body contains a
URI-list with the recipients of the MESSAGE. The URI-list body MAY URI-list with the recipients of the MESSAGE. The URI-list body MAY
also include the 'capacity' extension to the URI-list specified in also include the 'capacity' extension to the URI-list specified in
Section 4.1. Section 4.1. The UAC MUST also include the 'recipient-list-message'
option-tag, defined in Section 5, in a Require header field.
Multiple-recipient MESSAGE requests contain a multipart body that Multiple-recipient MESSAGE requests contain a multipart body that
contains the body carrying the list and the actual instant message contains the body carrying the list and the actual instant message
payload. In some cases, the MESSAGE request may contain bodies other payload. In some cases, the MESSAGE request may contain bodies other
than the text and the list bodies (e.g., when the request is than the text and the list bodies (e.g., when the request is
protected with S/MIME [11]). protected with S/MIME [11]).
Typically, the MESSAGE URI-list service will copy all the significant Typically, the MESSAGE URI-list service will copy all the significant
header fields in the outgoing MESSAGE request. However, there might header fields in the outgoing MESSAGE request. However, there might
be cases where the SIP UA wants the MESSAGE URI-list service to add a be cases where the SIP UA wants the MESSAGE URI-list service to add a
skipping to change at page 9, line 4 skipping to change at page 8, line 51
field wasn't present in the MESSAGE request sent by the UAC. In this field wasn't present in the MESSAGE request sent by the UAC. In this
case, the UAC MAY use the "?" mechanism described in Section 19.1.1 case, the UAC MAY use the "?" mechanism described in Section 19.1.1
of RFC 3261 [6] to encode extra information in any URI in the list. of RFC 3261 [6] to encode extra information in any URI in the list.
However, the UAC MUST NOT use the special "body" hname (see Section However, the UAC MUST NOT use the special "body" hname (see Section
19.1.1 of RFC 3261 [6]) to encode a body, since the body is present 19.1.1 of RFC 3261 [6]) to encode a body, since the body is present
in the MESSAGE request itself. in the MESSAGE request itself.
The following is an example of a URI that uses the "?" mechanism: The following is an example of a URI that uses the "?" mechanism:
sip:bob@example.com?Accept-Contact=*%3bmobility%3d%22mobile%22 sip:bob@example.com?Accept-Contact=*%3bmobility%3d%22mobile%22
The previous URI requests the MESSAGE URI-list service to add the The previous URI requests the MESSAGE URI-list service to add the
following header field to a MESSAGE request to be sent to following header field to a MESSAGE request to be sent to
bob@example.com: bob@example.com:
Accept-Contact: *;mobility="mobile" Accept-Contact: *;mobility="mobile"
6. Procedures at the MESSAGE URI-List Service 7. Procedures at the MESSAGE URI-List Service
On reception of a MESSAGE request with a URI-list, a MESSAGE URI-list On reception of a MESSAGE request with a URI-list, a MESSAGE URI-list
service SHOULD answer to the UAC with a 202 Accepted response. Note service SHOULD answer to the UAC with a 202 Accepted response. Note
that the status code in the response to the MESSAGE does not provide that the status code in the response to the MESSAGE does not provide
any information about whether or not the MESSAGEs generated by the any information about whether or not the MESSAGEs generated by the
URI-list service were successfully delivered to the URIs in the list. URI-list service were successfully delivered to the URIs in the list.
That is, a 202 Accepted means that the MESSAGE URI-list service has That is, a 202 Accepted means that the MESSAGE URI-list service has
received the MESSAGE and that it will try to send a similar MESSAGE received the MESSAGE and that it will try to send a similar MESSAGE
to the URIs in the list. Designing a mechanism to inform a client to the URIs in the list. Designing a mechanism to inform a client
about the delivery status of an instant message is outside the scope about the delivery status of an instant message is outside the scope
of this document. of this document.
6.1 Determining the intended recipient 7.1 Determining the intended recipient
On reception of a MESSAGE request with a URI-list, a MESSAGE URI-list On reception of a MESSAGE request with a URI-list, a MESSAGE URI-list
service SHOULD determine the list of intended recipients, by service SHOULD determine the list of intended recipients, by
inspecting the URI-list contained in the body. In case two of those inspecting the URI-list contained in the body. In case two of those
URIs are equivalent (section 19.1.4 of RFC 3261 [6] defines URIs are equivalent (section 19.1.4 of RFC 3261 [6] defines
equivalent URIs), the MESSAGE URI-list SHOULD consider a single equivalent URIs), the MESSAGE URI-list SHOULD consider a single
intended recipient. intended recipient.
6.2 Creating an outgoing MESSAGE request 7.2 Creating an outgoing MESSAGE request
Since the MESSAGE URI-list behaves as a UAC for outgoing MESSAGE Since the MESSAGE URI-list behaves as a UAC for outgoing MESSAGE
requests, for each of the intended recipients, the MESSAGE URI-list requests, for each of the intended recipients, the MESSAGE URI-list
service creates a new MESSAGE request according to the procedures service creates a new MESSAGE request according to the procedures
described in Section 4 of RFC 3428 [9] and the following procedures: described in Section 4 of RFC 3428 [9] and the following procedures:
o A MESSAGE URI-list service MUST include a From header field whose o A MESSAGE URI-list service MUST include a From header field whose
value is the same as the From header field included in the value is the same as the From header field included in the
incoming MESSAGE request, subject to the privacy requirements (see incoming MESSAGE request, subject to the privacy requirements (see
RFC 3323 [7] and RFC 3325 [8]) expressed in the incoming MESSAGE RFC 3323 [7] and RFC 3325 [8]) expressed in the incoming MESSAGE
skipping to change at page 10, line 34 skipping to change at page 10, line 30
o If the incoming MESSAGE request contains an Authorization or o If the incoming MESSAGE request contains an Authorization or
Proxy-Authorization header fields whose realm is set to the Proxy-Authorization header fields whose realm is set to the
MESSAGE URI-list server's realm, then the MESSAGE URI-list service MESSAGE URI-list server's realm, then the MESSAGE URI-list service
SHOULD NOT copy it to the outgoing MESSAGE request; otherwise SHOULD NOT copy it to the outgoing MESSAGE request; otherwise
(i.e., if the Authorization or Proxy-Authorization header field of (i.e., if the Authorization or Proxy-Authorization header field of
incoming MESSAGE request contains a different realm), the MESSAGE incoming MESSAGE request contains a different realm), the MESSAGE
URI-list service MUST copy the value to the respective header URI-list service MUST copy the value to the respective header
field of the outgoing MESSAGE request. field of the outgoing MESSAGE request.
o A MESSAGE URI-list service SHOULD create a separate count for the o A MESSAGE URI-list service SHOULD create a separate count for the
CSeq header field of the outgoing MESSAGE request. CSeq header field of the outgoing MESSAGE request.
o A MESSAGE URI-list service SHOULD initialize the value of the o A MESSAGE URI-list service SHOULD initialize the value of the Max-
Max-Forward header field of the outgoing MESSAGE request. Forward header field of the outgoing MESSAGE request.
o A MESSAGE URI-list service MUST include its own value in the Via o A MESSAGE URI-list service MUST include its own value in the Via
header field. header field.
o A MESSAGE URI-list service SHOULD include any other header field o A MESSAGE URI-list service SHOULD include any other header field
expressed with the "?" mechanism described in Section 19.1.1 of expressed with the "?" mechanism described in Section 19.1.1 of
RFC 3261 [6] and encoded in the intended recipient URI of the RFC 3261 [6] and encoded in the intended recipient URI of the URI-
URI-list. list.
o A MESSAGE URI-list service SHOULD preserve to the outgoing MESSAGE o A MESSAGE URI-list service SHOULD preserve to the outgoing MESSAGE
request any other header field not explicitly indicated in the request any other header field not explicitly indicated in the
above paragraphs. above paragraphs.
6.3 Composing bodies in the outgoing MESSAGE request 7.3 Composing bodies in the outgoing MESSAGE request
When creating the body of each of the outgoing MESSAGE requests, the When creating the body of each of the outgoing MESSAGE requests, the
MESSAGE URI-list service tries to keep the relevant bodies of the MESSAGE URI-list service tries to keep the relevant bodies of the
incoming MESSAGE request and copies them to the outgoing MESSAGE incoming MESSAGE request and copies them to the outgoing MESSAGE
request. The following guidelines are provided: request. The following guidelines are provided:
o A MESSAGE request received at a MESSAGE URI-list service can o A MESSAGE request received at a MESSAGE URI-list service can
contain one or more security bodies (e.g., S/MIME [11]) encrypted contain one or more security bodies (e.g., S/MIME [11]) encrypted
with the public key of the MESSAGE URI-list service. These bodies with the public key of the MESSAGE URI-list service. These bodies
are deemed to be read by the URI-list service rather than the are deemed to be read by the URI-list service rather than the
skipping to change at page 11, line 33 skipping to change at page 11, line 29
resources categorized with the "bcc" or lacking the capacity resources categorized with the "bcc" or lacking the capacity
attribute. attribute.
o If the MESSAGE URI-list service includes a URI-list in an outgoing o If the MESSAGE URI-list service includes a URI-list in an outgoing
MESSAGE request, it MUST include a Content-Disposition header MESSAGE request, it MUST include a Content-Disposition header
field [2] with the value set to 'recipient-list-history' and a field [2] with the value set to 'recipient-list-history' and a
'handling' parameter [5] set to "optional". 'handling' parameter [5] set to "optional".
o If a MESSAGE URI-list service includes a URI-list in an outgoing o If a MESSAGE URI-list service includes a URI-list in an outgoing
MESSAGE request, it SHOULD use S/MIME [11] to encrypt the URI-list MESSAGE request, it SHOULD use S/MIME [11] to encrypt the URI-list
with the public key of the receiver. with the public key of the receiver.
o The incoming MESSAGE request typically contains a URI-list body or o The incoming MESSAGE request typically contains a URI-list body or
reference [12] with the actual list of recipients. Section 6.2 reference [12] with the actual list of recipients. Section 7.2
contains procedures that determine when the MESSAGE URI-list contains procedures that determine when the MESSAGE URI-list
service should include a URI-list body in the outgoing MESSAGE service should include a URI-list body in the outgoing MESSAGE
request. request.
o The MESSAGE URI-list service SHOULD copy all the rest of the o The MESSAGE URI-list service SHOULD copy all the rest of the
message bodies (e.g., text messages, images, etc.) to the outgoing message bodies (e.g., text messages, images, etc.) to the outgoing
MESSAGE request. MESSAGE request.
o If there is only one body left, the MESSAGE URI-list service MUST o If there is only one body left, the MESSAGE URI-list service MUST
remove the multipart/mixed wrapper in the outgoing MESSAGE remove the multipart/mixed wrapper in the outgoing MESSAGE
request. request.
skipping to change at page 12, line 4 skipping to change at page 11, line 48
request. request.
The rest of the MESSAGE request corresponding to a given URI in the The rest of the MESSAGE request corresponding to a given URI in the
URI-list MUST be created following the rules in Section 19.1.5 URI-list MUST be created following the rules in Section 19.1.5
"Forming Requests from a URI" of RFC 3261 [6]. In particular, "Forming Requests from a URI" of RFC 3261 [6]. In particular,
Section 19.1.5 of RFC 3261 [6] states: Section 19.1.5 of RFC 3261 [6] states:
"An implementation SHOULD treat the presence of any headers or body "An implementation SHOULD treat the presence of any headers or body
parts in the URI as a desire to include them in the message, and parts in the URI as a desire to include them in the message, and
choose to honor the request on a per-component basis." choose to honor the request on a per-component basis."
SIP allows to append a "method" parameter to a URI. Therefore, it is SIP allows to append a "method" parameter to a URI. Therefore, it is
legitimate that an the 'uri' attribute of the <entry> element in the legitimate that an the 'uri' attribute of the <entry> element in the
XCAP resource list contains a 'method' parameter. MESSAGE URI-list XCAP resource list contains a 'method' parameter. MESSAGE URI-list
services MUST generate only MESSAGE requests, regardless of the services MUST generate only MESSAGE requests, regardless of the
'method' parameter that the URIs in the list indicate. Effectively, 'method' parameter that the URIs in the list indicate. Effectively,
MESSAGE URI-list services MUST ignore the 'method' parameter in each MESSAGE URI-list services MUST ignore the 'method' parameter in each
of the URIs present in the URI-list. of the URIs present in the URI-list.
7. Procedures at the UAS 8. Procedures at the UAS
A UAS (in this specification, also known as intended recipient UAS) A UAS (in this specification, also known as intended recipient UAS)
that receives a MESSAGE request from the URI-list service behaves as that receives a MESSAGE request from the URI-list service behaves as
specified in RFC 3428 [9] Section 7. specified in RFC 3428 [9] Section 7.
If the UAS supports this specification and the MESSAGE request If the UAS supports this specification and the MESSAGE request
contains a body with a Content-Disposition header field [2] set to contains a body with a Content-Disposition header field [2] set to
'recipient-list-history', then the UAS will be able to determine who 'recipient-list-history', then the UAS will be able to determine who
are the other intended visible recipients of the MESSAGE request. are the other intended visible recipients of the MESSAGE request.
This allows the user to create a reply request (e.g., MESSAGE, This allows the user to create a reply request (e.g., MESSAGE,
INVITE) to the sender and the rest of the visible recipients. INVITE) to the sender and the rest of the visible recipients.
8. Examples 9. Examples
Figure 5 shows an example of operation. A SIP UAC issuer sends a Figure 3 shows an example of operation. A SIP UAC issuer sends a
MESSAGE request. The MESSAGE URI-list service answers with a 202 MESSAGE request. The MESSAGE URI-list service answers with a 202
Accepted message and sends a MESSAGE request to each of the intended Accepted message and sends a MESSAGE request to each of the intended
recipients. recipients.
+--------+ +---------+ +--------+ +--------+ +--------+ +--------+ +---------+ +--------+ +--------+ +--------+
|SIP UAC | | MESSAGE | |intended| |intended| |intended| |SIP UAC | | MESSAGE | |intended| |intended| |intended|
| issuer | | URI-list| | recip. | | recip. | | recip. | | issuer | | URI-list| | recip. | | recip. | | recip. |
| | | service | | 1 | | 2 | | 3 | | | | service | | 1 | | 2 | | 3 |
+--------+ +---------+ +--------+ +--------+ +--------+ +--------+ +---------+ +--------+ +--------+ +--------+
| | | | | | | | | |
skipping to change at page 13, line 30 skipping to change at page 13, line 30
| | F6. 200 OK | | | | | F6. 200 OK | | |
| |<------------- | | | | |<------------- | | |
| | F7. 200 OK | | | | | F7. 200 OK | | |
| |<------------------------ | | | |<------------------------ | |
| | F8. 200 OK | | | | | F8. 200 OK | | |
| |<----------------------------------- | | |<----------------------------------- |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
Figure 5: Example of operation Figure 3: Example of operation
The MESSAGE request F1 is as follows: The MESSAGE request F1 is as follows:
MESSAGE sip:list-service.example.com SIP/2.0 MESSAGE sip:list-service.example.com SIP/2.0
Via: SIP/2.0/TCP uac.example.com Via: SIP/2.0/TCP uac.example.com
;branch=z9hG4bKhjhs8ass83 ;branch=z9hG4bKhjhs8ass83
Max-Forwards: 70 Max-Forwards: 70
To: MESSAGE URI-list Service <sip:list-service.example.com> To: MESSAGE URI-list Service <sip:list-service.example.com>
From: Carol <sip:carol@example.com>;tag=32331 From: Carol <sip:carol@example.com>;tag=32331
Call-ID: d432fa84b4c76e66710 Call-ID: d432fa84b4c76e66710
CSeq: 1 MESSAGE CSeq: 1 MESSAGE
Require: recipient-list-message
Content-Type: multipart/mixed;boundary="boundary1" Content-Type: multipart/mixed;boundary="boundary1"
Content-Length: 501 Content-Length: 501
--boundary1 --boundary1
Content-Type: text/plain Content-Type: text/plain
Hello World! Hello World!
--boundary1 --boundary1
Content-Type: application/resource-lists+xml Content-Type: application/resource-lists+xml
Content-Disposition: recipient-list Content-Disposition: recipient-list
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists" <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:cp="urn:ietf:params:xml:ns:capacity" xmlns:cp="urn:ietf:params:xml:ns:capacity"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<list> <list>
<entry uri="sip:bill@example.com" cp:capacity="to" /> <entry uri="sip:bill@example.com" cp:capacity="to" />
<entry uri="sip:joe@example.org" cp:capacity="cc /> <entry uri="sip:joe@example.org" cp:capacity="cc" />
<entry uri="sip:ted@example.net" cp:capacity="bcc" /> <entry uri="sip:ted@example.net" cp:capacity="bcc" />
</list> </list>
</resource-lists> </resource-lists>
--boundary1-- --boundary1--
Messages F4, F4 and F5 are similar in nature. Especially the bodies Messages F3, F4 and F5 are similar in nature. Especially the bodies
are exactly the same for all of them, since they include the instant are exactly the same for all of them, since they include the instant
message payload and a URI-list that contains the resources tagged message payload and a URI-list that contains the resources tagged
with the "to" and "cc" capacity attribute. We show an example of F3: with the "to" and "cc" capacity attribute. We show an example of F3:
MESSAGE sip:bill@example.com SIP/2.0 MESSAGE sip:bill@example.com SIP/2.0
Via: SIP/2.0/TCP list-service.example.com Via: SIP/2.0/TCP list-service.example.com
;branch=z9hG4bKhjhs8as34sc ;branch=z9hG4bKhjhs8as34sc
Max-Forwards: 70 Max-Forwards: 70
To: <sip:bill@example.com> To: <sip:bill@example.com>
From: Carol <sip:carol@uac.example.com>;tag=210342 From: Carol <sip:carol@uac.example.com>;tag=210342
skipping to change at page 15, line 36 skipping to change at page 15, line 36
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists" <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:cp="urn:ietf:params:xml:ns:capacity" xmlns:cp="urn:ietf:params:xml:ns:capacity"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<list> <list>
<entry uri="sip:bill@example.com" cp:capacity="to" /> <entry uri="sip:bill@example.com" cp:capacity="to" />
<entry uri="sip:joe@example.org" cp:capacity="cc" /> <entry uri="sip:joe@example.org" cp:capacity="cc" />
</list> </list>
</resource-lists> </resource-lists>
--boundary1-- --boundary1--
9. IANA Considerations 10. Security Considerations
The Framework and Security Considerations for SIP URI-List Services
[12] discusses issues related to SIP URI-list services.
Implementations of MESSAGE URI-list services MUST follow the
security-related rules in the Framework and Security Considerations
for SIP URI-List Services [12]. These rules include mandatory
authentication and authorization of clients, and opt-in lists.
If the contents of the instant message needs to be kept private, the
user agent client SHOULD use S/MIME [11] to prevent a third party
from viewing this information. In this case, the user agent client
SHOULD encrypt the instant message body with a content encryption
key. Then, for each receiver in the list, the UAC SHOULD encrypt the
content encryption key with the public key of the receiver, and
attach it to the MESSAGE request.
11. IANA Considerations
The following sections instruct the IANA to register a new
disposition type and a new SIP option-tag.
11.1 Disposition Type Registration
Section 4 defines a new 'recipient-list-history' value of the Mail Section 4 defines a new 'recipient-list-history' value of the Mail
Content Disposition Values registry. This value should be registered Content Disposition Values registry. This value should be registered
in the IANA registry of Mail Content Disposition Values with the in the IANA registry of Mail Content Disposition Values with the
following registration data: following registration data:
+------------------------+------------------------------+-----------+ +------------------------+------------------------------+-----------+
| Name | Description | Reference | | Name | Description | Reference |
+------------------------+------------------------------+-----------+ +------------------------+------------------------------+-----------+
| recipient-list-history | the body contains a list of | [RFCXXXX] | | recipient-list-history | the body contains a list of | [RFCXXXX] |
| | URIs that indicates the | | | | URIs that indicates the | |
| | recipients of the message | | | | recipients of the message | |
+------------------------+------------------------------+-----------+ +------------------------+------------------------------+-----------+
Table 1: Registration of the 'recipient-list-history' Mail Content Table 1: Registration of the 'recipient-list-history' Mail Content
Disposition Value Disposition Value
Note to IANA and the RFC editor: replace RFCXXXX above with the RFC Note to IANA and the RFC editor: replace RFCXXXX above with the RFC
number of this specification. number of this specification.
10. Security Considerations 11.2 Option-Tag Registration
The Framework and Security Considerations for SIP URI-List Services This document defines the 'recipient-list-message' SIP option-tag in
[12] discusses issues related to SIP URI-list services. Section 5. It should be registered in the Option Tags subregistry
Implementations of MESSAGE URI-list services MUST follow the under the SIP parameter registry. The following is the description
security-related rules in the Framework and Security Considerations to be used in the registration.
for SIP URI-List Services [12]. These rules include mandatory
authentication and authorization of clients, and opt-in lists.
If the contents of the instant message needs to be kept private, the This option-tag is used to ensure that a server can process the
user agent client SHOULD use S/MIME [11] to prevent a third party 'recipient-list' body used in a MESSAGE request.
from viewing this information. In this case, the user agent client
SHOULD encrypt the instant message body with a content encryption
key. Then, for each receiver in the list, the UAC SHOULD encrypt the
content encryption key with the public key of the receiver, and
attach it to the MESSAGE request.
11. Acknowledgements 12. Acknowledgements
Duncan Mills supported the idea of having 1 to n MESSAGEs. Ben Duncan Mills supported the idea of having 1 to n MESSAGEs. Ben
Campbell, Paul Kyzivat, Cullen Jennings, and Jonathan Rosenberg Campbell, Paul Kyzivat, Cullen Jennings, and Jonathan Rosenberg
provided helpful comments. provided helpful comments.
12. Change control 13. Change control
12.1 Changes from draft-ietf-sipping-uri-list-message-01.txt 13.1 Changes from draft-ietf-sipping-uri-list-message-02.txt
Typos fixed.
'recipient-list-message' option-tag defined and registered with the
IANA.
13.2 Changes from draft-ietf-sipping-uri-list-message-01.txt
Added a reference to missing REQ-GROUP-4 in the Advanced Instant Added a reference to missing REQ-GROUP-4 in the Advanced Instant
Messaging Requirements for SIP document. Messaging Requirements for SIP document.
Since the resource list allows now attribute extensibility, the Since the resource list allows now attribute extensibility, the
former <capacity> element has been replaced by a 'capacity' former <capacity> element has been replaced by a 'capacity'
attribute, which allows a more compact representation of the URI. attribute, which allows a more compact representation of the URI.
Added a new Content-Disposition disposition type Added a new Content-Disposition disposition type 'recipient-list-
'recipient-list-history'. It is used in the MESSAGE request that the history'. It is used in the MESSAGE request that the MESSAGE URI-
MESSAGE URI-list service sends to each of the recipients. This list service sends to each of the recipients. This allows the UAS to
allows the UAS to differentiate it from a 'recipient-list', which has differentiate it from a 'recipient-list', which has a separate
a separate meaning. meaning.
12.2 Changes from draft-ietf-sipping-uri-list-message-00.txt 13.3 Changes from draft-ietf-sipping-uri-list-message-00.txt
Revision of the treatment of headers the MESSAGE URI-list service, on Revision of the treatment of headers the MESSAGE URI-list service, on
a header by header basis. a header by header basis.
Added an overview section. Added an overview section.
Added functionality that allows the sender of the incoming MESSAGE Added functionality that allows the sender of the incoming MESSAGE
request to tag each of the intended recipients with the "to", "cc", request to tag each of the intended recipients with the "to", "cc",
or "bcc" capacity. If there are resources tagged as "to" or "cc", or "bcc" capacity. If there are resources tagged as "to" or "cc",
the URI-list service will include a URI-list in each of the outgoing the URI-list service will include a URI-list in each of the outgoing
MESSAGE request including those resources. MESSAGE request including those resources.
Procedures at the UAS included. Procedures at the UAS included.
Better example including a flow. Better example including a flow.
12.3 Changes from draft-ietf-sipping-message-exploder-00.txt to 13.4 Changes from draft-ietf-sipping-message-exploder-00.txt to
draft-ietf-sipping-uri-list-message-00.txt draft-ietf-sipping-uri-list-message-00.txt
Clarified that the MESSAGE exploder should not distribute a body that Clarified that the MESSAGE exploder should not distribute a body that
has been encrypted with the public key of the exploder. The has been encrypted with the public key of the exploder. The
exception is the URI-list, which can be distributed by the exploder, exception is the URI-list, which can be distributed by the exploder,
providing that is encrypted with the public key of the receiver. providing that is encrypted with the public key of the receiver.
The security considerations section describes how to encrypt the list The security considerations section describes how to encrypt the list
and how to encrypt the instant message payload. and how to encrypt the instant message payload.
Terminology aligned with the requirements and the framework for Terminology aligned with the requirements and the framework for URI-
URI-list services (e.g., the term "exploder" has been deprecated). list services (e.g., the term "exploder" has been deprecated).
12.4 Changes from draft-garcia-simple-message-exploder-00.txt to 13.5 Changes from draft-garcia-simple-message-exploder-00.txt to
draft-garcia-sipping-message-exploder-00.txt draft-garcia-sipping-message-exploder-00.txt
The MESSAGE exploder may or may not copy the URI-list body to the The MESSAGE exploder may or may not copy the URI-list body to the
outgoing MESSAGE request. This allows to extend the mechanism with a outgoing MESSAGE request. This allows to extend the mechanism with a
Reply-to-all feature. Reply-to-all feature.
It is clarified that the MESSAGE exploder must not include a list in It is clarified that the MESSAGE exploder must not include a list in
the outgoing MESSAGE requests. This avoids loops or requires a the outgoing MESSAGE requests. This avoids loops or requires a
MESSAGE exploder functionality in the next hop. MESSAGE exploder functionality in the next hop.
The MESSAGE exploder must remove the multipart/mixed wrapper if there The MESSAGE exploder must remove the multipart/mixed wrapper if there
is only one body left in the outgoing MESSAGE request. is only one body left in the outgoing MESSAGE request.
Filename changed due to focus on the SIPPING WG. Filename changed due to focus on the SIPPING WG.
13. References 14. References
13.1 Normative References 14.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Troost, R., Dorner, S. and K. Moore, "Communicating [2] Troost, R., Dorner, S., and K. Moore, "Communicating
Presentation Information in Internet Messages: The Presentation Information in Internet Messages: The Content-
Content-Disposition Header Field", RFC 2183, August 1997. Disposition Header Field", RFC 2183, August 1997.
[3] Levinson, E., "Content-ID and Message-ID Uniform Resource [3] Levinson, E., "Content-ID and Message-ID Uniform Resource
Locators", RFC 2392, August 1998. Locators", RFC 2392, August 1998.
[4] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., [4] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication:
Basic and Digest Access Authentication", RFC 2617, June 1999. Basic and Digest Access Authentication", RFC 2617, June 1999.
[5] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., [5] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F.,
Watson, M. and M. Zonoun, "MIME media types for ISUP and QSIG Watson, M., and M. Zonoun, "MIME media types for ISUP and QSIG
Objects", RFC 3204, December 2001. Objects", RFC 3204, December 2001.
[6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[7] Peterson, J., "A Privacy Mechanism for the Session Initiation [7] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC 3323, November 2002. Protocol (SIP)", RFC 3323, November 2002.
[8] Jennings, C., Peterson, J. and M. Watson, "Private Extensions [8] Jennings, C., Peterson, J., and M. Watson, "Private Extensions
to the Session Initiation Protocol (SIP) for Asserted Identity to the Session Initiation Protocol (SIP) for Asserted Identity
within Trusted Networks", RFC 3325, November 2002. within Trusted Networks", RFC 3325, November 2002.
[9] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and [9] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and
D. Gurle, "Session Initiation Protocol (SIP) Extension for D. Gurle, "Session Initiation Protocol (SIP) Extension for
Instant Messaging", RFC 3428, December 2002. Instant Messaging", RFC 3428, December 2002.
[10] Rosenberg, J., "Extensible Markup Language (XML) Formats for [10] Rosenberg, J., "Extensible Markup Language (XML) Formats for
Representing Resource Lists", Representing Resource Lists",
draft-ietf-simple-xcap-list-usage-04 (work in progress), draft-ietf-simple-xcap-list-usage-05 (work in progress),
October 2004. February 2005.
[11] Ramsdell, B., "S/MIME Version 3.1 Message Specification", [11] Ramsdell, B., "S/MIME Version 3.1 Message Specification",
draft-ietf-smime-rfc2633bis-09 (work in progress), April 2004. draft-ietf-smime-rfc2633bis-09 (work in progress), April 2004.
[12] Camarillo, G., "Requirements and Framework for Session [12] Camarillo, G. and A. Roach, "Requirements and Framework for
Initiation Protocol (SIP)Uniform Resource Identifier Session Initiation Protocol (SIP)Uniform Resource Identifier
(URI)-List Services", draft-ietf-sipping-uri-services-01 (work (URI)-List Services", draft-ietf-sipping-uri-services-02 (work
in progress), October 2004. in progress), December 2004.
13.2 Informational References 14.2 Informational References
[13] Rosenberg, J., "Advanced Instant Messaging Requirements for the [13] Rosenberg, J., "Advanced Instant Messaging Requirements for the
Session Initiation Protocol (SIP)", Session Initiation Protocol (SIP)",
draft-rosenberg-simple-messaging-requirements-01 (work in draft-rosenberg-simple-messaging-requirements-01 (work in
progress), February 2004. progress), February 2004.
[14] Peterson, J., "Session Initiation Protocol (SIP) Authenticated [14] Peterson, J., "Session Initiation Protocol (SIP) Authenticated
Identity Body (AIB) Format", RFC 3893, September 2004. Identity Body (AIB) Format", RFC 3893, September 2004.
Authors' Addresses Authors' Addresses
Miguel A. Garcia-Martin Miguel A. Garcia-Martin
Nokia Nokia
P.O.Box 407 P.O.Box 407
NOKIA GROUP, FIN 00045 NOKIA GROUP, FIN 00045
Finland Finland
EMail: miguel.an.garcia@nokia.com Email: miguel.an.garcia@nokia.com
Gonzalo Camarillo Gonzalo Camarillo
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
EMail: Gonzalo.Camarillo@ericsson.com Email: Gonzalo.Camarillo@ericsson.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
skipping to change at page 20, line 41 skipping to change at page 20, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/