draft-ietf-mmusic-img-req-06.txt   draft-ietf-mmusic-img-req-07.txt 
skipping to change at page 1, line 13 skipping to change at page 1, line 13
Internet Engineering Task Force MMUSIC WG Internet Engineering Task Force MMUSIC WG
Internet Draft Y. Nomura Internet Draft Y. Nomura
Fujitsu Labs. Fujitsu Labs.
R. Walsh R. Walsh
J-P. Luoma J-P. Luoma
Nokia Nokia
J. Ott J. Ott
Universitaet Bremen Universitaet Bremen
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
draft-ietf-mmusic-img-req-06.txt draft-ietf-mmusic-img-req-07.txt
June 1, 2004 June 21, 2004
Expires: December 2004 Expires: December 2004
Requirements for Internet Media Guides Requirements for Internet Media Guides
STATUS OF THIS MEMO STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, I certify that any applicable
all provisions of Section 10 of RFC2026. patent or other IPR claims of which I am aware have been disclosed,
and any of which I 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
and may be updated, replaced, or obsoleted by other documents at any months and may be updated, replaced, or obsoleted by other
time. It is inappropriate to use Internet-Drafts as reference documents at any time. It is inappropriate to use Internet-Drafts
material or to cite them other than as "work in progress". as reference material or to cite them other than a "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/1id-abstracts.html
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
Abstract Abstract
This memo specifies requirements for a framework and protocols for This memo specifies requirements for a framework and protocols for
accessing and updating Internet Media Guide (IMG) information for accessing and updating Internet Media Guide (IMG) information for
media-on-demand and multicast applications. These requirements are media-on-demand and multicast applications. These requirements are
designed to guide choice and development of IMG protocols for designed to guide choice and development of IMG protocols for
efficient and scalable delivery. efficient and scalable delivery.
Table of Contents Table of Contents
skipping to change at page 2, line 46 skipping to change at page 2, line 46
5.4.1 Managing Consistency ................................ 14 5.4.1 Managing Consistency ................................ 14
5.4.2 Reliable Message Exchange ........................... 15 5.4.2 Reliable Message Exchange ........................... 15
5.5 IMG Descriptions .................................... 15 5.5 IMG Descriptions .................................... 15
6 Security Considerations ............................. 17 6 Security Considerations ............................. 17
6.1 IMG Authentication and Integrity .................... 17 6.1 IMG Authentication and Integrity .................... 17
6.2 Privacy ............................................. 18 6.2 Privacy ............................................. 18
6.3 Access Control for IMGs ............................. 18 6.3 Access Control for IMGs ............................. 18
6.4 Denial-of-Service attacks ........................... 19 6.4 Denial-of-Service attacks ........................... 19
6.5 Replay Attacks ...................................... 19 6.5 Replay Attacks ...................................... 19
7 IANA Considerations ................................. 20 7 IANA Considerations ................................. 20
8 References .......................................... 20 8 Normative References ................................ 20
9 Acknowledgements .................................... 21 9 Informative References .............................. 20
10 Authors' Addresses .................................. 21 10 Acknowledgements .................................... 21
11 Full Copyright Statement ............................ 22 11 Authors' Addresses .................................. 21
12 Full Copyright Statement ............................ 22
1 Introduction 1 Introduction
1.1 Background and Motivation 1.1 Background and Motivation
For some ten years, multicast-based (multimedia) conferences For some ten years, multicast-based (multimedia) conferences
(including IETF WG sessions) as well as broadcasts of (including IETF WG sessions) as well as broadcasts of
lectures/seminars, concerts, and other events have been used in the lectures/seminars, concerts, and other events have been used in the
Internet, more precisely, on the MBONE. Schedules and descriptions Internet, more precisely, on the MBONE. Schedules and descriptions
for such multimedia sessions as well as the transport addresses, for such multimedia sessions as well as the transport addresses,
codecs, and their parameters have been described using SDP [1] as a codecs, and their parameters have been described using SDP [2] as a
rudimentary (but as of then largely sufficient) means. Dissemination rudimentary (but as of then largely sufficient) means. Dissemination
of the descriptions has been performed using the Session Announcement of the descriptions has been performed using the Session Announcement
Protocol (SAP) [2] and tools such as SD [3] or SDR [4]; descriptions Protocol (SAP) [3] and tools such as SD [4] or SDR [5]; descriptions
have also been put up on web pages, sent by electronic mail, etc. have also been put up on web pages, sent by electronic mail, etc.
Recently, interest has grown to expand -- or better: to generalize -- Recently, interest has grown to expand -- or better: to generalize --
the applicability of these kinds of session descriptions. the applicability of these kinds of session descriptions.
Descriptions are becoming more elaborate in terms of included Descriptions are becoming more elaborate in terms of included
metadata; more generic regarding the types of media sessions; and metadata; more generic regarding the types of media sessions; and
possibly also support other transports than just IP (e.g. legacy TV possibly also support other transports than just IP (e.g. legacy TV
channel addresses). This peers well with the DVB Organization's channel addresses). This peers well with the DVB Organization's
increased activities towards IP-based communications over satellite, increased activities towards IP-based communications over satellite,
cable, and terrestrial radio networks, also considering IP as the cable, and terrestrial radio networks, also considering IP as the
basis for TV broadcasts and further services. The program/content basis for TV broadcasts and further services. The program/content
descriptions are referred to as Internet Media Guides (IMGs) and can descriptions are referred to as Internet Media Guides (IMGs) and can
be viewed as a generalization of Electronic Program Guides (EPGs) and be viewed as a generalization of Electronic Program Guides (EPGs) and
multimedia session descriptions. multimedia session descriptions.
An Internet Media Guide (IMG) has a structured collection of An Internet Media Guide (IMG) has a structured collection of
multimedia session descriptions expressed using SDP, SDPng [5] or multimedia session descriptions expressed using SDP, SDPng [6] or
some similar session description format. This is used to describe a some similar session description format. This is used to describe a
set of multimedia services (e.g. television program schedules, set of multimedia services (e.g. television program schedules,
content delivery schedules) but may also refer to other networked content delivery schedules) but may also refer to other networked
resources including web pages. IMGs provide the envelope for metadata resources including web pages. IMGs provide the envelope for metadata
formats and session descriptions defined elsewhere with the aim of formats and session descriptions defined elsewhere with the aim of
facilitating structuring, versioning, referencing, distributing, and facilitating structuring, versioning, referencing, distributing, and
maintaining (caching, updating) such information. maintaining (caching, updating) such information.
The IMG metadata may be delivered to a potentially large audience, The IMG metadata may be delivered to a potentially large audience,
who use it to join a subset of the sessions described, and who may who use it to join a subset of the sessions described, and who may
skipping to change at page 4, line 50 skipping to change at page 4, line 50
statement and existing mechanisms in this area. Then several use case statement and existing mechanisms in this area. Then several use case
scenarios for IMGs are explained including descriptions of how IMG scenarios for IMGs are explained including descriptions of how IMG
metadata and IMG delivery mechanisms contribute to these scenarios. metadata and IMG delivery mechanisms contribute to these scenarios.
Following this, this document provides general requirements that are Following this, this document provides general requirements that are
independent of any transport layer mechanism and application, such as independent of any transport layer mechanism and application, such as
delivery properties, reliability and IMG descriptions. delivery properties, reliability and IMG descriptions.
This document reflects investigating work on delivery mechanisms for This document reflects investigating work on delivery mechanisms for
IMGs and generalizing work on session announcement and initiation IMGs and generalizing work on session announcement and initiation
protocols, especially in the field of the MMUSIC working group (SAP, protocols, especially in the field of the MMUSIC working group (SAP,
SIP [6], SDP). SIP [7], SDP).
2 Terminology 2 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [7]. document are to be interpreted as described in RFC 2119 [1].
Internet Media Guide (IMG): IMG is a generic term to describe Internet Media Guide (IMG): IMG is a generic term to describe
the formation, delivery and use of IMG metadata. The the formation, delivery and use of IMG metadata. The
definition of the IMG is intentionally left imprecise. definition of the IMG is intentionally left imprecise.
IMG Element: The smallest atomic element of metadata that can be IMG Element: The smallest atomic element of metadata that can be
transmitted separately by IMG operations and referenced transmitted separately by IMG operations and referenced
individually from other IMG elements. individually from other IMG elements.
IMG Metadata: A set of metadata consisting of one or more IMG IMG Metadata: A set of metadata consisting of one or more IMG
skipping to change at page 6, line 24 skipping to change at page 6, line 24
itself produces Session Announcement Protocol (SAP), Session itself produces Session Announcement Protocol (SAP), Session
Description Protocol (SDP), and the Session Initiation Protocol Description Protocol (SDP), and the Session Initiation Protocol
(SIP). SDP is capable of describing multimedia sessions (i.e. (SIP). SDP is capable of describing multimedia sessions (i.e.
content in a wider sense) by means of limited descriptive information content in a wider sense) by means of limited descriptive information
intended for human perception plus transport, scheduling information, intended for human perception plus transport, scheduling information,
and codecs and addresses for setting up media sessions. SIP and SAP and codecs and addresses for setting up media sessions. SIP and SAP
are protocols to distribute these session descriptions. are protocols to distribute these session descriptions.
However, we perceive a lack of a standard solution for scalable IMG However, we perceive a lack of a standard solution for scalable IMG
delivery mechanism in the number of receivers with consistency of IMG delivery mechanism in the number of receivers with consistency of IMG
metadata between an IMG sender and IMG receiver for both bi- metadata between an IMG sender and IMG receiver for both
directional and unidirectional transport. With increased service bi-directional and unidirectional transport. With increased service
dynamics and complexity, there is an increased requirement for dynamics and complexity, there is an increased requirement for
updates to these content descriptions. updates to these content descriptions.
HTTP [9] is a well known information retrieval protocol using bi- HTTP [9] is a well known information retrieval protocol using
directional transport and widely used to deliver web-based content bi-directional transport and widely used to deliver web-based
descriptions to many hosts. However, it has well recognized content descriptions to many hosts. However, it has well recognized
limitations of scalability in the number of HTTP clients since it limitations of scalability in the number of HTTP clients since it
relies on the polling mechanism to keep information consistent relies on the polling mechanism to keep information consistent
between the server and client. between the server and client.
SAP [2] is an announcement protocol that distributes session SAP [3] is an announcement protocol that distributes session
descriptions via multicast. It does not support prioritization or descriptions via multicast. It does not support prioritization or
fine-grained metadata selection and update notifications, as it fine-grained metadata selection and update notifications, as it
places restrictions on metadata payload size and always sends the places restrictions on metadata payload size and always sends the
whole metadata. It requires a wide-area multicast infrastructure for whole metadata. It requires a wide-area multicast infrastructure for
it to be deployable beyond a local area network. it to be deployable beyond a local area network.
SIP [6] and SIP-specific event notification [10] can be used to SIP [7] and SIP-specific event notification [10] can be used to
notify subscribers of the update of IMG metadata for bi-directional notify subscribers of the update of IMG metadata for bi-directional
transport. However, it is necessary for SIP Event to define an event transport. However, it is necessary for SIP Event to define an event
package as a standard protocol for each specific application package as a standard protocol for each specific application
including IMGs. including IMGs.
We also perceive a lack of standard solution for flexible content We also perceive a lack of standard solution for flexible content
descriptions to support a multitude of application-specific metadata descriptions to support a multitude of application-specific metadata
and associated data models with differing amount of detail and and associated data models with differing amount of detail and
different target audiences. different target audiences.
SDP [1] has a text-encoded syntax to specify multimedia sessions for SDP [2] has a text-encoded syntax to specify multimedia sessions for
announcements and invitations. It is primarily intended to describe announcements and invitations. It is primarily intended to describe
client capability requirements and enable client application client capability requirements and enable client application
selection. Although SDP is extensible, it has limitations such as selection. Although SDP is extensible, it has limitations such as
structured extensibility and capability to reference properties of a structured extensibility and capability to reference properties of a
multimedia session from the description of another session. multimedia session from the description of another session.
These are mostly overcome by the XML-based SDPng, which is intended These are mostly overcome by the XML-based SDPng, which is intended
for both two-way negotiation and also unidirectional delivery. Since for both two-way negotiation and also unidirectional delivery. Since
SDPng addresses multiparty multimedia conferences, it is necessary to SDPng addresses multiparty multimedia conferences, it is necessary to
extend the XML schema in order to describe general multimedia extend the XML schema in order to describe general multimedia
skipping to change at page 11, line 9 skipping to change at page 11, line 9
Since IMG metadata can describe time-related data for each receiver, Since IMG metadata can describe time-related data for each receiver,
the content provider can schedule delivery time for each receiver. the content provider can schedule delivery time for each receiver.
This can save network bandwidth and delivery capacity of senders. In This can save network bandwidth and delivery capacity of senders. In
addition, IMG metadata can be used to consistency check, and thus addition, IMG metadata can be used to consistency check, and thus
synchronize, a set of files between a sender host and receiver host, synchronize, a set of files between a sender host and receiver host,
when those files change as time elapses. when those files change as time elapses.
4.2.6 Coming-release and Pre-released Content 4.2.6 Coming-release and Pre-released Content
IMG metadata can be used to describe items of content before the IMG metadata can be used to describe items of content before the
details of their final release are known. A user may be interested in details of their final release are known. A user may be interested
coming content (a new movie or software title where some aspects of in coming content (a new movie or software title where some aspects
the content description are known in advance) and so subscribe to an of the content description are known in advance) and so subscribe
information service which notifies the user of changes to metadata to an information service which notifies the user of changes to
describing that content. Thus, as the coming release, or pre- metadata describing that content. Thus, as the coming release, or
releases, (such as movie trailers or software demos) become available pre-releases, (such as movie trailers or software demos) become
the IMG metadata changes and the user is notified of this change. For available the IMG metadata changes and the user is notified of this
example, the user could see an announcement of a movie that will be change. For example, the user could see an announcement of a movie
released sometime in the next few months, and configure the user's that will be released sometime in the next few months, and
terminal to receive and record any trailers or promotional material configure the user's terminal to receive and record any trailers or
as they become available. promotional material as they become available.
5 Requirements 5 Requirements
5.1 General Requirements 5.1 General Requirements
5.1.1 Independence of IMG Operations from IMG Metadata 5.1.1 Independence of IMG Operations from IMG Metadata
REQ GEN-1: Carrying different kinds of IMG metadata format in the IMG REQ GEN-1: Carrying different kinds of IMG metadata format in the IMG
message body MUST be allowed. message body MUST be allowed.
skipping to change at page 18, line 32 skipping to change at page 18, line 32
preferences of a user and may thus deserve confidentiality preferences of a user and may thus deserve confidentiality
protection, even though the information itself is public. protection, even though the information itself is public.
REQ PRI-1: It MUST be possible to keep user requests to subscribe to REQ PRI-1: It MUST be possible to keep user requests to subscribe to
or retrieve certain (parts of) IMG metadata confidential. or retrieve certain (parts of) IMG metadata confidential.
REQ PRI-2: It MUST be possible to keep IMG metadata, pieces of IMG REQ PRI-2: It MUST be possible to keep IMG metadata, pieces of IMG
metadata, or pointers to IMG metadata delivered to individual users metadata, or pointers to IMG metadata delivered to individual users
or groups of users confidential. or groups of users confidential.
REQ PRI-3: It SHOULD be possible to ensure this confidentiality end- REQ PRI-3: It SHOULD be possible to ensure this confidentiality
to-end, that is, to prevent intermediaries (such as IMG transceivers) end-to-end, that is, to prevent intermediaries (such as IMG
from accessing the contained information. transceivers) from accessing the contained information.
6.3 Access Control for IMGs 6.3 Access Control for IMGs
Some IMG metadata may be freely available, while access to other IMG Some IMG metadata may be freely available, while access to other IMG
metadata may be restricted to closed user groups (e.g. paying metadata may be restricted to closed user groups (e.g. paying
subscribers). Also, different parts of IMG metadata may be protected subscribers). Also, different parts of IMG metadata may be protected
at different levels: e.g. metadata describing a media session may be at different levels: e.g. metadata describing a media session may be
freely accessible while rendezvous information to actually access the freely accessible while rendezvous information to actually access the
media session may require authorization. media session may require authorization.
skipping to change at page 20, line 26 skipping to change at page 20, line 26
relay attacks may lead to different solutions for different systems, relay attacks may lead to different solutions for different systems,
independent of the basic delivery method and metadata definitions. A independent of the basic delivery method and metadata definitions. A
system with multiple senders presents a more challenging scenario for system with multiple senders presents a more challenging scenario for
handling replay attacks. As an example, bundling metadata with a handling replay attacks. As an example, bundling metadata with a
security mechanism is one potential solution. security mechanism is one potential solution.
7 IANA Considerations 7 IANA Considerations
There are no IANA considerations within this document. There are no IANA considerations within this document.
8 References 8 Normative References
[1] M. Handley and V. Jacobson, "SDP: session description protocol," [1] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.
9 Informative References
[2] M. Handley and V. Jacobson, "SDP: session description protocol,"
RFC 2327, Internet Engineering Task Force, Apr. 1998. RFC 2327, Internet Engineering Task Force, Apr. 1998.
[2] M. Handley, C. E. Perkins, and E. Whelan, "Session announcement [3] M. Handley, C. E. Perkins, and E. Whelan, "Session announcement
protocol," RFC 2974, Internet Engineering Task Force, Oct. 2000. protocol," RFC 2974, Internet Engineering Task Force, Oct. 2000.
[3] Session Directory, ftp://ftp.ee.lbl.gov/conferencing/sd/ [4] Session Directory, ftp://ftp.ee.lbl.gov/conferencing/sd/
[4] Session Directory Tool, http://www- [5] Session Directory Tool,
mice.cs.ucl.ac.uk/multimedia/software/sdr/ http://www-mice.cs.ucl.ac.uk/multimedia/software/sdr/
[5] D. Kutscher, J. Ott, and C. Bormann, "Session description and [6] D. Kutscher, J. Ott, and C. Bormann, "Session description and
capability negotiation," Internet Draft draft-ietf-mmusic-sdpng-07, capability negotiation," Internet Draft draft-ietf-mmusic-sdpng-07,
Internet Engineering Task Force, Oct. 2003. Work in progress. Internet Engineering Task Force, Oct. 2003. Work in progress.
[6] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. [7] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J.
Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session
initiation protocol," RFC 3261, Internet Engineering Task Force, June initiation protocol," RFC 3261, Internet Engineering Task Force, June
2002. 2002.
[7] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.
[8] Y. Nomura, R. Walsh, J-P. Luoma, H. Asaeda, and H. Schulzrinne, [8] Y. Nomura, R. Walsh, J-P. Luoma, H. Asaeda, and H. Schulzrinne,
"A framework for the usage of Internet media guides," Internet Draft "A framework for the usage of Internet media guides," Internet Draft
draft-ietf-mmusic-img-framework-06, Internet Engineering Task Force, draft-ietf-mmusic-img-framework-07, Internet Engineering Task Force,
June 2004. Work in progress. June 2004. Work in progress.
[9] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, L. Masinter, P. [9] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, L. Masinter, P.
Leach and T. Berners-Lee, "Hypertext transfer protocol -- HTTP/1.1," Leach and T. Berners-Lee, "Hypertext transfer protocol -- HTTP/1.1,"
RFC 2616, Internet Engineering Task Force, June 1999. RFC 2616, Internet Engineering Task Force, June 1999.
[10] A. B. Roach, "Session initiation protocol (sip)-specific event [10] A. B. Roach, "Session initiation protocol (sip)-specific event
notification," RFC 3265, Internet Engineering Task Force, June 2002. notification," RFC 3265, Internet Engineering Task Force, June 2002.
[11] B. Quinn and K. Almeroth, "IP multicast applications: Challenges [11] B. Quinn and K. Almeroth, "IP multicast applications: Challenges
and solutions," RFC 3170, Internet Engineering Task Force, Sept. and solutions," RFC 3170, Internet Engineering Task Force, Sept.
2001. 2001.
9 Acknowledgements 10 Acknowledgements
The authors would like to thank Colin Perkins, Jean-Pierre Evain, The authors would like to thank Colin Perkins, Jean-Pierre Evain,
Gonzalo Camarillo, Magnus Westerlund, Hitoshi Asaeda, Petri Gonzalo Camarillo, Magnus Westerlund, Hitoshi Asaeda, Petri
Koskelainen, Toni Paila and Dirk Kutscher for their excellent Koskelainen, Toni Paila and Dirk Kutscher for their excellent
comments and ideas on this work. comments and ideas on this work.
10 Authors' Addresses 11 Authors' Addresses
Yuji Nomura Yuji Nomura
Fujitsu Laboratories Ltd. Fujitsu Laboratories Ltd.
4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki 211-8588 4-1-1 Kamikodanaka, Nakahara-ku, Kawasaki 211-8588
Japan Japan
Email: nom@flab.fujitsu.co.jp Email: nom@flab.fujitsu.co.jp
Rod Walsh Rod Walsh
Nokia Research Center Nokia Research Center
P.O. Box 100, FIN-33721 Tampere P.O. Box 100, FIN-33721 Tampere
skipping to change at page 22, line 14 skipping to change at page 22, line 14
Email: jo@tzi.uni-bremen.de Email: jo@tzi.uni-bremen.de
Henning Schulzrinne Henning Schulzrinne
Dept. of Computer Science Dept. of Computer Science
Columbia University Columbia University
1214 Amsterdam Avenue 1214 Amsterdam Avenue
New York, NY 10027 New York, NY 10027
USA USA
Email: schulzrinne@cs.columbia.edu Email: schulzrinne@cs.columbia.edu
11 Full Copyright Statement 12 Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78 and to the rights, licenses and restrictions contained in BCP 78 and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors 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 AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 End of changes. 

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