view Side-By-Side changes

SIPPING Working Group                                   M. Garcia-Martin
Internet-Draft                                                     Nokia
Intended status: Standards Track                            G. Camarillo
Expires: March April 5, 2007                                          Ericsson
                                                       September 1,
                                                         October 2, 2006


Extensible Markup Language (XML) Format Extension for Representing
                 Capacity Copy
                  Control Attributes in Resource Lists
              draft-ietf-sipping-capacity-attribute-01.txt
              draft-ietf-sipping-capacity-attribute-02.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on March April 5, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document specifies an XML extension

   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 resource group.  This SIP request
   contains a list format
   for qualifiying resources with the capacity in of Uniform Resource Identifiers (URIs), which they are
   included in
   identify the resource list. recipients of the SIP request.  This URI-list is



Garcia-Martin & Camarillo  Expires March April 5, 2007                [Page 1]

Internet-Draft         Capacity  Copy Control Attribute in Resource Lists         September    October 2006


   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

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Overview . . . . . . . of operation  . . . . . . . . . . . . . . . . . . . .  4
   4.  Extension to the resource lists data format  . . . . . . . . .  5  6
   5.  XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . .  7  8
   6.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  7  8
   7.  Carrying URI-lists in SIP  . . . . . . . . . . . . . . . . . .  9 10
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10 11
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10 12
     9.1.  Disposition Type Registration  . . . . . . . . . . . . . . 10 12
     9.2.  XML Namespace Registration . . . . . . . . . . . . . . . . 11 12
     9.3.  XML Schema Registration  . . . . . . . . . . . . . . . . . 12 13
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 13
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 14
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 14
     11.2. Informational References . . . . . . . . . . . . . . . . . 13 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 15
   Intellectual Property and Copyright Statements . . . . . . . . . . 14 16

























Garcia-Martin & Camarillo  Expires March April 5, 2007                [Page 2]

Internet-Draft         Capacity  Copy Control Attribute in Resource Lists         September    October 2006


1.  Introduction

   The Framework and Security Considerations for Session Initiation
   Protocol (SIP) URI-List Services [9] describes a generic framework
   for carrying Uniform Resource Identifier (URI)-lists in SIP [5]
   messages.  Specifically  Specifically, the document provides a common framework for
   specific implementations of URI-list services, such as conferences
   initiated with INVITE requests [10] or Multiple-recipient MESSAGE
   requests [11].

   Common to a multiple of all URI-list services is the presence of a SIP request that
   contains a collection of resources, typically expressed as an XML
   resource list [7].  SIP requests carrying resource lists can appear
   either in requests received by the URI-list server, indicating the
   list of intended recipients; recipients, or in each of the requests that the URI-list URI-
   list server sends to recipients, indicating the list of recipients of
   the same SIP request.

   Although the XML resource list [7] provides a powerful mechanism for
   indicating
   describing list of resources, it there is usually beneficial a need for a copy control
   attribute to indicate
   the capacity in which determine whether a resource is receiving a SIP request. 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 assign categorize
   each recipient
   the capacity of as To, Cc, or Bcc, in which they are receiving an e-mail
   message. Bcc recipient.

   This document addresses this problem by providing an extension to the
   XML resource list [7] that enables the sender to tag supply a copy
   control attribute that labels each recipient as a "to", "cc", or
   "bcc" recipeint.  This attribute indicates whether the capacity recipient is
   receiving a primary copy of the recipients, as 'to', 'cc', SIP request, a carbon copy, or 'bcc'. 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 their some recipeints' URIs are not disclosed
   to the other recipients, but instead, they recipients.  Instead, these URIs are replaced with
   anonymous URIs.

   The rest remainder of this document is organized as follows: Section 2
   introduces a few new terms. 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.


2.  Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",



Garcia-Martin & Camarillo  Expires April 5, 2007                [Page 3]

Internet-Draft  Copy Control Attribute in Resource Lists    October 2006


   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
   RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
   described in BCP 14, RFC 2119 [1] and indicate requirement levels for



Garcia-Martin & Camarillo  Expires March 5, 2007                [Page 3]

Internet-Draft         Capacity in Resource Lists         September 2006
   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.

   Capacity:   The role

   Copy control:   An attribute assigned by the sender to a recipient.  The
      sender URI in a XML
      resource list.  Its purpose is able to tag recipients with indicate the 'to', 'cc', and 'bcc'
      capacity, which indicate, respectively, recipient whether the recipients get
      he is getting a primary, carbon copy, 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. server containing a recipient list of intended
   recipients.  The URI-list server generates a SIP request to each of the recipients,
   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  Expires April 5, 2007                [Page 4]

