draft-ietf-mmusic-file-transfer-mech-09.txt   draft-ietf-mmusic-file-transfer-mech-10.txt 
MMUSIC Working Group M. Garcia-Martin MMUSIC Working Group M. Garcia-Martin
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track M. Isomaki Intended status: Standards Track M. Isomaki
Expires: May 7, 2009 Nokia Expires: July 26, 2009 Nokia
G. Camarillo G. Camarillo
S. Loreto S. Loreto
Ericsson Ericsson
P. Kyzivat P. Kyzivat
Cisco Systems Cisco Systems
November 3, 2008 January 22, 2009
A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable
File Transfer File Transfer
draft-ietf-mmusic-file-transfer-mech-09.txt draft-ietf-mmusic-file-transfer-mech-10.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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.
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 Internet-
Drafts. 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.
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 May 7, 2009. This Internet-Draft will expire on July 26, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract Abstract
This document provides a mechanism to negotiate the transfer of one This document provides a mechanism to negotiate the transfer of one
or more files between two endpoints by using the Session Description or more files between two endpoints by using the Session Description
Protocol (SDP) offer/answer model specified in RFC 3264. SDP is Protocol (SDP) offer/answer model specified in RFC 3264. SDP is
extended to describe the attributes of the files to be transferred. extended to describe the attributes of the files to be transferred.
The offerer can either describe the files it wants to send, or the The offerer can either describe the files it wants to send, or the
files it would like to receive. The answerer can either accept or files it would like to receive. The answerer can either accept or
reject the offer separately for each individual file. The transfer reject the offer separately for each individual file. The transfer
skipping to change at page 3, line 22 skipping to change at page 3, line 22
6. Extensions to SDP . . . . . . . . . . . . . . . . . . . . . . 8 6. Extensions to SDP . . . . . . . . . . . . . . . . . . . . . . 8
7. File Disposition Types . . . . . . . . . . . . . . . . . . . . 13 7. File Disposition Types . . . . . . . . . . . . . . . . . . . . 13
8. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 14 8. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 14
8.1. The 'file-transfer-id' attribute . . . . . . . . . . . . . 14 8.1. The 'file-transfer-id' attribute . . . . . . . . . . . . . 14
8.2. Offerer's Behavior . . . . . . . . . . . . . . . . . . . . 17 8.2. Offerer's Behavior . . . . . . . . . . . . . . . . . . . . 17
8.2.1. The Offerer is a File Sender . . . . . . . . . . . . . 17 8.2.1. The Offerer is a File Sender . . . . . . . . . . . . . 17
8.2.2. The Offerer is a File Receiver . . . . . . . . . . . . 18 8.2.2. The Offerer is a File Receiver . . . . . . . . . . . . 18
8.2.3. SDP Offer for Several Files . . . . . . . . . . . . . 19 8.2.3. SDP Offer for Several Files . . . . . . . . . . . . . 19
8.3. Answerer's Behavior . . . . . . . . . . . . . . . . . . . 19 8.3. Answerer's Behavior . . . . . . . . . . . . . . . . . . . 19
8.3.1. The Answerer is a File Receiver . . . . . . . . . . . 19 8.3.1. The Answerer is a File Receiver . . . . . . . . . . . 19
8.3.2. The Answerer is a File Sender . . . . . . . . . . . . 20 8.3.2. The Answerer is a File Sender . . . . . . . . . . . . 21
8.4. Aborting an ongoing file transfer operation . . . . . . . 22 8.4. Aborting an ongoing file transfer operation . . . . . . . 22
8.5. Indicating File Transfer Offer/Answer Capability . . . . . 25 8.5. Indicating File Transfer Offer/Answer Capability . . . . . 25
8.6. Re-usage of Existing "m=" Lines in SDP . . . . . . . . . . 26 8.6. Re-usage of Existing "m=" Lines in SDP . . . . . . . . . . 26
8.7. MSRP Usage . . . . . . . . . . . . . . . . . . . . . . . . 26 8.7. MSRP Usage . . . . . . . . . . . . . . . . . . . . . . . . 26
8.8. Considerations about the 'file-icon' attribute . . . . . . 28 8.8. Considerations about the 'file-icon' attribute . . . . . . 28
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.1. Offerer sends a file to the Answerer . . . . . . . . . . . 28 9.1. Offerer sends a file to the Answerer . . . . . . . . . . . 28
9.2. Offerer requests a file from the Answerer and second 9.2. Offerer requests a file from the Answerer and second
file transfer . . . . . . . . . . . . . . . . . . . . . . 33 file transfer . . . . . . . . . . . . . . . . . . . . . . 33
9.3. Example of a capability indication . . . . . . . . . . . . 40 9.3. Example of a capability indication . . . . . . . . . . . . 40
10. Security Considerations . . . . . . . . . . . . . . . . . . . 41 10. Security Considerations . . . . . . . . . . . . . . . . . . . 41
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
11.1. Registration of new SDP attributes . . . . . . . . . . . . 42 11.1. Registration of new SDP attributes . . . . . . . . . . . . 42
11.1.1. Registration of the file-selector attribute . . . . . 42 11.1.1. Registration of the file-selector attribute . . . . . 43
11.1.2. Registration of the file-transfer-id attribute . . . . 43 11.1.2. Registration of the file-transfer-id attribute . . . . 43
11.1.3. Registration of the file-disposition attribute . . . . 43 11.1.3. Registration of the file-disposition attribute . . . . 43
11.1.4. Registration of the file-date attribute . . . . . . . 43 11.1.4. Registration of the file-date attribute . . . . . . . 43
11.1.5. Registration of the file-icon attribute . . . . . . . 44 11.1.5. Registration of the file-icon attribute . . . . . . . 44
11.1.6. Registration of the file-range attribute . . . . . . . 44 11.1.6. Registration of the file-range attribute . . . . . . . 44
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45
13.1. Normative References . . . . . . . . . . . . . . . . . . . 44 13.1. Normative References . . . . . . . . . . . . . . . . . . . 45
13.2. Informational References . . . . . . . . . . . . . . . . . 45 13.2. Informational References . . . . . . . . . . . . . . . . . 46
Appendix A. Alternatives Considered . . . . . . . . . . . . . . . 46 Appendix A. Alternatives Considered . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48
Intellectual Property and Copyright Statements . . . . . . . . . . 49
1. Introduction 1. Introduction
The Session Description Protocol (SDP) Offer/Answer [RFC3264] The Session Description Protocol (SDP) Offer/Answer [RFC3264]
provides a mechanism for two endpoints to arrive at a common view of provides a mechanism for two endpoints to arrive at a common view of
a multimedia session between them. These sessions often contain a multimedia session between them. These sessions often contain
real-time media streams such as voice and video, but are not limited real-time media streams such as voice and video, but are not limited
to that. Basically, any media component type can be supported, as to that. Basically, any media component type can be supported, as
long as there is a specification how to negotiate it within the SDP long as there is a specification how to negotiate it within the SDP
offer/answer exchange. offer/answer exchange.
skipping to change at page 18, line 35 skipping to change at page 18, line 35
file. file.
When the file sender receives the SDP answer, if the port number of When the file sender receives the SDP answer, if the port number of
the answer for a file request is non-zero, the file sender starts the the answer for a file request is non-zero, the file sender starts the
transfer of the file according to the negotiated parameters in SDP. transfer of the file according to the negotiated parameters in SDP.
8.2.2. The Offerer is a File Receiver 8.2.2. The Offerer is a File Receiver
In a pull operation, the file receiver creates the SDP offer and In a pull operation, the file receiver creates the SDP offer and
sends it to the file sender. The file receiver MUST include a 'file- sends it to the file sender. The file receiver MUST include a 'file-
selector' attribute and SHOULD add, at least, one of the selector selector' attribute and MUST include, at least, one of the selectors
defined for that attribute (i.e., 'name', 'type', 'size', or 'hash'). defined for such attribute (i.e., 'name', 'type', 'size', or 'hash').
In many cases, if the hash of the file is known, that is enough to In many cases, if the hash of the file is known, that is enough to
identify the file, therefore, the offerer can include only a 'hash' identify the file, therefore, the offerer can include only a 'hash'
selector. However, specially in cases where the hash of the file is selector. However, specially in cases where the hash of the file is
unknown, the file name, size, and type can provide a description of unknown, the file name, size, and type can provide a description of
the file to be fetched. If the file receiver wishes to start a new the file to be fetched. If the file receiver wishes to start a new
file transfer it MUST add a 'file-transfer-id' attribute containing a file transfer it MUST add a 'file-transfer-id' attribute containing a
new globally unique random value. The file receiver MAY also add a new globally unique random value. The file receiver MAY also add a
'file-range' attribute indicating the start and stop offsets of the 'file-range' attribute indicating the start and stop offsets of the
file. There is no need to for the file receiver to include further file. There is no need to for the file receiver to include further
file attributes in the SDP offer, thus it is RECOMMENDED that SDP file attributes in the SDP offer, thus it is RECOMMENDED that SDP
skipping to change at page 19, line 14 skipping to change at page 19, line 14
When the file receiver receives the SDP answer, if the port number of When the file receiver receives the SDP answer, if the port number of
the answer for a file request is non-zero, then the file receiver the answer for a file request is non-zero, then the file receiver
should receive the file using the protocol indicated in the "m=" should receive the file using the protocol indicated in the "m="
line. If the SDP answer contains a supported hashing algorithm in line. If the SDP answer contains a supported hashing algorithm in
the 'hash' selectors of the 'file-selector' attribute, then the file the 'hash' selectors of the 'file-selector' attribute, then the file
receiver SHOULD compute the hash of the file after its reception and receiver SHOULD compute the hash of the file after its reception and
check it against the hash received in the answer. In case the check it against the hash received in the answer. In case the
computed hash does not match the one contained in the SDP answer, the computed hash does not match the one contained in the SDP answer, the
file receiver SHOULD consider that the file transfer failed and file receiver SHOULD consider that the file transfer failed and
SHOULD inform the user. SHOULD inform the user. Similarly, the file receiver SHOULD also
verify that the other selectors declared in the SDP match the file
properties, otherwise, the file receiver SHOULD consider that the
file transfer failed and SHOULD inform the user.
8.2.3. SDP Offer for Several Files 8.2.3. SDP Offer for Several Files
An offerer that wishes to send or receive more than one file An offerer that wishes to send or receive more than one file
generates an "m=" line per file along with the file attributes generates an "m=" line per file along with the file attributes
described in this specification. This way, the answerer can reject described in this specification. This way, the answerer can reject
individual files by setting the port number of their associated "m=" individual files by setting the port number of their associated "m="
lines to zero, as per regular SDP [RFC4566] procedures. Similarly, lines to zero, as per regular SDP [RFC4566] procedures. Similarly,
the answerer can accept each individual file separately by setting the answerer can accept each individual file separately by setting
the port number of their associated "m=" lines to non-zero value. the port number of their associated "m=" lines to non-zero value.
skipping to change at page 20, line 12 skipping to change at page 20, line 15
the port number is different than zero, the file receiver inspects the port number is different than zero, the file receiver inspects
the 'file-transfer-id' attribute. If the value of the 'file- the 'file-transfer-id' attribute. If the value of the 'file-
transfer-id' attribute has been previously used then the existing transfer-id' attribute has been previously used then the existing
session remains without changes, perhaps the file transfer is still session remains without changes, perhaps the file transfer is still
in progress, or perhaps it has concluded, but there are no change in progress, or perhaps it has concluded, but there are no change
with respect the current status. In any case, independently of the with respect the current status. In any case, independently of the
port number, the SDP answerer creates a regular SDP answer and sends port number, the SDP answerer creates a regular SDP answer and sends
it to the offerer. it to the offerer.
If the port number is different than zero and the SDP offer contains If the port number is different than zero and the SDP offer contains
a new 'file-transfer-id' attribute, then this signals a request for a a new 'file-transfer-id' attribute, then it is signaling a request
new file transfer. The SDP answerer extracts the attributes and for a new file transfer. The SDP answerer extracts the attributes
parameters that describe the file and typically requests permission and parameters that describe the file and typically requests
from the user to accept or reject the reception of the file. If the permission from the user to accept or reject the reception of the
file transfer operation is accepted, the file receiver MUST create an file. If the file transfer operation is accepted, the file receiver
SDP answer according to the procedures specified in RFC 3264 MUST create an SDP answer according to the procedures specified in
[RFC3264]. If the offer contains 'name', 'type', 'size' selectors in RFC 3264 [RFC3264]. If the offer contains 'name', 'type', 'size'
the 'file-selector' attribute, the answerer MUST copy them into the selectors in the 'file-selector' attribute, the answerer MUST copy
answer. The file receiver copies the value of the 'file-transfer-id' them into the answer. The file receiver copies the value of the
attribute to the SDP answer. Then the file receiver MUST add a 'file-transfer-id' attribute to the SDP answer. Then the file
session or media 'recvonly' attribute according to the procedures receiver MUST add a session or media 'recvonly' attribute according
specified in RFC 3264 [RFC3264]. The file receiver MUST NOT include to the procedures specified in RFC 3264 [RFC3264]. The file receiver
'file-icon', 'file-disposition', or 'file-date' attributes in the SDP MUST NOT include 'file-icon', 'file-disposition', or 'file-date'
answer. attributes in the SDP answer.
The file receiver can use the hash to find out if a local file with The file receiver can use the hash to find out if a local file with
the same hash is already available, in which case, this could imply the same hash is already available, in which case, this could imply
the reception of a duplicated file. It is up to the answerer to the reception of a duplicated file. It is up to the answerer to
determine whether the file transfer is accepted or not in case of a determine whether the file transfer is accepted or not in case of a
duplicated file. duplicated file.
If the SDP offer contains a 'file-range' attribute and the file If the SDP offer contains a 'file-range' attribute and the file
receiver accepts to receive the range of octets declared in there, receiver accepts to receive the range of octets declared in there,
the file receiver MUST include a 'file-range' attribute in the SDP the file receiver MUST include a 'file-range' attribute in the SDP
answer with the same range of values. If the file receiver does not answer with the same range of values. If the file receiver does not
accept the reception of that range of octets, it SHOULD reject the accept the reception of that range of octets, it SHOULD reject the
transfer of the file. transfer of the file.
When the file transfer operation is complete, the file receiver
computes the hash of the file and SHOULD verify that it matches the
hash declared in the SDP. If they do not match, the file receiver
SHOULD consider that the file transfer failed and SHOULD inform the
user. Similarly, the file receiver SHOULD also verify that the other
selectors declared in the SDP match the file properties, otherwise,
the file receiver SHOULD consider that the file transfer failed and
SHOULD inform the user.
8.3.2. The Answerer is a File Sender 8.3.2. The Answerer is a File Sender
In a pull operation the answerer is the file sender. In this case, In a pull operation the answerer is the file sender. In this case,
the SDP answerer MUST first inspect the value of the the SDP answerer MUST first inspect the value of the
'file-transfer-id' attribute. If it has not been previously been 'file-transfer-id' attribute. If it has not been previously been
used throughout the session, then acceptance of the file MUST provoke used throughout the session, then acceptance of the file MUST provoke
the transfer of the file over the negotiated protocol. However, if the transfer of the file over the negotiated protocol. However, if
the value has been previously used by another file transfer operation the value has been previously used by another file transfer operation
within the session, then the file sender MUST NOT alert the user and within the session, then the file sender MUST NOT alert the user and
MUST NOT start a new transfer of the file. No matter whether an MUST NOT start a new transfer of the file. No matter whether an
skipping to change at page 41, line 42 skipping to change at page 41, line 42
The SDP attributes defined in this specification identify a file to The SDP attributes defined in this specification identify a file to
be transferred between two endpoints. An endpoint can offer to send be transferred between two endpoints. An endpoint can offer to send
the file to the other endpoint or request to receive the file from the file to the other endpoint or request to receive the file from
the other endpoint. In the former case, an attacker modifying those the other endpoint. In the former case, an attacker modifying those
SDP attributes could cheat the receiver making it think that the file SDP attributes could cheat the receiver making it think that the file
to be transferred was a different one. In the latter case, the to be transferred was a different one. In the latter case, the
attacker could make the sender send a different file than the one attacker could make the sender send a different file than the one
requested by the receiver. Consequently, it is RECOMMENDED that requested by the receiver. Consequently, it is RECOMMENDED that
integrity protection be applied to the SDP session descriptions integrity protection be applied to the SDP session descriptions
carrying the attributes specified in this specification. carrying the attributes specified in this specification.
Additionally, it is RECOMMENDED that senders verify the properties of
the file against the selectors that describe it.
The descriptions of the files being transferred between endpoints may The descriptions of the files being transferred between endpoints may
reveal information the endpoints may consider confidential. reveal information the endpoints may consider confidential.
Therefore, it is RECOMMENDED that SDP session descriptions carrying Therefore, it is RECOMMENDED that SDP session descriptions carrying
the attributes specified in this specification are encrypted. the attributes specified in this specification are encrypted.
TLS and S/MIME are the natural choices to provide offer/answer TLS and S/MIME are the natural choices to provide offer/answer
exchanges with integrity protection and confidentiality. exchanges with integrity protection and confidentiality.
When an SDP offer contains the description of a file to be sent or
received, the SDP answerer MUST first authenticate the SDP offerer
and then it MUST authorize the file transfer operation, typically
according to a local policy. Typically these functions are
integrated in the high-level protocol that carries SDP (e.g., SIP),
and in the file transfer protocol (e.g., MSRP). If SIP [RFC3261] and
MSRP [RFC4975] are used, the standard mechanisms for user
authentication and authorization are sufficient.
It is possible that a malicious or misbehaving implementation tries It is possible that a malicious or misbehaving implementation tries
to exhaust the resources of the remote endpoint, e.g., the internal to exhaust the resources of the remote endpoint, e.g., the internal
memory or the file system, by sending very large files. To protect memory or the file system, by sending very large files. To protect
from this attack, an SDP answer SHOULD first verify the identity of from this attack, an SDP answer SHOULD first verify the identity of
the SDP offerer, and perhaps only accept file transfers from trusted the SDP offerer, and perhaps only accept file transfers from trusted
sources. Mechanisms to verify the identity of the file sender depend sources. Mechanisms to verify the identity of the file sender depend
on the high-level protocol that carries the SDP, for example, SIP on the high-level protocol that carries the SDP, for example, SIP
[RFC3261] and MSRP [RFC4975]. [RFC3261] and MSRP [RFC4975].
It is also RECOMMENDED that implementations take measures to avoid It is also RECOMMENDED that implementations take measures to avoid
skipping to change at page 44, line 38 skipping to change at page 44, line 46
Specification: RFC XXXX Specification: RFC XXXX
12. Acknowledgements 12. Acknowledgements
The authors would like to thank Mats Stille, Nancy Greene, Adamu The authors would like to thank Mats Stille, Nancy Greene, Adamu
Haruna, and Arto Leppisaari for discussing initial concepts described Haruna, and Arto Leppisaari for discussing initial concepts described
in this memo. Thanks to Pekka Kuure for reviewing initial versions in this memo. Thanks to Pekka Kuure for reviewing initial versions
this document and providing helpful comments. Joerg Ott, Jiwey Wang, this document and providing helpful comments. Joerg Ott, Jiwey Wang,
Amitkumar Goel, Sudha Vs, Dan Wing, Juuso Lehtinen, Remi Denis- Amitkumar Goel, Sudha Vs, Dan Wing, Juuso Lehtinen, Remi Denis-
Courmont, Colin Perkins, Sudhakar An, Peter Saint-Andre, Jonathan Courmont, Colin Perkins, Sudhakar An, Peter Saint-Andre, Jonathan
Rosenberg, Eric Rescorla, Vikram Chhibber, and Ben Campbell discussed Rosenberg, Eric Rescorla, Vikram Chhibber, Ben Campbell, and Richard
and provided comments and improvements to this document. Barnes discussed and provided comments and improvements to this
document.
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
skipping to change at page 49, line 4 skipping to change at line 2146
Email: Salvatore.Loreto@ericsson.com Email: Salvatore.Loreto@ericsson.com
Paul H. Kyzivat Paul H. Kyzivat
Cisco Systems Cisco Systems
1414 Massachusetts Avenue 1414 Massachusetts Avenue
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Email: pkyzivat@cisco.com Email: pkyzivat@cisco.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject 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 are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
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
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 17 change blocks. 
33 lines changed or deleted 66 lines changed or added

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