The Framework and Security Considerations for Session Initiation Protocol (SIP) URI-List Services describes a generic framework for carrying Uniform Resource Identifier (URI)-lists in SIP messages. Specifically, the document provides a common framework for specific implementations of URI-list services, such as conferences initiated with INVITE requests or Multiple-recipient MESSAGE requests . Common to all URI-list services is the presence of a SIP request that contains a collection of resources, typically expressed as an XML resource list . SIP requests carrying resource lists can appear either in requests received by the URI-list server, indicating the list of intended recipients, or in each of the requests that the URI-list server sends to recipients, indicating the list of recipients of the same SIP request. Although the XML resource list provides a powerful mechanism for describing a list of resources, there is a need for a copy control attribute to determine whether a resource is receiving a SIP request as a primary recipient, a carbon copy, or a blind carbon copy. This is similar to common e-mail systems, where the sender can categorize each recipient as To, Cc, or Bcc recipient. This document addresses this problem by providing an extension to the XML resource list that enables the sender to supply a copy control attribute that labels each recipient as a "to", "cc", or "bcc" recipient. This attribute indicates whether the recipient is receiving a primary copy of the SIP request, a carbon copy, or a blind carbon copy. Additionally, we provide the sender with the capability of indicating in the URI-list that one or more resources should be anonymized, so that some recipients' URIs are not disclosed to the other recipients. Instead, these URIs are replaced with anonymous URIs. The remainder of this document is organized as follows: introduces the terminology used throughout this specification. gives an overview of operation. formally defines an extension to URI-lists. The XML schema definition is provided in . shows examples of the URI-lists with the extensions defined in this document. discusses the implications of carrying URI-lists in SIP messages.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 and indicate requirement levels for compliant implementations. SIP application service that receives a SIP request containing a URI-list and sends a similar SIP request to each URI in the list. The intended final recipient of the request to be generated by URI-list service. An attribute assigned by the sender to a URI in a XML resource list. Its purpose is to indicate to the recipient whether he is getting a primary, carbon, or blind carbon copy of the SIP request. 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. 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.

depicts a general overview of the operation of a URI-list server. A SIP User Agent Client (UAC) issuer sends a SIP request (F1) to a URI-list server containing a recipient list. The URI-list 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.

| | | | | F2. 2xx response | | | | |<---------------- | F3. SIP request | | | | | (recp-hist.list)| | | | | --------------->| | | | | F4. SIP request | | | | | (recp-hist.list)| | | | | -------------------------->| | | | F5. SIP request | | | | | (recp-hist.list)| | | | | ------------------------------------->| | | F6. 200 OK | | | | |<--------------- | | | | | F7. 200 OK | | | | |<-------------------------- | | | | F8. 200 OK | | | | |<------------------------------------- | | | | | | | | | | | | | | | | ]]> The URI-list mechanism allows a sender to specify multiple targets for a SIP request by including a recipient XML resource list in the body of the SIP request. This recipient list includes the target URIs of the SIP request (the actual procedures are method specific and outside the scope of this document). Each target URI may also be marked with a copy control attribute to indicate the copy level in which the recipient is receiving the SIP request. This is achieved by the sender qualifying each URI in the URI-list with a 'copyControl' attribute. The available values of the 'copyControl' attribute include "to", "cc", and "bcc" (analogous to e-mail). This is discussed in greater detailed in . When the URI-list server expands the request to each recipient, the URI-list server 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 recipient-history list those URIs marked with a "bcc" copy control, although it is able to preserve the address of a "bcc" tagged URI when it matches the URI of the recipient of the SIP request (this is described later in ). 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 a copy of the SIP request, 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. In addition to the 'copyControl' attribute for a URI in an XML resource list, we define a second boolean attribute called 'anonymize'. The sender of a SIP request can mark a URI in a recipient XML resource list with the 'anonymize' attribute to 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 knowledge to the recipients of a SIP request of the number of additional visible recipients whose URIs have not been disclosed. There are cases when the sender marks several URIs with the 'anonymize' attribute. The URI-list server can group the anonymized URIs in a single anonymized URI within its copy control level, and provide a count of the number of anonymized URIs. To support this scenario, we define a new 'count' attribute to a URI in the 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. Initially, it may be thought that the 'anonymize' attribute overlaps with the "bcc" value of the 'copyControl' attribute. However, there are differences between them. If the sender qualifies a URI with a 'copyControl' attribute of "bcc" in the recipient XML resource list, the URI-list server will typically remove that URI from the recipient-history XML resource list (unless the URI-list server decides to preserve a "bcc" marked URI when that URI is itself the recipient of the SIP request). Recipients of the SIP request will not notice that one or more extra "bcc" 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 are not disclosed.