Internet-Draft  Copy Control Attribute in Resource Lists    October 2006


   +--------+        +---------+        +--------+ +--------+ +--------+
   |SIP UAC |        | URI-list|        |intended| |intended| |intended|
   | issuer |        |  server |        | recip. | | recip. | | recip. |
   |        |        |         |        |   1    | |   2    | |   n   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. 2xx response 200 OK     |          |          |                  |<-------------
       |                  |<--------------- |          |          |
       |                  |  F7. 2xx response 200 OK     |          |          |
       |                  |<------------------------                  |<-------------------------- |          |
       |                  |  F8. 2xx response 200 OK     |          |          |                  |<-----------------------------------
       |                  |<------------------------------------- |
       |                  |                 |          |          |
       |                  |                 |          |          |
       |                  |                 |          |          |




Garcia-Martin & Camarillo  Expires March 5, 2007                [Page 4]

Internet-Draft         Capacity in Resource Lists         September 2006

                      Figure 1: Example of operation

   The URI-list mechanism allows a sender to specify multiple targets
   for a SIP request by including an a recipient XML resource list [7] in
   the body of the SIP request.  This XML resource recipient list includes the target
   URIs of the
   targets 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 what capacity (or role)
   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 capacities values of the 'copyControl'
   attribute include 'to',
   'cc', "to", "cc", and 'bcc' "bcc" (analogous to e-mail).  Each target URI may also be
   marked with the 'anonymize' attribute.  This allows
   is discussed in greater detailed in Section 4.  When the sender of URI-list
   server expands the
   SIP request to indicate to each recipient, the URI-list service that an intended
   recipient should receive the SIP request, but his URI should not be
   disclosed (for example, in server
   includes a URI-list that recipient-history XML resource list built upon the URI-list service could
   send to
   recipient list received from the recipients of sender.  The recipient-history XML
   resource list replaces the recipient list in the SIP request).

   When requests
   generated by the URI-list server expands the request for towards each recipient, it
   includes a new URI-list that contains only recipient.  The URI-
   list server copies from the recipient list those targets originally
   listed which are



Garcia-Martin & Camarillo  Expires April 5, 2007                [Page 5]

Internet-Draft  Copy Control Attribute in Resource Lists    October 2006


   marked with the "to" and "cc" capacities, excludes those listed copy control level, and pastes them in
   the
   'bcc' capacity.  Further more, recipient-history list.  The URI-list server explicitly excludes
   from the copy those URIs tagged 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.

   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 are to
   indicate the URI-list server that the URI marked with that attribute
   is to be replaced by with an anonymous URI.

   In case URI in the recipient-history XML
   resource list.  This provides a knowledge to recipients of multiple identical a SIP
   request of a number of additional recipients whose URIs have not been
   disclosed.

   There are cases when the sender marks several URIs with the size of
   'anonymize' attribute.  The URI-list server can be
   compressed by adding group the anonymized
   URIs in a 'count' attribute to single anonymized URI within its copy control level, and
   provide a URI.  The 'count'
   attribute indicates count of the number of repeated URIs.  This is
   particularly useful with anonymized URIs.  To support this
   scenario, we define a new 'count' attribute to a URI in the
   recipient-history XML resource list.  It is not expected to have
   value other than that the 'count'
   attribute is only used with anonymous URIs, although technically, syntactically it
   is possible to include the add a 'count' attribute to any URI.

   The presence 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-list URI with a
   'copyControl' attribute of "bcc" in each the recipient XML resource list,
   the URI-list server will completely remove that URI from the
   recipient-history XML resource list.  Recipients of the expanded SIP requests
   allows recipients to both see and reply to the non-anonymous "to" and
   "cc" targets, but request
   will not to the "bcc" notice that one or anonymous targets.  The default
   capacity assumed, more extra URIs also received the
   request.  However, if one is not specified by the sender, is "bcc".
   This is discussed sender qualifies a URI with the 'anonymize'
   attribute in greater detailed the recipient XML resource list, the URI-list server
   will replace the URI with an anonymous one in Section 4 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

   This document defines an extension to the XML resource list data
   format [7] that allows the sender to indicate the capacity or role a copy control



Garcia-Martin & Camarillo  Expires April 5, 2007                [Page 6]

