draft-ietf-sipping-transc-framework-00.txt   draft-ietf-sipping-transc-framework-01.txt 
Internet Engineering Task Force SIP WG SIPPING Working Group G. Camarillo
Internet Draft G. Camarillo Internet-Draft Ericsson
Ericsson Expires: August 22, 2005 February 21, 2005
draft-ietf-sipping-transc-framework-00.txt
February 6, 2004
Expires: August, 2004
Framework for Transcoding with the Session Initiation Protocol Conference Establishment Using Request-Contained Lists in the Session
Initiation Protocol (SIP)
draft-ietf-sipping-transc-framework-01.txt
STATUS OF THIS MEMO Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is subject to all provisions
all provisions of Section 10 of RFC2026. of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as
Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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.
To view the list Internet-Draft Shadow Directories, see 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 22, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract Abstract
This document defines a framework for transcoding with SIP. This This document defines a framework for transcoding with SIP. This
framework includes how to discover the need of transcoding services framework includes how to discover the need of transcoding services
in a session and how to invoke those transcoding services. Two models in a session and how to invoke those transcoding services. Two
for transcoding services invocation are discussed; the conference models for transcoding services invocation are discussed: the
bridge model and the third party call control model. Both models meet conference bridge model and the third party call control model. Both
the requirements for SIP regarding transcoding services invocation to models meet the requirements for SIP regarding transcoding services
support deaf, hard of hearing and speech-impaired individuals. invocation to support deaf, hard of hearing, and speech-impaired
individuals.
Table of Contents Table of Contents
1 Introduction ........................................ 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Discovery of the Need for Transcoding Services ...... 3 2. Discovery of the Need for Transcoding Services . . . . . . . . 3
3 Transcoding Services Invocation ..................... 4 3. Transcoding Services Invocation . . . . . . . . . . . . . . . 4
3.1 Third Party Call Control Transcoding Model .......... 5 3.1 Third Party Call Control Transcoding Model . . . . . . . . 5
3.2 Conference Bridge Transcoding Model ................. 5 3.2 Conference Bridge Transcoding Model . . . . . . . . . . . 6
4 Security Considerations ............................. 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5 Contributors ........................................ 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6 Authors' Addresses .................................. 8 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 8
7 Bibliography ........................................ 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1 Normative References . . . . . . . . . . . . . . . . . . . . 8
7.2 Informational References . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . 10
1 Introduction 1. Introduction
Two user agents involved in a SIP [1] dialog may find it impossible Two user agents involved in a SIP [2] dialog may find it impossible
to establish a media session due to a variety of incompatibilities. to establish a media session due to a variety of incompatibilities.
Assuming that both user agents understand the same session Assuming that both user agents understand the same session
description format (e.g., SDP), incompatibilities can be found at the description format (e.g., SDP [9]), incompatibilities can be found at
user agent level and at the user level. At the user agent level, both the user agent level and at the user level. At the user agent level,
terminals may not support any common codec or may not support common both terminals may not support any common codec or may not support
media types (e.g., a text-only terminal and an audio-only terminal). common media types (e.g., a text-only terminal and an audio-only
At the user level, a deaf person will not understand anything said terminal). At the user level, a deaf person will not understand
over an audio stream. anything said over an audio stream.
In order to make communications possible in the presence of In order to make communications possible in the presence of
incompatibilities, user agents need to introduce intermediaries that incompatibilities, user agents need to introduce intermediaries that
provide transcoding services to a session. From the SIP point of provide transcoding services to a session. From the SIP point of
view, the introduction of a transcoder is done in the same way to view, the introduction of a transcoder is done in the same way to
resolve both user level and user agent level incompatibilities. So, resolve both user level and user agent level incompatibilities. So,
the invocation mechanisms described in this document are generally the invocation mechanisms described in this document are generally
applicable to any type of incompatibility related to how the applicable to any type of incompatibility related to how the
information that needs to be communicated is encoded. information that needs to be communicated is encoded.
Furthermore, although this framework focuses on Furthermore, although this framework focuses on transcoding, the
transcoding, the mechanisms described are applicable to mechanisms described are applicable to media manipulation in
media manipulation in general. It would be possible to use general. It would be possible to use them, for example, to invoke
them, for example, to invoke a server that simply increased a server that simply increased the volume of an audio stream.
the volume of an audio stream.
This document does not describe media server discovery. That is an This document does not describe media server discovery. That is an
orthogonal problem that one can address using user agent provisioning orthogonal problem that one can address using user agent provisioning
or other methods. or other methods.
The remainder of this document is organized as follows. Section 2 The remainder of this document is organized as follows. Section 2
deals with the discovery of the need of transcoding services for a deals with the discovery of the need of transcoding services for a
particular session. Section 3.2 introduces the conference bridge particular session. Section 3 introduces the third party call
transcoding invocation model, and Section 3.1 introduces the third control and conference bridge transcoding invocation models, which
party call control model. Both models meet the requirements regarding are further described in Section 3.1 and Section 3.2 respectively.
transcoding services invocation in RFC3351 [2] to support deaf, hard Both models meet the requirements regarding transcoding services
of hearing and speech-impaired individuals. invocation in RFC3351 [4] to support deaf, hard of hearing and
speech-impaired individuals.
2 Discovery of the Need for Transcoding Services 2. Discovery of the Need for Transcoding Services
According to the one-party consent model defined in RFC 3238 [3], According to the one-party consent model defined in RFC 3238 [1] ,
services that involve media manipulation invocation are best invoked services that involve media manipulation invocation are best invoked
by one of the end-points involved in the communication, as opposed to by one of the end-points involved in the communication, as opposed to
being invoked by an intermediary in the network. Following this being invoked by an intermediary in the network. Following this
principle, one of the end-points should be the one detecting that principle, one of the end-points should be the one detecting that
transcoding is needed for a particular session. transcoding is needed for a particular session.
In order to decide whether or not transcoding is needed, a user agent In order to decide whether or not transcoding is needed, a user agent
needs to know the capabilities of the remote user agent. A user agent needs to know the capabilities of the remote user agent. A user
acting as an offerer typically obtains this knowledge by downloading agent acting as an offerer typically obtains this knowledge by
a presence document that includes media capabilities (e.g., Bob is downloading a presence document that includes media capabilities
available on a terminal that only supports audio) or by getting an (e.g., Bob is available on a terminal that only supports audio) or by
SDP description of media capabilities as defined in RFC 3264 [4]. getting an SDP description of media capabilities as defined in RFC
3264 [3].
Presence documents are typically received in a NOTIFY request as a Presence documents are typically received in a NOTIFY request as a
result of a subscription. SDP media capabilities descriptions are result of a subscription. SDP media capabilities descriptions are
typically received in a 200 (OK) response to an OPTIONS request or in typically received in a 200 (OK) response to an OPTIONS request or in
a 488 (Not Acceptable Here) response to an INVITE. a 488 (Not Acceptable Here) response to an INVITE.
It is recommended that an offerer does not invoke transcoding It is recommended that an offerer does not invoke transcoding
services before making sure that the answerer does not support the services before making sure that the answerer does not support the
capabilities needed for the session. Making wrong assumptions about capabilities needed for the session. Making wrong assumptions about
the answerer's capabilities can lead to situations where two the answerer's capabilities can lead to situations where two
transcoders are introduced (one by the offerer and one by the transcoders are introduced (one by the offerer and one by the
answerer) in a session that would not need any transcoding services answerer) in a session that would not need any transcoding services
at all. at all.
An example of the situation above is a call between two GSM An example of the situation above is a call between two GSM phones
phones (without using transcoding-free operation). Both (without using transcoding-free operation). Both phones use a GSM
phones use a GSM codec, but the speech is converted from codec, but the speech is converted from GSM to PCM by the
GSM to PCM by the originating MSC and from PCM back to GSM originating MSC and from PCM back to GSM by the terminating MSC.
by the terminating MSC.
Note that transcoding services can be symmetric (e.g., speech-to-text Note that transcoding services can be symmetric (e.g., speech-to-text
plus text-to-speech) or asymmetric (e.g., a one-way speech-to-text plus text-to-speech) or asymmetric (e.g., a one-way speech-to-text
transcoding for a hearing impaired user that can talk). transcoding for a hearing impaired user that can talk).
3 Transcoding Services Invocation 3. Transcoding Services Invocation
Once the need for transcoding for a particular session has been Once the need for transcoding for a particular session has been
identified as described in Section 2, one of the user agents needs to identified as described in Section 2, one of the user agents needs to
invoke transcoding services. invoke transcoding services.
As we said earlier, transcoder location is outside the scope of this As we said earlier, transcoder location is outside the scope of this
document. So, we assume that the user agent invoking transcoding document. So, we assume that the user agent invoking transcoding
services knows the URI of a server that provides them. services knows the URI of a server that provides them.
Invoking transcoding services from a server (T) for a session between Invoking transcoding services from a server (T) for a session between
skipping to change at page 5, line 13 skipping to change at page 5, line 13
use a (dial-in and dial-out) conference bridge that negotiates the use a (dial-in and dial-out) conference bridge that negotiates the
appropriate media parameters on each individual leg (i.e., A-T and appropriate media parameters on each individual leg (i.e., A-T and
T-B). T-B).
Section 3.1 analyzes the applicability of the third party call Section 3.1 analyzes the applicability of the third party call
control model and Section 3.2 analyzes the applicability of the control model and Section 3.2 analyzes the applicability of the
conference bridge transcoding invocation model. conference bridge transcoding invocation model.
3.1 Third Party Call Control Transcoding Model 3.1 Third Party Call Control Transcoding Model
In the 3pcc transcoding model, defined in (draft-ietf-sipping- In the 3pcc transcoding model, defined in [7], the user agent
transc-3pcc), the user agent invoking the transcoding service has a invoking the transcoding service has a signalling relationship with
signalling relationship with the transcoder and another signalling the transcoder and another signalling relationship with the remote
relationship with the remote user agent. There is no signalling user agent. There is no signalling relationship between the
relationship between the transcoder and the remote user agent, as transcoder and the remote user agent, as shown in Figure 1.
shown in Figure 1.
+-------+
| |
| T |**
| | **
+-------+ **
^ * **
| * **
| * **
SIP * **
| * **
| * **
v * **
+-------+ +-------+
| | | |
| A |<-----SIP----->| B |
| | | |
+-------+ +-------+
<-SIP-> Signalling
******* Media
Figure 1: Third party call control model
This model is suitable for advanced end points that are able to This model is suitable for advanced end points that are able to
perform third party call control. It allows end-points to invoke perform third party call control. It allows end-points to invoke
transcoding services on a stream basis. That is, the media streams transcoding services on a stream basis. That is, the media streams
that need transcoding are routed through the transcoder while the that need transcoding are routed through the transcoder while the
streams that do not need it are sent directly between the end points. streams that do not need it are sent directly between the end points.
This model also allows to invoke one transcoder for the sending This model also allows to invoke one transcoder for the sending
direction and a different one for the receiving direction of the same direction and a different one for the receiving direction of the same
stream. stream.
skipping to change at page 5, line 42 skipping to change at page 6, line 18
points cannot cope with the changes (e.g., they had common audio points cannot cope with the changes (e.g., they had common audio
codecs but no common video codecs). codecs but no common video codecs).
The privacy level that is achieved using 3pcc is high, since the The privacy level that is achieved using 3pcc is high, since the
transcoder does no see the signalling between both end-points. In transcoder does no see the signalling between both end-points. In
this model, the transcoder only has access to the information that is this model, the transcoder only has access to the information that is
strictly needed to perform its function. strictly needed to perform its function.
3.2 Conference Bridge Transcoding Model 3.2 Conference Bridge Transcoding Model
OPEN ISSUE: this section outlines how to use the URI-list
mechanism for INVITEs specified in [8] to invoke a transcoder.
Some people think that having an even simpler mechanism to perform
transcoding invocation would be useful. We need to decide whether
we are happy with the current solution or we want to use a
different mechanism.
In a centralized conference, there are a number of media streams In a centralized conference, there are a number of media streams
between the conference server and each participant of a conference. between the conference server and each participant of a conference.
For a given media type (e.g., audio) the conference server sends, For a given media type (e.g., audio) the conference server sends,
over each individual stream, the media received over the rest of the over each individual stream, the media received over the rest of the
streams, typically performing some mixing. If the capabilities of all streams, typically performing some mixing. If the capabilities of
the end-points participating in the conference are not the same, the all the end-points participating in the conference are not the same,
conference server may have to send audio to different participants the conference server may have to send audio to different
using different audio codecs. participants using different audio codecs.
+-------+
| |
| T |**
| | **
+-------+ **
^ * **
| * **
| * **
SIP * **
| * **
| * **
v * **
+-------+ +-------+
| | | |
| A |<-----SIP----->| B |
| | | |
+-------+ +-------+
<-SIP-> Signalling
******* Media
Figure 1: Third Party Call Control Model
Consequently, we can model a transcoding service as a two-party Consequently, we can model a transcoding service as a two-party
conference server that may change not only the codec in use, but also conference server that may change not only the codec in use, but also
the format of the media (e.g., audio to text). the format of the media (e.g., audio to text).
Using this model, T behaves as a B2BUA and the whole A-T-B session is Using this model, T behaves as a B2BUA and the whole A-T-B session is
established as described in [6]. Figure 2 shows the signalling established as described in [draft-camarillo-sipping-transc-b2bua].
relationships between the end-points and the transcoder. Figure 2 shows the signalling relationships between the end-points
and the transcoder.
In the conferencing bridge model, the end-point invoking the
transcoder is generally involved in less signalling exchanges than in
the 3pcc model. This may be an important feature for end-poing using
low bandwidth or high-delay access links (e.g., some wireless
+-------+ +-------+
| |** | |**
| T | ** | T | **
| |\ ** | |\ **
+-------+ \\ ** +-------+ \\ **
^ * \\ ** ^ * \\ **
| * \\ ** | * \\ **
| * SIP ** | * SIP **
SIP * \\ ** SIP * \\ **
| * \\ ** | * \\ **
skipping to change at page 7, line 25 skipping to change at page 7, line 26
v * \ ** v * \ **
+-------+ +-------+ +-------+ +-------+
| | | | | | | |
| A | | B | | A | | B |
| | | | | | | |
+-------+ +-------+ +-------+ +-------+
<-SIP-> Signalling <-SIP-> Signalling
******* Media ******* Media
Figure 2: Conference Bridge Control Model Figure 2: Conference bridge model
In the conferencing bridge model, the end-point invoking the
transcoder is generally involved in less signalling exchanges than in
the 3pcc model. This may be an important feature for end-poing using
low bandwidth or high-delay access links (e.g., some wireless
accesses). accesses).
On the other hand, this model is less flexible than the 3pcc model. On the other hand, this model is less flexible than the 3pcc model.
It is not possible to use different transcoders for different streams It is not possible to use different transcoders for different streams
or for different directions of a stream. or for different directions of a stream.
Invoking a transcoder in the middle of an ongoing session or changing Invoking a transcoder in the middle of an ongoing session or changing
from one transcoder to another requires the remote end-point to from one transcoder to another requires the remote end-point to
support the Replaces [7] extension. At present, not many user agents support the Replaces [6] extension. At present, not many user agents
support it. support it.
Simple end-points that cannot perform 3pcc and thus cannot use the Simple end-points that cannot perform 3pcc and thus cannot use the
3pcc model, of course, need to use the conference bridge model. 3pcc model, of course, need to use the conference bridge model.
4 Security Considerations 4. Security Considerations
This document does not introduce any new security considerations. TBD.
5 Contributors 5. IANA Considerations
This document does not contain any IANA actions.
6. Contributors
This document is the result of discussions amongst the conferencing This document is the result of discussions amongst the conferencing
design team. The members of this team include Eric Burger, Henning design team. The members of this team include Eric Burger, Henning
Schulzrinne and Arnoud van Wijk. Schulzrinne and Arnoud van Wijk.
6 Authors' Addresses 7. References
Gonzalo Camarillo 7.1 Normative References
Ericsson
Advanced Signalling Research Lab.
FIN-02420 Jorvas
Finland
electronic mail: Gonzalo.Camarillo@ericsson.com
7 Bibliography [1] Floyd, S. and L. Daigle, "IAB Architectural and Policy
Considerations for Open Pluggable Edge Services", RFC 3238,
January 2002.
[1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
initiation protocol," RFC 3261, Internet Engineering Task Force, June Session Initiation Protocol", RFC 3261, June 2002.
2002.
[2] N. Charlton, M. Gasson, G. Gybels, M. Spanner, and A. van Wijk, [3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
"User requirements for the session initiation protocol (SIP) in Session Description Protocol (SDP)", RFC 3264, June 2002.
support of deaf, hard of hearing and speech-impaired individuals,"
RFC 3351, Internet Engineering Task Force, Aug. 2002.
[3] S. Floyd and L. Daigle, "IAB architectural and policy [4] Charlton, N., Gasson, M., Gybels, G., Spanner, M. and A. van
considerations for open pluggable edge services," RFC 3238, Internet Wijk, "User Requirements for the Session Initiation Protocol
Engineering Task Force, Jan. 2002. (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired
Individuals", RFC 3351, August 2002.
[4] J. Rosenberg and H. Schulzrinne, "An offer/answer model with [5] Rosenberg, J., Peterson, J., Schulzrinne, H. and G. Camarillo,
session description protocol (SDP)," RFC 3264, Internet Engineering "Best Current Practices for Third Party Call Control (3pcc) in
Task Force, June 2002. the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April
2004.
[5] J. Rosenberg, J. Peterson, H. Schulzrinne, and G. Camarillo, [6] Mahy, R., Biggs, B. and R. Dean, "The Session Initiation
"Best current practices for third party call control in the session Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
initiation protocol," Internet Draft draft-ietf-sipping-3pcc-06,
Internet Engineering Task Force, Jan. 2004. Work in progress.
[6] G. Camarillo, "The session initiation protocol conference bridge [7] Camarillo, G., "Transcoding Services Invocation in the Session
transcoding model," Internet Draft draft-camarillo-sipping-transc- Initiation Protocol (SIP) Using Third Party Call Control
b2bua-00, Internet Engineering Task Force, Aug. 2003. Work in (3pcc)", draft-ietf-sipping-transc-3pcc-02 (work in progress),
progress. September 2004.
[7] B. Biggs, R. W. Dean, and R. Mahy, "The session inititation [8] Camarillo, G. and A. Johnston, "Conference Establishment Using
protocol (SIP) Engineering Task Force, Aug. 2003. Work in progress. Request-Contained Lists in the Session Initiation Protocol
(SIP)", draft-ietf-sipping-uri-list-conferencing-01 (work in
progress), October 2004.
7.2 Informational References
[9] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
Author's Address
Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
EMail: Gonzalo.Camarillo@ericsson.com
Intellectual Property Statement
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 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; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. 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 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 which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at
Director. ietf-ipr@ietf.org.
Full Copyright Statement Disclaimer of Validity
Copyright (c) The Internet Society (2004). All Rights Reserved. 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.
This document and translations of it may be copied and furnished to Copyright Statement
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be Copyright (C) The Internet Society (2005). This document is subject
revoked by the Internet Society or its successors or assigns. 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 is provided on an Acknowledgment
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING Funding for the RFC Editor function is currently provided by the
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Internet Society.
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/