GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5364

Network Working Group M. Garcia-Martin Request for Comments: 5364 G. Camarillo Category: Standards Track Ericsson

                                                          October 2008
Extensible Markup Language (XML) Format Extension for Representing
             Copy Control Attributes in Resource Lists

Status of This Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Abstract

 In certain types of multimedia communications, a Session Initiation
 Protocol (SIP) request is distributed to a group of SIP User Agents
 (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 email systems.

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
 2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
 3.  Overview of Operation  . . . . . . . . . . . . . . . . . . . .  3
 4.  Extension to the Resource List Data Format . . . . . . . . . .  6
 5.  XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . .  8
 6.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
 7.  Carrying URI Lists in SIP  . . . . . . . . . . . . . . . . . . 10
 8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
 9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   9.1.  Disposition Type Registration  . . . . . . . . . . . . . . 13
   9.2.  XML Namespace Registration . . . . . . . . . . . . . . . . 13
   9.3.  XML Schema Registration  . . . . . . . . . . . . . . . . . 14
 10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
   11.2. Informative References . . . . . . . . . . . . . . . . . . 15

Garcia-Martin & Camarillo Standards Track [Page 1] RFC 5364 Copy Control Attribute in Resource Lists October 2008

1. Introduction

 RFC 5363 [RFC5363] describes a generic framework for carrying Uniform
 Resource Identifier (URI) lists in SIP [RFC3261] messages.
 Specifically, the document provides a common framework for specific
 implementations of URI-list services, such as conferences initiated
 with INVITE requests [RFC5366] or Multiple-recipient MESSAGE requests
 [RFC5365].
 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 [RFC4826].  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 [RFC4826] 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 email systems, where the sender can
 categorize each recipient as a "to", "cc", or "bcc" recipient.
 This document addresses this problem by providing an extension to the
 XML resource list [RFC4826] 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: Section 2
 introduces the terminology used throughout this specification.
 Section 3 gives an overview of operation.  Section 4 formally defines
 an extension to URI lists.  The XML schema definition is provided in
 Section 5.  Section 6 shows examples of the URI lists with the
 extensions defined in this document.  Section 7 discusses the
 implications of carrying URI lists in SIP messages.

Garcia-Martin & Camarillo Standards Track [Page 2] RFC 5364 Copy Control Attribute in Resource Lists October 2008

2. Terminology

 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
 [RFC2119] and indicate requirement levels for compliant
 implementations.
 URI-list service:  SIP application service that receives a SIP
    request containing a URI list and sends a similar SIP request to
    each URI in the list.
 Intended recipient:  The intended final recipient of the request to
    be generated by URI-list service.
 Copy control:   An attribute assigned by the sender to a URI in an
    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.
 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
 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.

Garcia-Martin & Camarillo Standards Track [Page 3] RFC 5364 Copy Control Attribute in Resource Lists October 2008

 +--------+        +---------+        +--------+ +--------+ +--------+
 |SIP UAC |        | URI-list|        |intended| |intended| |intended|
 | issuer |        |  server |        | recip. | | recip. | | recip. |
 |        |        |         |        |   1    | |   2    | |   3    |
 +--------+        +---------+        +--------+ +--------+ +--------+
     |                  |                 |          |          |
     | F1 SIP request   |                 |          |          |
     |  (recipt. list)  |                 |          |          |
     | ---------------->|                 |          |          |
     | 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      |          |          |
     |                  |<------------------------------------- |
     |                  |                 |          |          |
     |                  |                 |          |          |
     |                  |                 |          |          |
                    Figure 1: Example of operation
 The URI-list mechanism allows a sender to specify multiple targets
 for a SIP request by including a recipient XML resource list
 [RFC4826] 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
 email).  This is discussed in greater detail in Section 4.  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 that are

Garcia-Martin & Camarillo Standards Track [Page 4] RFC 5364 Copy Control Attribute in Resource Lists October 2008

 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 Section 4).  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.

Garcia-Martin & Camarillo Standards Track [Page 5] RFC 5364 Copy Control Attribute in Resource Lists October 2008

4. Extension to the Resource List Data Format

 This document defines an extension to the XML resource list data
 format [RFC4826] 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 [RFC4826].  The 'copyControl' attribute
 has similar semantics to the type of destination address in email
 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 email systems [RFC2822] 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:
 o  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.
 o  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 the 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.

Garcia-Martin & Camarillo Standards Track [Page 6] RFC 5364 Copy Control Attribute in Resource Lists October 2008

 A new 'anonymize' attribute can be included in a <entry> element of
 the resource list document format [RFC4826].  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 to 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 server 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 an <entry> element of
 the resource list document format [RFC4826].  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".

Garcia-Martin & Camarillo Standards Track [Page 7] RFC 5364 Copy Control Attribute in Resource Lists October 2008

 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).
 Section 5 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.

