draft-ietf-sipping-capacity-attribute-04.txt   draft-ietf-sipping-capacity-attribute-05.txt 
SIPPING Working Group M. Garcia-Martin SIPPING Working Group M. Garcia-Martin
Internet-Draft Nokia Internet-Draft Nokia Siemens Networks
Intended status: Standards Track G. Camarillo Intended status: Standards Track G. Camarillo
Expires: September 28, 2007 Ericsson Expires: May 16, 2008 Ericsson
March 27, 2007 November 13, 2007
Extensible Markup Language (XML) Format Extension for Representing Copy Extensible Markup Language (XML) Format Extension for Representing Copy
Control Attributes in Resource Lists Control Attributes in Resource Lists
draft-ietf-sipping-capacity-attribute-04.txt draft-ietf-sipping-capacity-attribute-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 28, 2007. This Internet-Draft will expire on May 16, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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
skipping to change at page 2, line 12 skipping to change at page 2, line 12
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 e-mail systems.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of operation . . . . . . . . . . . . . . . . . . . . 4 3. Overview of operation . . . . . . . . . . . . . . . . . . . . 4
4. Extension to the resource lists data format . . . . . . . . . 6 4. Extension to the resource lists data format . . . . . . . . . 6
5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Carrying URI-lists in SIP . . . . . . . . . . . . . . . . . . 11 7. Carrying URI-lists in SIP . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9.1. Disposition Type Registration . . . . . . . . . . . . . . 13 9.1. Disposition Type Registration . . . . . . . . . . . . . . 13
9.2. XML Namespace Registration . . . . . . . . . . . . . . . . 13 9.2. XML Namespace Registration . . . . . . . . . . . . . . . . 13
9.3. XML Schema Registration . . . . . . . . . . . . . . . . . 14 9.3. XML Schema Registration . . . . . . . . . . . . . . . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . . 15 11.1. Normative References . . . . . . . . . . . . . . . . . . . 15
11.2. Informational References . . . . . . . . . . . . . . . . . 15 11.2. Informational References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 17
1. Introduction 1. Introduction
The Framework and Security Considerations for Session Initiation The Framework and Security Considerations for Session Initiation
Protocol (SIP) URI-List Services [9] describes a generic framework Protocol (SIP) URI-List Services [I-D.ietf-sipping-uri-services]
for carrying Uniform Resource Identifier (URI)-lists in SIP [4] describes a generic framework for carrying Uniform Resource
messages. Specifically, the document provides a common framework for Identifier (URI)-lists in SIP [RFC3261] messages. Specifically, the
specific implementations of URI-list services, such as conferences document provides a common framework for specific implementations of
initiated with INVITE requests [10] or Multiple-recipient MESSAGE URI-list services, such as conferences initiated with INVITE requests
requests [11]. [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 [7]. SIP requests carrying resource lists can appear resource list [RFC4826]. SIP requests carrying resource lists can
either in requests received by the URI-list server, indicating the appear either in requests received by the URI-list server, indicating
list of intended recipients, or in each of the requests that the URI- the list of intended recipients, or in each of the requests that the
list server sends to recipients, indicating the list of recipients of URI-list server sends to recipients, indicating the list of
the same SIP request. recipients of the same SIP request.
Although the XML resource list [7] provides a powerful mechanism for Although the XML resource list [RFC4826] provides a powerful
describing a list of resources, there is a need for a copy control mechanism for describing a list of resources, there is a need for a
attribute to determine whether a resource is receiving a SIP request copy control attribute to determine whether a resource is receiving a
as a primary recipient, a carbon copy, or a blind carbon copy. This SIP request as a primary recipient, a carbon copy, or a blind carbon
is similar to common e-mail systems, where the sender can categorize copy. This is similar to common e-mail systems, where the sender can
each recipient as To, Cc, or Bcc recipient. categorize each recipient as 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 [7] 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
skipping to change at page 4, line 5 skipping to change at page 4, line 9
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 [1] document are to be interpreted as described in BCP 14, RFC 2119
and indicate requirement levels for compliant implementations. [RFC2119] and indicate requirement levels for compliant
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 a XML
resource list. Its purpose is to indicate to the recipient resource list. Its purpose is to indicate to the recipient
skipping to change at page 5, line 37 skipping to change at page 5, line 37
| |<-------------------------- | | | |<-------------------------- | |
| | 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 [7] in for a SIP request by including a recipient XML resource list
the body of the SIP request. This recipient list includes the target [RFC4826] in the body of the SIP request. This recipient list
URIs of the SIP request (the actual procedures are method specific includes the target URIs of the SIP request (the actual procedures
and outside the scope of this document). Each target URI may also be are method specific and outside the scope of this document). Each
marked with a copy control attribute to indicate the copy level in target URI may also be marked with a copy control attribute to
which the recipient is receiving the SIP request. This is achieved indicate the copy level in which the recipient is receiving the SIP
by the sender qualifying each URI in the URI-list with a request. This is achieved by the sender qualifying each URI in the
'copyControl' attribute. The available values of the 'copyControl' URI-list with a 'copyControl' attribute. The available values of the
attribute include "to", "cc", and "bcc" (analogous to e-mail). This 'copyControl' attribute include "to", "cc", and "bcc" (analogous to
is discussed in greater detailed in Section 4. When the URI-list e-mail). This is discussed in greater detailed in Section 4. When
server expands the request to each recipient, the URI-list server the URI-list server expands the request to each recipient, the URI-
includes a recipient-history XML resource list built upon the list server includes a recipient-history XML resource list built upon
recipient list received from the sender. The recipient-history XML the recipient list received from the sender. The recipient-history
resource list replaces the recipient list in the SIP requests XML 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 which 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 copy those URIs marked with a "bcc" copy control. When a from the copy those URIs marked with a "bcc" copy control. When a
recipient receives the SIP request containing the recipient-history recipient receives the SIP request containing the recipient-history
XML resource list, he is able to determine which other visible XML resource list, he is able to determine which other visible
recipients are getting the same SIP requests, and whether they are recipients are getting the same SIP requests, and whether they are
marked with the "to" or "cc" copy control level. Later, if needed, marked with the "to" or "cc" copy control level. Later, if needed,
the recipient can generate a reply to those visible recipients. the recipient can generate a reply to those visible recipients.
In addition to the 'copyControl' attribute for a URI in an XML In addition to the 'copyControl' attribute for a URI in an XML
resource list, we define a second boolean attribute called resource list, we define a second boolean attribute called
'anonymize'. The sender of a SIP request can mark a URI in a 'anonymize'. The sender of a SIP request can mark a URI in a
recipient XML resource list with the 'anonymize' attribute to recipient XML resource list with the 'anonymize' attribute to
indicate the URI-list server that the URI marked with that attribute indicate the URI-list server that the URI marked with that attribute
is to be replaced with an anonymous URI in the recipient-history XML is to be replaced with an anonymous URI in the recipient-history XML
resource list. This provides a knowledge to recipients of a SIP resource list. This provides knowledge to the recipients of a SIP
request of a number of additional recipients whose URIs have not been request of the number of additional visible recipients whose URIs
disclosed. have not been disclosed.
There are cases when the sender marks several URIs with the There are cases when the sender marks several URIs with the
'anonymize' attribute. The URI-list server can group the anonymized 'anonymize' attribute. The URI-list server can group the anonymized
URIs in a single anonymized URI within its copy control level, and URIs in a single anonymized URI within its copy control level, and
provide a count of the number of anonymized URIs. To support this provide a count of the number of anonymized URIs. To support this
scenario, we define a new 'count' attribute to a URI in the scenario, we define a new 'count' attribute to a URI in the
recipient-history XML resource list. It is expected that the 'count' recipient-history XML resource list. It is expected that the 'count'
attribute is only used with anonymous URIs, although syntactically it attribute is only used with anonymous URIs, although syntactically it
is possible to add a 'count' attribute to any URI in any XML resource is possible to add a 'count' attribute to any URI in any XML resource
list. list.
skipping to change at page 6, line 50 skipping to change at page 6, line 50
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
have not been disclosed. have not been disclosed.
4. Extension to the resource lists data format 4. Extension to the resource lists 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 [7] 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 [7]. The 'copyControl' attribute has resource list document format [RFC4826]. The 'copyControl' attribute
similar semantics to the type of destination address in e-mail has similar semantics to the type of destination address in e-mail
systems. It can take the values "to", "cc", and "bcc". A "to" value 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 in carbon copy of the SIP request (i.e., this URI is not disclosed in
the recipient-history list). The default 'copyControl' value is the recipient-history list). The default 'copyControl' value is
"bcc". That is, the absence of a 'copyControl' attribute MUST be "bcc". That is, the absence of a 'copyControl' attribute MUST be
treated as if the 'copyControl' was set to "bcc". URI-list servers treated as if the 'copyControl' was set to "bcc". URI-list servers
use URIs marked with the "bcc" 'copyControl' attribute to route SIP use URIs marked with the "bcc" 'copyControl' attribute to route SIP
requests, but MUST NOT include them in recipient-history lists. requests, but MUST NOT include them in recipient-history lists.
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 [7]. If set to a "true" value, it the resource list document format [RFC4826]. If set to a "true"
provides an indication to the URI-list server for not disclosing the value, it provides an indication to the URI-list server for not
URI itself in a URI-list sent to the recipient, but instead, to disclosing the URI itself in a URI-list sent to the recipient, but
anonymize the URI (i.e., making it bogus in the recipient-history XML instead, to anonymize the URI (i.e., making it bogus in the
resource list). URI-list servers can use URIs tagged with the recipient-history XML resource list). URI-list servers can use URIs
'anonymize' attribute for routing SIP requests, but MUST convert them tagged with the 'anonymize' attribute for routing SIP requests, but
to an anonymized URI (such as sip:anonymous@anonymous.invalid) in MUST convert them to an anonymized URI (such as
recipient-history lists. The default value of the 'anonymize' sip:anonymous@anonymous.invalid) in recipient-history lists. The
attribute is "false". default value of the 'anonymize' 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 MUST 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 in a resource list, it MUST send at most a single the same URI entry duplicated in a resource list, it should send at
copy of the request to that intended recipient. The URI-list server most a single copy of the request to that intended recipient. For
MUST select the highest precedence value of the 'copyControl' each set of duplicated URI entries, the URI-list server MUST select
attribute of the duplicated entries for the same intended recipient. the highest precedence value of the 'copyControl' attribute for the
The order of precedence of the values of the 'copyControl' attribute same intended recipient. The order of precedence of the values of
is: "to", "cc", and "bcc". Once the URI-list server has selected a the 'copyControl' attribute is: "to", "cc", and "bcc". Once the URI-
value for the 'copyControl' attribute of an intended recipient, the list server has selected a value for the 'copyControl' attribute of
URI-list can continue processing the request. an intended recipient, the URI-list can continue processing 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 a <entry> element of
the resource list document format [7]. It provides the number of the resource list document format [RFC4826]. It provides the number
equal URIs. Typically, recipient lists created by UACs will not have of equal URIs. Typically, recipient lists created by UACs will not
equal (or duplicate) URI entries, thus, it is not expected to contain have equal (or duplicate) URI entries, thus, it is not expected to
URIs tagged with 'count' attributes. However, recipient-history contain URIs tagged with 'count' attributes. However, recipient-
lists can contain duplicated anonymized URIs, therefore, it is history lists can contain duplicated anonymized URIs, therefore, it
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.
skipping to change at page 9, line 50 skipping to change at page 9, line 50
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
[7]. Each resource indicates the copy control of a resource with a specified in RFC 4826 [RFC4826]. Each resource indicates the copy
'copyControl' attribute. Some of the resources are also marked with control of a resource with a 'copyControl' attribute. Some of the
the 'anonymize' attribute. This provides an indication to the URI- resources are also marked with the 'anonymize' attribute. This
list service for not disclosing their URIs in a recipient-history provides an indication to the URI-list service for not disclosing
list. The last two <entry> elements are marked with a 'copyControl' their URIs in a recipient-history list. The last two <entry>
attribute of "bcc". This provides an indication to the URI-list elements are marked with a 'copyControl' attribute of "bcc". This
server for removing these URIs in the recipient-history list. provides an indication to the URI-list server for removing these URIs
in the recipient-history list.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists" <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:cp="urn:ietf:params:xml:ns: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" />
<entry uri="sip:randy@example.net" cp:copyControl="to" <entry uri="sip:randy@example.net" cp:copyControl="to"
cp:anonymize="true"/> cp:anonymize="true"/>
<entry uri="sip:eddy@example.com" cp:copyControl="to" <entry uri="sip:eddy@example.com" cp:copyControl="to"
cp:anonymize="true"/> cp:anonymize="true"/>
skipping to change at page 11, line 27 skipping to change at page 11, line 28
</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 the
Framework and Security Considerations for SIP URI-List Services [9], Framework and Security Considerations for SIP URI-List Services
the UAC adds a Content-Disposition [2] header field set to the value [I-D.ietf-sipping-uri-services], the UAC adds a Content-Disposition
'recipient-list'. Typically UACs send these 'recipient-list' bodies [RFC2183] header field set to the value 'recipient-list'. Typically
to URI-list services (this corresponds to flow F1 in Figure 1). A UACs send these 'recipient-list' bodies to URI-list services (this
body whose Content-Disposition type is 'recipient-list' contains a corresponds to flow F1 in Figure 1). A body whose Content-
URI-list that includes the intended recipients of the SIP request, Disposition type is 'recipient-list' contains a URI-list that
something known throughout this document as a recipient list. The includes the intended recipients of the SIP request, something known
<entry> element in the URI-list MAY also include a 'copyControl' and throughout this document as a recipient list. The <entry> element in
'anonymize' attributes, as specified in Section 4. the URI-list MAY also include a 'copyControl' and 'anonymize'
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 [2] header field of a SIP request. included in a Content-Disposition [RFC2183] header field of a SIP
The value of this new disposition type is 'recipient-list-history' request. The value of this new disposition type is 'recipient-list-
and its purpose is to indicate a list of recipients that a SIP history' and its purpose is to indicate a list of recipients that a
request was sent to, something known throughout this document as a SIP request was sent to, something known throughout this document as
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 [3] set to "optional". Otherwise, SHOULD add a 'handling' parameter [RFC3204] set to "optional".
the SIP request could fail and never be received by the intended Otherwise, the SIP request could fail and never be received by the
recipient. intended recipient.
Even though Message Body Handling in SIP [I-D.ietf-sip-body-handling]
mandates support for multipart bodies, legacy recipients may not
support them. In such a case, if the request sent by the relay to
the recipient needs to contain another body (e.g., a MESSAGE request
carrying a message in its body), the relay will not be able to use
this extension because the recipient would not be able to process a
multipart body with the original body plus the 'recipient-list-
history' body.
8. Security Considerations 8. Security Considerations
The Framework and Security Considerations for SIP URI-List Services The Framework and Security Considerations for SIP URI-List Services
[9] 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 the Framework and Security Considerations for SIP security-related rules in the Framework and Security Considerations
URI-List Services [9]. These rules include mandatory authentication for SIP URI-List Services [I-D.ietf-sipping-uri-services]. These
and authorization of clients, and opt-in lists. 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) [6], or unless the URI-list body itself is encrypted Security (TLS) [RFC4346], or unless the URI-list body itself is
with, e.g., S/MIME [8]. Therefore, it is RECOMMENDED that URI-list encrypted with, e.g., S/MIME [RFC3851]. Therefore, it is RECOMMENDED
bodies are encrypted with S/MIME [8] or that the SIP request is that URI-list bodies are encrypted with S/MIME [RFC3851] or that the
encrypted with TLS [6] or any other suitable encryption mechanism. SIP request is encrypted with TLS [RFC4346] or any other suitable
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.
9. IANA Considerations 9. IANA Considerations
skipping to change at page 13, line 30 skipping to change at page 13, line 40
Table 1: Registration of the 'recipient-list-history' Mail Content Table 1: Registration of the 'recipient-list-history' Mail Content
Disposition Value Disposition Value
Note to IANA and the RFC editor: replace RFCXXXX above with the RFC Note to IANA and the RFC editor: replace RFCXXXX above with the RFC
number of this specification. number of this specification.
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 [5]. 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.an.garcia@nokia.com).
XML: XML:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
skipping to change at page 14, line 29 skipping to change at page 14, line 29
<p>See <a href="[URL of published RFC]">RFCXXXX <p>See <a href="[URL of published RFC]">RFCXXXX
[NOTE TO IANA/RFC-EDITOR: Please replace XXXX with [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with
the RFC number of this specification.]</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 [5]. 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.an.garcia@nokia.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. Acknowledgements
Thanks to Dean Willis, Jari Urpalainen, Pekka Kuure, Atsushi Sato, Thanks to Dean Willis, Jari Urpalainen, Pekka Kuure, Atsushi Sato,
Brian Rosen, Mary Barnes, and James Polk for reviewing this document Brian Rosen, Mary Barnes, and James Polk for reviewing this document
and providing helpful comments. and providing helpful comments.
11. References 11. References
11.1. Normative References 11.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Troost, R., Dorner, S., and K. Moore, "Communicating [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating
Presentation Information in Internet Messages: The Content- Presentation Information in Internet Messages: The
Disposition Header Field", RFC 2183, August 1997. Content-Disposition Header Field", RFC 2183, August 1997.
[3] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., [RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet,
Watson, M., and M. Zonoun, "MIME media types for ISUP and QSIG F., Watson, M., and M. Zonoun, "MIME media types for ISUP
Objects", RFC 3204, December 2001. and QSIG Objects", RFC 3204, December 2001.
[4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: A., Peterson, J., Sparks, R., Handley, M., and E.
Session Initiation Protocol", RFC 3261, June 2002. Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[5] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[6] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Protocol Version 1.1", RFC 4346, April 2006. Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004.
[7] Rosenberg, J., "Extensible Markup Language (XML) Formats for [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
Representing Resource Lists", (TLS) Protocol Version 1.1", RFC 4346, April 2006.
draft-ietf-simple-xcap-list-usage-05 (work in progress),
February 2005.
[8] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions [RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats
(S/MIME) Version 3.1 Message Specification", RFC 3851, for Representing Resource Lists", RFC 4826, May 2007.
July 2004.
[9] Camarillo, G. and A. Roach, "Framework and Security [I-D.ietf-sipping-uri-services]
Considerations for Session Initiation Protocol (SIP) Uniform Camarillo, G. and A. Roach, "Framework and Security
Resource Identifier (URI)-List Services", Considerations for Session Initiation Protocol (SIP)
Uniform Resource Identifier (URI)-List Services",
draft-ietf-sipping-uri-services-06 (work in progress), draft-ietf-sipping-uri-services-06 (work in progress),
September 2006. September 2006.
11.2. Informational References 11.2. Informational References
[10] Camarillo, G. and A. Johnston, "Conference Establishment Using [I-D.ietf-sip-uri-list-conferencing]
Request-Contained Lists in the Session Initiation Protocol Camarillo, G. and A. Johnston, "Conference Establishment
(SIP)", draft-ietf-sip-uri-list-conferencing-01 (work in Using Request-Contained Lists in the Session Initiation
Protocol (SIP)", draft-ietf-sip-uri-list-conferencing-01
(work in progress), January 2007.
[I-D.ietf-sip-uri-list-message]
Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient
MESSAGE Requests in the Session Initiation Protocol
(SIP)", draft-ietf-sip-uri-list-message-01 (work in
progress), January 2007. progress), January 2007.
[11] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE [I-D.ietf-sip-body-handling]
Requests in the Session Initiation Protocol (SIP)", Camarillo, G., "Message Body Handling in the Session
draft-ietf-sip-uri-list-message-01 (work in progress), Initiation Protocol (SIP)",
January 2007. draft-ietf-sip-body-handling-00 (work in progress),
August 2007.
Authors' Addresses Authors' Addresses
Miguel A. Garcia-Martin Miguel A. Garcia-Martin
Nokia Nokia Siemens Networks
P.O.Box 407 P.O.Box 6
NOKIA GROUP, FIN 00045 Nokia Siemens Networks, FIN 02022
Finland Finland
Email: miguel.an.garcia@nokia.com Email: miguel.garcia@nsn.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
 End of changes. 40 change blocks. 
141 lines changed or deleted 165 lines changed or added

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