Internet-Draft  Copy Control Attribute in
   which Resource Lists    October 2006


   attribute that qualifies a recipient is receiving with a message. copy control level.  We
   define a new 'capacity' 'copyControl' attribute to the <entry> element of the
   resource list document format [7].  The 'capacity' '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 'capacity' '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



Garcia-Martin & Camarillo  Expires March 5, 2007                [Page 5]

Internet-Draft         Capacity in Resource Lists         September 2006  A "bcc" value indicates that the resource receives a blind
   carbon copy of the SIP request, i.e., request (i.e., this URI is not disclosed in a URI-list sent to
   the recipients. recipient-history list).  The default
   'capacity' 'copyControl' value is "bcc", that
   "bcc".  That is, the absence of a 'capacity' 'copyControl' attribute MUST be
   treated as if the 'capacity' 'copyControl' was set to "bcc".  URI-list servers can
   use URIs tagged marked with the "bcc" 'capacity' 'copyControl' attribute for routing to route SIP
   requests, but MUST delete NOT include them if the URI-
   list service includes a URI-list in outgoing requests. recipient-history lists.

   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
   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. 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 an anonymized URI (such as sip:anonymous@anonymous.invalid) if the
   URI-list server includes a URI-list in outgoing requests.
   recipient-history lists.  The default value of the 'anonymize'
   attribute is "false".

   Processing of URIs tagged with a 'copyControl' attribute set to a
   "bcc" 'capacity' value has higher precedence of over the 'anonymize' attribute, thus, attribute.
   Thus, if the 'capacity' 'copyControl' of a URI is set to "bcc", the URI-list service will
   server MUST remove the that URI from the list recipient-history list, and the
   'anonymize' attribute will be ignored.  Therefore, the 'anonymize'
   attribute is only useful for those URIs tagged with a
   'capacity' 'copyControl'
   of "to" or "cc".

   A new 'count' attribute can be also included in a <entry> element of
   the resource list document format [7].  It provides the number of
   equal URIs.  Typically URI-lists  Typically, recipient lists created by UACs will not have
   equal (or duplicated) duplicate) URI entries, thus, it is not expected to contain
   URIs tagged with the 'count' attributes.  However, URI-lists created by
   URI-list servers recipient-history
   lists can contain duplicated anonymized URIs, thus, therefore, it is
   expected that URI-list created by URI-list servers recipient-history lists will contain 'count'
   attributes.  The default value of the 'count' attribute is "1".

   The 'capacity', '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).



Garcia-Martin & Camarillo  Expires April 5, 2007                [Page 7]

Internet-Draft  Copy Control Attribute in Resource Lists    October 2006


   Section 5 describes the format of the 'capacity', 'copyControl', 'anonymize', and
   'count' attributes.  Implementations according to this specification
   MUST support this XML Schema.








Garcia-Martin & Camarillo  Expires March 5, 2007                [Page 6]

Internet-Draft         Capacity in Resource Lists         September 2006


5.  XML Schema

  <?xml version="1.0" encoding="UTF-8"?>
  <xs:schema targetNamespace="urn:ietf:params:xml:ns:capacity"
      xmlns="urn:ietf:params:xml:ns:capacity" 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 capacity, 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="capacity"> 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>

     <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 URI-list recipient list



Garcia-Martin & Camarillo  Expires April 5, 2007                [Page 8]

Internet-Draft  Copy Control Attribute in Resource Lists    October 2006


   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
   [7].  Each resource indicates the capacity copy control of a resource. resource with a
   'copyControl' attribute.  Some of the resources are also attributed marked with
   the 'anonymize' attribute.  This provides an



Garcia-Martin & Camarillo  Expires March 5, 2007                [Page 7]

Internet-Draft         Capacity in Resource Lists         September 2006 indication to the URI-list URI-
   list service for not disclosing their URIs in a
   URI-list. recipient-history
   list.  The last two <entry> elements are attributed marked with a "bcc"
   'capacity'. 'copyControl'
   attribute of "bcc".  This provides an indication to the URI-list service
   server for removing these URIs from in the outgoing URI-lists. 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:capacity">
             xmlns:cp="urn:ietf:params:xml:ns:copycontrol">
     <list>
       <entry uri="sip:bill@example.com" cp:capacity="to" cp:copyControl="to" />
       <entry uri="sip:randy@example.net" cp:capacity="to" cp:copyControl="to"
                                          cp:anonymize="true"/>
       <entry uri="sip:eddy@example.com" cp:capacity="to" cp:copyControl="to"
                                         cp:anonymize="true"/>
       <entry uri="sip:joe@example.org" cp:capacity="cc" cp:copyControl="cc" />
       <entry uri="sip:carol@example.net" cp:capacity="cc" cp:copyControl="cc"
                                          cp:anonymize="true"/>
       <entry uri="sip:ted@example.net" cp:capacity="bcc" cp:copyControl="bcc" />
       <entry uri="sip:andy@example.com" cp:capacity="bcc" cp:copyControl="bcc" />
     </list>
   </resource-lists>

     Figure 3: URI-list Recipient list sent from the UAC to the URI-list server

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