This document defines an extension to the XML resource list data format that allows the sender to indicate a copy control attribute that qualifies a recipient with a copy control level. We define a new 'copyControl' attribute to the <entry> element of the resource list document format . The 'copyControl' attribute has similar semantics to the type of destination address in e-mail systems. It can take the values "to", "cc", and "bcc". A "to" value of the 'copyControl' attribute indicates that the resource is considered a primary recipient of the SIP request. A "cc" value indicates that the resource receives a carbon copy of the SIP request. A "bcc" value indicates that the resource receives a blind carbon copy of the SIP request (i.e., this URI is not disclosed to other recipients of the SIP request). The default 'copyControl' value is "bcc". That is, the absence of a 'copyControl' attribute MUST be treated as if the 'copyControl' was set to "bcc". When creating a recipient-history list, URI-list servers use "bcc" 'copyControl' attributes to route SIP requests. In addition, URI-list servers behave similarly to e-mail systems with respect to the treatment of these URIs marked with a "bcc" copy control, because they have two ways of treating "bcc" marked URIs. URI-list servers MUST treat these "bcc" marked URIs in either of the following two ways: URI-list servers MUST remove all URIs marked with a "bcc" copy control in recipient-history lists. This mechanism allows URI-list servers to send the same recipient-history list to each recipient of the SIP request. However, recipients who are tagged with "bcc" values are not explicitly informed about it. URI-list servers MUST preserve with a "bcc" copy control in the recipient-history list the URI that identifies the recipient (if any) and MUST remove the remaining URIs marked with a "bcc" copy control. Consequently, each recipient receives a different recipient-history list. However, recipients who have been marked with a "bcc" copy control are explicitly informed about it. Implementations that are able to receive recipient-history lists must pay attention to the contents of the list. If the recipient's URI is not included in recipient-history list or if it is included but tagged with a "bcc" copy control, then implementations SHOULD prevent the user from replying to all the recipients of the SIP request. This would allow the non-blind recipients to notice the existence of blind recipients of the SIP request. A new 'anonymize' attribute can be included in a <entry> element of the resource list document format . If set to a "true" value, it provides an indication to the URI-list server for not disclosing the URI itself in a URI-list sent to the recipient, but instead, to 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 the SIP URI "sip:anonymous@anonymous.invalid" in recipient-history lists. The default value of the 'anonymize' attribute is "false". There are occasions where the URI-list server encounters the same URI entry duplicated in a resource list, where duplicated URI entries are tagged with the same or different values of the 'copyControl' attribute. There are no reasonable usages that justify duplicated URIs in resource lists, thus, this is considered an error. URI-list 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 URI entry duplicated in a resource list, it should send at most a single copy of the request to that intended recipient. For each set of duplicated URI entries, the URI-list server MUST select the highest precedence value of the 'copyControl' attribute for the same intended recipient. The order of precedence of the values of the 'copyControl' attribute is: "to", "cc", and "bcc". Once the URI-list server has selected a value for the 'copyControl' attribute of an intended recipient, the URI-list can continue processing the request. Processing of URIs tagged with a 'copyControl' attribute set to a "bcc" value has higher precedence over the 'anonymize' attribute. 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 'anonymize' attribute will be ignored. Therefore, the 'anonymize' 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 the resource list document format . It provides the number of equal URIs. Typically, recipient lists created by UACs will not have equal (or duplicate) URI entries, thus, it is not expected to contain URIs tagged with 'count' attributes. However, recipient-history lists can contain duplicated anonymized URIs, therefore, it is expected that recipient-history lists will contain 'count' attributes. The default value of the 'count' attribute is "1". The 'copyControl', 'anonymize', and 'count' attributes SHOULD be 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 <external> elements). describes the format of the 'copyControl', 'anonymize', and 'count' attributes. Implementations according to this specification MUST support this XML Schema. Implementations that receive recipient-history lists must pay attention to the contents of the list. If the recipient's URI is not included in recipient-history list or if it is included but tagged with a "bcc" copy control, then they SHOULD prevent the user from replying to all the recipients of the SIP request. This would allow the non-blind recipients to notice the existence of blind recipients in the original SIP request.

