draft-ietf-sipping-capacity-attribute-02.txt   draft-ietf-sipping-capacity-attribute-03.txt 
SIPPING Working Group M. Garcia-Martin SIPPING Working Group M. Garcia-Martin
Internet-Draft Nokia Internet-Draft Nokia
Intended status: Standards Track G. Camarillo Intended status: Standards Track G. Camarillo
Expires: April 5, 2007 Ericsson Expires: June 8, 2007 Ericsson
October 2, 2006 December 5, 2006
Extensible Markup Language (XML) Format Extension for Representing Copy Extensible Markup Language (XML) Format Extension for Representing Copy
Control Attributes in Resource Lists Control Attributes in Resource Lists
draft-ietf-sipping-capacity-attribute-02.txt draft-ietf-sipping-capacity-attribute-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 5, 2007. This Internet-Draft will expire on June 8, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2006).
Abstract Abstract
In certain types of multimedia communications, a Session Initiation In certain types of multimedia communications, a Session Initiation
Protocol (SIP) request is distributed to a group of SIP User Agents Protocol (SIP) request is distributed to a group of SIP User Agents
(UAs). The sender sends a single SIP request to a server which (UAs). The sender sends a single SIP request to a server which
further distributes the request to the group. This SIP request further distributes the request to the group. This SIP request
contains a list of Uniform Resource Identifiers (URIs), which contains a list of Uniform Resource Identifiers (URIs), which
identify the recipients of the SIP request. This URI-list is identify the recipients of the SIP request. This URI-list is
expressed as a resource list XML document. This specification expressed as a resource list XML document. This specification
skipping to change at page 3, line 24 skipping to change at page 3, line 24
Common to all URI-list services is the presence of a SIP request that Common to all URI-list services is the presence of a SIP request that
contains a collection of resources, typically expressed as an XML contains a collection of resources, typically expressed as an XML
resource list [7]. SIP requests carrying resource lists can appear resource list [7]. SIP requests carrying resource lists can appear
either in requests received by the URI-list server, indicating the 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 of intended recipients, or in each of the requests that the URI-
list server sends to recipients, indicating the list of recipients of list server sends to recipients, indicating the list of recipients of
the same SIP request. the same SIP request.
Although the XML resource list [7] provides a powerful mechanism for Although the XML resource list [7] provides a powerful mechanism for
describing list of resources, there is a need for a copy control describing a list of resources, there is a need for a copy control
attribute to determine whether a resource is receiving a SIP request attribute to determine whether a resource is receiving a SIP request
as a primary recipient, a carbon copy, or a blind carbon copy. This 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 is similar to common e-mail systems, where the sender can categorize
each recipient as To, Cc, or Bcc recipient. each recipient as To, Cc, or Bcc recipient.
This document addresses this problem by providing an extension to the This document addresses this problem by providing an extension to the
XML resource list [7] that enables the sender to supply a copy XML resource list [7] that enables the sender to supply a copy
control attribute that labels each recipient as a "to", "cc", or control attribute that labels each recipient as a "to", "cc", or
"bcc" recipeint. This attribute indicates whether the recipient is "bcc" recipient. This attribute indicates whether the recipient is
receiving a primary copy of the SIP request, a carbon copy, or a receiving a primary copy of the SIP request, a carbon copy, or a
blind carbon copy. Additionally, we provide the sender with the blind carbon copy. Additionally, we provide the sender with the
capability of indicating in the URI-list that one or more resources capability of indicating in the URI-list that one or more resources
should be anonymized, so that some recipeints' URIs are not disclosed should be anonymized, so that some recipients' URIs are not disclosed
to the other recipients. Instead, these URIs are replaced with to the other recipients. Instead, these URIs are replaced with
anonymous URIs. anonymous URIs.
The remainder of this document is organized as follows: Section 2 The remainder of this document is organized as follows: Section 2
introduces the terminology used throughout this specification. introduces the terminology used throughout this specification.
Section 3 gives an overview of operation. Section 4 formally defines Section 3 gives an overview of operation. Section 4 formally defines
an extension to URI-lists. The XML schema definition is provided in an extension to URI-lists. The XML schema definition is provided in
Section 5. Section 6 shows examples of the URI-lists with the Section 5. Section 6 shows examples of the URI-lists with the
extensions defined in this document. Section 7 discusses the extensions defined in this document. Section 7 discusses the
implications of carrying URI-lists in SIP messages. implications of carrying URI-lists in SIP messages.
skipping to change at page 4, line 17 skipping to change at page 4, line 17
compliant implementations. compliant implementations.
URI-list service: SIP application service that receives a SIP URI-list service: SIP application service that receives a SIP
request containing a URI-list and sends a similar SIP request to request containing a URI-list and sends a similar SIP request to
each URI in the list. each URI in the list.
Intended recipient: The intended final recipient of the request to Intended recipient: The intended final recipient of the request to
be generated by URI-list service. be generated by URI-list service.
Copy control: An attribute assigned by the sender to a URI in a XML Copy control: An attribute assigned by the sender to a URI in a XML
resource list. Its purpose is to indicate the recipient whether resource list. Its purpose is to indicate to the recipient
he is getting a primary, carbon, or blind carbon copy of the SIP whether he is getting a primary, carbon, or blind carbon copy of
request. the SIP request.
Recipient list or recipient XML resource list: An XML resource list Recipient list or recipient XML resource list: An XML resource list
containing the list of intended recipients. The sender sets this containing the list of intended recipients. The sender sets this
list in the SIP request he sends to the URI-list server. list in the SIP request he sends to the URI-list server.
Recipient-history list or recipient-history XML resource list: An Recipient-history list or recipient-history XML resource list: An
XML resource list containing the visible list of recipients (i.e., XML resource list containing the visible list of recipients (i.e.,
those non-anonymous non-bcc). The URI-list server creates this those non-anonymous non-bcc). The URI-list server creates this
list, based on the recipient list, and includes it in each of the list, based on the recipient list, and includes it in each of the
SIP requests it sends to each recipient. SIP requests it sends to each recipient.
3. Overview of operation 3. Overview of operation
Figure 1 depicts a general overview of the operation of a URI-list Figure 1 depicts a general overview of the operation of a URI-list
server. A SIP User Agent Client (UAC) issuer sends a SIP request server. A SIP User Agent Client (UAC) issuer sends a SIP request
(F1) to a URI-list server containing a recipient list of intended (F1) to a URI-list server containing a recipient list. The URI-list
recipients. The URI-list server generates a SIP request to each server generates a SIP request to each recipient, according to the
recipient, according to the specific SIP method. Each of these SIP specific SIP method. Each of these SIP requests contains a
requests contains a recipient-history list that indicates the visible recipient-history list that indicates the visible list of recipients
list of recipients of the SIP request. of the SIP request.
+--------+ +---------+ +--------+ +--------+ +--------+ +--------+ +---------+ +--------+ +--------+ +--------+
|SIP UAC | | URI-list| |intended| |intended| |intended| |SIP UAC | | URI-list| |intended| |intended| |intended|
| issuer | | server | | recip. | | recip. | | recip. | | issuer | | server | | recip. | | recip. | | recip. |
| | | | | 1 | | 2 | | 3 | | | | | | 1 | | 2 | | 3 |
+--------+ +---------+ +--------+ +--------+ +--------+ +--------+ +---------+ +--------+ +--------+ +--------+
| | | | | | | | | |
| F1. SIP request | | | | | F1. SIP request | | | |
| (recipt. list) | | | | | (recipt. list) | | | |
| ---------------->| | | | | ---------------->| | | |
skipping to change at page 12, line 34 skipping to change at page 12, line 34
+------------------------+------------------------------+-----------+ +------------------------+------------------------------+-----------+
Table 1: Registration of the 'recipient-list-history' Mail Content Table 1: Registration of the 'recipient-list-history' Mail Content
Disposition Value Disposition Value
Note to IANA and the RFC editor: replace RFCXXXX above with the RFC Note to IANA and the RFC editor: replace RFCXXXX above with the RFC
number of this specification. number of this specification.
9.2. XML Namespace Registration 9.2. XML Namespace Registration
This section registers a new XML namespace in the XML registry, as This section registers a new XML namespace in the IANA XML registry,
per the guidelines in RFC 3688 [6]. as per the guidelines in RFC 3688 [6].
URI: The URI for this namespace is urn:ietf:params:xml:ns:copycontrol URI: The URI for this namespace is urn:ietf:params:xml:ns:copycontrol
Registrant Contact: IETF, SIPPING working group, (sipping@ietf.org), Registrant Contact: IETF, SIPPING working group, (sipping@ietf.org),
Miguel Garcia-Martin (miguel.an.garcia@nokia.com). Miguel Garcia-Martin (miguel.an.garcia@nokia.com).
XML: XML:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
skipping to change at page 13, line 28 skipping to change at page 13, line 28
<h2>urn:ietf:params:xml:ns:copycontrol</h2> <h2>urn:ietf:params:xml:ns:copycontrol</h2>
<p>See <a href="[URL of published RFC]">RFCXXXX <p>See <a href="[URL of published RFC]">RFCXXXX
[NOTE TO IANA/RFC-EDITOR: Please replace XXXX with [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with
the RFC number of this specification.]</a>.</p> the RFC number of this specification.]</a>.</p>
</body> </body>
</html> </html>
END END
9.3. XML Schema Registration 9.3. XML Schema Registration
This section registers a new XML schema in the XML registry per the This section registers a new XML schema in the IANA XML registry per
procedures in RFC 3688 [6]. the procedures in RFC 3688 [6].
URI: urn:ietf:params:xml:schema:copycontrol URI: urn:ietf:params:xml:schema:copycontrol
Registrant Contact: IETF, SIPPING working group, (sipping@ietf.org), Registrant Contact: IETF, SIPPING working group, (sipping@ietf.org),
Miguel Garcia-Martin (miguel.an.garcia@nokia.com). Miguel Garcia-Martin (miguel.an.garcia@nokia.com).
The XML for this schema can be found as the sole content of The XML for this schema can be found as the sole content of
Section 5. Section 5.
10. Acknowledgements 10. Acknowledgements
skipping to change at page 16, line 7 skipping to change at page 16, line 7
Gonzalo Camarillo Gonzalo Camarillo
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: Gonzalo.Camarillo@ericsson.com Email: Gonzalo.Camarillo@ericsson.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2006).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 13 change blocks. 
25 lines changed or deleted 25 lines changed or added

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