draft-ietf-sipping-capacity-attribute-03.txt   draft-ietf-sipping-capacity-attribute-04.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: June 8, 2007 Ericsson Expires: September 28, 2007 Ericsson
December 5, 2006 March 27, 2007
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-03.txt draft-ietf-sipping-capacity-attribute-04.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 June 8, 2007. This Internet-Draft will expire on September 28, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2006). Copyright (C) The IETF Trust (2007).
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
defines an XML extension to the XML resource list format that allows 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 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. level similar to the copy control level of existing e-mail systems.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of operation . . . . . . . . . . . . . . . . . . . . 4 3. Overview of operation . . . . . . . . . . . . . . . . . . . . 4
4. Extension to the resource lists data format . . . . . . . . . 6 4. Extension to the resource lists data format . . . . . . . . . 6
5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Carrying URI-lists in SIP . . . . . . . . . . . . . . . . . . 10 7. Carrying URI-lists in SIP . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9.1. Disposition Type Registration . . . . . . . . . . . . . . 12 9.1. Disposition Type Registration . . . . . . . . . . . . . . 13
9.2. XML Namespace Registration . . . . . . . . . . . . . . . . 12 9.2. XML Namespace Registration . . . . . . . . . . . . . . . . 13
9.3. XML Schema Registration . . . . . . . . . . . . . . . . . 13 9.3. XML Schema Registration . . . . . . . . . . . . . . . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . . 15
11.2. Informational References . . . . . . . . . . . . . . . . . 14 11.2. Informational References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 17
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 [4]
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].
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-
skipping to change at page 3, line 51 skipping to change at page 3, line 51
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.
2. Terminology 2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as document are to be interpreted as described in BCP 14, RFC 2119 [1]
described in BCP 14, RFC 2119 [1] and indicate requirement levels for and indicate requirement levels for 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 to the recipient resource list. Its purpose is to indicate to the recipient
skipping to change at page 7, line 31 skipping to change at page 7, line 31
the resource list document format [7]. If set to a "true" value, it 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 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 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 anonymize the URI (i.e., making it bogus in the recipient-history XML
resource list). URI-list servers can use URIs tagged with the resource list). URI-list servers can use URIs tagged with the
'anonymize' attribute for routing SIP requests, but MUST convert them 'anonymize' attribute for routing SIP requests, but MUST convert them
to an anonymized URI (such as sip:anonymous@anonymous.invalid) in to an anonymized URI (such as sip:anonymous@anonymous.invalid) in
recipient-history lists. The default value of the 'anonymize' recipient-history lists. The default value of the 'anonymize'
attribute is "false". 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 MUST 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 in a resource list, it MUST send at most a single
copy of the request to that intended recipient. The URI-list server
MUST select the highest precedence value of the 'copyControl'
attribute of the duplicated entries for the same intended recipient.
The order of precedence of the values of the 'copyControl' attribute
is: "to", "cc", and "bcc". Once the URI-list server has selected a
value for the 'copyControl' attribute of an intended recipient, the
URI-list can continue processing the request.
Processing of URIs tagged with a 'copyControl' attribute set to a Processing of URIs tagged with a 'copyControl' attribute set to a
"bcc" value has higher precedence over the 'anonymize' attribute. "bcc" value has higher precedence over the 'anonymize' attribute.
Thus, if the 'copyControl' of a URI is set to "bcc", the URI-list 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 server MUST remove that URI from the recipient-history list, and the
'anonymize' attribute will be ignored. Therefore, the 'anonymize' 'anonymize' attribute will be ignored. Therefore, the 'anonymize'
attribute is only useful for those URIs tagged with a 'copyControl' attribute is only useful for those URIs tagged with a 'copyControl'
of "to" or "cc". of "to" or "cc".
A new 'count' attribute can be also included in a <entry> element of A new 'count' attribute can be also included in a <entry> element of
the resource list document format [7]. It provides the number of the resource list document format [7]. It provides the number of
skipping to change at page 11, line 13 skipping to change at page 12, line 8
(including anonymized) recipients of the SIP request. The <entry> (including anonymized) recipients of the SIP request. The <entry>
element in the URI-list MAY also include a 'copyControl' and 'count' element in the URI-list MAY also include a 'copyControl' and 'count'
attributes, as specified in Section 4. attributes, as specified in Section 4.
On sending a SIP request that contains a recipient-history list, if On sending a SIP request that contains a recipient-history list, if
the intended recipient does not support this specification, the SIP the intended recipient does not support this specification, the SIP
request should not fail. In order to ensure successful receipt of request should not fail. In order to ensure successful receipt of
the SIP requests that include 'recipient-list-history' bodies, User the SIP requests that include 'recipient-list-history' bodies, User
Agents (such as URI-list servers) that build SIP requests with the Agents (such as URI-list servers) that build SIP requests with the
Content-Disposition header field set to 'recipient-list-history' Content-Disposition header field set to 'recipient-list-history'
SHOULD add a 'handling' parameter [4] set to "optional". Otherwise, SHOULD add a 'handling' parameter [3] set to "optional". Otherwise,
the SIP request could fail and never be received by the intended the SIP request could fail and never be received by the intended
recipient. recipient.
8. Security Considerations 8. 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
skipping to change at page 11, line 36 skipping to change at page 12, line 31
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
man-in-the-middle attacks or acquiring URI-lists for performing SPAM man-in-the-middle attacks or acquiring URI-lists for performing SPAM
attacks. attacks.
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 is sent over a secured channel, by requests unless the SIP message is sent over a secured channel, by
using any of the available SIP mechanisms, such as Transport Layer using any of the available SIP mechanisms, such as Transport Layer
Security (TLS) [3], or unless the URI-list body itself is encrypted Security (TLS) [6], or unless the URI-list body itself is encrypted
with, e.g., S/MIME [8]. Therefore, it is RECOMMENDED that URI-list with, e.g., S/MIME [8]. Therefore, it is RECOMMENDED that URI-list
bodies are encrypted with S/MIME [8] or that the SIP request is bodies are encrypted with S/MIME [8] or that the SIP request is
encrypted with TLS [3] or any other suitable encryption mechanism. encrypted with TLS [6] or any other suitable encryption mechanism.
Note that this URI-list does not indicate the actual participants in Note that this URI-list does not indicate the actual participants in
the session. It indicates only the URIs invited and that might the session. It indicates only the URIs invited and that might
accept the request. It does not assert that these parties actually accept the request. It does not assert that these parties actually
exist, that they are reachable at the given URI, or that they have exist, that they are reachable at the given URI, or that they have
accepted the invitation. No inferences about billing should be made accepted the invitation. No inferences about billing should be made
from this information. It is subject to spoofing by loading the list from this information. It is subject to spoofing by loading the list
with falsified content. with falsified content.
9. IANA Considerations 9. IANA Considerations
skipping to change at page 12, line 35 skipping to change at page 13, line 30
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 IANA XML registry, This section registers a new XML namespace in the IANA XML registry,
as per the guidelines in RFC 3688 [6]. as per the guidelines in RFC 3688 [5].
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 29 skipping to change at page 14, line 29
<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 IANA XML registry per This section registers a new XML schema in the IANA XML registry per
the procedures in RFC 3688 [6]. the procedures in RFC 3688 [5].
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 14, line 14 skipping to change at page 15, line 14
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.
[3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [3] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F.,
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 Watson, M., and M. Zonoun, "MIME media types for ISUP and QSIG
Objects", RFC 3204, December 2001. Objects", RFC 3204, December 2001.
[5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[6] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [5] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[6] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.1", RFC 4346, April 2006.
[7] Rosenberg, J., "Extensible Markup Language (XML) Formats for [7] Rosenberg, J., "Extensible Markup Language (XML) Formats for
Representing Resource Lists", Representing Resource Lists",
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-06 (work in progress), draft-ietf-sipping-uri-services-06 (work in progress),
September 2006. September 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-sip-uri-list-conferencing-00 (work in (SIP)", draft-ietf-sip-uri-list-conferencing-01 (work in
progress), September 2006. progress), January 2007.
[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-sip-uri-list-message-00 (work in progress), draft-ietf-sip-uri-list-message-01 (work in progress),
September 2006. January 2007.
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 16, line 7 skipping to change at page 17, 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 IETF Trust (2006). Copyright (C) The IETF Trust (2007).
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, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 21 change blocks. 
40 lines changed or deleted 55 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/