Adds the copyControl, anonymize, and count attributes to URIs included in a resource list. ]]>

This section shows two examples of URI-lists that can be included in SIP requests. The first example in shows a recipient list that the UAC sends to the URI-list server. This corresponds to a list that will be included in the flow F2 in . The recipient list contains a flat list according to the resource list data format specified in RFC 4826 . Each resource indicates the copy control of a resource with a 'copyControl' attribute. Some of the resources are also marked with the 'anonymize' attribute. This provides an indication to the URI-list service for not disclosing their URIs in a recipient-history list. The last two <entry> elements are marked with a 'copyControl' attribute of "bcc". This provides an indication to the URI-list server for removing these URIs in the recipient-history list.

]]> Upon receipt of the SIP request containing the recipient list of the URI-list server creates a SIP request to each of the URIs listed in the recipient list (so, in our example, it creates 7 SIP requests). The URI-list server processes the recipient list and creates a recipient-history list that is included in each of the outgoing SIP requests. The process is as follows: the URI-list server creates a new recipient-history list, based on the recipient list, but with changes. First it copies all the URIs (<entry> elements) marked with the "to" or "cc" 'copyControl' attributes, which do not contain an 'anonymize' attribute (or when the 'anonymize' attribute is set to "false"). Then all the URIs marked with a 'copyControl' attribute set to "to" and 'anonymize' attribute set to "true" are replaced with the SIP anonymous URI "sip:anonymous@anonymous.invalid". In this entry the URI-list server also adds the original value of the 'copyControl' attribute ("to" in our example), and it adds a 'count' attribute containing the number of anonymous entries in this group ("2" in our example). Then the URI-list server does the same operation to the URIs tagged with the 'copyControl' attribute set to "cc" and 'anonymize' attribute set to "true", adding also the 'count' attribute containing the number of anonymous attributes in this group ("1" in the example). Last, the URI-list server removes all URIs marked with the "bcc" 'copyControl' attribute. The resulting recipient-history list is shown in .

]]>

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 the list of intended recipients. On doing so, as specified in the Framework and Security Considerations for SIP URI-List Services , the UAC adds a Content-Disposition header field set to the value 'recipient-list'. Typically UACs send these 'recipient-list' bodies to URI-list services (this corresponds to flow F1 in ). A body whose Content-Disposition type is 'recipient-list' contains a URI-list that includes the intended recipients of the SIP request, 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 . 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 included in a Content-Disposition header field of a SIP request. The value of this new disposition type is 'recipient-list-history' and its purpose is to indicate a list of recipients that a SIP request was sent to, something known throughout this document as a recipient-history list. A body whose Content-Disposition type is 'recipient-list-history' contains a URI-list with the visible (including anonymized) recipients of the SIP request. The <entry> element in the URI-list MAY also include a 'copyControl' and 'count' attributes, as specified in . On sending a SIP request that contains a recipient-history list, if the intended recipient does not support this specification, the SIP request should not fail. In order to ensure successful receipt of the SIP requests that include 'recipient-list-history' bodies, User Agents (such as URI-list servers) that build SIP requests with the Content-Disposition header field set to 'recipient-list-history' SHOULD add a 'handling' parameter set to "optional". Otherwise, the SIP request could fail and never be received by the intended recipient. Even though Message Body Handling in SIP 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.