5. XML Schema

 <?xml version="1.0" encoding="UTF-8"?>
 <xs:schema targetNamespace="urn:ietf:params:xml:ns:copycontrol"
     xmlns="urn:ietf:params:xml:ns:copycontrol"
     xmlns:rls="urn:ietf:params:xml:ns:resource-lists"
     xmlns:xs="http://www.w3.org/2001/XMLSchema"
     elementFormDefault="qualified"
     attributeFormDefault="unqualified">
     <xs:annotation>
       <xs:documentation xml:lang="en">
          Adds the copyControl, anonymize, and count attributes
          to URIs included in a resource list.
       </xs:documentation>
     </xs:annotation>
    <xs:import namespace="urn:ietf:params:xml:ns:resource-lists"
          schemaLocation="urn:ietf:params:xml:schema:resource-lists"/>
     <xs:attribute name="copyControl">
        <xs:simpleType>
           <xs:restriction base="xs:string">
              <xs:enumeration value="to"/>
              <xs:enumeration value="cc"/>
              <xs:enumeration value="bcc"/>
           </xs:restriction>
        </xs:simpleType>
     </xs:attribute>

Garcia-Martin & Camarillo Standards Track [Page 8] RFC 5364 Copy Control Attribute in Resource Lists October 2008

    <xs:attribute name="anonymize" type="xs:boolean" default="false"/>
    <xs:attribute name="count" type="xs:nonNegativeInteger"
                               default="1"/>
 </xs:schema>
   Figure 2: XML schema of the extension to the resource list format

6. Examples

 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
 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 contains a flat list according to the resource list data format
 specified in RFC 4826 [RFC4826].  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.
 <?xml version="1.0" encoding="UTF-8"?>
 <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
           xmlns:cp="urn:ietf:params:xml:ns:copycontrol">
   <list>
     <entry uri="sip:bill@example.com" cp:copyControl="to" />
     <entry uri="sip:randy@example.net" cp:copyControl="to"
                                        cp:anonymize="true"/>
     <entry uri="sip:eddy@example.com" cp:copyControl="to"
                                       cp:anonymize="true"/>
     <entry uri="sip:joe@example.org" cp:copyControl="cc" />
     <entry uri="sip:carol@example.net" cp:copyControl="cc"
                                        cp:anonymize="true"/>
     <entry uri="sip:ted@example.net" cp:copyControl="bcc" />
     <entry uri="sip:andy@example.com" cp:copyControl="bcc" />
   </list>
 </resource-lists>
   Figure 3: Recipient list sent from the UAC to the URI-list server
 Upon receipt of the SIP request containing the recipient list of
 Figure 3, the URI-list server creates a SIP request to each of the
 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

Garcia-Martin & Camarillo Standards Track [Page 9] RFC 5364 Copy Control Attribute in Resource Lists October 2008

 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
 Figure 4.
 <?xml version="1.0" encoding="UTF-8"?>
 <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
           xmlns:cp="urn:ietf:params:xml:ns:copycontrol">
   <list>
     <entry uri="sip:bill@example.com" cp:copyControl="to" />
     <entry uri="sip:anonymous@anonymous.invalid" cp:copyControl="to"
                                                  cp:count="2"/>
     <entry uri="sip:joe@example.org" cp:copyControl="cc" />
     <entry uri="sip:anonymous@anonymous.invalid" cp:copyControl="cc"
                                                  cp:count="1"/>
   </list>
 </resource-lists>
   Figure 4: Recipient-history list sent from the URI-list server to
                            each recipient

7. Carrying URI Lists in SIP

 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 RFC
 5363 [RFC5363], the UAC adds a Content-Disposition [RFC2183] 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 Figure 1).  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

Garcia-Martin & Camarillo Standards Track [Page 10] RFC 5364 Copy Control Attribute in Resource Lists October 2008

 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.
 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 [RFC2183] 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 Section 4.
 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 [RFC3204] set to "optional".
 Otherwise, the SIP request could fail and never be received by the
 intended recipient.
 Even though "Message Body Handling in SIP" [SIP_BODY] 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

 RFC 5363 [RFC5363] discusses issues related to SIP URI-list services.
 Implementations of this specification MUST follow the security-
 related rules in RFC 5363 [RFC5363].  These rules include opt-in
 lists and mandatory authentication and authorization of clients.
 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.

Garcia-Martin & Camarillo Standards Track [Page 11] RFC 5364 Copy Control Attribute in Resource Lists October 2008

 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) [RFC4346], or unless the URI-list body itself is
 encrypted with, e.g., S/MIME [RFC3851].  Therefore, it is RECOMMENDED
 that URI-list bodies are encrypted with S/MIME [RFC3851] or that the
 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
 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 Section 4 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 Section 4, where the "bcc" tagged URIs are
 removed from the 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 Section 4 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 Section 4 so
 as not to accidentally reveal the blind recipient to other
 recipients.

