draft-ietf-sipping-capacity-attribute-01.txt   draft-ietf-sipping-capacity-attribute-02.txt 
SIPPING Working Group M. Garcia-Martin SIPPING Working Group M. Garcia-Martin
Internet-Draft Nokia Internet-Draft Nokia
Intended status: Standards Track G. Camarillo Intended status: Standards Track G. Camarillo
Expires: March 5, 2007 Ericsson Expires: April 5, 2007 Ericsson
September 1, 2006 October 2, 2006
Extensible Markup Language (XML) Format Extension for Representing Extensible Markup Language (XML) Format Extension for Representing Copy
Capacity Attributes in Resource Lists Control Attributes in Resource Lists
draft-ietf-sipping-capacity-attribute-01.txt draft-ietf-sipping-capacity-attribute-02.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 March 5, 2007. This Internet-Draft will expire on April 5, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document specifies an XML extension to the resource list format In certain types of multimedia communications, a Session Initiation
for qualifiying resources with the capacity in which they are Protocol (SIP) request is distributed to a group of SIP User Agents
included in the resource list. (UAs). The sender sends a single SIP request to a server which
further distributes the request to the group. This SIP request
contains a list of Uniform Resource Identifiers (URIs), which
identify the recipients of the SIP request. This URI-list is
expressed as a resource list XML document. This specification
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
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview of operation . . . . . . . . . . . . . . . . . . . . 4
4. Extension to the resource lists data format . . . . . . . . . 5 4. Extension to the resource lists data format . . . . . . . . . 6
5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Carrying URI-lists in SIP . . . . . . . . . . . . . . . . . . 9 7. Carrying URI-lists in SIP . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9.1. Disposition Type Registration . . . . . . . . . . . . . . 10 9.1. Disposition Type Registration . . . . . . . . . . . . . . 12
9.2. XML Namespace Registration . . . . . . . . . . . . . . . . 11 9.2. XML Namespace Registration . . . . . . . . . . . . . . . . 12
9.3. XML Schema Registration . . . . . . . . . . . . . . . . . 12 9.3. XML Schema Registration . . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
11.2. Informational References . . . . . . . . . . . . . . . . . 13 11.2. Informational References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 16
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 [9] describes a generic framework
for carrying Uniform Resource Identifier (URI)-lists in SIP [5] for carrying Uniform Resource Identifier (URI)-lists in SIP [5]
messages. Specifically the document provides a common framework for messages. Specifically, the document provides a common framework for
specific implementations of URI-list services, such as conferences specific implementations of URI-list services, such as conferences
initiated with INVITE requests [10] or Multiple-recipient MESSAGE initiated with INVITE requests [10] or Multiple-recipient MESSAGE
requests [11]. requests [11].
Common to a multiple of URI-list services is the presence of a SIP Common to all URI-list services is the presence of a SIP request that
request that contains a collection of resources, typically expressed contains a collection of resources, typically expressed as an XML
as an XML resource list [7]. SIP requests carrying resource lists resource list [7]. SIP requests carrying resource lists can appear
can appear either in requests received by the URI-list server, either in requests received by the URI-list server, indicating the
indicating the list of intended recipients; or in each of the list of intended recipients, or in each of the requests that the URI-
requests that the URI-list server sends to recipients, indicating the list server sends to recipients, indicating the list of recipients of
list of recipients of the same SIP request. the same SIP request.
Although the XML resource list [7] provides a powerful mechanism for Although the XML resource list [7] provides a powerful mechanism for
indicating list of resources, it is usually beneficial to indicate describing list of resources, there is a need for a copy control
the capacity in which a resource is receiving a SIP request. This is attribute to determine whether a resource is receiving a SIP request
similar to common e-mail where the sender can assign each recipient as a primary recipient, a carbon copy, or a blind carbon copy. This
the capacity of To, Cc, or Bcc, in which they are receiving an e-mail is similar to common e-mail systems, where the sender can categorize
message. 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 tag the capacity of XML resource list [7] that enables the sender to supply a copy
the recipients, as 'to', 'cc', or 'bcc'. Additionally, we provide control attribute that labels each recipient as a "to", "cc", or
the sender with the capability of indicating in the URI-list that one "bcc" recipeint. This attribute indicates whether the recipient is
or more resources should be anonymized, so that their URIs are not receiving a primary copy of the SIP request, a carbon copy, or a
disclosed to the other recipients, but instead, they are replaced blind carbon copy. Additionally, we provide the sender with the
with anonymous URIs. capability of indicating in the URI-list that one or more resources
should be anonymized, so that some recipeints' URIs are not disclosed
to the other recipients. Instead, these URIs are replaced with
anonymous URIs.
The rest of this document is organized as follows: Section 2 The remainder of this document is organized as follows: Section 2
introduces a few new terms. Section 3 gives an overview of introduces the terminology used throughout this specification.
operation. Section 4 formally defines an extension to URI-lists. Section 3 gives an overview of operation. Section 4 formally defines
The XML schema definition is provided in Section 5. Section 6 shows an extension to URI-lists. The XML schema definition is provided in
examples of the URI-lists with the extensions defined in this Section 5. Section 6 shows examples of the URI-lists with the
document. Section 7 discusses the implications of carrying URI-lists extensions defined in this document. Section 7 discusses the
in SIP messages. implications of carrying URI-lists in SIP messages.
2. Terminology 2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, RFC 2119 [1] and indicate requirement levels for described in BCP 14, RFC 2119 [1] and indicate requirement levels for
compliant implementations. compliant implementations.
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.
Capacity: The role assigned by the sender to a recipient. The Copy control: An attribute assigned by the sender to a URI in a XML
sender is able to tag recipients with the 'to', 'cc', and 'bcc' resource list. Its purpose is to indicate the recipient whether
capacity, which indicate, respectively, whether the recipients get he is getting a primary, carbon, or blind carbon copy of the SIP
a primary, carbon copy, or blind carbon copy of the SIP request. request.
3. Overview Recipient list or recipient XML resource list: An XML resource list
containing the list of intended recipients. The sender sets this
list in the SIP request he sends to the URI-list server.
Recipient-history list or recipient-history XML resource list: An
XML resource list containing the visible list of recipients (i.e.,
those non-anonymous non-bcc). The URI-list server creates this
list, based on the recipient list, and includes it in each of the
SIP requests it sends to each recipient.
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. The URI-list server generates a SIP (F1) to a URI-list server containing a recipient list of intended
request to each of the recipients, according to the specific method. recipients. The URI-list server generates a SIP request to each
recipient, according to the specific SIP method. Each of these SIP
requests contains a recipient-history list that indicates the visible
list of recipients 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 | | n | | | | | | 1 | | 2 | | 3 |
+--------+ +---------+ +--------+ +--------+ +--------+ +--------+ +---------+ +--------+ +--------+ +--------+
| | | | | | | | | |
| F1. SIP request | | | | | F1. SIP request | | | |
| (recipt. list) | | | |
| ---------------->| | | | | ---------------->| | | |
| F2. 2xx response | | | | | F2. 2xx response | | | |
|<---------------- | F3. SIP request | | |<---------------- | F3. SIP request | | |
| | ------------->| | | | | (recp-hist.list)| | |
| | F4. SIP request | | | | --------------->| | |
| | ------------------------>| | | | F4. SIP request | | |
| | F5. SIP request | | | | (recp-hist.list)| | |
| | ----------------------------------->| | | -------------------------->| |
| | F6. 2xx response | | | | F5. SIP request | | |
| |<------------- | | | | | (recp-hist.list)| | |
| | F7. 2xx response | | | | ------------------------------------->|
| |<------------------------ | | | | F6. 200 OK | | |
| | F8. 2xx response | | | |<--------------- | | |
| |<----------------------------------- | | | F7. 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 an XML resource list [7] in the body for a SIP request by including a recipient XML resource list [7] in
of the SIP request. This XML resource list includes the URIs of the the body of the SIP request. This recipient list includes the target
targets of the SIP request (the actual procedures are method specific URIs of the SIP request (the actual procedures are method specific
and outside the scope of this document). Each target URI may also be and outside the scope of this document). Each target URI may also be
marked to indicate in what capacity (or role) the recipient is marked with a copy control attribute to indicate the copy level in
receiving the SIP request. The available capacities include 'to', which the recipient is receiving the SIP request. This is achieved
'cc', and 'bcc' (analogous to e-mail). Each target URI may also be by the sender qualifying each URI in the URI-list with a
marked with the 'anonymize' attribute. This allows the sender of the 'copyControl' attribute. The available values of the 'copyControl'
SIP request to indicate to the URI-list service that an intended attribute include "to", "cc", and "bcc" (analogous to e-mail). This
recipient should receive the SIP request, but his URI should not be is discussed in greater detailed in Section 4. When the URI-list
disclosed (for example, in a URI-list that the URI-list service could server expands the request to each recipient, the URI-list server
send to the recipients of the SIP request). includes a recipient-history XML resource list built upon the
recipient list received from the sender. The recipient-history XML
resource list replaces the recipient list in the SIP requests
generated by the URI-list server towards each recipient. The URI-
list server copies from the recipient list those targets which are
marked with the "to" and "cc" copy control level, and pastes them in
the recipient-history list. The URI-list server explicitly excludes
from the copy those URIs marked with a "bcc" copy control. When a
recipient receives the SIP request containing the recipient-history
XML resource list, he is able to determine which other visible
recipients are getting the same SIP requests, and whether they are
marked with the "to" or "cc" copy control level. Later, if needed,
the recipient can generate a reply to those visible recipients.
When the URI-list server expands the request for each recipient, it In addition to the 'copyControl' attribute for a URI in an XML
includes a new URI-list that contains only the targets originally resource list, we define a second boolean attribute called
listed in the "to" and "cc" capacities, excludes those listed in the 'anonymize'. The sender of a SIP request can mark a URI in a
'bcc' capacity. Further more, those URIs tagged with the 'anonymize' recipient XML resource list with the 'anonymize' attribute to
attribute are replaced by an anonymous URI. 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
resource list. This provides a knowledge to recipients of a SIP
request of a number of additional recipients whose URIs have not been
disclosed.
In case of multiple identical URIs the size of URI-list can be There are cases when the sender marks several URIs with the
compressed by adding a 'count' attribute to a URI. The 'count' 'anonymize' attribute. The URI-list server can group the anonymized
attribute indicates the number of repeated URIs. This is URIs in a single anonymized URI within its copy control level, and
particularly useful with anonymized URIs. It is not expected to have provide a count of the number of anonymized URIs. To support this
value other than with anonymous URIs, although technically, it is scenario, we define a new 'count' attribute to a URI in the
possible to include the 'count' attribute to any URI. recipient-history XML resource list. It is expected that the 'count'
attribute is only used with anonymous URIs, although syntactically it
is possible to add a 'count' attribute to any URI in any XML resource
list.
The presence of a URI-list in each of the expanded SIP requests Initially, it may be thought that the 'anonymize' attribute overlaps
allows recipients to both see and reply to the non-anonymous "to" and with the "bcc" value of the 'copyControl' attribute. However, there
"cc" targets, but not to the "bcc" or anonymous targets. The default are differences between them. If the sender qualifies a URI with a
capacity assumed, if one is not specified by the sender, is "bcc". 'copyControl' attribute of "bcc" in the recipient XML resource list,
This is discussed in greater detailed in Section 4 the URI-list server will completely remove that URI from the
recipient-history XML resource list. Recipients of the SIP request
will not notice that one or more extra URIs also received the
request. However, if the sender qualifies a URI with the 'anonymize'
attribute in the recipient XML resource list, the URI-list server
will replace the URI with an anonymous one in the recipient-history
list. Recipients of the SIP request will notice that there have been
one or more additional recipients of the same request, but their URIs
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 the capacity or role in format [7] that allows the sender to indicate a copy control
which a recipient is receiving a message. We define a new 'capacity' attribute that qualifies a recipient with a copy control level. We
attribute to the <entry> element of the resource list document format define a new 'copyControl' attribute to the <entry> element of the
[7]. The 'capacity' attribute has similar semantics to the type of resource list document format [7]. The 'copyControl' attribute has
destination address in e-mail systems. It can take the values "to", similar semantics to the type of destination address in e-mail
"cc", and "bcc". A "to" value of the 'capacity' attribute indicates systems. It can take the values "to", "cc", and "bcc". A "to" value
that the resource is considered a primary recipient of the SIP of the 'copyControl' attribute indicates that the resource is
request. A "cc" value indicates that the resource receives a carbon considered a primary recipient of the SIP request. A "cc" value
copy of the SIP request. A "bcc" value indicates that the resource indicates that the resource receives a carbon copy of the SIP
receives a blind carbon copy of the SIP request, i.e., this URI is request. A "bcc" value indicates that the resource receives a blind
not disclosed in a URI-list sent to the recipients. The default carbon copy of the SIP request (i.e., this URI is not disclosed in
'capacity' value is "bcc", that is, the absence of a 'capacity' the recipient-history list). The default 'copyControl' value is
attribute MUST be treated as if the 'capacity' was set to "bcc". "bcc". That is, the absence of a 'copyControl' attribute MUST be
URI-list servers can use URIs tagged with the "bcc" 'capacity' treated as if the 'copyControl' was set to "bcc". URI-list servers
attribute for routing SIP requests, but MUST delete them if the URI- use URIs marked with the "bcc" 'copyControl' attribute to route SIP
list service includes a URI-list in outgoing requests. 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 [7]. If set to a "true" value, it
provides an indication to the URI-list server for not disclosing the provides an indication to the URI-list server for not disclosing the
URI itself in a URI-list sent to the recipient, but instead, URI itself in a URI-list sent to the recipient, but instead, to
anonymize the URI. URI-list servers can use URIs tagged with the anonymize the URI (i.e., making it bogus in the recipient-history XML
resource list). URI-list servers can use URIs tagged with the
'anonymize' attribute for routing SIP requests, but MUST convert them 'anonymize' attribute for routing SIP requests, but MUST convert them
to an anonymized URI (such as sip:anonymous@anonymous.invalid) if the to an anonymized URI (such as sip:anonymous@anonymous.invalid) in
URI-list server includes a URI-list in outgoing requests. The recipient-history lists. The default value of the 'anonymize'
default value of the 'anonymize' attribute is "false". attribute is "false".
Processing of URIs tagged with a "bcc" 'capacity' has higher Processing of URIs tagged with a 'copyControl' attribute set to a
precedence of the 'anonymize' attribute, thus, if the 'capacity' of a "bcc" value has higher precedence over the 'anonymize' attribute.
URI is set to "bcc", the URI-list service will remove the URI from Thus, if the 'copyControl' of a URI is set to "bcc", the URI-list
the list and the 'anonymize' attribute will be ignored. Therefore, server MUST remove that URI from the recipient-history list, and the
the 'anonymize' attribute is only useful for those URIs tagged with a 'anonymize' attribute will be ignored. Therefore, the 'anonymize'
'capacity' of "to" or "cc". attribute is only useful for those URIs tagged with a 'copyControl'
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 [7]. It provides the number of
equal URIs. Typically URI-lists created by UACs will not have equal equal URIs. Typically, recipient lists created by UACs will not have
(or duplicated) URI entries, thus, it is not expected to contain URIs equal (or duplicate) URI entries, thus, it is not expected to contain
tagged with the 'count' attributes. However, URI-lists created by URIs tagged with 'count' attributes. However, recipient-history
URI-list servers can contain duplicated anonymized URIs, thus, it is lists can contain duplicated anonymized URIs, therefore, it is
expected that URI-list created by URI-list servers will contain expected that recipient-history lists will contain 'count'
'count' attributes. The default value of the 'count' attribute is attributes. The default value of the 'count' attribute is "1".
"1".
The 'capacity', '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 'capacity', '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.
5. XML Schema 5. XML Schema
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:capacity" <xs:schema targetNamespace="urn:ietf:params:xml:ns:copycontrol"
xmlns="urn:ietf:params:xml:ns:capacity" xmlns="urn:ietf:params:xml:ns:copycontrol"
xmlns:rls="urn:ietf:params:xml:ns:resource-lists" xmlns:rls="urn:ietf:params:xml:ns:resource-lists"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" elementFormDefault="qualified"
attributeFormDefault="unqualified"> attributeFormDefault="unqualified">
<xs:annotation> <xs:annotation>
<xs:documentation xml:lang="en"> <xs:documentation xml:lang="en">
Adds the capacity, anonymize, and count attributes Adds the copyControl, anonymize, and count attributes
to URIs included in a resource list. to URIs included in a resource list.
</xs:documentation> </xs:documentation>
</xs:annotation> </xs:annotation>
<xs:import namespace="urn:ietf:params:xml:ns:resource-lists" <xs:import namespace="urn:ietf:params:xml:ns:resource-lists"
schemaLocation="urn:ietf:params:xml:schema:resource-lists"/> schemaLocation="urn:ietf:params:xml:schema:resource-lists"/>
<xs:attribute name="capacity"> <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 URI-list that SIP requests. The first example in Figure 3 shows a recipient list
the UAC sends to the URI-list server. This corresponds to a list that the UAC sends to the URI-list server. This corresponds to a
that will be included in the flow F2 in Figure 1. The list contains list that will be included in the flow F2 in Figure 1. The recipient
a flat list according to the resource list data format [7]. Each list contains a flat list according to the resource list data format
resource indicates the capacity of a resource. Some of the resources [7]. Each resource indicates the copy control of a resource with a
are also attributed with the 'anonymize' attribute. This provides an 'copyControl' attribute. Some of the resources are also marked with
indication to the URI-list service for not disclosing their URIs in a the 'anonymize' attribute. This provides an indication to the URI-
URI-list. The last two <entry> elements are attributed with a "bcc" list service for not disclosing their URIs in a recipient-history
'capacity'. This provides an indication to the URI-list service for list. The last two <entry> elements are marked with a 'copyControl'
removing these URIs from the outgoing URI-lists. attribute of "bcc". This 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:capacity"> xmlns:cp="urn:ietf:params:xml:ns:copycontrol">
<list> <list>
<entry uri="sip:bill@example.com" cp:capacity="to" /> <entry uri="sip:bill@example.com" cp:copyControl="to" />
<entry uri="sip:randy@example.net" cp:capacity="to" <entry uri="sip:randy@example.net" cp:copyControl="to"
cp:anonymize="true"/> cp:anonymize="true"/>
<entry uri="sip:eddy@example.com" cp:capacity="to" <entry uri="sip:eddy@example.com" cp:copyControl="to"
cp:anonymize="true"/> cp:anonymize="true"/>
<entry uri="sip:joe@example.org" cp:capacity="cc" /> <entry uri="sip:joe@example.org" cp:copyControl="cc" />
<entry uri="sip:carol@example.net" cp:capacity="cc" <entry uri="sip:carol@example.net" cp:copyControl="cc"
cp:anonymize="true"/> cp:anonymize="true"/>
<entry uri="sip:ted@example.net" cp:capacity="bcc" /> <entry uri="sip:ted@example.net" cp:copyControl="bcc" />
<entry uri="sip:andy@example.com" cp:capacity="bcc" /> <entry uri="sip:andy@example.com" cp:copyControl="bcc" />
</list> </list>
</resource-lists> </resource-lists>
Figure 3: URI-list sent from the UAC to the URI-list server Figure 3: Recipient list sent from the UAC to the URI-list server
Upon reception of the SIP request containing the URI-list of Figure 3 Upon receipt of the SIP request containing the recipient list of
the URI-list service creates a SIP request for each of the URIs Figure 3 the URI-list server creates a SIP request to each of the
listed in the URI-list (so, in our example, it creates 7 SIP URIs listed in the recipient list (so, in our example, it creates 7
requests). Each outgoing SIP request contains a copy of the same SIP requests). The URI-list server processes the recipient list and
processed outgoing URI-list. The process is as follows: the URI-list creates a recipient-history list that is included in each of the
service creates a new URI-list, based on the received one, but with outgoing SIP requests. The process is as follows: the URI-list
changes. First it copies all the URIs (<entry> elements) tagged with server creates a new recipient-history list, based on the recipient
the "to" or "cc" 'capacity' which do not contain an 'anonymize' list, but with changes. First it copies all the URIs (<entry>
attribute (or when the 'anonymize' attribute is set to "false"). elements) marked with the "to" or "cc" 'copyControl' attributes,
Then all the URIs tagged with a 'capacity' attribute set to "to" and which do not contain an 'anonymize' attribute (or when the
'anonymize' set to "true" are replaced by an anonymous URI, such as 'anonymize' attribute is set to "false"). Then all the URIs marked
"sip:anonymous@anonymous.invalid". In this entry it also adds the with a 'copyControl' attribute set to "to" and 'anonymize' attribute
original 'capacity' attribute ("to" in our example), and it adds a set to "true" are replaced with an anonymous URI, such as
'count' attribute with the number of anonymous entries with this "sip:anonymous@anonymous.invalid". In this entry the URI-list server
capacity ("2" in our example). Then the URI-list service does the also adds the original value of the 'copyControl' attribute ("to" in
same operation to the URIs tagged with the 'capacity' attribute set our example), and it adds a 'count' attribute containing the number
to "cc" and 'anonymize' attribute set to "true", adding also the of anonymous entries in this group ("2" in our example). Then the
'count' attribute containing the number of anonymous attributes with URI-list server does the same operation to the URIs tagged with the
this capacity ("1" in the example). Last, the URI-list service 'copyControl' attribute set to "cc" and 'anonymize' attribute set to
completely removes URIs tagged with the "bcc" 'capacity'. The result "true", adding also the 'count' attribute containing the number of
URI-list if shown in Figure 4. anonymous attributes in this group ("1" in the example). Last, the
URI-list server completely removes URIs marked with the "bcc"
'copyControl' attribute. The resulting recipient-history list is
shown in 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:capacity"> xmlns:cp="urn:ietf:params:xml:ns:copycontrol">
<list> <list>
<entry uri="sip:bill@example.com" cp:capacity="to" /> <entry uri="sip:bill@example.com" cp:copyControl="to" />
<entry uri="sip:anonymous@anonymous.invalid" cp:capacity="to" <entry uri="sip:anonymous@anonymous.invalid" cp:copyControl="to"
cp:count="2"/> cp:count="2"/>
<entry uri="sip:joe@example.org" cp:capacity="cc" /> <entry uri="sip:joe@example.org" cp:copyControl="cc" />
<entry uri="sip:anonymous@anonymous.invalid" cp:capacity="cc" <entry uri="sip:anonymous@anonymous.invalid" cp:copyControl="cc"
cp:count="1"/> cp:count="1"/>
</list> </list>
</resource-lists> </resource-lists>
Figure 4: URI-List sent from the URI-list server to each recipient Figure 4: Recipient-history list sent from the URI-list server to
each recipient
7. Carrying URI-lists in SIP 7. Carrying URI-lists in SIP
A SIP User Agent Client (UAC) 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 [9],
the UAC adds a Content-Disposition [2] header field set to the value the UAC adds a Content-Disposition [2] header field set to the value
'recipient-list'. Typically UACs send these 'recipient-list' bodies 'recipient-list'. Typically UACs send these 'recipient-list' bodies
to URI-list services (this corresponds to flow F1 in Figure 1). A to URI-list services (this corresponds to flow F1 in Figure 1). A
body whose Content-Disposition type is 'recipient-list' contains a body whose Content-Disposition type is 'recipient-list' contains a
URI-list with list of intended recipients of the SIP request. The URI-list that includes the intended recipients of the SIP request,
<entry> element in the URI-list MAY also include a 'capacity' and something known throughout this document as a recipient list. The
<entry> element in the URI-list MAY also include a 'copyControl' and
'anonymize' attributes, as specified in Section 4. 'anonymize' attributes, as specified in Section 4.
To enable the capability of the intended recipients to become aware To be able to inform intended recipients of who else is receiving a
of who else is receiving a copy of the SIP request, we define a new copy of the SIP request, we define a new mail disposition type to be
mail disposition type to be included in a Content-Disposition [2] included in a Content-Disposition [2] header field of a SIP request.
header field of a SIP request. The value of this new disposition The value of this new disposition type is 'recipient-list-history'
type is 'recipient-list-history' and its purpose is to indicate a and its purpose is to indicate a list of recipients that a SIP
list of recipients that a SIP request was sent to. A body whose request was sent to, something known throughout this document as a
Content-Disposition type is 'recipient-list-history' contains a URI- recipient-history list. A body whose Content-Disposition type is
list with the visible (including anonymized) recipients of the SIP 'recipient-list-history' contains a URI-list with the visible
request. The <entry> element in the URI-list MAY also include a (including anonymized) recipients of the SIP request. The <entry>
'capacity' and 'count' attributes, as specified in Section 4. element in the URI-list MAY also include a 'copyControl' and 'count'
attributes, as specified in Section 4.
It is often desired that, if the intended recipient of the SIP On sending a SIP request that contains a recipient-history list, if
request does not support this specification, still the SIP request the intended recipient does not support this specification, the SIP
does not fail. In order to provide the maximum probability of request should not fail. In order to ensure successful receipt of
success of those requests that include 'recipient-list-history' the SIP requests that include 'recipient-list-history' bodies, User
bodies, User Agents (such as URI-list services) that build SIP Agents (such as URI-list servers) that build SIP requests with the
requests with the Content-Disposition header field set to 'recipient- Content-Disposition header field set to 'recipient-list-history'
list-history' SHOULD add a 'handling' parameter [4] set to SHOULD add a 'handling' parameter [4] set to "optional". Otherwise,
"optional". the SIP request could fail and never be received by the intended
recipient.
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. [9] discusses issues related to SIP URI-list services.
Implementations of this specification MUST follow the security- Implementations of this specification MUST follow the security-
related rules in the Framework and Security Considerations for SIP related rules in the Framework and Security Considerations for SIP
URI-List Services [9]. These rules include mandatory authentication URI-List Services [9]. These rules include mandatory authentication
and authorization of clients, and opt-in lists. 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 was sent over a secured channel with requests unless the SIP message is sent over a secured channel, by
Transport Layer Security (TLS) [3] or unless the URI-list body itself using any of the available SIP mechanisms, such as Transport Layer
is encrypted with S/MIME [8]. Therefore, it is RECOMMENDED that URI- Security (TLS) [3], or unless the URI-list body itself is encrypted
list bodies are encrypted with S/MIME [8] or that the SIP request is with, e.g., S/MIME [8]. Therefore, it is RECOMMENDED that URI-list
encrypted with TLS [3]. bodies are encrypted with S/MIME [8] or that the SIP request is
encrypted with TLS [3] 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
The following sections instruct the IANA to register: a new The following sections instruct the IANA to register: a new
disposition type, a new SIP option-tag, a new XML namespace, and a disposition type, a new XML namespace, and a new XML schema.
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 should be registered
in the IANA registry of Mail Content Disposition Values with the in the IANA registry of Mail Content Disposition Values with the
following registration data: following registration data:
+------------------------+------------------------------+-----------+ +------------------------+------------------------------+-----------+
| Name | Description | Reference | | Name | Description | Reference |
skipping to change at page 11, line 25 skipping to change at page 12, line 37
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 XML registry, as This section registers a new XML namespace in the XML registry, as
per the guidelines in RFC 3688 [6]. per the guidelines in RFC 3688 [6].
URI: The URI for this namespace is urn:ietf:params:xml:ns:capacity. 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"?>
<!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>Capacity Namespace</title> <title>Copy Control Namespace</title>
</head> </head>
<body> <body>
<h1>Namespace for the Capacity Attribute Extension <h1>Namespace for the Copy Control Attribute Extension
in Resource Lists</h1> in Resource Lists</h1>
<h2>urn:ietf:params:xml:ns:capacity</h2> <h2>urn:ietf:params:xml:ns:copycontrol</h2>
<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 XML registry per the This section registers a new XML schema in the XML registry per the
procedures in RFC 3688 [6]. procedures in RFC 3688 [6].
URI: urn:ietf:params:xml:schema:capacity 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, and Atsushi Sato Thanks to Dean Willis, Jari Urpalainen, Pekka Kuure, Atsushi Sato,
for reviewing this document and providing helpful comments. Brian Rosen, Mary Barnes, and James Polk for reviewing this document
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 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Troost, R., Dorner, S., and K. Moore, "Communicating [2] Troost, R., Dorner, S., and K. Moore, "Communicating
Presentation Information in Internet Messages: The Content- Presentation Information in Internet Messages: The Content-
skipping to change at page 13, line 13 skipping to change at page 14, line 40
draft-ietf-simple-xcap-list-usage-05 (work in progress), draft-ietf-simple-xcap-list-usage-05 (work in progress),
February 2005. February 2005.
[8] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions [8] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", RFC 3851, (S/MIME) Version 3.1 Message Specification", RFC 3851,
July 2004. July 2004.
[9] Camarillo, G. and A. Roach, "Framework and Security [9] Camarillo, G. and A. Roach, "Framework and Security
Considerations for Session Initiation Protocol (SIP) Uniform Considerations for Session Initiation Protocol (SIP) Uniform
Resource Identifier (URI)-List Services", Resource Identifier (URI)-List Services",
draft-ietf-sipping-uri-services-05 (work in progress), draft-ietf-sipping-uri-services-06 (work in progress),
January 2006. September 2006.
11.2. Informational References 11.2. Informational References
[10] Camarillo, G. and A. Johnston, "Conference Establishment Using [10] Camarillo, G. and A. Johnston, "Conference Establishment Using
Request-Contained Lists in the Session Initiation Protocol Request-Contained Lists in the Session Initiation Protocol
(SIP)", draft-ietf-sipping-uri-list-conferencing-05 (work in (SIP)", draft-ietf-sip-uri-list-conferencing-00 (work in
progress), February 2006. progress), September 2006.
[11] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE [11] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE
Requests in the Session Initiation Protocol (SIP)", Requests in the Session Initiation Protocol (SIP)",
draft-ietf-sipping-uri-list-message-08 (work in progress), draft-ietf-sip-uri-list-message-00 (work in progress),
September 2006. September 2006.
Authors' Addresses Authors' Addresses
Miguel A. Garcia-Martin Miguel A. Garcia-Martin
Nokia Nokia
P.O.Box 407 P.O.Box 407
NOKIA GROUP, FIN 00045 NOKIA GROUP, FIN 00045
Finland Finland
 End of changes. 59 change blocks. 
224 lines changed or deleted 289 lines changed or added

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