The Framework and Security Considerations for SIP URI-List Services discusses issues related to SIP URI-list services. Implementations of this specification MUST follow the security-related rules in the Framework and Security Considerations for SIP URI-List Services. These rules include mandatory authentication and authorization of clients, and opt-in lists. User Agent Clients SHOULD NOT hand SIP requests containing URI-list services to unauthenticated and untrusted parties. This is to avoid man-in-the-middle attacks or acquiring URI-lists for performing SPAM attacks. URI-lists may contain private information, such as SIP URIs. It is therefore not desirable that these URI-lists are known by third parties. Eavesdroppers are able to watch URI-lists contained in SIP requests unless the SIP message is sent over a secured channel, by using any of the available SIP mechanisms, such as Transport Layer Security (TLS) , or unless the URI-list body itself is encrypted with, e.g., S/MIME. Therefore, it is RECOMMENDED that URI-list bodies are encrypted with S/MIME or that the SIP request is encrypted with TLS or any other suitable encryption mechanism. Note that this URI-list does not indicate the actual participants in the session. It indicates only the URIs invited and that might accept the request. It does not assert that these parties actually exist, that they are reachable at the given URI, or that they have accepted the invitation. No inferences about billing should be made from this information. It is subject to spoofing by loading the list with falsified content. Issuers of SIP request use the "bcc" copy control attribute described in to facilitate sending SIP requests to recipients without revealing the URIs of one or more of the other recipients. Mishandling this use of "bcc" copy control has implications for confidential information that might be revealed, which could eventually lead to security problems through knowledge of even the existence of a particular URI. For example, if using the first method described in , where the "bcc" tagged URIs are removed from recipient-history list, blind recipients have no explicit indication that they have been sent a blind copy of the SIP request, except insofar as their URI does not appear in the recipient-history list. Because of this, one of the blind URIs could potentially send a reply to all of the shown recipients and accidentally reveal that the message went to the blind recipient. When the second method from is used, the blind recipient's address appears in the recipient-history list of a separate copy of the list. If the "bcc" tagged URI sent contains all of the "bcc" tagged URIs, all of the "bcc" recipients will be seen by each "bcc" recipient. Even if a separate message is sent to each "bcc" recipient with only the individual's URI, implementations still need to be careful to process replies to the message as per so as not to accidentally reveal the blind recipient to other recipients.

The following sections instruct the IANA to register: a new disposition type, a new XML namespace, and a new XML schema.

defines a new 'recipient-list-history' value of the Mail Content Disposition Values registry. This value should be registered in the IANA registry of Mail Content Disposition Values with the following registration data: Name Description Reference recipient-list-history the body contains a list of URIs that indicates the recipients of the SIP request [RFCXXXX] Note to IANA and the RFC editor: replace RFCXXXX above with the RFC number of this specification.

This section registers a new XML namespace in the IANA XML registry, as per the guidelines in RFC 3688 . URI: The URI for this namespace is urn:ietf:params:xml:ns:copycontrol Registrant Contact: IETF, SIPPING working group, (sipping@ietf.org), Miguel Garcia-Martin (miguel.an.garcia@nokia.com). XML:

Copy Control Namespace

Namespace for the Copy Control Attribute Extension in Resource Lists

urn:ietf:params:xml:ns:copycontrol

See RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this specification.].

END ]]>

This section registers a new XML schema in the IANA XML registry per the procedures in RFC 3688 . URI: urn:ietf:params:xml:schema:copycontrol Registrant Contact: IETF, SIPPING working group, (sipping@ietf.org), Miguel Garcia-Martin (miguel.an.garcia@nokia.com). The XML for this schema can be found as the sole content of .

Thanks to Dean Willis, Jari Urpalainen, Pekka Kuure, Atsushi Sato, Brian Rosen, Mary Barnes, James Polk, Brian E. Carpenter, and Chris Newman for reviewing this document and providing helpful comments.