Garcia-Martin & Camarillo Standards Track [Page 12] RFC 5364 Copy Control Attribute in Resource Lists October 2008

9. IANA Considerations

 IANA has made registrations according to the following subsections: a
 new disposition type, a new XML namespace, and a new XML schema.

9.1. Disposition Type Registration

 Section 7 defines a new 'recipient-list-history' value of the Mail
 Content Disposition Values registry.  This value has been 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  | [RFC5364] |
 |                        | URIs that indicates the      |           |
 |                        | recipients of the request    |           |
 +------------------------+------------------------------+-----------+
  Table 1: Registration of the 'recipient-list-history' Mail Content
                           Disposition Value

9.2. XML Namespace Registration

 This section registers a new XML namespace in the IANA XML registry,
 as per the guidelines in RFC 3688 [RFC3688].
 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.a.garcia@ericsson.com).
 XML:
       BEGIN
       <?xml version="1.0"?>
       <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
         "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
       <html xmlns="http://www.w3.org/1999/xhtml">
       <head>
         <meta http-equiv="content-type"
            content="text/html;charset=iso-8859-1"/>
         <title>Copy Control Namespace</title>
       </head>
       <body>
         <h1>Namespace for the Copy Control Attribute Extension
         in Resource Lists</h1>

Garcia-Martin & Camarillo Standards Track [Page 13] RFC 5364 Copy Control Attribute in Resource Lists October 2008

         <h2>urn:ietf:params:xml:ns:copycontrol</h2>
         <p>See <a href="http://www.rfc-editor.org/rfc/rfc5364.txt">
             RFC5364</a>.</p>
       </body>
       </html>
       END

9.3. XML Schema Registration

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

10. Acknowledgments

 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.

11. References

11.1. Normative References

 [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC2183]   Troost, R., Dorner, S., and K. Moore, "Communicating
             Presentation Information in Internet Messages: The
             Content-Disposition Header Field", RFC 2183, August 1997.
 [RFC3204]   Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet,
             F., Watson, M., and M. Zonoun, "MIME media types for ISUP
             and QSIG Objects", RFC 3204, December 2001.
 [RFC3261]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
             A., Peterson, J., Sparks, R., Handley, M., and E.
             Schooler, "SIP: Session Initiation Protocol", RFC 3261,
             June 2002.
 [RFC3688]   Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
             January 2004.

Garcia-Martin & Camarillo Standards Track [Page 14] RFC 5364 Copy Control Attribute in Resource Lists October 2008

 [RFC3851]   Ramsdell, B., "Secure/Multipurpose Internet Mail
             Extensions (S/MIME) Version 3.1 Message Specification",
             RFC 3851, July 2004.
 [RFC4346]   Dierks, T. and E. Rescorla, "The Transport Layer Security
             (TLS) Protocol Version 1.1", RFC 4346, April 2006.
 [RFC4826]   Rosenberg, J., "Extensible Markup Language (XML) Formats
             for Representing Resource Lists", RFC 4826, May 2007.
 [RFC5363]   Camarillo, G. and A.B. Roach, "Framework and Security
             Considerations for Session Initiation Protocol (SIP) URI-
             List Services", RFC 5363, October 2008.

11.2. Informative References

 [RFC2822]   Resnick, P., "Internet Message Format", RFC 2822,
             April 2001.
 [RFC5366]   Camarillo, G. and A. Johnston, "Conference Establishment
             Using Request-Contained Lists in the Session Initiation
             Protocol (SIP)", RFC 5366, October 2008.
 [RFC5365]   Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient
             MESSAGE Requests in the Session Initiation Protocol
             (SIP)", RFC 5365, October 2008.
 [SIP_BODY]  Camarillo, G., "Message Body Handling in the Session
             Initiation Protocol (SIP)", Work in Progress,
             August 2008.

Garcia-Martin & Camarillo Standards Track [Page 15] RFC 5364 Copy Control Attribute in Resource Lists October 2008

Authors' Addresses

 Miguel A. Garcia-Martin
 Ericsson
 Via de los Poblados 13
 Madrid  28033
 Spain
 EMail: miguel.a.garcia@ericsson.com
 Gonzalo Camarillo
 Ericsson
 Hirsalantie 11
 Jorvas  02420
 Finland
 EMail: Gonzalo.Camarillo@ericsson.com

Garcia-Martin & Camarillo Standards Track [Page 16] RFC 5364 Copy Control Attribute in Resource Lists October 2008

Full Copyright Statement

 Copyright (C) The IETF Trust (2008).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at
 ietf-ipr@ietf.org.

Garcia-Martin & Camarillo Standards Track [Page 17]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5364.txt · Last modified: 2008/10/27 21:20 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki