draft-ietf-sipping-capacity-attribute-07.txt   rfc5364.txt 
SIPPING Working Group M. Garcia-Martin Network Working Group M. Garcia-Martin
Internet-Draft G. Camarillo Request for Comments: 5364 G. Camarillo
Intended status: Standards Track Ericsson Category: Standards Track Ericsson
Expires: February 2, 2009 August 1, 2008 October 2008
Extensible Markup Language (XML) Format Extension for Representing Copy
Control Attributes in Resource Lists
draft-ietf-sipping-capacity-attribute-07.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Extensible Markup Language (XML) Format Extension for Representing
http://www.ietf.org/ietf/1id-abstracts.txt. Copy Control Attributes in Resource Lists
The list of Internet-Draft Shadow Directories can be accessed at Status of This Memo
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 2, 2009. This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract Abstract
In certain types of multimedia communications, a Session Initiation In certain types of multimedia communications, a Session Initiation
Protocol (SIP) request is distributed to a group of SIP User Agents Protocol (SIP) request is distributed to a group of SIP User Agents
(UAs). The sender sends a single SIP request to a server which (UAs). The sender sends a single SIP request to a server which
further distributes the request to the group. This SIP request further distributes the request to the group. This SIP request
contains a list of Uniform Resource Identifiers (URIs), which contains a list of Uniform Resource Identifiers (URIs), which
identify the recipients of the SIP request. This URI-list is identify the recipients of the SIP request. This URI list is
expressed as a resource list XML document. This specification expressed as a resource list XML document. This specification
defines an XML extension to the XML resource list format that allows defines an XML extension to the XML resource list format that allows
the sender of the request to qualify a recipient with a copy control the sender of the request to qualify a recipient with a copy control
level similar to the copy control level of existing e-mail systems. level similar to the copy control level of existing email systems.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of operation . . . . . . . . . . . . . . . . . . . . 4 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 3
4. Extension to the resource lists data format . . . . . . . . . 7 4. Extension to the Resource List Data Format . . . . . . . . . . 6
5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Carrying URI-lists in SIP . . . . . . . . . . . . . . . . . . 12 7. Carrying URI Lists in SIP . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9.1. Disposition Type Registration . . . . . . . . . . . . . . 14 9.1. Disposition Type Registration . . . . . . . . . . . . . . 13
9.2. XML Namespace Registration . . . . . . . . . . . . . . . . 15 9.2. XML Namespace Registration . . . . . . . . . . . . . . . . 13
9.3. XML Schema Registration . . . . . . . . . . . . . . . . . 15 9.3. XML Schema Registration . . . . . . . . . . . . . . . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
11.2. Informational References . . . . . . . . . . . . . . . . . 17 11.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18
1. Introduction 1. Introduction
The Framework and Security Considerations for Session Initiation RFC 5363 [RFC5363] describes a generic framework for carrying Uniform
Protocol (SIP) URI-List Services [I-D.ietf-sipping-uri-services] Resource Identifier (URI) lists in SIP [RFC3261] messages.
describes a generic framework for carrying Uniform Resource Specifically, the document provides a common framework for specific
Identifier (URI)-lists in SIP [RFC3261] messages. Specifically, the implementations of URI-list services, such as conferences initiated
document provides a common framework for specific implementations of with INVITE requests [RFC5366] or Multiple-recipient MESSAGE requests
URI-list services, such as conferences initiated with INVITE requests [RFC5365].
[I-D.ietf-sip-uri-list-conferencing] or Multiple-recipient MESSAGE
requests [I-D.ietf-sip-uri-list-message].
Common to all URI-list services is the presence of a SIP request that Common to all URI-list services is the presence of a SIP request that
contains a collection of resources, typically expressed as an XML contains a collection of resources, typically expressed as an XML
resource list [RFC4826]. SIP requests carrying resource lists can resource list [RFC4826]. SIP requests carrying resource lists can
appear either in requests received by the URI-list server, indicating appear either in requests received by the URI-list server, indicating
the list of intended recipients, or in each of the requests that the the list of intended recipients, or in each of the requests that the
URI-list server sends to recipients, indicating the list of URI-list server sends to recipients, indicating the list of
recipients of the same SIP request. recipients of the same SIP request.
Although the XML resource list [RFC4826] provides a powerful Although the XML resource list [RFC4826] provides a powerful
mechanism for describing a list of resources, there is a need for a mechanism for describing a list of resources, there is a need for a
copy control attribute to determine whether a resource is receiving a copy control attribute to determine whether a resource is receiving a
SIP request as a primary recipient, a carbon copy, or a blind carbon SIP request as a primary recipient, a carbon copy, or a blind carbon
copy. This is similar to common e-mail systems, where the sender can copy. This is similar to common email systems, where the sender can
categorize each recipient as To, Cc, or Bcc recipient. categorize each recipient as a "to", "cc", or "bcc" recipient.
This document addresses this problem by providing an extension to the This document addresses this problem by providing an extension to the
XML resource list [RFC4826] that enables the sender to supply a copy XML resource list [RFC4826] that enables the sender to supply a copy
control attribute that labels each recipient as a "to", "cc", or control attribute that labels each recipient as a "to", "cc", or
"bcc" recipient. This attribute indicates whether the recipient is "bcc" recipient. This attribute indicates whether the recipient is
receiving a primary copy of the SIP request, a carbon copy, or a receiving a primary copy of the SIP request, a carbon copy, or a
blind carbon copy. Additionally, we provide the sender with the blind carbon copy. Additionally, we provide the sender with the
capability of indicating in the URI-list that one or more resources capability of indicating in the URI list that one or more resources
should be anonymized, so that some recipients' URIs are not disclosed should be anonymized, so that some recipients' URIs are not disclosed
to the other recipients. Instead, these URIs are replaced with to the other recipients. Instead, these URIs are replaced with
anonymous URIs. anonymous URIs.
The remainder of this document is organized as follows: Section 2 The remainder of this document is organized as follows: Section 2
introduces the terminology used throughout this specification. introduces the terminology used throughout this specification.
Section 3 gives an overview of operation. Section 4 formally defines Section 3 gives an overview of operation. Section 4 formally defines
an extension to URI-lists. The XML schema definition is provided in an extension to URI lists. The XML schema definition is provided in
Section 5. Section 6 shows examples of the URI-lists with the Section 5. Section 6 shows examples of the URI lists with the
extensions defined in this document. Section 7 discusses the extensions defined in this document. Section 7 discusses the
implications of carrying URI-lists in SIP messages. implications of carrying URI lists in SIP messages.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119] and indicate requirement levels for compliant [RFC2119] and indicate requirement levels for compliant
implementations. implementations.
URI-list service: SIP application service that receives a SIP URI-list service: SIP application service that receives a SIP
request containing a URI-list and sends a similar SIP request to request containing a URI list and sends a similar SIP request to
each URI in the list. each URI in the list.
Intended recipient: The intended final recipient of the request to Intended recipient: The intended final recipient of the request to
be generated by URI-list service. be generated by URI-list service.
Copy control: An attribute assigned by the sender to a URI in a XML Copy control: An attribute assigned by the sender to a URI in an
resource list. Its purpose is to indicate to the recipient XML resource list. Its purpose is to indicate to the recipient
whether he is getting a primary, carbon, or blind carbon copy of whether he is getting a primary, carbon, or blind carbon copy of
the SIP request. the SIP request.
Recipient list or recipient XML resource list: An XML resource list Recipient list or recipient XML resource list: An XML resource list
containing the list of intended recipients. The sender sets this containing the list of intended recipients. The sender sets this
list in the SIP request he sends to the URI-list server. list in the SIP request he sends to the URI-list server.
Recipient-history list or recipient-history XML resource list: An Recipient-history list or recipient-history XML resource list: An
XML resource list containing the visible list of recipients (i.e., XML resource list containing the visible list of recipients (i.e.,
those non-anonymous non-bcc). The URI-list server creates this those non-anonymous non-bcc). The URI-list server creates this
list, based on the recipient list, and includes it in each of the list, based on the recipient list, and includes it in each of the
SIP requests it sends to each recipient. SIP requests it sends to each recipient.
3. Overview of operation 3. Overview of Operation
Figure 1 depicts a general overview of the operation of a URI-list Figure 1 depicts a general overview of the operation of a URI-list
server. A SIP User Agent Client (UAC) issuer sends a SIP request server. A SIP User Agent Client (UAC) issuer sends a SIP request
(F1) to a URI-list server containing a recipient list. The URI-list (F1) to a URI-list server containing a recipient list. The URI-list
server generates a SIP request to each recipient, according to the server generates a SIP request to each recipient, according to the
specific SIP method. Each of these SIP requests contains a specific SIP method. Each of these SIP requests contains a
recipient-history list that indicates the visible list of recipients recipient-history list that indicates the visible list of recipients
of the SIP request. of the SIP request.
+--------+ +---------+ +--------+ +--------+ +--------+ +--------+ +---------+ +--------+ +--------+ +--------+
|SIP UAC | | URI-list| |intended| |intended| |intended| |SIP UAC | | URI-list| |intended| |intended| |intended|
| issuer | | server | | recip. | | recip. | | recip. | | issuer | | server | | recip. | | recip. | | recip. |
| | | | | 1 | | 2 | | 3 | | | | | | 1 | | 2 | | 3 |
+--------+ +---------+ +--------+ +--------+ +--------+ +--------+ +---------+ +--------+ +--------+ +--------+
| | | | | | | | | |
| F1. SIP request | | | | | F1 SIP request | | | |
| (recipt. list) | | | | | (recipt. list) | | | |
| ---------------->| | | | | ---------------->| | | |
| F2. 2xx response | | | | | F2 2xx response | | | |
|<---------------- | F3. SIP request | | | |<---------------- | F3 SIP request | | |
| | (recp-hist.list)| | | | | (recp-hist.list)| | |
| | --------------->| | | | | --------------->| | |
| | F4. SIP request | | | | | F4 SIP request | | |
| | (recp-hist.list)| | | | | (recp-hist.list)| | |
| | -------------------------->| | | | -------------------------->| |
| | F5. SIP request | | | | | F5 SIP request | | |
| | (recp-hist.list)| | | | | (recp-hist.list)| | |
| | ------------------------------------->| | | ------------------------------------->|
| | F6. 200 OK | | | | | F6 200 OK | | |
| |<--------------- | | | | |<--------------- | | |
| | F7. 200 OK | | | | | F7 200 OK | | |
| |<-------------------------- | | | |<-------------------------- | |
| | F8. 200 OK | | | | | F8 200 OK | | |
| |<------------------------------------- | | |<------------------------------------- |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
Figure 1: Example of operation Figure 1: Example of operation
The URI-list mechanism allows a sender to specify multiple targets The URI-list mechanism allows a sender to specify multiple targets
for a SIP request by including a recipient XML resource list for a SIP request by including a recipient XML resource list
[RFC4826] in the body of the SIP request. This recipient list [RFC4826] in the body of the SIP request. This recipient list
includes the target URIs of the SIP request (the actual procedures includes the target URIs of the SIP request (the actual procedures
are method specific and outside the scope of this document). Each are method specific and outside the scope of this document). Each
target URI may also be marked with a copy control attribute to target URI may also be marked with a copy control attribute to
indicate the copy level in which the recipient is receiving the SIP indicate the copy level in which the recipient is receiving the SIP
request. This is achieved by the sender qualifying each URI in the request. This is achieved by the sender qualifying each URI in the
URI-list with a 'copyControl' attribute. The available values of the URI list with a 'copyControl' attribute. The available values of the
'copyControl' attribute include "to", "cc", and "bcc" (analogous to 'copyControl' attribute include "to", "cc", and "bcc" (analogous to
e-mail). This is discussed in greater detailed in Section 4. When email). This is discussed in greater detail in Section 4. When the
the URI-list server expands the request to each recipient, the URI- URI-list server expands the request to each recipient, the URI-list
list server includes a recipient-history XML resource list built upon server includes a recipient-history XML resource list built upon the
the recipient list received from the sender. The recipient-history recipient list received from the sender. The recipient-history XML
XML resource list replaces the recipient list in the SIP requests resource list replaces the recipient list in the SIP requests
generated by the URI-list server towards each recipient. The URI- generated by the URI-list server towards each recipient. The URI-
list server copies from the recipient list those targets which are list server copies from the recipient list those targets that are
marked with the "to" and "cc" copy control level, and pastes them in marked with the "to" and "cc" copy control level, and pastes them in
the recipient-history list. The URI-list server explicitly excludes the recipient-history list. The URI-list server explicitly excludes
from the recipient-history list those URIs marked with a "bcc" copy from the recipient-history list those URIs marked with a "bcc" copy
control, although it is able to preserve the address of a "bcc" control, although it is able to preserve the address of a "bcc"
tagged URI when it matches the URI of the recipient of the SIP tagged URI when it matches the URI of the recipient of the SIP
request (this is described later in Section 4). When a recipient request (this is described later in Section 4). When a recipient
receives the SIP request containing the recipient-history XML receives the SIP request containing the recipient-history XML
resource list, he is able to determine which other visible recipients resource list, he is able to determine which other visible recipients
are getting a copy of the SIP request, and whether they are marked are getting a copy of the SIP request, and whether they are marked
with the "to" or "cc" copy control level. Later, if needed, the with the "to" or "cc" copy control level. Later, if needed, the
skipping to change at page 7, line 5 skipping to change at page 6, line 5
decides to preserve a "bcc" marked URI when that URI is itself the decides to preserve a "bcc" marked URI when that URI is itself the
recipient of the SIP request). Recipients of the SIP request will recipient of the SIP request). Recipients of the SIP request will
not notice that one or more extra "bcc" URIs also received the not notice that one or more extra "bcc" URIs also received the
request. However, if the sender qualifies a URI with the 'anonymize' request. However, if the sender qualifies a URI with the 'anonymize'
attribute in the recipient XML resource list, the URI-list server attribute in the recipient XML resource list, the URI-list server
will replace the URI with an anonymous one in the recipient-history will replace the URI with an anonymous one in the recipient-history
list. Recipients of the SIP request will notice that there have been list. Recipients of the SIP request will notice that there have been
one or more additional recipients of the same request, but their URIs one or more additional recipients of the same request, but their URIs
are not disclosed. are not disclosed.
4. Extension to the resource lists data format 4. Extension to the Resource List Data Format
This document defines an extension to the XML resource list data This document defines an extension to the XML resource list data
format [RFC4826] that allows the sender to indicate a copy control format [RFC4826] that allows the sender to indicate a copy control
attribute that qualifies a recipient with a copy control level. We attribute that qualifies a recipient with a copy control level. We
define a new 'copyControl' attribute to the <entry> element of the define a new 'copyControl' attribute to the <entry> element of the
resource list document format [RFC4826]. The 'copyControl' attribute resource list document format [RFC4826]. The 'copyControl' attribute
has similar semantics to the type of destination address in e-mail has similar semantics to the type of destination address in email
systems. It can take the values "to", "cc", and "bcc". A "to" value systems. It can take the values "to", "cc", and "bcc". A "to" value
of the 'copyControl' attribute indicates that the resource is of the 'copyControl' attribute indicates that the resource is
considered a primary recipient of the SIP request. A "cc" value considered a primary recipient of the SIP request. A "cc" value
indicates that the resource receives a carbon copy of the SIP indicates that the resource receives a carbon copy of the SIP
request. A "bcc" value indicates that the resource receives a blind request. A "bcc" value indicates that the resource receives a blind
carbon copy of the SIP request (i.e., this URI is not disclosed to carbon copy of the SIP request (i.e., this URI is not disclosed to
other recipients of the SIP request). The default 'copyControl' other recipients of the SIP request). The default 'copyControl'
value is "bcc". That is, the absence of a 'copyControl' attribute value is "bcc". That is, the absence of a 'copyControl' attribute
MUST be treated as if the 'copyControl' was set to "bcc". MUST be treated as if the 'copyControl' was set to "bcc".
When creating a recipient-history list, URI-list servers use "bcc" When creating a recipient-history list, URI-list servers use "bcc"
'copyControl' attributes to route SIP requests. In addition, URI- 'copyControl' attributes to route SIP requests. In addition, URI-
list servers behave similarly to e-mail systems [RFC2822] with list servers behave similarly to email systems [RFC2822] with respect
respect to the treatment of these URIs marked with a "bcc" copy to the treatment of these URIs marked with a "bcc" copy control,
control, because they have two ways of treating "bcc" marked URIs. because they have two ways of treating "bcc" marked URIs. URI-list
URI-list servers MUST treat these "bcc" marked URIs in either of the servers MUST treat these "bcc" marked URIs in either of the following
following two ways: two ways:
o URI-list servers MUST remove all URIs marked with a "bcc" copy o URI-list servers MUST remove all URIs marked with a "bcc" copy
control in recipient-history lists. This mechanism allows URI- control in recipient-history lists. This mechanism allows URI-
list servers to send the same recipient-history list to each list servers to send the same recipient-history list to each
recipient of the SIP request. However, recipients who are tagged recipient of the SIP request. However, recipients who are tagged
with "bcc" values are not explicitly informed about it. with "bcc" values are not explicitly informed about it.
o URI-list servers MUST preserve with a "bcc" copy control in the o URI-list servers MUST preserve with a "bcc" copy control in the
recipient-history list the URI that identifies the recipient (if recipient-history list the URI that identifies the recipient (if
any) and MUST remove the remaining URIs marked with a "bcc" copy any) and MUST remove the remaining URIs marked with a "bcc" copy
control. Consequently, each recipient receives a different control. Consequently, each recipient receives a different
recipient-history list. However, recipients who have been marked recipient-history list. However, recipients who have been marked
with a "bcc" copy control are explicitly informed about it. with a "bcc" copy control are explicitly informed about it.
Implementations that are able to receive recipient-history lists must Implementations that are able to receive recipient-history lists must
pay attention to the contents of the list. If the recipient's URI is pay attention to the contents of the list. If the recipient's URI is
not included in recipient-history list or if it is included but not included in the recipient-history list or if it is included but
tagged with a "bcc" copy control, then implementations SHOULD prevent tagged with a "bcc" copy control, then implementations SHOULD prevent
the user from replying to all the recipients of the SIP request. the user from replying to all the recipients of the SIP request.
This would allow the non-blind recipients to notice the existence of This would allow the non-blind recipients to notice the existence of
blind recipients of the SIP request. blind recipients of the SIP request.
A new 'anonymize' attribute can be included in a <entry> element of A new 'anonymize' attribute can be included in a <entry> element of
the resource list document format [RFC4826]. If set to a "true" the resource list document format [RFC4826]. If set to a "true"
value, it provides an indication to the URI-list server for not value, it provides an indication to the URI-list server for not
disclosing the URI itself in a URI-list sent to the recipient, but disclosing the URI itself in a URI list sent to the recipient, but
instead, to anonymize the URI (i.e., making it bogus in the instead to anonymize the URI (i.e., making it bogus in the recipient-
recipient-history XML resource list). URI-list servers can use URIs history XML resource list). URI-list servers can use URIs tagged
tagged with the 'anonymize' attribute for routing SIP requests, but with the 'anonymize' attribute for routing SIP requests, but MUST
MUST convert them the SIP URI "sip:anonymous@anonymous.invalid" in convert them to the SIP URI "sip:anonymous@anonymous.invalid" in
recipient-history lists. The default value of the 'anonymize' recipient-history lists. The default value of the 'anonymize'
attribute is "false". attribute is "false".
There are occasions where the URI-list server encounters the same URI There are occasions where the URI-list server encounters the same URI
entry duplicated in a resource list, where duplicated URI entries are entry duplicated in a resource list, where duplicated URI entries are
tagged with the same or different values of the 'copyControl' tagged with the same or different values of the 'copyControl'
attribute. There are no reasonable usages that justify duplicated attribute. There are no reasonable usages that justify duplicated
URIs in resource lists, thus, this is considered an error. URI-list URIs in resource lists; thus, this is considered an error. URI-list
servers should not send duplicated copies of the same SIP request to servers should not send duplicated copies of the same SIP request to
the same intended recipient. In case the URI-list server encounters the same intended recipient. In case the URI-list server encounters
the same URI entry duplicated in a resource list, it should send at the same URI entry duplicated in a resource list, it should send at
most a single copy of the request to that intended recipient. For most a single copy of the request to that intended recipient. For
each set of duplicated URI entries, the URI-list server MUST select each set of duplicated URI entries, the URI-list server MUST select
the highest precedence value of the 'copyControl' attribute for the the highest precedence value of the 'copyControl' attribute for the
same intended recipient. The order of precedence of the values of same intended recipient. The order of precedence of the values of
the 'copyControl' attribute is: "to", "cc", and "bcc". Once the URI- the 'copyControl' attribute is: "to", "cc", and "bcc". Once the URI-
list server has selected a value for the 'copyControl' attribute of list server has selected a value for the 'copyControl' attribute of
an intended recipient, the URI-list can continue processing the an intended recipient, the URI-list server can continue processing
request. the request.
Processing of URIs tagged with a 'copyControl' attribute set to a Processing of URIs tagged with a 'copyControl' attribute set to a
"bcc" value has higher precedence over the 'anonymize' attribute. "bcc" value has higher precedence over the 'anonymize' attribute.
Thus, if the 'copyControl' of a URI is set to "bcc", the URI-list Thus, if the 'copyControl' of a URI is set to "bcc", the URI-list
server MUST remove that URI from the recipient-history list, and the server MUST remove that URI from the recipient-history list, and the
'anonymize' attribute will be ignored. Therefore, the 'anonymize' 'anonymize' attribute will be ignored. Therefore, the 'anonymize'
attribute is only useful for those URIs tagged with a 'copyControl' attribute is only useful for those URIs tagged with a 'copyControl'
of "to" or "cc". of "to" or "cc".
A new 'count' attribute can be also included in a <entry> element of A new 'count' attribute can be also included in an <entry> element of
the resource list document format [RFC4826]. It provides the number the resource list document format [RFC4826]. It provides the number
of equal URIs. Typically, recipient lists created by UACs will not of equal URIs. Typically, recipient lists created by UACs will not
have equal (or duplicate) URI entries, thus, it is not expected to have equal (or duplicate) URI entries; thus, it is not expected to
contain URIs tagged with 'count' attributes. However, recipient- contain URIs tagged with 'count' attributes. However, recipient-
history lists can contain duplicated anonymized URIs, therefore, it history lists can contain duplicated anonymized URIs; therefore, it
is expected that recipient-history lists will contain 'count' is expected that recipient-history lists will contain 'count'
attributes. The default value of the 'count' attribute is "1". attributes. The default value of the 'count' attribute is "1".
The 'copyControl', 'anonymize', and 'count' attributes SHOULD be The 'copyControl', 'anonymize', and 'count' attributes SHOULD be
included as modifiers of any of the child elements included in the included as modifiers of any of the child elements included in the
<list> element of a resource list (e.g., attribute of the <entry> or <list> element of a resource list (e.g., attribute of the <entry> or
<external> elements). <external> elements).
Section 5 describes the format of the 'copyControl', 'anonymize', and Section 5 describes the format of the 'copyControl', 'anonymize', and
'count' attributes. Implementations according to this specification 'count' attributes. Implementations according to this specification
MUST support this XML Schema. MUST support this XML schema.
Implementations that receive recipient-history lists must pay Implementations that receive recipient-history lists must pay
attention to the contents of the list. If the recipient's URI is not attention to the contents of the list. If the recipient's URI is not
included in recipient-history list or if it is included but tagged included in recipient-history list or if it is included but tagged
with a "bcc" copy control, then they SHOULD prevent the user from with a "bcc" copy control, then they SHOULD prevent the user from
replying to all the recipients of the SIP request. This would allow replying to all the recipients of the SIP request. This would allow
the non-blind recipients to notice the existence of blind recipients the non-blind recipients to notice the existence of blind recipients
in the original SIP request. in the original SIP request.
5. XML Schema 5. XML Schema
skipping to change at page 10, line 31 skipping to change at page 9, line 4
<xs:attribute name="copyControl"> <xs:attribute name="copyControl">
<xs:simpleType> <xs:simpleType>
<xs:restriction base="xs:string"> <xs:restriction base="xs:string">
<xs:enumeration value="to"/> <xs:enumeration value="to"/>
<xs:enumeration value="cc"/> <xs:enumeration value="cc"/>
<xs:enumeration value="bcc"/> <xs:enumeration value="bcc"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:attribute> </xs:attribute>
<xs:attribute name="anonymize" type="xs:boolean" default="false"/> <xs:attribute name="anonymize" type="xs:boolean" default="false"/>
<xs:attribute name="count" type="xs:nonNegativeInteger" <xs:attribute name="count" type="xs:nonNegativeInteger"
default="1"/> default="1"/>
</xs:schema> </xs:schema>
Figure 2: XML Schema of the extension to the resource list format Figure 2: XML schema of the extension to the resource list format
6. Examples 6. Examples
This section shows two examples of URI-lists that can be included in This section shows two examples of URI lists that can be included in
SIP requests. The first example in Figure 3 shows a recipient list SIP requests. The first example in Figure 3 shows a recipient list
that the UAC sends to the URI-list server. This corresponds to a that the UAC sends to the URI-list server. This corresponds to a
list that will be included in the flow F2 in Figure 1. The recipient list that will be included in the flow F2 in Figure 1. The recipient
list contains a flat list according to the resource list data format list contains a flat list according to the resource list data format
specified in RFC 4826 [RFC4826]. Each resource indicates the copy specified in RFC 4826 [RFC4826]. Each resource indicates the copy
control of a resource with a 'copyControl' attribute. Some of the control of a resource with a 'copyControl' attribute. Some of the
resources are also marked with the 'anonymize' attribute. This resources are also marked with the 'anonymize' attribute. This
provides an indication to the URI-list service for not disclosing provides an indication to the URI-list service for not disclosing
their URIs in a recipient-history list. The last two <entry> their URIs in a recipient-history list. The last two <entry>
elements are marked with a 'copyControl' attribute of "bcc". This elements are marked with a 'copyControl' attribute of "bcc". This
skipping to change at page 11, line 29 skipping to change at page 9, line 48
<entry uri="sip:carol@example.net" cp:copyControl="cc" <entry uri="sip:carol@example.net" cp:copyControl="cc"
cp:anonymize="true"/> cp:anonymize="true"/>
<entry uri="sip:ted@example.net" cp:copyControl="bcc" /> <entry uri="sip:ted@example.net" cp:copyControl="bcc" />
<entry uri="sip:andy@example.com" cp:copyControl="bcc" /> <entry uri="sip:andy@example.com" cp:copyControl="bcc" />
</list> </list>
</resource-lists> </resource-lists>
Figure 3: Recipient list sent from the UAC to the URI-list server Figure 3: Recipient list sent from the UAC to the URI-list server
Upon receipt of the SIP request containing the recipient list of Upon receipt of the SIP request containing the recipient list of
Figure 3 the URI-list server creates a SIP request to each of the Figure 3, the URI-list server creates a SIP request to each of the
URIs listed in the recipient list (so, in our example, it creates 7 URIs listed in the recipient list (so, in our example, it creates 7
SIP requests). The URI-list server processes the recipient list and SIP requests). The URI-list server processes the recipient list and
creates a recipient-history list that is included in each of the creates a recipient-history list that is included in each of the
outgoing SIP requests. The process is as follows: the URI-list outgoing SIP requests. The process is as follows: the URI-list
server creates a new recipient-history list, based on the recipient server creates a new recipient-history list, based on the recipient
list, but with changes. First it copies all the URIs (<entry> list, but with changes. First, it copies all the URIs (<entry>
elements) marked with the "to" or "cc" 'copyControl' attributes, elements) marked with the "to" or "cc" 'copyControl' attributes,
which do not contain an 'anonymize' attribute (or when the which do not contain an 'anonymize' attribute (or when the
'anonymize' attribute is set to "false"). Then all the URIs marked 'anonymize' attribute is set to "false"). Then all the URIs marked
with a 'copyControl' attribute set to "to" and 'anonymize' attribute with a 'copyControl' attribute set to "to" and 'anonymize' attribute
set to "true" are replaced with the SIP anonymous URI set to "true" are replaced with the SIP anonymous URI
"sip:anonymous@anonymous.invalid". In this entry the URI-list server "sip:anonymous@anonymous.invalid". In this entry, the URI-list
also adds the original value of the 'copyControl' attribute ("to" in server also adds the original value of the 'copyControl' attribute
our example), and it adds a 'count' attribute containing the number ("to" in our example), and it adds a 'count' attribute containing the
of anonymous entries in this group ("2" in our example). Then the number of anonymous entries in this group ("2" in our example). Then
URI-list server does the same operation to the URIs tagged with the the URI-list server does the same operation to the URIs tagged with
'copyControl' attribute set to "cc" and 'anonymize' attribute set to the 'copyControl' attribute set to "cc" and 'anonymize' attribute set
"true", adding also the 'count' attribute containing the number of to "true", adding also the 'count' attribute containing the number of
anonymous attributes in this group ("1" in the example). Last, the anonymous attributes in this group ("1" in the example). Last, the
URI-list server removes all URIs marked with the "bcc" 'copyControl' URI-list server removes all URIs marked with the "bcc" 'copyControl'
attribute. The resulting recipient-history list is shown in attribute. The resulting recipient-history list is shown in
Figure 4. Figure 4.
<?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:copycontrol"> xmlns:cp="urn:ietf:params:xml:ns:copycontrol">
<list> <list>
<entry uri="sip:bill@example.com" cp:copyControl="to" /> <entry uri="sip:bill@example.com" cp:copyControl="to" />
skipping to change at page 12, line 21 skipping to change at page 10, line 40
cp:count="2"/> cp:count="2"/>
<entry uri="sip:joe@example.org" cp:copyControl="cc" /> <entry uri="sip:joe@example.org" cp:copyControl="cc" />
<entry uri="sip:anonymous@anonymous.invalid" cp:copyControl="cc" <entry uri="sip:anonymous@anonymous.invalid" cp:copyControl="cc"
cp:count="1"/> cp:count="1"/>
</list> </list>
</resource-lists> </resource-lists>
Figure 4: Recipient-history list sent from the URI-list server to Figure 4: Recipient-history list sent from the URI-list server to
each recipient each recipient
7. Carrying URI-lists in SIP 7. Carrying URI Lists in SIP
A SIP UAC (User Agent Client) that composes a SIP request can include A SIP UAC (User Agent Client) that composes a SIP request can include
a URI-list with the extensions specified in this document to indicate a URI list with the extensions specified in this document to indicate
the list of intended recipients. On doing so, as specified in the the list of intended recipients. On doing so, as specified in RFC
Framework and Security Considerations for SIP URI-List Services 5363 [RFC5363], the UAC adds a Content-Disposition [RFC2183] header
[I-D.ietf-sipping-uri-services], the UAC adds a Content-Disposition field set to the value 'recipient-list'. Typically UACs send these
[RFC2183] header field set to the value 'recipient-list'. Typically 'recipient-list' bodies to URI-list services (this corresponds to
UACs send these 'recipient-list' bodies to URI-list services (this flow F1 in Figure 1). A body whose Content-Disposition type is
corresponds to flow F1 in Figure 1). A body whose Content- 'recipient-list' contains a URI list that includes the intended
Disposition type is 'recipient-list' contains a URI-list that recipients of the SIP request, something known throughout this
includes the intended recipients of the SIP request, something known document as a recipient list. The <entry> element in the URI list
throughout this document as a recipient list. The <entry> element in MAY also include a 'copyControl' and 'anonymize' attributes, as
the URI-list MAY also include a 'copyControl' and 'anonymize' specified in Section 4.
attributes, as specified in Section 4.
To be able to inform intended recipients of who else is receiving a To be able to inform intended recipients of who else is receiving a
copy of the SIP request, we define a new mail disposition type to be copy of the SIP request, we define a new mail disposition type to be
included in a Content-Disposition [RFC2183] header field of a SIP included in a Content-Disposition [RFC2183] header field of a SIP
request. The value of this new disposition type is 'recipient-list- request. The value of this new disposition type is 'recipient-list-
history' and its purpose is to indicate a list of recipients that a history' and its purpose is to indicate a list of recipients that a
SIP request was sent to, something known throughout this document as SIP request was sent to, something known throughout this document as
a recipient-history list. A body whose Content-Disposition type is a recipient-history list. A body whose Content-Disposition type is
'recipient-list-history' contains a URI-list with the visible 'recipient-list-history' contains a URI list with the visible
(including anonymized) recipients of the SIP request. The <entry> (including anonymized) recipients of the SIP request. The <entry>
element in the URI-list MAY also include a 'copyControl' and 'count' element in the URI list MAY also include a 'copyControl' and 'count'
attributes, as specified in Section 4. attributes, as specified in Section 4.
On sending a SIP request that contains a recipient-history list, if On sending a SIP request that contains a recipient-history list, if
the intended recipient does not support this specification, the SIP the intended recipient does not support this specification, the SIP
request should not fail. In order to ensure successful receipt of request should not fail. In order to ensure successful receipt of
the SIP requests that include 'recipient-list-history' bodies, User the SIP requests that include 'recipient-list-history' bodies, User
Agents (such as URI-list servers) that build SIP requests with the Agents (such as URI-list servers) that build SIP requests with the
Content-Disposition header field set to 'recipient-list-history' Content-Disposition header field set to 'recipient-list-history'
SHOULD add a 'handling' parameter [RFC3204] set to "optional". SHOULD add a "handling" parameter [RFC3204] set to "optional".
Otherwise, the SIP request could fail and never be received by the Otherwise, the SIP request could fail and never be received by the
intended recipient. intended recipient.
Even though Message Body Handling in SIP [I-D.ietf-sip-body-handling] Even though "Message Body Handling in SIP" [SIP_BODY] mandates
mandates support for multipart bodies, legacy recipients may not support for multipart bodies, legacy recipients may not support them.
support them. In such a case, if the request sent by the relay to In such a case, if the request sent by the relay to the recipient
the recipient needs to contain another body (e.g., a MESSAGE request needs to contain another body (e.g., a MESSAGE request carrying a
carrying a message in its body), the relay will not be able to use message in its body), the relay will not be able to use this
this extension because the recipient would not be able to process a extension because the recipient would not be able to process a
multipart body with the original body plus the 'recipient-list- multipart body with the original body plus the 'recipient-list-
history' body. history' body.
8. Security Considerations 8. Security Considerations
The Framework and Security Considerations for SIP URI-List Services RFC 5363 [RFC5363] discusses issues related to SIP URI-list services.
[I-D.ietf-sipping-uri-services] discusses issues related to SIP URI- Implementations of this specification MUST follow the security-
list services. Implementations of this specification MUST follow the related rules in RFC 5363 [RFC5363]. These rules include opt-in
security-related rules in the Framework and Security Considerations lists and mandatory authentication and authorization of clients.
for SIP URI-List Services [I-D.ietf-sipping-uri-services]. These
rules include mandatory authentication and authorization of clients,
and opt-in lists.
User Agent Clients SHOULD NOT hand SIP requests containing URI-list User Agent Clients SHOULD NOT hand SIP requests containing URI-list
services to unauthenticated and untrusted parties. This is to avoid services to unauthenticated and untrusted parties. This is to avoid
man-in-the-middle attacks or acquiring URI-lists for performing SPAM man-in-the-middle attacks or acquiring URI lists for performing spam
attacks. attacks.
URI-lists may contain private information, such as SIP URIs. It is URI lists may contain private information, such as SIP URIs. It is
therefore not desirable that these URI-lists are known by third therefore not desirable that these URI lists are known by third
parties. Eavesdroppers are able to watch URI-lists contained in SIP parties. Eavesdroppers are able to watch URI lists contained in SIP
requests unless the SIP message is sent over a secured channel, by requests unless the SIP message is sent over a secured channel, by
using any of the available SIP mechanisms, such as Transport Layer using any of the available SIP mechanisms, such as Transport Layer
Security (TLS) [RFC4346], or unless the URI-list body itself is Security (TLS) [RFC4346], or unless the URI-list body itself is
encrypted with, e.g., S/MIME [RFC3851]. Therefore, it is RECOMMENDED encrypted with, e.g., S/MIME [RFC3851]. Therefore, it is RECOMMENDED
that URI-list bodies are encrypted with S/MIME [RFC3851] or that the that URI-list bodies are encrypted with S/MIME [RFC3851] or that the
SIP request is encrypted with TLS [RFC4346] or any other suitable SIP request is encrypted with TLS [RFC4346] or any other suitable
encryption mechanism. encryption mechanism.
Note that this URI-list does not indicate the actual participants in Note that this URI list does not indicate the actual participants in
the session. It indicates only the URIs invited and that might the session. It indicates only the URIs invited and that might
accept the request. It does not assert that these parties actually accept the request. It does not assert that these parties actually
exist, that they are reachable at the given URI, or that they have exist, that they are reachable at the given URI, or that they have
accepted the invitation. No inferences about billing should be made accepted the invitation. No inferences about billing should be made
from this information. It is subject to spoofing by loading the list from this information. It is subject to spoofing by loading the list
with falsified content. with falsified content.
Issuers of SIP request use the "bcc" copy control attribute described Issuers of SIP request use the "bcc" copy control attribute described
in Section 4 to facilitate sending SIP requests to recipients without in Section 4 to facilitate sending SIP requests to recipients without
revealing the URIs of one or more of the other recipients. revealing the URIs of one or more of the other recipients.
Mishandling this use of "bcc" copy control has implications for Mishandling this use of "bcc" copy control has implications for
confidential information that might be revealed, which could confidential information that might be revealed, which could
eventually lead to security problems through knowledge of even the eventually lead to security problems through knowledge of even the
existence of a particular URI. For example, if using the first existence of a particular URI. For example, if using the first
method described in Section 4, where the "bcc" tagged URIs are method described in Section 4, where the "bcc" tagged URIs are
removed from recipient-history list, blind recipients have no removed from the recipient-history list, blind recipients have no
explicit indication that they have been sent a blind copy of the SIP explicit indication that they have been sent a blind copy of the SIP
request, except insofar as their URI does not appear in the request, except insofar as their URI does not appear in the
recipient-history list. Because of this, one of the blind URIs could recipient-history list. Because of this, one of the blind URIs could
potentially send a reply to all of the shown recipients and potentially send a reply to all of the shown recipients and
accidentally reveal that the message went to the blind recipient. accidentally reveal that the message went to the blind recipient.
When the second method from Section 4 is used, the blind recipient's When the second method from Section 4 is used, the blind recipient's
address appears in the recipient-history list of a separate copy of address appears in the recipient-history list of a separate copy of
the list. If the "bcc" tagged URI sent contains all of the "bcc" the list. If the "bcc" tagged URI sent contains all of the "bcc"
tagged URIs, all of the "bcc" recipients will be seen by each "bcc" tagged URIs, all of the "bcc" recipients will be seen by each "bcc"
recipient. Even if a separate message is sent to each "bcc" recipient. Even if a separate message is sent to each "bcc"
recipient with only the individual's URI, implementations still need recipient with only the individual's URI, implementations still need
to be careful to process replies to the message as per Section 4 so to be careful to process replies to the message as per Section 4 so
as not to accidentally reveal the blind recipient to other as not to accidentally reveal the blind recipient to other
recipients. recipients.
9. IANA Considerations 9. IANA Considerations
The following sections instruct the IANA to register: a new IANA has made registrations according to the following subsections: a
disposition type, a new XML namespace, and a new XML schema. new disposition type, a new XML namespace, and a new XML schema.
9.1. Disposition Type Registration 9.1. Disposition Type Registration
Section 7 defines a new 'recipient-list-history' value of the Mail Section 7 defines a new 'recipient-list-history' value of the Mail
Content Disposition Values registry. This value should be registered Content Disposition Values registry. This value has been registered
in the IANA registry of Mail Content Disposition Values with the in the IANA registry of Mail Content Disposition Values with the
following registration data: following registration data:
+------------------------+------------------------------+-----------+ +------------------------+------------------------------+-----------+
| Name | Description | Reference | | Name | Description | Reference |
+------------------------+------------------------------+-----------+ +------------------------+------------------------------+-----------+
| recipient-list-history | the body contains a list of | [RFCXXXX] | | recipient-list-history | the body contains a list of | [RFC5364] |
| | URIs that indicates the | | | | URIs that indicates the | |
| | recipients of the SIP | | | | recipients of the request | |
| | request | |
+------------------------+------------------------------+-----------+ +------------------------+------------------------------+-----------+
Table 1: Registration of the 'recipient-list-history' Mail Content Table 1: Registration of the 'recipient-list-history' Mail Content
Disposition Value Disposition Value
Note to IANA and the RFC editor: replace RFCXXXX above with the RFC
number of this specification.
9.2. XML Namespace Registration 9.2. XML Namespace Registration
This section registers a new XML namespace in the IANA XML registry, This section registers a new XML namespace in the IANA XML registry,
as per the guidelines in RFC 3688 [RFC3688]. as per the guidelines in RFC 3688 [RFC3688].
URI: The URI for this namespace is urn:ietf:params:xml:ns:copycontrol URI: The URI for this namespace is urn:ietf:params:xml:ns:copycontrol
Registrant Contact: IETF, SIPPING working group, (sipping@ietf.org), Registrant Contact: IETF SIPPING working group (sipping@ietf.org),
Miguel Garcia-Martin (miguel.an.garcia@nokia.com). Miguel Garcia-Martin (miguel.a.garcia@ericsson.com).
XML: XML:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"> <html xmlns="http://www.w3.org/1999/xhtml">
<head> <head>
<meta http-equiv="content-type" <meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/> content="text/html;charset=iso-8859-1"/>
<title>Copy Control Namespace</title> <title>Copy Control Namespace</title>
</head> </head>
<body> <body>
<h1>Namespace for the Copy Control Attribute Extension <h1>Namespace for the Copy Control Attribute Extension
in Resource Lists</h1> in Resource Lists</h1>
<h2>urn:ietf:params:xml:ns:copycontrol</h2> <h2>urn:ietf:params:xml:ns:copycontrol</h2>
<p>See <a href="[URL of published RFC]">RFCXXXX <p>See <a href="http://www.rfc-editor.org/rfc/rfc5364.txt">
[NOTE TO IANA/RFC-EDITOR: Please replace XXXX with RFC5364</a>.</p>
the RFC number of this specification.]</a>.</p>
</body> </body>
</html> </html>
END END
9.3. XML Schema Registration 9.3. XML Schema Registration
This section registers a new XML schema in the IANA XML registry per This section registers a new XML schema in the IANA XML registry per
the procedures in RFC 3688 [RFC3688]. the procedures in RFC 3688 [RFC3688].
URI: urn:ietf:params:xml:schema:copycontrol URI: urn:ietf:params:xml:schema:copycontrol
Registrant Contact: IETF, SIPPING working group, (sipping@ietf.org), Registrant Contact: IETF SIPPING working group (sipping@ietf.org),
Miguel Garcia-Martin (miguel.an.garcia@nokia.com). Miguel Garcia-Martin (miguel.a.garcia@ericsson.com).
The XML for this schema can be found as the sole content of The XML for this schema can be found as the sole content of
Section 5. Section 5.
10. Acknowledgements 10. Acknowledgments
Thanks to Dean Willis, Jari Urpalainen, Pekka Kuure, Atsushi Sato, Thanks to Dean Willis, Jari Urpalainen, Pekka Kuure, Atsushi Sato,
Brian Rosen, Mary Barnes, James Polk, Brian E. Carpenter, and Chris Brian Rosen, Mary Barnes, James Polk, Brian E. Carpenter, and Chris
Newman for reviewing this document and providing helpful comments. Newman for reviewing this document and providing helpful comments.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 16, line 48 skipping to change at page 15, line 15
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification", Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004. RFC 3851, July 2004.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006. (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats [RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats
for Representing Resource Lists", RFC 4826, May 2007. for Representing Resource Lists", RFC 4826, May 2007.
[I-D.ietf-sipping-uri-services] [RFC5363] Camarillo, G. and A.B. Roach, "Framework and Security
Camarillo, G. and A. Roach, "Framework and Security Considerations for Session Initiation Protocol (SIP) URI-
Considerations for Session Initiation Protocol (SIP) List Services", RFC 5363, October 2008.
Uniform Resource Identifier (URI)-List Services",
draft-ietf-sipping-uri-services-07 (work in progress),
November 2007.
11.2. Informational References 11.2. Informative References
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001. April 2001.
[I-D.ietf-sip-uri-list-conferencing] [RFC5366] Camarillo, G. and A. Johnston, "Conference Establishment
Camarillo, G. and A. Johnston, "Conference Establishment
Using Request-Contained Lists in the Session Initiation Using Request-Contained Lists in the Session Initiation
Protocol (SIP)", draft-ietf-sip-uri-list-conferencing-02 Protocol (SIP)", RFC 5366, October 2008.
(work in progress), November 2007.
[I-D.ietf-sip-uri-list-message] [RFC5365] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient
Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient
MESSAGE Requests in the Session Initiation Protocol MESSAGE Requests in the Session Initiation Protocol
(SIP)", draft-ietf-sip-uri-list-message-03 (work in (SIP)", RFC 5365, October 2008.
progress), December 2007.
[I-D.ietf-sip-body-handling] [SIP_BODY] Camarillo, G., "Message Body Handling in the Session
Camarillo, G., "Message Body Handling in the Session Initiation Protocol (SIP)", Work in Progress,
Initiation Protocol (SIP)", August 2008.
draft-ietf-sip-body-handling-02 (work in progress),
May 2008.
Authors' Addresses Authors' Addresses
Miguel A. Garcia-Martin Miguel A. Garcia-Martin
Ericsson Ericsson
Via de los Poblados 13 Via de los Poblados 13
Madrid 28033 Madrid 28033
Spain Spain
Email: miguel.a.garcia@ericsson.com EMail: miguel.a.garcia@ericsson.com
Gonzalo Camarillo Gonzalo Camarillo
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: Gonzalo.Camarillo@ericsson.com EMail: Gonzalo.Camarillo@ericsson.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
 End of changes. 73 change blocks. 
189 lines changed or deleted 150 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/