draft-ietf-sipping-uri-list-message-06.txt   draft-ietf-sipping-uri-list-message-07.txt 
SIPPING Working Group M. Garcia-Martin SIPPING Working Group M. Garcia-Martin
Internet-Draft Nokia Internet-Draft Nokia
Expires: August 4, 2006 G. Camarillo Expires: August 26, 2006 G. Camarillo
Ericsson Ericsson
January 31, 2006 February 22, 2006
Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol
(SIP) (SIP)
draft-ietf-sipping-uri-list-message-06.txt draft-ietf-sipping-uri-list-message-07.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 August 4, 2006. This Internet-Draft will expire on August 26, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document specifies how to request a SIP URI-list service to send This document specifies a mechanism that allows a SIP User Agent
a copy of a MESSAGE to a set of destinations. The client sends a SIP Client (UAC) to request a SIP URI-list (Uniform Resource Identifier
MESSAGE request with a URI-list to the MESSAGE URI-list service, list) service to send a SIP MESSAGE request to a set of destinations.
which sends a similar MESSAGE request to each of the URIs included in The client sends a SIP MESSAGE request that includes the payload
the list. along with the URI-list to the MESSAGE URI-list service, which sends
a similar MESSAGE request to each of the URIs included in 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 5. Option-tag . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1.1. XML Schema . . . . . . . . . . . . . . . . . . . . . . 7 6. Procedures at the User Agent Client . . . . . . . . . . . . . 6
4.2. URI-list example . . . . . . . . . . . . . . . . . . . . . 7 7. Procedures at the MESSAGE URI-List Service . . . . . . . . . . 7
5. Option-tag . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Determining the intended recipient . . . . . . . . . . . . 8
6. Procedures at the User Agent Client . . . . . . . . . . . . . 8 7.2. Creating an outgoing MESSAGE request . . . . . . . . . . . 8
7. Procedures at the MESSAGE URI-List Service . . . . . . . . . . 9 7.3. Composing bodies in the outgoing MESSAGE request . . . . . 9
7.1. Determining the intended recipient . . . . . . . . . . . . 9 8. Procedures at the UAS . . . . . . . . . . . . . . . . . . . . 11
7.2. Creating an outgoing MESSAGE request . . . . . . . . . . . 9 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.3. Composing bodies in the outgoing MESSAGE request . . . . . 11 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. Procedures at the UAS . . . . . . . . . . . . . . . . . . . . 12 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 13.1. Normative References . . . . . . . . . . . . . . . . . . . 15
11.1. Disposition Type Registration . . . . . . . . . . . . . . 16 13.2. Informational References . . . . . . . . . . . . . . . . . 16
11.2. Option-Tag Registration . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
11.3. URN Sub-Namespace Registration . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 16
11.3.1. urn:ietf:params:xml:ns:capacity . . . . . . . . . . . 16
11.4. Schema Registration . . . . . . . . . . . . . . . . . . . 17
11.4.1. urn:ietf:params:xml:schema:capacity . . . . . . . . . 17
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
13.1. Normative References . . . . . . . . . . . . . . . . . . . 18
13.2. Informational References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 19
1. Introduction 1. Introduction
SIP [5] can carry instant messages in MESSAGE [8] requests. The SIP [5] can carry instant messages in MESSAGE [8] 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."
skipping to change at page 3, line 26 skipping to change at page 3, line 26
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 wants to send a small page- other situations the sending user just wants to send a small page-
mode instant message to an ad-hoc group without the burden of setting mode instant message to an ad-hoc group without the burden of setting
up a session. This document focuses on sending a page-mode instant up a session. This document focuses on sending a page-mode instant
message to a number of intended recipients. message to a number of intended recipients.
To meet the requirement with a page-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 Content- SIP MESSAGE requests carry URI-lists in body parts whose Content-
Disposition [2] is 'recipient-list', as specified in the Framework Disposition [2] is 'recipient-list', as specified in the Framework
and Security Considerations for SIP URI-List Services [12]. A SIP and Security Considerations for SIP URI-List Services [11]. A SIP
MESSAGE URI-list service, which is a specialized application service, MESSAGE URI-list service, which is a specialized application service,
receives the request and sends a similar MESSAGE request to each of receives the request and sends a similar MESSAGE request to each of
the URIs in the list. Each of these MESSAGE requests contains a copy the URIs in the list. Each of these MESSAGE requests 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
URI-list service can include the received URI-list along with the URI-list service also includes a URI-list in body parts whose
instant message payload in each of the instant messages sent to the Content-Disposition [2] is 'recipient-list-history', as specified in
recipients. Further more, we provide an extension to the URI-list the Extensible Markup Language (XML) Format Extension for
format that allows the sender to tag each recipient with the role or Representing Capacity Attributes in Resource Lists [12]. The
'capacity' in which he is receiving an instant message. 'recipient-list-history' body is sent along with the instant message
payload in each of the instant messages sent to the recipients.
The UAC (User Agent Client) that sends a MESSAGE request to a MESSAGE The User Agent Client (UAC) that sends a MESSAGE request to a MESSAGE
URI-list service needs to be configured with the SIP URI of the URI-list service needs to be configured with the SIP URI of the
service that provides the functionality. Discovering and service that provides the functionality. Discovering and
provisioning of this URI to the UAC is outside the scope of this provisioning of this URI to the UAC is outside the scope of this
document. document.
2. Terminology 2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
skipping to change at page 4, line 36 skipping to change at page 4, line 36
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 URI- Outgoing MESSAGE request: A SIP MESSAGE request that a MESSAGE URI-
list service creates and addresses to a UAS (User Agent Server). list service creates and addresses to a UAS (User Agent 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 Intended recipient: The intended final recipient of the request to
be generated by MESSAGE URI-list service. be generated by MESSAGE URI-list service.
Capacity: The role assigned by the sender to a recipient. The
sender is able to tag recipients with the 'to', 'cc', and 'bcc'
capacity, which indicate, respectively, whether the recipients get
a primary, carbon copy, or blind carbon copy of the message.
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 list of URIs is formatted according to the XML resource
service. On reception of this incoming MESSAGE request, the MESSAGE list [9] and extended with the attributes defined in [12]. The UAC
URI-list service creates a MESSAGE request per intended recipient sends this MESSAGE request to the MESSAGE URI-list service. On
(listed in the URI-list) and copies the instant message payload to reception of this incoming MESSAGE request, the MESSAGE URI-list
each of those MESSAGES. Then the MESSAGE URI-list service sends each service creates a MESSAGE request per intended recipient (listed in
of the created outgoing MESSAGE request to the respective receiver. the URI-list) and copies the instant message payload to each of those
MESSAGES. The MESSAGE URI-list service also manipulates the XML
resource list according to the procedures indicated in [12], and
attaches the result to each of the MESSAGE requests, along with the
instant message payload. Then the MESSAGE URI-list service sends
each of the created outgoing MESSAGE request to the respective
receiver.
The MESSAGE URI-list mechanism allows a sender to specify multiple The MESSAGE URI-list mechanism allows a sender to specify multiple
targets for a MESSAGE request by including a resource list in the targets for a MESSAGE request by including an XML resource list [9]
body of the MESSAGE request. This resource list includes the URIs of in the body of the MESSAGE request extended with the attributes
the targets. Each target URI may also be marked to indicate in what defined in the XML Format Extension for Representing Capacity
capacity (or role) the URI-list service will place the target. he Attributes in Resource Lists [12]. This resource list, whose
available capacities include "to", "cc", and "bcc". When the MESSAGE Content-Disposition [2] is 'recipient-list', as specified in the
URi-list server expands the request for each recipient, it includes a Framework and Security Considerations for SIP URI-List Services [11],
new URI-list that contains only the targets originally listed in the includes the URIs of the targets. Each target URI may also be marked
"to" and "cc" capacities, and excludes those listed in the "bcc" to indicate in what capacity (or role) the URI-list service will
capacity. this allows recipients to both see and reply to the "to" place the target (e.g., "to", "cc", or "bcc"), and whether the target
and "cc" targets, but not to the "bcc" targets. The default capacity URI should be anonymized or not, according to the procedures
assumed if one is not specified by the sender is "bcc". This is described in [12]. When the MESSAGE URI-list server expands the
discussed in greater detailed in Section 4.1 of this document. The MESSAGE request to each recipient, it includes (along with the
mechanism reuses the XML format for representing resource lists [10] instant message payload) a new URI-list (based on the received one),
to include the list of intended recipients. We define an extension whose Content-Disposition [2] is 'recipient-list-history', as
to that list to indicate the capacity of each resource, which can be specified in the XML Format Extension for Representing Capacity
To, Cc or Bcc (in an analogy to e-mail). The MESSAGE URI-list Attributes in Resource Lists [12]. This new URI-list includes the
service can include a resource list in the outgoing MESSAGE request list of non-anonymous "to" and "cc" targets, allowing recipients to
that contain those resources tagged with a To or Cc capacities (and both get knowledge of other recipients and reply to them.
not Bcc capacities). This allows the creator of the incoming MESSAGE
request to identify if a resource should be receiving a copy of the
MESSAGE request as a capacity of recipient (to), carbon copy (cc) or
blind carbon copy (bcc). It also allows some the intended recipients
to reply to the initial sender and all the visible recipients of the
MESSAGE request.
4. URI-List document 4. URI-List document
As described in the Framework and Security Considerations for SIP As described in the Framework and Security Considerations for SIP
URI-List Services [12], specifications of individual URI-list URI-List Services [11], specifications of individual URI-list
services, like the MESSAGE URI-list service described here, need to services, like the MESSAGE URI-list service described here, need to
specify a default format for 'recipient-list' bodies used within the specify a default format for 'recipient-list' bodies used within the
particular service. particular service.
The default format for recipient-list bodies for MESSAGE URI-list The default format for 'recipient-list' bodies for MESSAGE URI-list
services is the resource list document format [10] . UAs (User services is the XML resource list document format [9] extended with
Agents) and servers handling recipient-list bodies MUST support this the XML Format Extension for Representing Capacity Attributes in
format and MAY support other formats. Resource Lists [12]. UACs and MESSAGE URI-list services handling
'recipient-list' bodies MUST support both of these formats and MAY
support other formats.
Nevertheless, the Extensible Markup Language (XML) Configuration As described in the XML Format Extension for Representing Capacity
Access Protocol (XCAP) resource list document provides features, such Attributes in Resource Lists [12], each URI can be tagged with a
as hierarchical lists and the ability to include entries by reference 'capacity' attribute set to either "to", "cc", or "bcc", indicating
relative to the XCAP root URI, that are not needed by the MESSAGE the capacity or role in which the recipient will get the MESSAGE
URI-list service defined in this document, which only needs to request. Additionally, URIs can be tagged with the 'anonymize'
transfer a flat list of URIs between a UA and the server. Therefore, attribute to prevent that the MESSAGE URI-list server discloses the
when using the default resource list document, UAs SHOULD use flat target URI in a URI-list.
lists (i.e., no hierarchical lists) and SHOULD NOT use <entry-ref>
elements.
Section 4.1 defines an extension to the XML format for representing Additionally, the XML Format Extension for Representing Capacity
resource lists [10]. This extension allows us to characterize a Attributes in Resource Lists [12] defines a 'recipient-list-history'
resource with a 'capacity' attribute. UACs (User Agent Clients) and body that contains the list of intended recipients. The default
MESSAGE URI-list services handling 'recipient-list' bodies MUST format for 'recipient-list-history' bodies for MESSAGE URI-list
support 'capacity' extension. services is also the XML resource list document format [9] extended
with the XML Format Extension for Representing Capacity Attributes in
Resource Lists [12]. MESSAGE URI-list services MUST support both of
these formats; UASes MAY support these formats. MESSAGE URI-list
servers and UASes MAY support other formats.
Nevertheless, the XML resource list document [9] provides features,
such as hierarchical lists and the ability to include entries by
reference relative to the XCAP root URI, that are not needed by the
MESSAGE URI-list service defined in this document, which only needs
to transfer a flat list of URIs between a UA (User Agent) and the
MESSAGE URI-list server. Therefore, when using the default resource
list document, UAs SHOULD use flat lists (i.e., no hierarchical
lists) and SHOULD NOT use <entry-ref> elements.
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
to be included in a Content-Disposition [2] header field of a SIP
MESSAGE request. The value of this new disposition type is
'recipient-list-history' and its purpose is to indicate a list of
recipients that a MESSAGE was sent to. A body whose Content-
Disposition type is 'recipient-list-history' contains a URI-list with
the visible recipients of the MESSAGE. The <entry> element in the
URI-list MAY also include a 'capacity' attribute, as specified in
Section 4.1. MESSAGE URI-list services MUST implement support for
this Content-Disposition type. User Agent Servers (UAS) MAY
implement support for the resource-list document format [10] and the
'recipient-list-history' Content-Disposition type.
4.1. Extension to the resource lists data format
This document defines an extension that allows the sender to indicate
the capacity of role in which a recipient is receiving a message. We
define a new 'capacity' attribute to the <entry> element of the
resource list document format [10]. The 'capacity' attribute has
similar semantics to the type of destination address in e-mail
systems. It can take the values "to", "cc" and "bcc". A "to" value
of the 'capacity' attribute indicates that the resource is considered
the recipient of the MESSAGE request. A "cc" value indicates that
the resource receives a carbon copy of the MESSAGE request. A "bcc"
value indicates that the resource receives a blind carbon copy of the
MESSAGE request. The default 'capacity' value is "bcc", that is, the
absence of a 'capacity' attribute MUST be treated as if the
'capacity' was set to "bcc".
The 'capacity' attribute SHOULD be included as a modifier of any of
the child elements included in the <list> element of a resource list
(e.g., an attribute of the <entry> or <external> elements).
Figure 1 in Section 4.1.1 describes the format of the 'capacity'
attribute. Implementations according to this specification MUST
support this XML Schema.
4.1.1. XML Schema
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:capacity"
xmlns="urn:ietf:params:xml:ns:capacity"
xmlns:rls="urn:ietf:params:xml:ns:resource-lists"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:annotation>
<xs:documentation xml:lang="en">
Adds the capacity attribute to URIs included
in a resource list.
</xs:documentation>
</xs:annotation>
<xs:attribute name="capacity">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="to"/>
<xs:enumeration value="cc"/>
<xs:enumeration value="bcc"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:schema>
Figure 1: XML Schema of the Capacity Attribute Extension
4.2. URI-list example
Figure 2 shows an example of a flat list that follows the resource
list data format. Each resource indicates the capacity of a
resource.
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:cp="urn:ietf:params:xml:ns:capacity">
<list>
<entry uri="sip:bill@example.com" cp:capacity="to" />
<entry uri="sip:joe@example.org" cp:capacity="cc" />
<entry uri="sip:ted@example.net" cp:capacity="bcc" />
</list>
</resource-lists>
Figure 2: URI-List
5. Option-tag 5. Option-tag
This document defines the 'recipient-list-message' option-tag for use This document defines the 'recipient-list-message' option-tag for use
in the Require and Supported SIP header fields. in the Require and Supported SIP header fields.
User agent clients generating a MESSAGE with a recipient-list body, This option-tag is used to ensure that a server can process the
as described in previous sections, MUST include this option-tag in a 'recipient-list' body used in a MESSAGE request. It also provides
Require header field. User agents that are able to receive and a mechanism to discover the capability of the server in responses
process MESSAGEs with a recipient-list body, as described in previous to OPTIONS requests.
UACs generating MESSAGE request that carry recipient-list bodies, as
described in previous sections, MUST include this option-tag in a
Require header field. UAs 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 sections, SHOULD include this option-tag in a Supported header field
when responding to OPTIONS requests. when responding to OPTIONS requests.
6. Procedures at the User Agent Client 6. Procedures at the User Agent Client
A UAC that wants to create a multiple-recipient MESSAGE request A UAC that wants to create a multiple-recipient MESSAGE request
creates a MESSAGE request that MUST be formatted according to RFC creates a MESSAGE request that MUST be formatted according to RFC
3428 [8] Section 4. The UAC populates the Request-URI with the SIP 3428 [8] Section 4. The UAC populates the Request-URI with the SIP
or SIPS URI of the MESSAGE URI-list service. In addition to the or SIPS URI of the MESSAGE URI-list service. In addition to the
regular instant message body, the UAC adds a URI-list body whose regular instant message body, the UAC adds a URI-list body whose
Content-Disposition type is 'recipient-list', specified in the Content-Disposition type is 'recipient-list', specified in the
Framework and Security Considerations for SIP URI-list Services [12]. Framework and Security Considerations for SIP URI-list Services [11].
This body contains a URI-list with the recipients of the MESSAGE. This body contains a URI-list with the recipients of the MESSAGE.
The URI-list body MAY also include the 'capacity' extension to the Target URIs in this body MAY also be tagged with the 'capacity' and
URI-list specified in Section 4.1. The UAC MUST also include the 'anonymize' attributes specified in the XML Format Extension for
'recipient-list-message' option-tag, defined in Section 5, in a Representing Capacity Attributes in Resource Lists [12]. The UAC
Require header field. 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 [10]).
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
particular header field with a particular value, even if the header particular header field with a particular value, even if the header
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 [5] to encode extra information in any URI in the list. of RFC 3261 [5] 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 [5]) to encode a body, since the body is present 19.1.1 of RFC 3261 [5]) to encode a body, since the body is present
skipping to change at page 9, line 17 skipping to change at page 7, line 41
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"
7. 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, the MESSAGE URI-
service answer to the UAC with a 202 Accepted response. Note that list service answers to the UAC with a 202 (Accepted) response. Note
the status code in the response to the MESSAGE does not provide any that the status code in the response to the MESSAGE does not provide
information about whether or not the MESSAGEs generated by the URI- any information about whether or not the MESSAGEs generated by the
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) response means that the MESSAGE URI-list
received the MESSAGE and that it will try to send a similar MESSAGE service has received the MESSAGE and that it will try to send a
to the URIs in the list. Designing a mechanism to inform a client similar MESSAGE to the URIs in the list. Designing a mechanism to
about the delivery status of an instant message is outside the scope inform a client about the delivery status of an instant message is
of this document. outside the scope of this document.
7.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 determines the list of intended recipients by inspecting the service determines the list of intended recipients by inspecting the
URI-list contained in the body. In case two of those URIs are URI-list contained in the body. In case two of those URIs are
equivalent (section 19.1.4 of RFC 3261 [5] defines equivalent URIs), equivalent (section 19.1.4 of RFC 3261 [5] defines equivalent URIs),
the MESSAGE URI-list SHOULD consider a single intended recipient the MESSAGE URI-list SHOULD consider a single intended recipient
rather than sending multiple copies of the MESSAGE to the same rather than sending multiple copies of the MESSAGE to the same
destination. destination.
skipping to change at page 10, line 15 skipping to change at page 8, line 37
Failing to copy the From header field of the sender would Failing to copy the From header field of the sender would
prevent the recipient to get a hint of the sender's identity. prevent the recipient to get a hint of the sender's identity.
Note also that this requirement does not intend to contradict Note also that this requirement does not intend to contradict
requirements for additional services running on the same requirements for additional services running on the same
physical node. Specifically, a privacy service (see RFC 3323 physical node. Specifically, a privacy service (see RFC 3323
[6]) can be co-located with the MESSAGE URI-list service, in [6]) can be co-located with the MESSAGE URI-list service, in
which case, the privacy service has precedence over the MESSAGE which case, the privacy service has precedence over the MESSAGE
URI-list service. URI-list service.
o A MESSAGE URI-list service SHOULD generate a new To header field o A MESSAGE URI-list service SHOULD generate a new To header field
value set to the intended recipient's URI. According to the value set to the intended recipient's URI. According to the
procedures of RFC 3261 Section 8.1.1.1, this value should also be procedures of RFC 3261 [5] Section 8.1.1.1, this value should also
equal to the Request-URI of the outgoing MESSAGE request. be equal to the Request-URI of the outgoing MESSAGE request.
The MESSAGE URI-list service behaves as a User Agent Client, The MESSAGE URI-list service behaves as a User Agent Client,
thus, the To header field should be populated with the thus, the To header field should be populated with the
recipient's URI. recipient's URI.
o A MESSAGE URI-list service SHOULD create a new Call-ID header o A MESSAGE URI-list service SHOULD create a new Call-ID header
field value. field value.
A Call-ID header field might contain addressing information A Call-ID header field might contain addressing information
that the sender wants to remain private. Since there is no that the sender wants to remain private. Since there is no
need to keep the same Call-ID on both sides of the MESSAGE URI- need to keep the same Call-ID on both sides of the MESSAGE URI-
list service, and since the MESSAGE URI-list service behaves as list service, and since the MESSAGE URI-list service behaves as
a User Agent Client, it is recommended to create a new Call-ID a User Agent Client, it is recommended to create a new Call-ID
skipping to change at page 10, line 41 skipping to change at page 9, line 14
outgoing MESSAGE request is also trusted, a MESSAGE URI-list outgoing MESSAGE request is also trusted, a MESSAGE URI-list
service MUST include a P-Asserted-Identity header field in the service MUST include a P-Asserted-Identity header field in the
outgoing MESSAGE request with the same received value. However, outgoing MESSAGE request with the same received value. However,
if the first hop of the outgoing MESSAGE request is not trusted if the first hop of the outgoing MESSAGE request is not trusted
and the incoming MESSAGE request included a Privacy header field and the incoming MESSAGE request included a Privacy header field
with a value different than 'none', the MESSAGE URI-list service with a value different than 'none', the MESSAGE URI-list service
MUST NOT include a P-Asserted-Identity header field in the MUST NOT include a P-Asserted-Identity header field in the
outgoing MESSAGE request. outgoing MESSAGE request.
o If a MESSAGE URI-list service is able to assert the identity of a o If a MESSAGE URI-list service is able to assert the identity of a
user (e.g., using HTTP Digest authentication scheme [3], S/MIME user (e.g., using HTTP Digest authentication scheme [3], S/MIME
[11], etc.) and the service implements a mechanism where it can [10], etc.) and the service implements a mechanism where it can
map that authentication scheme to a user's SIP or SIPS URI, and map that authentication scheme to a user's SIP or SIPS URI, and
subject to the privacy requirements expressed in the incoming subject to the privacy requirements expressed in the incoming
MESSAGE request (see RFC 3323 [6], the MESSAGE URI-list MAY insert MESSAGE request (see RFC 3323 [6], the MESSAGE URI-list MAY insert
a P-Asserted-Identity header with the value of the user's asserted a P-Asserted-Identity header with the value of the user's asserted
URI. URI.
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
skipping to change at page 11, line 19 skipping to change at page 9, line 41
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 [5] and encoded in the intended recipient URI of the URI- RFC 3261 [5] and encoded in the intended recipient URI of the 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.
o If the URI-list of the incoming MESSAGE request includes resources
tagged with the 'capacity' attribute set with a value of "to" or
"cc", the URI-list service SHOULD include a URI-list in each of
the outgoing MESSAGE requests.
7.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 [10]) 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
recipient of the outgoing MESSAGE request (which will not be able recipient of the outgoing MESSAGE request (which will not be able
to decrypt them). Therefore, a MESSAGE URI-list service MUST NOT to decrypt them). Therefore, a MESSAGE URI-list service MUST NOT
copy any security body (such as an S/MIME [11] encrypted body) copy any security body (such as an S/MIME [10] encrypted body)
addressed to the MESSAGE URI-list service to the outgoing MESSAGE addressed to the MESSAGE URI-list service to the outgoing MESSAGE
request. This includes bodies encrypted with the public key of request. This includes bodies encrypted with the public key of
the URI-list service. the URI-list service.
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 7.2 reference [11] with the actual list of recipients. If this URI-
contains procedures that determine when the MESSAGE URI-list list includes resources tagged with the 'capacity' attribute set
service should include a URI-list body in the outgoing MESSAGE to a value of "to" or "cc", the URI-list service SHOULD include a
request. URI-list in each of the outgoing MESSAGE requests. This list
o If the MESSAGE URI-list service includes a URI-list in an outgoing SHOULD be formatted according to the XML format for representing
MESSAGE request, then the list SHOULD be formatted according to resource lists [9] and the capacity extension specified in [12].
the XML format for representing resource lists [10] and the The URI-list service MUST follow the procedures specified in XML
capacity extension specified in Section 4.1. This resource list format for representing resource lists [12] with respect handling
MUST contain those elements categorized with the "to" or "cc" of the 'anonymize', 'count' and 'capacity' attributes.
capacity attribute and MUST NOT contain those resources
categorized with the "bcc" or lacking the capacity attribute (the
default value for the capacity of resources without a capacity
attribute is "bcc").
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 [4] set to "optional". 'handling' parameter [4] 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 [10] to encrypt the URI-list
with the public key of the receiver. with the public key of the receiver.
o The MESSAGE URI-list service SHOULD copy all the rest of the o The MESSAGE URI-list service SHOULD copy all the remaining message
message bodies (e.g., text messages, images, etc.) to the outgoing bodies (e.g., text messages, images, etc.) of the incoming MESSAGE
MESSAGE request. request to the outgoing 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.
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 [5]. In particular, "Forming Requests from a URI" of RFC 3261 [5]. In particular,
Section 19.1.5 of RFC 3261 [5] states: Section 19.1.5 of RFC 3261 [5] 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 XML 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.
8. 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 [8] Section 7. specified in RFC 3428 [8] 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 recipients of the MESSAGE request. This
This allows the user to create a reply request (e.g., MESSAGE, allows the user to create a reply request (e.g., MESSAGE, INVITE) to
INVITE) to the sender and the rest of the visible recipients. the sender and the rest of the recipients included in the URI-list.
9. Examples 9. Examples
Figure 3 shows an example of operation. A SIP UAC issuer sends a Figure 1 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) response and sends a MESSAGE request to each of the
recipients. intended 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 | | n |
+--------+ +---------+ +--------+ +--------+ +--------+ +--------+ +---------+ +--------+ +--------+ +--------+
| | | | | | | | | |
| F1. MESSAGE | | | | | F1. MESSAGE | | | |
| ---------------->| | | | | ---------------->| | | |
| F2. 202 Accepted | | | | | F2. 202 Accepted | | | |
|<---------------- | F3. MESSAGE | | | |<---------------- | F3. MESSAGE | | |
| | ------------->| | | | | ------------->| | |
| | F4. MESSAGE | | | | | F4. MESSAGE | | |
| | ------------------------>| | | | ------------------------>| |
| | F5. MESSAGE | | | | | F5. MESSAGE | | |
skipping to change at page 13, line 37 skipping to change at page 11, line 50
| | F6. 200 OK | | | | | F6. 200 OK | | |
| |<------------- | | | | |<------------- | | |
| | F7. 200 OK | | | | | F7. 200 OK | | |
| |<------------------------ | | | |<------------------------ | |
| | F8. 200 OK | | | | | F8. 200 OK | | |
| |<----------------------------------- | | |<----------------------------------- |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
Figure 3: Example of operation Figure 1: Example of operation
The MESSAGE request F1 (shown in Figure 2) contains a multipart/mixed
The MESSAGE request F1 is as follows: body that is composed of two bodies: a text/plain body containing the
instant message payload and an application/resource-lists+xml body
containing the list of recipients.
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: Alice <sip:alice@example.com>;tag=32331
Call-ID: d432fa84b4c76e66710 Call-ID: d432fa84b4c76e66710
CSeq: 1 MESSAGE CSeq: 1 MESSAGE
Require: recipient-list-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">
<list> <list>
<entry uri="sip:bill@example.com" cp:capacity="to" /> <entry uri="sip:bill@example.com" cp:capacity="to" />
<entry uri="sip:randy@example.net" cp:capacity="to"
cp:anonymize="true"/>
<entry uri="sip:eddy@example.com" cp:capacity="to"
cp:anonymize="true"/>
<entry uri="sip:joe@example.org" cp:capacity="cc" /> <entry uri="sip:joe@example.org" cp:capacity="cc" />
<entry uri="sip:carol@example.net" cp:capacity="cc"
cp:anonymize="true"/>
<entry uri="sip:ted@example.net" cp:capacity="bcc" /> <entry uri="sip:ted@example.net" cp:capacity="bcc" />
<entry uri="sip:andy@example.com" cp:capacity="bcc" />
</list> </list>
</resource-lists> </resource-lists>
--boundary1-- --boundary1--
Messages F3, F4 and F5 are similar in nature. Especially the bodies Figure 2: MESSAGE request received at the MESSAGE URI-list server
are exactly the same for all of them, since they include the instant
message payload and a URI-list that contains the resources tagged The MESSAGE requests F3, F4 and F5 are similar in nature. All those
with the "to" and "cc" capacity attribute. We show an example of F3: MESSAGE requests contain a multipart/mixed body which is composed of
two other bodies: a text/plain body containing the instant message
payload and an application/resource-lists+xml containing the list of
recipients. Unlike the text/plain body the application/
resource-lists+xml body is not equal to the application/
resource-lists+xml included in the incoming MESSAGE request F1,
because the URI-list service has anonymized those URIs tagged with
the 'anonymize' attribute and has removed those URIs tagged with a
"bcc" 'capacity' attribute. Figure 3 shows an examples of the
message 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: Alice <sip:alice@example.com>;tag=210342
Call-ID: 39s02sdsl20d9sj2l Call-ID: 39s02sdsl20d9sj2l
CSeq: 1 MESSAGE CSeq: 1 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-history; handling=optional Content-Disposition: recipient-list-history; handling=optional
<?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">
<list> <list>
<entry uri="sip:bill@example.com" cp:capacity="to" /> <entry uri="sip:bill@example.com" cp:capacity="to" />
<entry uri="sip:anonymous@anonymous.invalid" cp:capacity="to"
cp:count="2"/>
<entry uri="sip:joe@example.org" cp:capacity="cc" /> <entry uri="sip:joe@example.org" cp:capacity="cc" />
<entry uri="sip:anonymous@anonymous.invalid" cp:capacity="cc"
cp:count="1"/>
</list> </list>
</resource-lists> </resource-lists>
--boundary1-- --boundary1--
Figure 3: MESSAGE request sent by the MESSAGE URI-list server
10. Security Considerations 10. Security Considerations
The Framework and Security Considerations for SIP URI-List Services The Framework and Security Considerations for SIP URI-List Services
[12] discusses issues related to SIP URI-list services. [11] discusses issues related to SIP URI-list services.
Implementations of MESSAGE URI-list services MUST follow the Implementations of MESSAGE URI-list services MUST follow the
security-related rules in the Framework and Security Considerations security-related rules in the Framework and Security Considerations
for SIP URI-List Services [12]. These rules include mandatory for SIP URI-List Services [11]. These rules include mandatory
authentication and authorization of clients, and opt-in lists. authentication and authorization of clients, and opt-in lists.
If the contents of the instant message needs to be kept private, the 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 user agent client SHOULD use S/MIME [10] to prevent a third party
from viewing this information. In this case, the user agent client from viewing this information. In this case, the user agent client
SHOULD encrypt the instant message body with a content encryption SHOULD encrypt the instant message body with a content encryption
key. Then, for each receiver in the list, the UAC SHOULD encrypt the key. Then, for each receiver in the list, the UAC SHOULD encrypt the
content encryption key with the public key of the receiver, and content encryption key with the public key of the receiver, and
attach it to the MESSAGE request. attach it to the MESSAGE request.
11. IANA Considerations 11. IANA Considerations
The following sections instruct the IANA to register a new This document defines the 'recipient-list-message' SIP option-tag in
disposition type and a new SIP option-tag. Section 5. IANA should register this option-tag in the Option Tags
subregistry under the IANA registry of SIP parameters, with the
11.1. Disposition Type Registration
Section 4 defines a new 'recipient-list-history' value of the Mail
Content Disposition Values registry. This value should be registered
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-message | The body contains a list of | [RFCXXXX] |
| | URIs that indicates the | | | | URIs that indicates the | |
| | recipients of the message | | | | recipients of the SIP | |
| | MESSAGE request | |
+------------------------+------------------------------+-----------+ +------------------------+------------------------------+-----------+
Table 1: Registration of the 'recipient-list-history' Mail Content Table 1: Registration of the 'recipient-list-message' Option-Tag in
Disposition Value SIP
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.
11.2. Option-Tag Registration
This document defines the 'recipient-list-message' SIP option-tag in
Section 5. It should be registered in the Option Tags subregistry
under the SIP parameter registry. The following is the description
to be used in the registration.
This option-tag is used to ensure that a server can process the
'recipient-list' body used in a MESSAGE request.
11.3. URN Sub-Namespace Registration
This section registers a new XML namespace, as per the guidelines in
RFC 3688 [9].
11.3.1. urn:ietf:params:xml:ns:capacity
URI: The URI for this namespace is urn:ietf:params:xml:ns:capacity.
Registrant Contact: IETF, SIPPING working group, (sipping@ietf.org),
Miguel Garcia-Martin (miguel.an.garcia@nokia.com).
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Capacity Namespace</title>
</head>
<body>
<h1>Namespace for the Capacity Atttribute Extension
in Resource Lists</h1>
<h2>urn:ietf:params:xml:ns:capacity</h2>
<p>See <a href="[URL of published RFC]">RFCXXXX
[NOTE TO IANA/RFC-EDITOR: Please replace XXXX with
the RFC number of this specification.]</a>.</p>
</body>
</html>
END
11.4. Schema Registration
This section registers a new XML schema per the procedures in RFC
3688 [9].
11.4.1. urn:ietf:params:xml:schema:capacity
URI: urn:ietf:params:xml:schema:capacity
Registrant Contact: IETF, SIPPING working group, (sipping@ietf.org),
Miguel Garcia-Martin (miguel.an.garcia@nokia.com).
The XML for this schema can be found as the sole content of
Section 4.1.1.
12. 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, Jonathan Rosenberg, and Dean Campbell, Paul Kyzivat, Cullen Jennings, Jonathan Rosenberg, and Dean
Willis provided helpful comments. Willis provided helpful comments.
13. References 13. References
13.1. Normative References 13.1. Normative References
skipping to change at page 18, line 39 skipping to change at page 15, line 39
Protocol (SIP)", RFC 3323, November 2002. Protocol (SIP)", RFC 3323, November 2002.
[7] Jennings, C., Peterson, J., and M. Watson, "Private Extensions [7] 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.
[8] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and [8] 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.
[9] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [9] Rosenberg, J., "Extensible Markup Language (XML) Formats for
January 2004.
[10] Rosenberg, J., "Extensible Markup Language (XML) Formats for
Representing Resource Lists", Representing Resource Lists",
draft-ietf-simple-xcap-list-usage-05 (work in progress), draft-ietf-simple-xcap-list-usage-05 (work in progress),
February 2005. February 2005.
[11] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions [10] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", RFC 3851, (S/MIME) Version 3.1 Message Specification", RFC 3851,
July 2004. July 2004.
[12] Camarillo, G. and A. Roach, "Framework and Security [11] Camarillo, G. and A. Roach, "Framework and Security
Considerations for Session Initiation Protocol (SIP) Uniform Considerations for Session Initiation Protocol (SIP) Uniform
Resource Identifier (URI)-List Services", Resource Identifier (URI)-List Services",
draft-ietf-sipping-uri-services-04 (work in progress), draft-ietf-sipping-uri-services-04 (work in progress),
October 2005. October 2005.
[12] Garcia-Martin, M. and G. Camarillo, "Extensible Markup Language
(XML) Format Extension for Representing Capacity Attributes in
Resource Lists", draft-ietf-sipping-capacity-attribute-00 (work
in progress), February 2006.
13.2. Informational References 13.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.
Authors' Addresses Authors' Addresses
Miguel A. Garcia-Martin Miguel A. Garcia-Martin
 End of changes. 57 change blocks. 
323 lines changed or deleted 200 lines changed or added

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