draft-ietf-sipping-uri-list-message-00.txt   draft-ietf-sipping-uri-list-message-01.txt 
SIPPING Working Group M. Garcia-Martin SIPPING Working Group M. Garcia-Martin
Internet-Draft Nokia Internet-Draft Nokia
Expires: January 5, 2005 G. Camarillo Expires: April 14, 2005 G. Camarillo
Ericsson Ericsson
July 7, 2004 October 14, 2004
Multiple-Recipient MESSAGE Requests in the Session Initiation Multiple-Recipient MESSAGE Requests in the Session Initiation
Protocol (SIP) Protocol (SIP)
draft-ietf-sipping-uri-list-message-00.txt draft-ietf-sipping-uri-list-message-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable This document is an Internet-Draft and is subject to all provisions
patent or other IPR claims of which I am aware have been disclosed, of section 3 of RFC 3667. By submitting this Internet-Draft, each
and any of which I become aware will be disclosed, in accordance with author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668. 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 other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as
Internet-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 http:// The list of current Internet-Drafts can be accessed at
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 January 5, 2005. This Internet-Draft will expire on April 14, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004).
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 URI-list service, which sends MESSAGE request with a URI-list to the URI-list service, which sends
a similar MESSAGE request to each of the URIs included in the list. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Procedures at the UAC . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Procedures at the MESSAGE URI-List Service . . . . . . . . . . 5 4. URI-List document . . . . . . . . . . . . . . . . . . . . . 4
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1 Extension to the resource lists data format . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 4.2 URI-list example . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 5. Procedures at the User Agent Client . . . . . . . . . . . . 7
8. Change control . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Procedures at the MESSAGE URI-List Service . . . . . . . . . 8
8.1 Changes from draft--sipping-message-exploder-00.txt to 6.1 Determining the intended recipient . . . . . . . . . . . . 8
draft-ietf-sipping-uri-list-message-00.txt . . . . . . . . 8 6.2 Creating an outgoing MESSAGE request . . . . . . . . . . . 8
8.2 Changes from 6.3 Composing bodies in the outgoing MESSAGE request . . . . . 9
7. Procedures at the UAS . . . . . . . . . . . . . . . . . . . 11
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
11. Change control . . . . . . . . . . . . . . . . . . . . . . . 15
11.1 Changes from
draft-ietf-sipping-uri-list-message-00.txt . . . . . . . 15
11.2 Changes from
draft-ietf-sipping-message-exploder-00.txt to
draft-ietf-sipping-uri-list-message-00.txt . . . . . . . 15
11.3 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 . . . . . . . 9 draft-garcia-sipping-message-exploder-00.txt . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 9 12.1 Normative References . . . . . . . . . . . . . . . . . . . 16
9.2 Informational References . . . . . . . . . . . . . . . . . . 10 12.2 Informational References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . 18
1. Introduction 1. Introduction
SIP [2] can carry instant messages in MESSAGE [3] requests. The SIP [4] can carry instant messages in MESSAGE [7] requests. The
Advanced Instant Messaging Requirements for SIP [8] mentions the need Advanced Instant Messaging Requirements for SIP [11] mentions the
for sending a MESSAGE request to multiple receipients: 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."
To meet this requirement, we allow SIP MESSAGE requests carry One possibility to fulfill the above requirement is to establish a
URI-lists in "uri-list" body parts, as specified in [4]. A SIP session of instant messages with an instant messaging conference
URI-list service, which is a specialized application server, receives server. While this option seems to be reasonable in many cases, in
the request and sends a similar MESSAGE request to each of the URIs other situations the sending user just want to send a small
in the list. Each of these MESSAGE requests contains a copy of the pager-mode instant message to an ad-hoc group, without entering the
body included in the original MESSAGE request. burden of setting up a session. This document focuses on sending a
pager-mode instant message to a number of intended recipients.
The UAC (User Agent Client) needs to be configured with the SIP URI To meet the requirement with a pager-mode instant message, we allow
of the application server that provides the functionality. SIP MESSAGE requests carry URI-lists in 'recipient-list- body parts,
Discovering and provisioning of this URI to the UAC is outside the as specified in the framework for URI-list services [10]. A SIP
scope of this document. URI-list service, which is a specialized application service,
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
of the body included in the original MESSAGE request.
The UAC (User Agent Client) that sends a MESSAGE request to a URI
list service needs to be configured with the SIP URI of the service
that provides the functionality. Discovering and provisioning of
this URI to the UAC is outside the scope of this 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
described in BCP 14, RFC 2119 [1] and indicate requirement levels for described in BCP 14, RFC 2119 [1] and indicate requirement levels for
compliant implementations. compliant implementations.
'MESSAGE URI-list service': SIP application server that receives a MESSAGE URI-list service: SIP application service that receives a
MESSAGE request with a URI-list and sends a similar MESSAGE request MESSAGE request with a URI-list and sends a similar MESSAGE
to each URI in the list. MESSAGE URI-list services behave effectively request to each URI in the list. In this context, similar
as specialised B2BUAs (Back-To-Back-User-Agents). A MESSAGE URI-list indicates that some SIP header fields can change, but the MESSAGE
service can also offer URI-list services for other methods, although URI-list service will not change the instant message payload.
this functionality is outside the scope of this document. In this MESSAGE URI-list services behave effectively as specialised B2BUAs
document we only discuss MESSAGE URI-list services. (Back-To-Back-User-Agents). A server providing MESSAGE URI-list
services can also offer URI-list services for other methods,
although this functionality is outside the scope of this document.
'Incoming MESSAGE request': A SIP MESSAGE request that a UAC creates In this document we only discuss MESSAGE URI-list services.
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-list service creates and addresses to a UAS (User Agent Server). URI-list service creates and addresses to a UAS (User Agent
It contains the regular instant message payload. Server). It contains the regular instant message payload.
3. Procedures at the UAC Intended recipient: The intended final recipient of the request to be
generated by MESSAGE URI-list service.
A client that wants to create a multiple-recipient MESSAGE request 3. Overview
adds a body part, whose disposition type is "uri-list", which
contains a URI-list with the recipients of the MESSAGE.
Multiple-recipient MESSAGE requests typically contain a multipart A UAC creates a MESSAGE request that contains a multipart body
body that contains the body carrying the list and the actual instant including a list of URIs (intended recipients) and an instant
message payload. In some cases, the MESSAGE request may contain message. The UAC sends this MESSAGE request to the MESSAGE URI-List
bodies other than the text and the list bodies (e.g., when the service. On reception of this incoming MESSAGE request, the MESSAGE
request is protected with S/MIME [6]). URI-list service creates a MESSAGE request per intended recipient
(listed in the URI list) and copies the instant message payload to
each of those MESSAGES. Then the MESSAGE URI-list service sends each
of the created outgoing MESSAGE request to the respective receiver.
The mechanism reuses the XML format for representing resource lists
[8] to include the list of intended recipients. We define an
extension to that list to indicate the capacity of each resource,
which can be To, Cc or Bcc (in an analogy to e-mail). The MESSAGE
URI list service can include a resource list in the outgoing MESSAGE
request that contain those resources tagged with a To or Cc
capacities (and 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
As described in the framework for URI-list services [10],
specifications of individual URI-list services, like the MESSAGE
URI-list service described here, need to specify a default format for
'recipient-list' bodies used within the particular service.
The default format for recipient-list bodies for MESSAGE URI-list
services is the resource list document format [8] . UAs (User
Agents) and servers handling recipient-list bodies MUST support this
format and MAY support other formats.
Nevertheless, the Extensible Markup Language (XML) Configuration
Access Protocol (XCAP) resource list document 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 and the 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.
Section 4.1 defines an extension to the XML format for representing
resource lists [8]. This extension allows to provide an 'capacity'
attribute to a resource. UAs (User Agents) and servers handling
'recipient-list' bodies MUST support that extension.
A MESSAGE URI-list service receiving a URI-list with more information
than what has just been described MAY discard all the extra
information.
4.1 Extension to the resource lists data format
An extension to indicate the capacity of a resource is included. We
define a new <capacity> element that can take the values "to", "cc"
and "bcc". A "to" value 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> element MUST be treated as if the capacity
was set to "bcc".
The <capacity> element SHOULD be included as a child element of any
of the elements included in the <list> element of a resource list.
Figure 1 describes the format of the capacity element.
Implementations according to this specification MUST support this 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 element to a resource list.
</xs:documentation>
</xs:annotation>
<xs:element 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:element>
</xs:schema>
Figure 1: Extension to the resource lists data format
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"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<list>
<entry uri="sip:bill@example.com">
<cp:capacity>to</cp:capacity>
</entry>
<entry uri="sip:joe@example.org">
<cp:capacity>cc</cp:capacity>
</entry>
<entry uri="sip:ted@example.net">
<cp:capacity>bcc</cp:capacity>
</entry>
</list>
</resource-lists>
Figure 2: URI-List
5. Procedures at the User Agent Client
A UAC that wants to create a multiple-recipient MESSAGE request MUST
create a MESSAGE request according to RFC 3428 [7] Section 4. The
UAC SHOULD add a body part, whose Content-Disposition type is
"recipient-list", which contains a URI-list with the recipients of
the MESSAGE. The URI-list MAY also include the "capacity" extension
to the URI-list specified in Section 4.1.
Multiple-recipient MESSAGE requests contain a multipart body that
contains the body carrying the list and the actual instant message
payload. In some cases, the MESSAGE request may contain bodies other
than the text and the list bodies (e.g., when the request is
protected with S/MIME [9]).
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 [2] to encode extra information in any URI in the list. of RFC 3261 [4] 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 [2]) to encode a body, since the body is present 19.1.1 of RFC 3261 [4]) 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"
As described in [4], the default format for URI-lists in SIP is the 6. Procedures at the MESSAGE URI-List Service
XCAP resource list format [5]. Still, specific services need to
describe which information clients should include in their URI lists,
as described in [4]
UAs generating multiple recipient MESSAGEs SHOULD use flat lists
(i.e., no hierarchical lists), SHOULD NOT use any entry's attributes
but "uri", and SHOULD NOT include any elements inside entries but
"display-name" elements.
A MESSAGE URI-list service receiving a URI-list with more information
than what we have just described SHOULD discard all the extra
information.
4. 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
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 create as many new MESSAGE requests as URIs the list service SHOULD determine the list of intended recipients, by
contains, except when two of those URIs are equivalent (section inspecting the URI list contained in the body. In case two of those
19.1.4 of RFC 3261 [2] defines equivalent URIs), in which case the URIs are equivalent (section 19.1.4 of RFC 3261 [4] defines
MESSAGE URI-list service SHOULD create only one outgoing MESSAGE equivalent URIs), the MESSAGE URI-list SHOULD consider a single
request per URI. intended recipient.
6.2 Creating an outgoing MESSAGE request
Since the MESSAGE URI-list behaves as a UAC for outgoing MESSAGE
requests, for each of the intended recipients, the MESSAGE URI-list
service creates a new MESSAGE request according to the procedures
described in Section 4 of RFC 3428 [7] and the following procedures:
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
incoming MESSAGE request, subject to the privacy requirements (see
RFC 3323 [5] and RFC 3325 [6]) expressed in the incoming MESSAGE
request. Note that this does not apply to the "tag" parameter.
o A MESSAGE URI-list service SHOULD generate a new To header field
value set to the intended recipient URI. According to the
procedures of RFC 3261 Section 8.1.1.1, this value should also be
equal to the Request-URI of the outgoing MESSAGE request
o A MESSAGE URI-list service SHOULD create a new Call-ID header
field value.
o If a P-Asserted-Identity header field was present in the incoming
MESSAGE request and the request was received from a trusted
source, as specified in RFC 3325 [6], and the first hop of the
outgoing MESSAGE request is also trusted, a MESSAGE URI-list
service MUST include a P-Asserted-Identity header field in the
outgoing MESSAGE request with the same received value. However,
if the first hop of the outgoing MESSAGE request is not trusted
and the incoming MESSAGE request included a Privacy header field
with a value different than 'none', the MESSAGE URI-list service
MUST NOT include a P-Asserted-Identity header field in the
outgoing MESSAGE request.
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
[9], etc.) and the service implements a mechanism where it can map
that authentication scheme to a user's SIP or SIPS URI, and
subject to the privacy requirements expressed in the incoming
MESSAGE request (see RFC 3323 [5], the MESSAGE URI list MAY insert
a P-Asserted-Identity header with the value of the user's asserted
URI.
o If the incoming MESSAGE request contains an Authorization or
Proxy-Authorization header fields whose realm is set to the
MESSAGE URI-List server's realm, then the MESSAGE URI-List service
SHOULD NOT copy it to the outgoing MESSAGE request; otherwise
(i.e., if the Authorization or Proxy-Authorization header field of
incoming MESSAGE request contains a different realm), the MESSAGE
URI-List service MUST copy the value to the respective header
field of the outgoing MESSAGE request.
o A MESSAGE URI-List service SHOULD create a separate count for the
CSeq header field of the outgoing MESSAGE request.
o A MESSAGE URI-list service SHOULD initialize the value of the
Max-Forward header field of the outgoing MESSAGE request.
o A MESSAGE URI-list service MUST include its own value in the Via
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
RFC 3261 [4] and encoded in the intended recipient URI of the URI
list.
o A MESSAGE URI-List service SHOULD preserve to the outgoing MESSAGE
request any other header field not explicitly indicated in the
above paragraphs.
6.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 The incoming MESSAGE request typically contains a URI-list body
[4] with the actual list of recipients. The MESSAGE URI-list
service need not copy the URI-list body to each of the outgoing
MESSAGE requests, although it MAY do it.
NOTE: This document does not provide any semantics associated to a
URI-list body included in an outgoing MESSAGE request. Future
extensions may indicate actions at a UAS when it receives that
body.
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 encrypted with the public key contain one or more security bodies (e.g., S/MIME [9]) encrypted
of the MESSAGE URI-list service. These bodies are deemed to be with the public key of the MESSAGE URI-list service. These bodies
read by the URI-list service rather than the recipient of the are deemed to be read by the URI-list service rather than the
outgoing MESSAGE request (which will not be able to decrypt them). recipient of the outgoing MESSAGE request (which will not be able
Therefore, a MESSAGE URI-list service MUST NOT copy any security to decrypt them). Therefore, a MESSAGE URI-list service MUST NOT
body (such as an S/MIME encrypted body) addressed to the MESSAGE copy any security body (such as an S/MIME [9] encrypted body)
URI-list service to the outgoing MESSAGE request. This includes addressed to the MESSAGE URI-list service to the outgoing MESSAGE
bodies encrypted with the public key of the URI-list service. request. This includes bodies encrypted with the public key of
o An exception to this rule is the URI-list itself: as mentioned in the URI-list service.
Section 4, a MESSAGE URI-list service need not, but MAY, copy the o If the URI-list of the incoming MESSAGE request include resources
URI-list into each of the outgoing MESSAGE requests; on doing so, tagged with the <capacity> value of "to" or "cc", the URI-list
a MESSAGE URI-list service SHOULD use S/MIME [6] to encrypt the service SHOULD include a URI-list in each of the outgoing MESSAGE
URI-list with the public key of the receiver. requests. The format of such list SHOULD BE according to the XML
format for representing resource lists [8] and the capacity
extension specified in Section 4.1. This resource list MUST
contain those elements categorized with the "to" or "cc" capacity
and MUST NOT contain those resources categorized are "bcc" or
lacking the capacity element.
o If a MESSAGE URI-list service includes a URI-list in an outgoing
MESSAGE request, it SHOULD use S/MIME [9] to encrypt the URI-list
with the public key of the receiver.
o The incoming MESSAGE request typically contains a URI-list body or
reference [10] with the actual list of recipients. Section 6.2
contains procedures that determine when the MESSAGE URI-list
service should include a URI-list body in the outgoing MESSAGE
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.
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
list MUST be created following the rules in Section 19.1.5 "Forming list MUST be created following the rules in Section 19.1.5 "Forming
Requests from a URI" of RFC 3261 [2]. In particular, Section 19.1.5 Requests from a URI" of RFC 3261 [4]. In particular, Section 19.1.5
of RFC 3261 [2] states: of RFC 3261 [4] 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.
It is RECOMMENDED that the MESSAGE URI-list service copies the From 7. Procedures at the UAS
header field of the incoming MESSAGE into the outgoing MESSAGE
requests (note that this does not apply to the "tag" parameter). The
MESSAGE URI-list service SHOULD also copy into the outgoing MESSAGE
request any P-Asserted-Identity header fields present in the incoming
MESSAGE request.
For each given outgoing MESSAGE request, the MESSAGE URI-list service A UAS (in this specification, also known as intended recipient UAS)
SHOULD generate a new To header field value which, according to the that receives a MESSAGE request from the URI-list service behaves as
procedures of RFC 3261 Section 8.1.1.1, should be equal to the specified in RFC 3428 [7] Section 7.
Request-URI of the outgoing MESSAGE request.
For each given outgoing MESSAGE request, the MESSAGE URI-list service If the UAS supports this specification and the MESSAGE request
SHOULD initialize the values of the Call-ID, CSeq and Max-Forwards contains a body with a Content-Disposition header set to
header fields. The MESSAGE URI-list service should also include its 'recipient-list', then the UAS will be able to determine who are the
own value in the Via header field. other intended recipients (visible) of the MESSAGE request. This
allows the user to create a reply request (e.g., MESSAGE, INVITE) to
the sender and the rest of the visible recipients.
5. Examples 8. Examples
The following is an example of an incoming MESSAGE request which Figure 5 shows an example of operation. A SIP UAC issuer sends a
carries a URI list in its body. MESSAGE request. The MESSAGE URI-list service answers with a 202
Accepted message and sends a MESSAGE request to each of the intended
recipients.
+--------+ +---------+ +--------+ +--------+ +--------+
|SIP UAC | | MESSAGE | |intended| |intended| |intended|
| issuer | | URI-list| | recip. | | recip. | | recip. |
| | | service | | 1 | | 2 | | 3 |
+--------+ +---------+ +--------+ +--------+ +--------+
| | | | |
| F1. MESSAGE | | | |
| ---------------->| | | |
| F2. 202 Accepted | | | |
|<---------------- | F3. MESSAGE | | |
| | ------------->| | |
| | F4. MESSAGE | | |
| | ------------------------>| |
| | F5. MESSAGE | | |
| | ----------------------------------->|
| | F6. 200 OK | | |
| |<------------- | | |
| | F7. 200 OK | | |
| |<------------------------ | |
| | F8. 200 OK | | |
| |<----------------------------------- |
| | | | |
| | | | |
| | | | |
Figure 5: Example of operation
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
Content-Type: multipart/mixed;boundary="boundary1" Content-Type: multipart/mixed;boundary="boundary1"
Content-Length: 440 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: uri-list Content-Disposition: recipient-list
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:cp="urn:ietf:params:xml:ns:capacity"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<list> <list>
<entry uri="sip:bill@example.com" /> <entry uri="sip:bill@example.com">
<entry uri="sip:joe@example.org" /> <cp:capacity>to</cp:capacity>
<entry uri="sip:ted@example.net" /> </entry>
<entry uri="sip:joe@example.org">
<cp:capacity>cc</cp:capacity>
</entry>
<entry uri="sip:ted@example.net">
<cp:capacity>bcc</cp:capacity>
</entry>
</list> </list>
</resource-lists> </resource-lists>
--boundary1-- --boundary1--
Figure 3: Multiple recipient incoming MESSAGE request Messages F4, F4 and F5 are similar in nature. Especially the bodies
are exactly the same for all of them, since they include the instant
The following is an example of one of the outgoing MESSAGE requests message payload and a URI-list that contains the resources tagged
that the MESSAGE URI-list service creates. with the "to" and "cc " capacity. 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
Call-ID: 39s02sdsl20d9sj2l Call-ID: 39s02sdsl20d9sj2l
CSeq: 1 MESSAGE CSeq: 1 MESSAGE
Content-Type: multipart/mixed;boundary="boundary1"
Content-Length: 501
--boundary1
Content-Type: text/plain Content-Type: text/plain
Content-Length: 13
Hello World! Hello World!
Figure 4: Outgoing MESSAGE request --boundary1
Content-Type: application/resource-lists+xml
Content-Disposition: recipient-list
6. Security Considerations <?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"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<list>
<entry uri="sip:bill@example.com">
<cp:capacity>to</cp:capacity>
</entry>
<entry uri="sip:joe@example.org">
<cp:capacity>cc</cp:capacity>
</entry>
</list>
</resource-lists>
--boundary1--
The Security Considerations Section of the Requirements and Framework 9. Security Considerations
for SIP URI-List Services [7] discusses issues related to SIP
URI-list services. Implementations of MESSAGE URI-list services MUST The Framework and Security Considerations for SIP URI-List Services
follow the security-related rules in [7]. These rules include [10] discusses issues related to SIP URI-list services.
mandatory authentication and authorization of clients, and opt-in Implementations of MESSAGE URI-list services MUST follow the
lists. security-related rules in the framework for URI-list services [10].
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 If the contents of the instant message needs to be kept private, the
user agent client SHOULD use S/MIME [6] to prevent a third party from user agent client SHOULD use S/MIME [9] to prevent a third party from
viewing this information. In this case, the user agent client SHOULD viewing this information. In this case, the user agent client SHOULD
encrypt the instant message body with a content encryption key. Then, encrypt the instant message body with a content encryption key.
for each receiver in the list, the UAC SHOULD encrypt the content Then, for each receiver in the list, the UAC SHOULD encrypt the
encryption key with the public key of the receiver, and attach it to content encryption key with the public key of the receiver, and
the MESSAGE request. attach it to the MESSAGE request.
7. Acknowledgements 10. 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, and Cullen Jennings provided helpful Campbell, Paul Kyzivat, Cullen Jennings, and Jonathan Rosenberg
comments. provided helpful comments.
8. Change control 11. Change control
8.1 Changes from draft--sipping-message-exploder-00.txt to 11.1 Changes from draft-ietf-sipping-uri-list-message-00.txt
Revision of the treatment of headers the MESSAGE URI-list service, on
a header by header basis.
Added an overview section.
Added functionality that allows the sender of the incoming MESSAGE
request to tag each of the intended recipients with the "to", "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
MESSAGE request including those resources.
Procedures at the UAS included.
Better example including a flow.
11.2 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 exception has been encrypted with the public key of the exploder. The
is the URI list, which can be distributed by the exploder, providing exception is the URI-list, which can be distributed by the exploder,
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-list services (e.g., the term "exploder" has been deprecated). URI-list services (e.g., the term "exploder" has been deprecated).
8.2 Changes from draft-garcia-simple-message-exploder-00.txt to 11.3 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.
9. References 12. References
9.1 Normative References 12.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] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [2] Levinson, E., "Content-ID and Message-ID Uniform Resource
Locators", RFC 2392, August 1998.
[3] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication:
Basic and Digest Access Authentication", RFC 2617, June 1999.
[4] 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.
[3] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and D. [5] Peterson, J., "A Privacy Mechanism for the Session Initiation
Gurle, "Session Initiation Protocol (SIP) Extension for Instant Protocol (SIP)", RFC 3323, November 2002.
Messaging", RFC 3428, December 2002.
[4] Camarillo, G., "Providing a Session Initiation Protocol (SIP) [6] Jennings, C., Peterson, J. and M. Watson, "Private Extensions
Application Server with a List of URIs", to the Session Initiation Protocol (SIP) for Asserted Identity
draft-camarillo-sipping-uri-list-01 (work in progress), February within Trusted Networks", RFC 3325, November 2002.
2004.
[5] Rosenberg, J., "An Extensible Markup Language (XML) [7] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and
Configuration Access Protocol (XCAP) Usage for Presence Lists", D. Gurle, "Session Initiation Protocol (SIP) Extension for
draft-ietf-simple-xcap-list-usage-02 (work in progress), Instant Messaging", RFC 3428, December 2002.
February 2004.
[6] Ramsdell, B., "S/MIME Version 3.1 Message Specification", [8] Rosenberg, J., "Extensible Markup Language (XML) Formats for
draft-ietf-smime-rfc2633bis-07 (work in progress), February Representing Resource Lists",
draft-ietf-simple-xcap-list-usage-03 (work in progress), July
2004. 2004.
[7] Camarillo, G., "Requirements for Session Initiation Protocol [9] Ramsdell, B., "S/MIME Version 3.1 Message Specification",
(SIP) Exploder Invocation", draft-camarillo-sipping-exploders-02 draft-ietf-smime-rfc2633bis-09 (work in progress), April 2004.
(work in progress), February 2004.
9.2 Informational References [10] Camarillo, G., "Requirements and Framework for Session
Initiation Protocol (SIP)Uniform Resource Identifier
(URI)-List Services", draft-ietf-sipping-uri-services-00 (work
in progress), July 2004.
[8] Rosenberg, J., "Advanced Instant Messaging Requirements for the 12.2 Informational References
[11] 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.
[9] Peterson, J., "SIP Authenticated Identity Body (AIB) Format", [12] Peterson, J., "Session Initiation Protocol (SIP) Authenticated
draft-ietf-sip-authid-body-02 (work in progress), July 2003. Identity Body (AIB) Format", RFC 3893, September 2004.
[10] Jennings, C., Peterson, J. and M. Watson, "Private Extensions
to the Session Initiation Protocol (SIP) for Asserted Identity
within Trusted Networks", RFC 3325, November 2002.
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
skipping to change at page 11, line 13 skipping to change at page 18, line 13
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 IETF's procedures with respect to rights in IETF Documents can on the procedures with respect to rights in RFC documents can be
be found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
 End of changes. 

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