draft-ietf-sipping-capacity-attribute-00.txt   draft-ietf-sipping-capacity-attribute-01.txt 
SIPPING Working Group M. Garcia-Martin SIPPING Working Group M. Garcia-Martin
Internet-Draft Nokia Internet-Draft Nokia
Expires: August 26, 2006 G. Camarillo Intended status: Standards Track G. Camarillo
Ericsson Expires: March 5, 2007 Ericsson
February 22, 2006 September 1, 2006
Extensible Markup Language (XML) Format Extension for Representing Extensible Markup Language (XML) Format Extension for Representing
Capacity Attributes in Resource Lists Capacity Attributes in Resource Lists
draft-ietf-sipping-capacity-attribute-00.txt draft-ietf-sipping-capacity-attribute-01.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 August 26, 2006. This Internet-Draft will expire on March 5, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document specifies an XML extension to the resource list format This document specifies an XML extension to the resource list format
for qualifiying resources with the capacity in which they are for qualifiying resources with the capacity in which they are
included in the resource list. included in the resource list.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Extension to the resource lists data format . . . . . . . . . 5 4. Extension to the resource lists data format . . . . . . . . . 5
5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Carrying URI-lists in SIP . . . . . . . . . . . . . . . . . . 9 7. Carrying URI-lists in SIP . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9.1. Disposition Type Registration . . . . . . . . . . . . . . 10
10.1. Disposition Type Registration . . . . . . . . . . . . . . 10 9.2. XML Namespace Registration . . . . . . . . . . . . . . . . 11
10.2. XML Namespace Registration . . . . . . . . . . . . . . . 11 9.3. XML Schema Registration . . . . . . . . . . . . . . . . . 12
10.3. XML Schema Registration . . . . . . . . . . . . . . . . . 12 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 12 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12
11.2. Informational References . . . . . . . . . . . . . . . . 13 11.2. Informational References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14
1. Introduction 1. Introduction
The Framework and Security Considerations for Session Initiation The Framework and Security Considerations for Session Initiation
Protocol (SIP) URI-List Services [9] describes a generic framework Protocol (SIP) URI-List Services [9] describes a generic framework
for carrying Uniform Resource Identifier (URI)-lists in SIP [5] for carrying Uniform Resource Identifier (URI)-lists in SIP [5]
messages. Specifically the document provides a common framework for messages. Specifically the document provides a common framework for
specific implementations of URI-list services, such as conferences specific implementations of URI-list services, such as conferences
initiated with INVITE requests [10] or Multiple-recipient MESSAGE initiated with INVITE requests [10] or Multiple-recipient MESSAGE
requests [11]. requests [11].
skipping to change at page 10, line 6 skipping to change at page 10, line 6
It is often desired that, if the intended recipient of the SIP It is often desired that, if the intended recipient of the SIP
request does not support this specification, still the SIP request request does not support this specification, still the SIP request
does not fail. In order to provide the maximum probability of does not fail. In order to provide the maximum probability of
success of those requests that include 'recipient-list-history' success of those requests that include 'recipient-list-history'
bodies, User Agents (such as URI-list services) that build SIP bodies, User Agents (such as URI-list services) that build SIP
requests with the Content-Disposition header field set to 'recipient- requests with the Content-Disposition header field set to 'recipient-
list-history' SHOULD add a 'handling' parameter [4] set to list-history' SHOULD add a 'handling' parameter [4] set to
"optional". "optional".
8. Acknowledgements 8. Security Considerations
Thanks to Dean Willis, Jari Urpalainen, and Pekka Kuure for reviewing
this document and providing helpful comments.
9. Security Considerations
The Framework and Security Considerations for SIP URI-List Services The Framework and Security Considerations for SIP URI-List Services
[9] discusses issues related to SIP URI-list services. [9] discusses issues related to SIP URI-list services.
Implementations of this specification MUST follow the security- Implementations of this specification MUST follow the security-
related rules in the Framework and Security Considerations for SIP related rules in the Framework and Security Considerations for SIP
URI-List Services [9]. These rules include mandatory authentication URI-List Services [9]. These rules include mandatory authentication
and authorization of clients, and opt-in lists. and authorization of clients, and opt-in lists.
User Agent Clients SHOULD NOT hand SIP requests containing URI-list User Agent Clients SHOULD NOT hand SIP requests containing URI-list
services to unauthenticated and untrusted parties. This is to avoid services to unauthenticated and untrusted parties. This is to avoid
skipping to change at page 10, line 34 skipping to change at page 10, line 29
URI-lists may contain private information, such as SIP URIs. It is URI-lists may contain private information, such as SIP URIs. It is
therefore not desirable that these URI-lists are known by third therefore not desirable that these URI-lists are known by third
parties. Eavesdroppers are able to watch URI-lists contained in SIP parties. Eavesdroppers are able to watch URI-lists contained in SIP
requests unless the SIP message was sent over a secured channel with requests unless the SIP message was sent over a secured channel with
Transport Layer Security (TLS) [3] or unless the URI-list body itself Transport Layer Security (TLS) [3] or unless the URI-list body itself
is encrypted with S/MIME [8]. Therefore, it is RECOMMENDED that URI- is encrypted with S/MIME [8]. Therefore, it is RECOMMENDED that URI-
list bodies are encrypted with S/MIME [8] or that the SIP request is list bodies are encrypted with S/MIME [8] or that the SIP request is
encrypted with TLS [3]. encrypted with TLS [3].
10. IANA Considerations 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.
9. IANA Considerations
The following sections instruct the IANA to register: a new The following sections instruct the IANA to register: a new
disposition type, a new SIP option-tag, a new XML namespace, and a disposition type, a new SIP option-tag, a new XML namespace, and a
new XML schema. new XML schema.
10.1. Disposition Type Registration 9.1. Disposition Type Registration
Section 7 defines a new 'recipient-list-history' value of the Mail Section 7 defines a new 'recipient-list-history' value of the Mail
Content Disposition Values registry. This value should be registered Content Disposition Values registry. This value should be registered
in the IANA registry of Mail Content Disposition Values with the in the IANA registry of Mail Content Disposition Values with the
following registration data: following registration data:
+------------------------+------------------------------+-----------+ +------------------------+------------------------------+-----------+
| Name | Description | Reference | | Name | Description | Reference |
+------------------------+------------------------------+-----------+ +------------------------+------------------------------+-----------+
| recipient-list-history | the body contains a list of | [RFCXXXX] | | recipient-list-history | the body contains a list of | [RFCXXXX] |
skipping to change at page 11, line 20 skipping to change at page 11, line 20
| | recipients of the SIP | | | | recipients of the SIP | |
| | request | | | | request | |
+------------------------+------------------------------+-----------+ +------------------------+------------------------------+-----------+
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.
10.2. XML Namespace Registration 9.2. XML Namespace Registration
This section registers a new XML namespace in the XML registry, as This section registers a new XML namespace in the XML registry, as
per the guidelines in RFC 3688 [6]. per the guidelines in RFC 3688 [6].
URI: The URI for this namespace is urn:ietf:params:xml:ns:capacity. URI: The URI for this namespace is urn:ietf:params:xml:ns:capacity.
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:
skipping to change at page 12, line 5 skipping to change at page 12, line 5
<h1>Namespace for the Capacity Attribute Extension <h1>Namespace for the Capacity Attribute Extension
in Resource Lists</h1> in Resource Lists</h1>
<h2>urn:ietf:params:xml:ns:capacity</h2> <h2>urn:ietf:params:xml:ns:capacity</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
10.3. XML Schema Registration 9.3. XML Schema Registration
This section registers a new XML schema in the XML registry per the This section registers a new XML schema in the XML registry per the
procedures in RFC 3688 [6]. procedures in RFC 3688 [6].
URI: urn:ietf:params:xml:schema:capacity URI: urn:ietf:params:xml:schema:capacity
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
Thanks to Dean Willis, Jari Urpalainen, Pekka Kuure, and Atsushi Sato
for reviewing this document and providing helpful comments.
11. References 11. References
11.1. Normative References 11.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Troost, R., Dorner, S., and K. Moore, "Communicating [2] Troost, R., Dorner, S., and K. Moore, "Communicating
Presentation Information in Internet Messages: The Content- Presentation Information in Internet Messages: The Content-
Disposition Header Field", RFC 2183, August 1997. Disposition Header Field", RFC 2183, August 1997.
skipping to change at page 13, line 8 skipping to change at page 13, line 13
draft-ietf-simple-xcap-list-usage-05 (work in progress), draft-ietf-simple-xcap-list-usage-05 (work in progress),
February 2005. February 2005.
[8] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions [8] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", RFC 3851, (S/MIME) Version 3.1 Message Specification", RFC 3851,
July 2004. July 2004.
[9] Camarillo, G. and A. Roach, "Framework and Security [9] Camarillo, G. and A. Roach, "Framework and Security
Considerations for Session Initiation Protocol (SIP) Uniform Considerations for Session Initiation Protocol (SIP) Uniform
Resource Identifier (URI)-List Services", Resource Identifier (URI)-List Services",
draft-ietf-sipping-uri-services-04 (work in progress), draft-ietf-sipping-uri-services-05 (work in progress),
October 2005. January 2006.
11.2. Informational References 11.2. Informational References
[10] Camarillo, G. and A. Johnston, "Conference Establishment Using [10] Camarillo, G. and A. Johnston, "Conference Establishment Using
Request-Contained Lists in the Session Initiation Protocol Request-Contained Lists in the Session Initiation Protocol
(SIP)", draft-ietf-sipping-uri-list-conferencing-04 (work in (SIP)", draft-ietf-sipping-uri-list-conferencing-05 (work in
progress), October 2005. progress), February 2006.
[11] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE [11] Garcia-Martin, M. and G. Camarillo, "Multiple-Recipient MESSAGE
Requests in the Session Initiation Protocol (SIP)", Requests in the Session Initiation Protocol (SIP)",
draft-ietf-sipping-uri-list-message-04 (work in progress), draft-ietf-sipping-uri-list-message-08 (work in progress),
October 2005. September 2006.
Authors' Addresses Authors' Addresses
Miguel A. Garcia-Martin Miguel A. Garcia-Martin
Nokia Nokia
P.O.Box 407 P.O.Box 407
NOKIA GROUP, FIN 00045 NOKIA GROUP, FIN 00045
Finland Finland
Email: miguel.an.garcia@nokia.com Email: miguel.an.garcia@nokia.com
skipping to change at page 14, line 37 skipping to change at page 14, line 47
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 16 change blocks. 
30 lines changed or deleted 38 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/