Garcia-Martin & Camarillo  Expires April 5, 2007                [Page 9]

Internet-Draft  Copy Control Attribute in Resource Lists    October 2006


   'copyControl' attribute set to "cc" and 'anonymize' attribute set to
   "true", adding also the 'count' attribute containing the number of
   anonymous attributes with in this capacity group ("1" in the example).  Last, the
   URI-list service server completely removes URIs tagged marked with the "bcc" 'capacity'.  The result
   URI-list if
   'copyControl' attribute.  The resulting recipient-history list is
   shown in Figure 4.






Garcia-Martin & Camarillo  Expires March 5, 2007                [Page 8]

Internet-Draft         Capacity in Resource Lists         September 2006

   <?xml version="1.0" encoding="UTF-8"?>
   <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>
       <entry uri="sip:bill@example.com" cp:capacity="to" cp:copyControl="to" />
       <entry uri="sip:anonymous@anonymous.invalid" cp:capacity="to" cp:copyControl="to"
                                                    cp:count="2"/>
       <entry uri="sip:joe@example.org" cp:capacity="cc" cp:copyControl="cc" />
       <entry uri="sip:anonymous@anonymous.invalid" cp:capacity="cc" cp:copyControl="cc"
                                                    cp:count="1"/>
     </list>
   </resource-lists>

     Figure 4: URI-List Recipient-history list sent from the URI-list server to
                              each recipient


7.  Carrying URI-lists in SIP

   A SIP User UAC (User Agent Client (UAC) 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 [9],
   the UAC adds a Content-Disposition [2] 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 with list of that includes the intended recipients of the SIP request. request,
   something known throughout this document as a recipient list.  The
   <entry> element in the URI-list MAY also include a 'capacity' 'copyControl' and
   'anonymize' attributes, as specified in Section 4.

   To enable the capability of the be able to inform intended recipients to become aware 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 [2] 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. 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 URI-list with the visible
   (including anonymized) recipients of the SIP request.  The <entry>



Garcia-Martin & Camarillo  Expires April 5, 2007               [Page 10]

Internet-Draft  Copy Control Attribute in Resource Lists    October 2006


   element in the URI-list MAY also include a
   'capacity' 'copyControl' and 'count'
   attributes, as specified in Section 4.

   It is often desired that,

   On sending a SIP request that contains a recipient-history list, if
   the intended recipient of the SIP
   request does not support this specification, still the SIP
   request
   does should not fail.  In order to provide the maximum probability of
   success ensure successful receipt of those
   the SIP requests that include 'recipient-list-history' bodies, User
   Agents (such as URI-list services) servers) that build SIP requests with the
   Content-Disposition header field set to 'recipient-
   list-history' 'recipient-list-history'
   SHOULD add a 'handling' parameter [4] set to



Garcia-Martin & Camarillo  Expires March 5, 2007                [Page 9]

Internet-Draft         Capacity in Resource Lists         September 2006 "optional".  Otherwise,
   the SIP request could fail and never be received by the intended
   recipient.


8.  Security Considerations

   The Framework and Security Considerations for SIP URI-List Services
   [9] 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 [9].  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 was is sent over a secured channel with channel, by
   using any of the available SIP mechanisms, such as Transport Layer
   Security (TLS) [3] [3], or unless the URI-list body itself is encrypted with
   with, e.g., S/MIME [8].  Therefore, it is RECOMMENDED that URI-
   list URI-list
   bodies are encrypted with S/MIME [8] or that the SIP request is
   encrypted with TLS [3]. [3] 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.






Garcia-Martin & Camarillo  Expires April 5, 2007               [Page 11]

Internet-Draft  Copy Control Attribute in Resource Lists    October 2006


9.  IANA Considerations

   The following sections instruct the IANA to register: a new
   disposition type, a new SIP option-tag, 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 should be registered
   in the IANA registry of Mail Content Disposition Values with the
   following registration data:




Garcia-Martin & Camarillo  Expires March 5, 2007               [Page 10]

Internet-Draft         Capacity in Resource Lists         September 2006

   +------------------------+------------------------------+-----------+
   | Name                   | Description                  | Reference |
   +------------------------+------------------------------+-----------+
   | recipient-list-history | the body contains a list of  | [RFCXXXX] |
   |                        | URIs that indicates the      |           |
   |                        | recipients of the SIP        |           |
   |                        | request                      |           |
   +------------------------+------------------------------+-----------+

    Table 1: Registration of the 'recipient-list-history' Mail Content
                             Disposition Value

   Note to IANA and the RFC editor: replace RFCXXXX above with the RFC
   number of this specification.

9.2.  XML Namespace Registration

   This section registers a new XML namespace in the XML registry, as
   per the guidelines in RFC 3688 [6].

   URI: The URI for this namespace is urn:ietf:params:xml:ns:capacity. urn:ietf:params:xml:ns:copycontrol

   Registrant Contact: IETF, SIPPING working group, (sipping@ietf.org),
   Miguel Garcia-Martin (miguel.an.garcia@nokia.com).

   XML:













Garcia-Martin & Camarillo  Expires April 5, 2007               [Page 12]

Internet-Draft  Copy Control Attribute in Resource Lists    October 2006


         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>Capacity
           <title>Copy Control Namespace</title>
         </head>
         <body>
           <h1>Namespace for the Capacity Copy Control Attribute Extension
           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
           [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with
           the RFC number of this specification.]</a>.</p>
         </body>
         </html>
         END




Garcia-Martin & Camarillo  Expires March 5, 2007               [Page 11]

Internet-Draft         Capacity in Resource Lists         September 2006


9.3.  XML Schema Registration

   This section registers a new XML schema in the XML registry per the
   procedures in RFC 3688 [6].

   URI: urn:ietf:params:xml:schema:capacity 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
   Section 5.


10.  Acknowledgements

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


11.  References







Garcia-Martin & Camarillo  Expires April 5, 2007               [Page 13]

Internet-Draft  Copy Control Attribute in Resource Lists    October 2006


11.1.  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  Troost, R., Dorner, S., and K. Moore, "Communicating
        Presentation Information in Internet Messages: The Content-
        Disposition Header Field", RFC 2183, August 1997.

   [3]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
        RFC 2246, January 1999.

   [4]  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.

   [5]  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.

   [6]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
        January 2004.

   [7]  Rosenberg, J., "Extensible Markup Language (XML) Formats for
        Representing Resource Lists",
        draft-ietf-simple-xcap-list-usage-05 (work in progress),



Garcia-Martin & Camarillo  Expires March 5, 2007               [Page 12]

Internet-Draft         Capacity in Resource Lists         September 2006
        February 2005.

   [8]  Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
        (S/MIME) Version 3.1 Message Specification", RFC 3851,
        July 2004.

   [9]  Camarillo, G. and A. Roach, "Framework and Security
        Considerations for Session Initiation Protocol (SIP)  Uniform
        Resource Identifier (URI)-List Services",
        draft-ietf-sipping-uri-services-05
        draft-ietf-sipping-uri-services-06 (work in progress),
        January
        September 2006.

11.2.  Informational References

   [10]  Camarillo, G. and A. Johnston, "Conference Establishment Using
         Request-Contained Lists in the Session  Initiation Protocol
         (SIP)", draft-ietf-sipping-uri-list-conferencing-05 draft-ietf-sip-uri-list-conferencing-00 (work in
         progress), February September 2006.

   [11]  Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE
         Requests in the Session Initiation Protocol  (SIP)",
         draft-ietf-sipping-uri-list-message-08
         draft-ietf-sip-uri-list-message-00 (work in progress),



Garcia-Martin & Camarillo  Expires April 5, 2007               [Page 14]

Internet-Draft  Copy Control Attribute in Resource Lists    October 2006


         September 2006.


Authors' Addresses

   Miguel A. Garcia-Martin
   Nokia
   P.O.Box 407
   NOKIA GROUP, FIN  00045
   Finland

   Email: miguel.an.garcia@nokia.com


   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: Gonzalo.Camarillo@ericsson.com






























Garcia-Martin & Camarillo  Expires March April 5, 2007               [Page 13] 15]

Internet-Draft         Capacity  Copy Control Attribute in Resource Lists         September    October 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   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 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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Garcia-Martin & Camarillo  Expires March April 5, 2007               [Page 14] 16]


----