draft-ietf-mmusic-file-transfer-mech-06.txt		draft-ietf-mmusic-file-transfer-mech-07.txt
	MMUSIC Working Group M. Garcia-Martin		MMUSIC Working Group M. Garcia-Martin
	Internet-Draft Nokia Siemens Networks		Internet-Draft Nokia Siemens Networks
	Intended status: Standards Track M. Isomaki		Intended status: Standards Track M. Isomaki
	Expires: June 23, 2008 Nokia		Expires: September 28, 2008 Nokia
	G. Camarillo		G. Camarillo
	S. Loreto		S. Loreto
	Ericsson		Ericsson
	P. Kyzivat		P. Kyzivat
	Cisco Systems		Cisco Systems
	December 21, 2007		March 27, 2008
	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-06.txt		draft-ietf-mmusic-file-transfer-mech-07.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 41		skipping to change at page 1, line 41
	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 23, 2008.		This Internet-Draft will expire on September 28, 2008.
	Copyright Notice
	Copyright (C) The IETF Trust (2007).
	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
	of one or more files is initiated after a successful negotiation.		of one or more files is initiated after a successful negotiation.
	The Message Session Relay Protocol (MSRP) is defined as the default		The Message Session Relay Protocol (MSRP) is defined as the default
	mechanism to actually carry the files between the endpoints. The		mechanism to actually carry the files between the endpoints. The
	conventions on how to use MSRP for file transfer are also provided in		conventions on how to use MSRP for file transfer are also provided in
	this document.		this document.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Alternatives Considered . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6		3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6		4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5
	4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7		5. File selector . . . . . . . . . . . . . . . . . . . . . . . . 7
	5. File selector . . . . . . . . . . . . . . . . . . . . . . . . 8		6. Extensions to SDP . . . . . . . . . . . . . . . . . . . . . . 8
	6. Extensions to SDP . . . . . . . . . . . . . . . . . . . . . . 9		7. File Disposition Types . . . . . . . . . . . . . . . . . . . . 13
	7. File Disposition Types . . . . . . . . . . . . . . . . . . . . 15		8. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 14
	8. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 15		8.1. Offerer's Behavior . . . . . . . . . . . . . . . . . . . . 14
	8.1. Offerer's Behavior . . . . . . . . . . . . . . . . . . . . 16		8.1.1. The Offerer is a File Sender . . . . . . . . . . . . . 15
	8.1.1. The Offerer is a File Sender . . . . . . . . . . . . . 16		8.1.2. The Offerer is a File Receiver . . . . . . . . . . . . 15
	8.1.2. The Offerer is a File Receiver . . . . . . . . . . . . 17		8.1.3. SDP Offer for Several Files . . . . . . . . . . . . . 16
	8.1.3. SDP Offer for Several Files . . . . . . . . . . . . . 18		8.2. Answerer's Behavior . . . . . . . . . . . . . . . . . . . 16
	8.2. Answerer's Behavior . . . . . . . . . . . . . . . . . . . 18		8.2.1. The Answerer is a File Receiver . . . . . . . . . . . 17
	8.2.1. The Answerer is a File Receiver . . . . . . . . . . . 18		8.2.2. The Answerer is a File Sender . . . . . . . . . . . . 18
	8.2.2. The Answerer is a File Sender . . . . . . . . . . . . 19		8.3. The 'file-transfer-id' attribute . . . . . . . . . . . . . 19
	8.3. The 'file-transfer-id' attribute . . . . . . . . . . . . . 21		8.4. Aborting an ongoing file transfer operation . . . . . . . 21
	8.4. Indicating File Transfer Offer/Answer Capability . . . . . 23		8.5. Indicating File Transfer Offer/Answer Capability . . . . . 22
	8.5. Re-usage of Existing m= Lines in SDP . . . . . . . . . . . 23		8.6. Re-usage of Existing "m=" Lines in SDP . . . . . . . . . . 22
	8.6. MSRP Usage . . . . . . . . . . . . . . . . . . . . . . . . 23		8.7. MSRP Usage . . . . . . . . . . . . . . . . . . . . . . . . 23
	8.7. Considerations about the 'file-icon' attribute . . . . . . 25		8.8. Considerations about the 'file-icon' attribute . . . . . . 24
	9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 25		9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
	9.1. Offerer sends a file to the Answerer . . . . . . . . . . . 25		9.1. Offerer sends a file to the Answerer . . . . . . . . . . . 25
	9.2. Offerer requests a file from the Answerer and second		9.2. Offerer requests a file from the Answerer and second
	file transfer . . . . . . . . . . . . . . . . . . . . . . 30		file transfer . . . . . . . . . . . . . . . . . . . . . . 30
	9.3. Example of a capability indication . . . . . . . . . . . . 37		9.3. Example of a capability indication . . . . . . . . . . . . 37
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 38		10. Security Considerations . . . . . . . . . . . . . . . . . . . 38
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
	11.1. Registration of new SDP attributes . . . . . . . . . . . . 39		11.1. Registration of new SDP attributes . . . . . . . . . . . . 39
	11.1.1. Registration of the file-selector attribute . . . . . 39		11.1.1. Registration of the file-selector attribute . . . . . 39
	11.1.2. Registration of the file-transfer-id attribute . . . . 40		11.1.2. Registration of the file-transfer-id attribute . . . . 40
	11.1.3. Registration of the file-disposition attribute . . . . 40		11.1.3. Registration of the file-disposition attribute . . . . 40
	11.1.4. Registration of the file-date attribute . . . . . . . 40		11.1.4. Registration of the file-date attribute . . . . . . . 40
	11.1.5. Registration of the file-icon attribute . . . . . . . 41		11.1.5. Registration of the file-icon attribute . . . . . . . 41
	11.1.6. Registration of the file-range attribute . . . . . . . 41		11.1.6. Registration of the file-range attribute . . . . . . . 41
	12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41		12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41		13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
	13.1. Normative References . . . . . . . . . . . . . . . . . . . 41		13.1. Normative References . . . . . . . . . . . . . . . . . . . 41
	13.2. Informational References . . . . . . . . . . . . . . . . . 42		13.2. Informational References . . . . . . . . . . . . . . . . . 42
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43		Appendix A. Alternatives Considered . . . . . . . . . . . . . . . 43
	Intellectual Property and Copyright Statements . . . . . . . . . . 45		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45
			Intellectual Property and Copyright Statements . . . . . . . . . . 46
	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 5, line 14		skipping to change at page 5, line 14
	The rest of this document is organized as follows. Section 3 defines		The rest of this document is organized as follows. Section 3 defines
	a few terms used in this document. Section 4 provides the overview		a few terms used in this document. Section 4 provides the overview
	of operation. Section 5 introduces the concept of the file selector.		of operation. Section 5 introduces the concept of the file selector.
	The detailed syntax and semantics of the new SDP attributes and		The detailed syntax and semantics of the new SDP attributes and
	conventions on how the existing ones are used is defined in		conventions on how the existing ones are used is defined in
	Section 6. Section 7 discusses the file disposition types.		Section 6. Section 7 discusses the file disposition types.
	Section 8 describes the protocol operation involving SDP and MSRP.		Section 8 describes the protocol operation involving SDP and MSRP.
	Finally, some examples are given in Section 9.		Finally, some examples are given in Section 9.
	1.1. Alternatives Considered
	The requirements are related to the description and negotiation of
	the session, not to the actual file transfer mechanism. Thus, it is
	natural that in order to meet them it is enough to define attribute
	extensions and usage conventions to SDP, while MSRP itself needs no
	extensions and can be used as it is. This is effectively the
	approach taken in this specification. Another goal has been to
	specify the SDP extensions in such a way that a regular MSRP endpoint
	which does not support them could still in some cases act as an
	endpoint in a file transfer session, albeit with a somewhat reduced
	functionality.
	In some ways the aim of this specification is similar to the aim of
	content indirection mechanism in the Session Initiation Protocol
	(SIP) [RFC4483]. Both mechanisms allow a user agent to decide
	whether or not to download a file based on information about the
	file. However, there are some differences. With content
	indirection, it is not possible for the other endpoint to explicitly
	accept or reject the file transfer. Also, it is not possible for an
	endpoint to request a file from another endpoint. Furthermore,
	content indirection is not tied to the context of a media session,
	which is sometimes a desirable property. Finally, content
	indirection typically requires some server infrastructure, which may
	not always be available. It is possible to use content indirection
	directly between the endpoints too, but in that case there is no
	definition for how it works for endpoints behind NATs. The level of
	requirements in implementations decides which solution meets the
	requirements.
	Based on the argumentation above, this document defines the SDP
	attribute extensions and usage conventions needed for meeting the
	requirements on file transfer services with the SDP offer/answer
	model, using MSRP as the transfer protocol within the session.
	In principle it is possible to use the SDP extensions defined here
	and replace MSRP with any other similar protocol that can carry
	MIME objects. This kind of specification can be written as a
	separate document if the need arises. Essentially, such protocol
	should be able to be negotiated on an SDP offer/answer exchange
	(RFC 3264 [RFC3264]), be able to carry MIME objects between two
	endpoints, and use a reliable transport protocol (e.g., TCP).
	This specification defines a set of SDP attributes that describe a
	file to be transferred between two endpoints. The information needed
	to describe a file could be potentially encoded in a few different
	ways. The MMUSIC working group considered a few alternative
	approaches before deciding to use the encoding described in
	Section 6. In particular, the working group looked at the MIME
	'external-body' type and the use of a single SDP attribute or
	parameter.
	A MIME 'external-body' could potentially be used to describe the file
	to be transferred. In fact, many of the SDP parameters this
	specification defines are also supported by 'external-body' body
	parts. The MMUSIC working group decided not to use 'external-body'
	body parts because a number of existing offer/answer implementations
	do not support multipart bodies.
	The information carried in the SDP attributes defined in Section 6
	could potentially be encoded in a single SDP attribute. The MMUSIC
	working group decided not to follow this approach because it is
	expected that implementations support only a subset of the parameters
	defined in Section 6. Those implementations will be able to use
	regular SDP rules in order to ignore non-supported SDP parameters.
	If all the information was encoded in a single SDP attribute, those
	rules, which relate to backwards compatibility, would need to be
	redefined specifically for that parameter.
	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 BCP 14, RFC 2119		document are to be interpreted as described in BCP 14, RFC 2119
	[RFC2119].		[RFC2119].
	3. Definitions		3. Definitions
	For the purpose of this document, the following definitions specified		For the purpose of this document, the following definitions specified
	skipping to change at page 8, line 22		skipping to change at page 6, line 45
	indicate the direction of the transfer, i.e., whether the SDP offerer		indicate the direction of the transfer, i.e., whether the SDP offerer
	is willing to send of receive the file. Assuming that the answerer		is willing to send of receive the file. Assuming that the answerer
	accepts the file transfer, the actual transfer of the files takes		accepts the file transfer, the actual transfer of the files takes
	place with ordinary MSRP. Note that the 'sendonly' and 'recvonly'		place with ordinary MSRP. Note that the 'sendonly' and 'recvonly'
	attributes refer to the direction of MSRP SEND requests and do not		attributes refer to the direction of MSRP SEND requests and do not
	preclude other protocol elements (such as 200 responses, REPORT		preclude other protocol elements (such as 200 responses, REPORT
	requests, etc.).		requests, etc.).
	In principle the file transfer can work even with an endpoint		In principle the file transfer can work even with an endpoint
	supporting only regular MSRP without understanding the extensions		supporting only regular MSRP without understanding the extensions
	defined herein, in a special case where that endpoint is the		defined herein, in a particular case where that endpoint is both
	recipient of the file. The regular MSRP endpoint answers the		the SDP answerer and the file receiver. The regular MSRP endpoint
	offer as it would answer any ordinary MSRP offer without paying		answers the offer as it would answer any ordinary MSRP offer
	attention to the extension attributes. In such a scenario the		without paying attention to the extension attributes. In such a
	user experience would however be reduced, as the recipient would		scenario the user experience would, however, be reduced, since the
	not know (by any protocol means) the reason for the session and		recipient would not know (by any protocol means) the reason for
	would not be able to accept/reject it based on the file		the session and would not be able to accept/reject it based on the
	attributes.		file attributes.
	5. File selector		5. File selector
	Specially in case the SDP offer is generated by the file receiver,		When the SDP offerer is the file the offer needs to unambiguously
	the offer needs a mechanism to unambiguously identify the requested		identify the requested file. For this purpose we introduce the
	file. For this purpose, the file transfer mechanism introduces the		notion of a file selector, which is a tuple composed of one or more
	notion of a file selector, which is defined as the combination of the		of the following individual selectors: the name, size, type, and hash
	4-tuple composed of the name, size, type, and hash of the file. We		of the file. The file selector can include any number of selectors,
	call each of these individual items a selector. The file selector		so all four of them do not always need to be present.
	can be composed of any number of selectors, so, it does not require
	that all four selectors are present at the same time.
	The purpose of the file selector is to provide enough information		The purpose of the file selector is to provide enough information
	that characterizes a file to the remote entity, so that both the		about the file to the remote entity, so that both the local and the
	local and the remote entity can refer to the same file. The file		remote entity can refer to the same file. The file selector is
	selector is encoded in a 'file-selector' media attribute in SDP. The		encoded in a 'file-selector' media attribute in SDP. The formal
	formal syntax of the 'file-selector' media attribute is described in		syntax of the 'file-selector' media attribute is described in
	Figure 1.		Figure 1.
	The file selection process is applied to all the available files at		The file selection process is applied to all the available files at
	the host. The process selects those file that match each of the		the host. The process selects those file that match each of the
	4-tuple selectors present in the 'file-selector' attribute. Thus, a		selectors present in the 'file-selector' attribute. The result can
	file selector can point to zero, one, or more files, depending on the		be zero, one, or more files, depending on the presence of the
	presence of the mentioned selectors in the SDP and depending on the		mentioned selectors in the SDP and depending on the available files
	available files in a host. The file transfer mechanism specified in		in a host. The file transfer mechanism specified in this document
	this document requires that a file selector eventually results at		requires that a file selector eventually results at most in a single
	most in a single file to be chosen. Typically, if the hash selector		file to be chosen. Typically, if the hash selector is known, it is
	is known, it is enough to produce a file selector that points to		enough to produce a file selector that points to exactly zero or one
	exactly zero or one file. However, a file selector that selects a		file. However, a file selector that selects a unique file is not
	unique file is not always known by the offerer. Sometimes only the		always known by the offerer. Sometimes only the name, size or type
	name, size or type of file are known, so the file selector may result		of file are known, so the file selector may result in selecting more
	in selecting more than one file, which is an undesired case. The		than one file, which is an undesired case. The opposite is also
	opposite is also true: if the file selector contains a hash selector		true: if the file selector contains a hash selector and a name
	and a name selector, there is a risk that the remote host has renamed		selector, there is a risk that the remote host has renamed the file,
	the file, in which case, although a file whose computed hash equals		in which case, although a file whose computed hash equals the hash
	the hash selector exists, the file name does not match that of the		selector exists, the file name does not match that of the name
	name selector, thus, the file selection process will result in the		selector, thus, the file selection process will result in the
	selection of zero files.		selection of zero files.
	This specification uses the Secure Hash Algorithm 1, SHA-1 [RFC3174].		This specification uses the Secure Hash Algorithm 1, SHA-1 [RFC3174].
	If future needs require adding support for different hashing		If future needs require adding support for different hashing
	algorithms, they will be specified as extensions to this document.		algorithms, they will be specified as extensions to this document.
	Implementations according to this specification MUST implement the		Implementations according to this specification MUST implement the
	'file-selector' attribute and MAY implement any of the other		'file-selector' attribute and MAY implement any of the other
	attributes specified in this specification. SDP offers and answers		attributes specified in this specification. SDP offers and answers
	for file transfer MUST contain a 'file-selector' media attribute that		for file transfer MUST contain a 'file-selector' media attribute that
	selects the file to be transferred and MAY contain any of the other		selects the file to be transferred and MAY contain any of the other
	attributes specified in this specification.		attributes specified in this specification.
	The 'file-selector' media attribute is also useful when learning the		The 'file-selector' media attribute is also useful when learning the
	support of the file transfer offer/answer capability that this		support of the file transfer offer/answer capability that this
	document specifies. This is further explained in Section 8.4.		document specifies. This is further explained in Section 8.5.
	6. Extensions to SDP		6. Extensions to SDP
	We define a number of new SDP [RFC4566] attributes that provide the		We define a number of new SDP [RFC4566] attributes that provide the
	required information to describe the transfer of a file with MSRP.		required information to describe the transfer of a file with MSRP.
	These are all media level only attributes in SDP. The following is		These are all media level only attributes in SDP. The following is
	the formal ABNF syntax [RFC4234] of these new attributes. It is		the formal ABNF syntax [RFC5234] of these new attributes. It is
	built above the SDP [RFC4566] grammar, RFC 2045 [RFC2045], RFC 2183		built above the SDP [RFC4566] grammar, RFC 2045 [RFC2045], RFC 2183
	[RFC2183], RFC 2392 [RFC2392], and RFC 2822 [RFC2822].		[RFC2183], RFC 2392 [RFC2392], and RFC 2822 [RFC2822].
	attribute = file-selector-attr / file-disp-attr /		attribute = file-selector-attr / file-disp-attr /
	file-tr-id-attr / file-date-attr /		file-tr-id-attr / file-date-attr /
	file-icon-attr / file-range-attr		file-icon-attr / file-range-attr
	;attribute is defined in RFC 4566		;attribute is defined in RFC 4566
	file-selector-attr = "file-selector" [":" selector *(SP selector)]		file-selector-attr = "file-selector" [":" selector *(SP selector)]
	selector = filename-selector / filesize-selector /		selector = filename-selector / filesize-selector /
	filetype-selector / hash-selector		filetype-selector / hash-selector
	filename-selector = "name:" DQUOTE filename-string DQUOTE		filename-selector = "name:" DQUOTE filename-string DQUOTE
	; DQUOTE defined in RFC 4234		; DQUOTE defined in RFC 5234
	filename-string = 1*(filename-char/percent-encoded)		filename-string = 1*(filename-char/percent-encoded)
	filename-char = %x01-09/%x0B-0C/%x0E-21/%x23-24/%26-FF)		filename-char = %x01-09/%x0B-0C/%x0E-21/%x23-24/%26-FF)
	;any byte except NUL, CR, LF,		;any byte except NUL, CR, LF,
	;double quotes, or percent		;double quotes, or percent
	percent-encoded = "%" HEXDIG HEXDIG		percent-encoded = "%" HEXDIG HEXDIG
	; HEXDIG defined in RFC 4234		; HEXDIG defined in RFC 5234
	filesize-selector = "size:" filesize-value		filesize-selector = "size:" filesize-value
	filesize-value = integer ;integer defined in RFC 4566		filesize-value = integer ;integer defined in RFC 4566
	filetype-selector = "type:" type "/" subtype *(";"parameter)		filetype-selector = "type:" type "/" subtype *(";"parameter)
	; parameter defined in RFC 2045		; parameter defined in RFC 2045
	type = token ; token defined in RFC 4566		type = token ; token defined in RFC 4566
	subtype = token		subtype = token
	hash-selector = "hash:" hash-algorithm ":" hash-value		hash-selector = "hash:" hash-algorithm ":" hash-value
	hash-algorithm = token ;see IANA Hash Function		hash-algorithm = token ;see IANA Hash Function
	;Textual Names registry		;Textual Names registry
	;only "sha-1" currently supported		;only "sha-1" currently supported
	hash-value = 2HEXDIG *(":" 2HEXDIG)		hash-value = 2HEXDIG *(":" 2HEXDIG)
	; Each byte in upper-case hex, separated		; Each byte in upper-case hex, separated
	; by colons.		; by colons.
	; HEXDIG defined in RFC 4234		; HEXDIG defined in RFC 5234
	file-tr-id-attr = "file-transfer-id:" file-tr-id-value		file-tr-id-attr = "file-transfer-id:" file-tr-id-value
	file-tr-id-value = token		file-tr-id-value = token
	file-disp-attr = "file-disposition:" file-disp-value		file-disp-attr = "file-disposition:" file-disp-value
	file-disp-value = token		file-disp-value = token
	file-date-attr = "file-date:" date-param *(SP date-param)		file-date-attr = "file-date:" date-param *(SP date-param)
	date-param = c-date-param / m-date-param / r-date-param		date-param = c-date-param / m-date-param / r-date-param
	c-date-param = "creation:" DQUOTE date-time DQUOTE		c-date-param = "creation:" DQUOTE date-time DQUOTE
	m-date-param = "modification:" DQUOTE date-time DQUOTE		m-date-param = "modification:" DQUOTE date-time DQUOTE
	r-date-param = "read:" DQUOTE date-time DQUOTE		r-date-param = "read:" DQUOTE date-time DQUOTE
	; date-time is defined in RFC 2822		; date-time is defined in RFC 2822
	; numeric timezones (+HHMM or -HHMM)		; numeric timezones (+HHMM or -HHMM)
	; must be used		; must be used
	; DQUOTE defined in RFC 4234 files.		; DQUOTE defined in RFC 5234 files.
	file-icon-attr = "file-icon:" file-icon-value		file-icon-attr = "file-icon:" file-icon-value
	file-icon-value = cid-url ;cid-url defined in RFC 2392		file-icon-value = cid-url ;cid-url defined in RFC 2392
	file-range-attr = "file-range:" start-offset "-" stop-offset		file-range-attr = "file-range:" start-offset "-" stop-offset
	start-offset = integer ;integer defined in RFC 4566		start-offset = integer ;integer defined in RFC 4566
	stop-offset = integer / "*"		stop-offset = integer / "*"
	Figure 1: Syntax of the SDP extension		Figure 1: Syntax of the SDP extension
	When used for capability query (see Section 8.4), the 'file-selector'		When used for capability query (see Section 8.5), the 'file-selector'
	attribute MUST NOT contain any selector, because its presence merely		attribute MUST NOT contain any selector, because its presence merely
	indicates compliance to this specification.		indicates compliance to this specification.
	When used in an SDP offer or answer, the 'file-selector' attribute		When used in an SDP offer or answer, the 'file-selector' attribute
	MUST contain at least one selector. Selectors characterize the file		MUST contain at least one selector. Selectors characterize the file
	to be transferred. There are four selectors in this attribute:		to be transferred. There are four selectors in this attribute:
	'name', 'size', 'type', and 'hash'.		'name', 'size', 'type', and 'hash'.
	The 'name' selector in the 'file-selector' attribute contains the		The 'name' selector in the 'file-selector' attribute contains the
	filename of the content enclosed in double quotes. The filename is		filename of the content enclosed in double quotes. The filename is
	skipping to change at page 12, line 45		skipping to change at page 11, line 20
	can be drafted to support several hashing algorithms. Therefore,		can be drafted to support several hashing algorithms. Therefore,
	implementations according to this specification MUST be prepared to		implementations according to this specification MUST be prepared to
	receive SDP containing more than a single 'hash' selector in the		receive SDP containing more than a single 'hash' selector in the
	'file-selector' attribute.		'file-selector' attribute.
	The value of the 'hash' selector is the byte string resulting of		The value of the 'hash' selector is the byte string resulting of
	applying the hash algorithm to the content of the whole file, even		applying the hash algorithm to the content of the whole file, even
	when the file transfer is limited to a number of octets (i.e., the		when the file transfer is limited to a number of octets (i.e., the
	'file-range' attribute is indicated).		'file-range' attribute is indicated).
	The 'file-transfer-id' attribute provides a unique identification to		The 'file-transfer-id' attribute provides a randomly chosen globally
	the actual file transfer. It is used to distinguish a new file		unique identification to the actual file transfer. It is used to
	transfer request from a repetition of the SDP (or the fraction of the		distinguish a new file transfer request from a repetition of the SDP
	SDP that deals with the file description). This attribute is		(or the fraction of the SDP that deals with the file description).
	described in much greater detail in Section 8.3.		This attribute is described in much greater detail in Section 8.3.
	The 'file-disposition' attribute provides a suggestion to the other		The 'file-disposition' attribute provides a suggestion to the other
	endpoint about the intended disposition of the file. Section 7		endpoint about the intended disposition of the file. Section 7
	provides further discussion of the possible values. The value of		provides further discussion of the possible values. The value of
	this attribute SHOULD be the same as the disposition type parameter		this attribute SHOULD be the same as the disposition type parameter
	of the Content-Disposition header field [RFC2183] that would be		of the Content-Disposition header field [RFC2183] that would be
	signaled by the actual file transfer protocol.		signaled by the actual file transfer protocol.
	The 'file-date' attribute indicates the dates at which the file was		The 'file-date' attribute indicates the dates at which the file was
	created, modified, or last read. This attribute MAY contain a		created, modified, or last read. This attribute MAY contain a
	skipping to change at page 13, line 47		skipping to change at page 12, line 21
	'read-date' parameter of the Content-Disposition header field		'read-date' parameter of the Content-Disposition header field
	[RFC2183] that would be signaled by the actual file transfer		[RFC2183] that would be signaled by the actual file transfer
	protocol.		protocol.
	The 'file-icon' attribute can be useful with certain file types such		The 'file-icon' attribute can be useful with certain file types such
	as images. It allows the file sender to include a pointer to a body		as images. It allows the file sender to include a pointer to a body
	that includes a small preview icon representing the contents of the		that includes a small preview icon representing the contents of the
	file to be transferred, which the file receiver can use to determine		file to be transferred, which the file receiver can use to determine
	whether it wants to receive such file. The 'file-icon' attribute		whether it wants to receive such file. The 'file-icon' attribute
	contains a Content-ID URL, which is specified in RFC 2392 [RFC2392].		contains a Content-ID URL, which is specified in RFC 2392 [RFC2392].
	Section 8.7 contains further considerations about the 'file-icon'		Section 8.8 contains further considerations about the 'file-icon'
	attribute.		attribute.
	The 'file-range' attribute provides a mechanism to signal a chunk of		The 'file-range' attribute provides a mechanism to signal a chunk of
	a file rather than the complete file. This enable use cases where a		a file rather than the complete file. This enable use cases where a
	file transfer can be interrupted, resumed, even perhaps changing one		file transfer can be interrupted, resumed, even perhaps changing one
	of the endpoints. The 'file-range' attribute contains the "start		of the endpoints. The 'file-range' attribute contains the "start
	offset" and "stop offset" of the file, separated by a dash "-". The		offset" and "stop offset" of the file, separated by a dash "-". The
	"start offset" value refers to the position of the file where the		"start offset" value refers to the position of the file where the
	file transfer should start. The first byte of a file is denoted by		file transfer should start. The first byte of a file is denoted by
	the ordinal number "1". The "stop offset" value refers position of		the ordinal number "1". The "stop offset" value refers position of
	skipping to change at page 15, line 48		skipping to change at page 14, line 23
	"Body parts can be designated 'attachment' to indicate that		"Body parts can be designated 'attachment' to indicate that
	they are separate from the main body of the mail message, and		they are separate from the main body of the mail message, and
	that their display should not be automatic, but contingent upon		that their display should not be automatic, but contingent upon
	some further action of the user."		some further action of the user."
	In the case of this specification, the 'attachment' disposition		In the case of this specification, the 'attachment' disposition
	type is used to indicate that the display of the file should not		type is used to indicate that the display of the file should not
	be automatic, but contingent upon some further action of the user.		be automatic, but contingent upon some further action of the user.
	8. Protocol Operation		8. Protocol Operation
	This Section discusses how to use the parameters defined in Section 6		This section discusses how to use the parameters defined in Section 6
	in the context of an offer/answer [RFC3264] exchange. Additionally,		in the context of an offer/answer [RFC3264] exchange. Additionally,
	this section also discusses the behavior of the endpoints using MSRP.		this section also discusses the behavior of the endpoints using MSRP.
	Usually the file transfer session is initiated when the offerer sends		A file transfer session is initiated by the offerer sending an SDP
	an SDP offer to the answerer. The answerer either accepts or rejects		offer to the answerer. The answerer either accepts or rejects the
	the file transfer session and sends an SDP answer to the offerer.		file transfer session and sends an SDP answer to the offerer.
	We can differentiate two use cases, depending on whether the offerer		We can differentiate two use cases, depending on whether the offerer
	is the file sender or file receiver:		is the file sender or file receiver:
	1. The offerer is the file sender, i.e., the offerer wants to		1. The offerer is the file sender, i.e., the offerer wants to
	transmit a file to the answerer. Consequently the answerer is		transmit a file to the answerer. Consequently the answerer is
	the file receiver. In this case the SDP offer contains a		the file receiver. In this case the SDP offer contains a
	'sendonly' attribute, and accordingly the SDP answer contains a		'sendonly' attribute, and accordingly the SDP answer contains a
	'recvonly' attribute.		'recvonly' attribute.
	2. The offerer is the file receiver, i.e., the offerer wants to		2. The offerer is the file receiver, i.e., the offerer wants to
	fetch a file from the answerer. Consequently the answerer is the		fetch a file from the answerer. Consequently the answerer is the
	file sender. In this case the SDP offer contains a session or		file sender. In this case the SDP offer contains a session or
	media 'recvonly' attribute, and accordingly the SDP answer		media 'recvonly' attribute, and accordingly the SDP answer
	contains a session or media 'sendonly' attribute.		contains a session or media 'sendonly' attribute.
	8.1. Offerer's Behavior		8.1. Offerer's Behavior
	An offerer that wishes to send or receive one or more files to or		An offerer who wishes to send or receive one or more files to or from
	from an answerer MUST build an SDP [RFC4566] description of a session		an answerer MUST build an SDP [RFC4566] description of a session
	containing one or more "m=" lines, each one describing an MSRP		containing one "m=" line per file. When MSRP is used as the transfer
	session (and thus, one file transfer operation), according to the		mechanism, each "m=" line also describes a single MSRP session,
	MSRP [RFC4975] procedures. All the media line attributes specified		according to the MSRP [RFC4975] procedures. Any "m=" lines that may
	and required by MSRP [RFC4975] (e.g., "a=path", "a=accept-types",		have already been present in a previous SDP exchange are normally
	etc.) MUST be included as well. For each file to be transferred		kept unmodified; the new "m=" lines are added afterwards (Section 8.6
	there MUST be a separate "m=" line.		describes cases when "m=" lines are re-used). All the media line
			attributes specified and required by MSRP [RFC4975] (e.g., "a=path",
			"a=accept-types", etc.) MUST be included as well.
	8.1.1. The Offerer is a File Sender		8.1.1. The Offerer is a File Sender
	In a push operation, the file sender creates and SDP offer describing		In a push operation, the file sender creates and SDP offer describing
	the file to be sent. The file sender MUST add a 'file-selector'		the file to be sent. The file sender MUST add a 'file-selector'
	attribute media line containing at least one of the 'type', 'size',		attribute media line containing at least one of the 'type', 'size',
	'hash' selectors in indicating the type, size, or hash of the file,		'hash' selectors in indicating the type, size, or hash of the file,
	respectively. The file sender MUST add a 'file-transfer-id'		respectively. If the file sender wishes to start a new file
	attribute containing a new randomly chosen identifier value, which		transfer, the file sender MUST add a 'file-transfer-id' attribute
	does not clash with other previously used values in the same		containing a new globally unique random identifier value.
	attribute. Additionally, the file sender MUST add a session or media		Additionally, the file sender MUST add a session or media 'sendonly'
	'sendonly' attribute to the SDP offer. Then the file sender sends		attribute to the SDP offer. Then the file sender sends the SDP offer
	the SDP offer to the file receiver.		to the file receiver.
	Not all the selectors in the 'file-selector' attribute might be		Not all the selectors in the 'file-selector' attribute might be
	known when the file sender creates the SDP offer, for example,		known when the file sender creates the SDP offer, for example,
	because the host is still processing the file.		because the host is still processing the file.
	The 'hash' selector in the 'file-selector' attribute contains		The 'hash' selector in the 'file-selector' attribute contains
	valuable information to the file receiver to identify whether the		valuable information to the file receiver to identify whether the
	file is already available and need not be transmitted.		file is already available and need not be transmitted.
	The file sender MAY also add a 'name' selector in the 'file-selector'		The file sender MAY also add a 'name' selector in the 'file-selector'
	skipping to change at page 17, line 33		skipping to change at page 16, line 4
	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.1.2. The Offerer is a File Receiver		8.1.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 SHOULD add, at least, one of the selector
	defined for that attribute (i.e., 'name', 'type', 'size', or 'hash').		defined for that 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. The file receiver MUST also add a 'file-		the file to be fetched. If the file receiver wishes to start a new
	transfer-id' attribute with a newly created random value (new within		file transfer it MUST add a 'file-transfer-id' attribute containing a
	the current session). The file receiver MAY also add a 'file-range'		new globally unique random value. The file receiver MAY also add a
	attribute indicating the start and stop offsets of the file. There		'file-range' attribute indicating the start and stop offsets of the
	is no need to for the file receiver to include further file		file. There is no need to for the file receiver to include further
	attributes in the SDP offer, thus it is RECOMMENDED that SDP offerers		file attributes in the SDP offer, thus it is RECOMMENDED that SDP
	do not include any other file attribute defined by this specification		offerers do not include any other file attribute defined by this
	(other than the mandatory ones). Additionally, the file receiver		specification (other than the mandatory ones). Additionally, the
	MUST create an SDP offer that contains a session or media 'recvonly'		file receiver MUST create an SDP offer that contains a session or
	attribute.		media 'recvonly' attribute.
	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= line.		should receive the file using the protocol indicated in the "m="
	If the SDP answer contains a supported hashing algorithm in the		line. If the SDP answer contains a supported hashing algorithm in
	'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.
	8.1.3. SDP Offer for Several Files		8.1.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
	skipping to change at page 18, line 40		skipping to change at page 17, line 12
	zero, as per regular SDP [RFC4566] procedures. The rejected answer		zero, as per regular SDP [RFC4566] procedures. The rejected answer
	MUST contained a 'file-selector' and 'file-transfer-id' attributes		MUST contained a 'file-selector' and 'file-transfer-id' attributes
	whose values mirror the corresponding values of the SDP offer.		whose values mirror the corresponding values of the SDP offer.
	If the answerer decides to accept the file, it proceeds as per		If the answerer decides to accept the file, it proceeds as per
	regular MSRP [RFC4975] and SDP [RFC4566] procedures.		regular MSRP [RFC4975] and SDP [RFC4566] procedures.
	8.2.1. The Answerer is a File Receiver		8.2.1. The Answerer is a File Receiver
	In a push operation the SDP answerer is the file receiver. When the		In a push operation the SDP answerer is the file receiver. When the
	file receiver gets the SDP offer, it first examines the 'file-		file receiver gets the SDP offer, it first examines the port number.
	transfer-id' attribute. If the value of the 'file-transfer-id'		If the port number is set to zero, the file transfer operation is
	attribute has been previously used then the existing session remains		closed, and no more data is expected over the media stream. Then, if
	without changes, perhaps the file transfer is still in progress, or		the port number is different than zero, the file receiver inspects
	perhaps it has concluded, but there are no change with respect the		the 'file-transfer-id' attribute. If the value of the 'file-
	current status. The SDP answerer creates a regular SDP answer and		transfer-id' attribute has been previously used then the existing
	sends it to the offerer.		session remains without changes, perhaps the file transfer is still
			in progress, or perhaps it has concluded, but there are no change
			with respect the current status. In any case, independently of the
			port number, the SDP answerer creates a regular SDP answer and sends
			it to the offerer.
	If the SDP offer contains a new 'file-transfer-id' attribute, then		If the port number is different than zero and the SDP offer contains
	this signals a request for a new file transfer. The SDP answerer		a new 'file-transfer-id' attribute, then this signals a request for a
	extracts the attributes and parameters that describe the file and		new file transfer. The SDP answerer extracts the attributes and
	typically requests permission from the user to accept or reject the		parameters that describe the file and typically requests permission
	reception of the file. If the file transfer operation is accepted,		from the user to accept or reject the reception of the file. If the
	the file receiver MUST create an SDP answer according to the		file transfer operation is accepted, the file receiver MUST create an
	procedures specified in RFC 3264 [RFC3264]. If the offer contains		SDP answer according to the procedures specified in RFC 3264
	'name', 'type', 'size' selectors in the 'file-selector' attribute,		[RFC3264]. If the offer contains 'name', 'type', 'size' selectors in
	the answerer MUST copy them into the answer. The file receiver		the 'file-selector' attribute, the answerer MUST copy them into the
	copies the value of the 'file-transfer-id' attribute to the SDP		answer. The file receiver copies the value of the 'file-transfer-id'
	answer. Then the file receiver MUST add a session or media		attribute to the SDP answer. Then the file receiver MUST add a
	'recvonly' attribute according to the procedures specified in RFC		session or media 'recvonly' attribute according to the procedures
	3264 [RFC3264]. The file receiver MUST NOT include 'file-icon',		specified in RFC 3264 [RFC3264]. The file receiver MUST NOT include
	'file-disposition', or 'file-date' attributes in the SDP answer.		'file-icon', 'file-disposition', or 'file-date' 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 bytes declared in there, the		receiver accepts to receive the range of bytes declared in there, the
	file receiver MUST include a 'file-range' attribute in the SDP answer		file receiver MUST include a 'file-range' attribute in the SDP answer
	skipping to change at page 21, line 38		skipping to change at page 20, line 14
	the current ongoing file transfer and add the new media descriptions.		the current ongoing file transfer and add the new media descriptions.
	The problem is that, the other endpoint is not able to determine if a		The problem is that, the other endpoint is not able to determine if a
	new file transfer is requested or not.		new file transfer is requested or not.
	In other cases, a file transfer was successfully completed. Then, if		In other cases, a file transfer was successfully completed. Then, if
	an endpoint re-sends the SDP offer with the media stream for the file		an endpoint re-sends the SDP offer with the media stream for the file
	transfer, then the other endpoint wouldn't be able to determine		transfer, then the other endpoint wouldn't be able to determine
	whether a new file transfer should start or not.		whether a new file transfer should start or not.
	To address these scenarios this specification defines the 'file-		To address these scenarios this specification defines the 'file-
	transfer-id' attribute which contains a unique file transfer		transfer-id' attribute which contains a globally unique random
	identifier. The file transfer identifier helps both endpoints to		identifier allocated to the file transfer operation. The file
	determine whether the SDP offer is requesting a new file transfer or		transfer identifier helps both endpoints to determine whether the SDP
	it is a repetition of the SDP. A new file transfer is one that, in		offer is requesting a new file transfer or it is a repetition of the
	case of acceptance, will provoke the actual transfer of a file. This		SDP. A new file transfer is one that, in case of acceptance, will
	is typically the case of new offer/answer exchanges, or in cases		provoke the actual transfer of a file. This is typically the case of
	where an endpoint wants to abort the existing file transfer and re-		new offer/answer exchanges, or in cases where an endpoint wants to
	start the file transfer once more. On the other hand, the repetition		abort the existing file transfer and re-start the file transfer once
	of the SDP does not lead to any actual file to be transferred,		more. On the other hand, the repetition of the SDP does not lead to
	potentially because the file transfer is still going on or because it		any actual file to be transferred, potentially because the file
	has already finished. This is the case of a repeated offer/answer		transfer is still going on or because it has already finished. This
	exchanges, which can be due to a number of reasons (session timer,		is the case of a repeated offer/answer exchanges, which can be due to
	addition/removal of other media types in the SDP, update in SDP due		a number of reasons (session timer, addition/removal of other media
	to changes in other session parameters, etc.).		types in the SDP, update in SDP due to changes in other session
			parameters, etc.).
	Implementations according to this specification MUST include a 'file-		Implementations according to this specification MUST include a 'file-
	transfer-id' attribute in SDP offers and answers. The SDP offerer		transfer-id' attribute in SDP offers and answers. The SDP offerer
	MUST select a file transfer identifier according to the syntax and		MUST select a file transfer identifier according to the syntax and
	add it to the 'file-transfer-id' attribute. The SDP answerer MUST		add it to the 'file-transfer-id' attribute. The SDP answerer MUST
	copy the value of the 'file-transfer-id' attribute in the SDP answer.		copy the value of the 'file-transfer-id' attribute in the SDP answer.
	The file transfer identifier MUST be unique within the current		The file transfer identifier MUST be unique within the current
	session (never used before in this session), and it is RECOMMENDED to		session (never used before in this session), and it is RECOMMENDED to
	be unique across different sessions. It is RECOMMENDED to select a		be unique across different sessions. It is RECOMMENDED to select a
	skipping to change at page 22, line 26		skipping to change at page 20, line 51
	transfer identifiers in each session and copy the value of the		transfer identifiers in each session and copy the value of the
	received file transfer identifier in the SDP answer.		received file transfer identifier in the SDP answer.
	If a file transfer is suspended and resumed at a later time, the		If a file transfer is suspended and resumed at a later time, the
	resumption is considered a new file transfer (even when the file to		resumption is considered a new file transfer (even when the file to
	be transferred is the same), therefore, the SDP offerer MUST choose a		be transferred is the same), therefore, the SDP offerer MUST choose a
	new file transfer identifier.		new file transfer identifier.
	If an endpoint sets the port number to zero in the media description		If an endpoint sets the port number to zero in the media description
	of a file transfer, for example because it wants to reject the file		of a file transfer, for example because it wants to reject the file
	transfer operation, then the SDP answer should mirror the value of		transfer operation, then the SDP answer MUST mirror the value of the
	the 'file-transfer-id' attribute included in the SDP offer. This		'file-transfer-id' attribute included in the SDP offer. This
	effectively means that setting a media stream to zero has higher		effectively means that setting a media stream to zero has higher
	precedence than any value that the 'file-transfer-id' attribute can		precedence than any value that the 'file-transfer-id' attribute can
	take.		take.
	As a side effect, the 'file-transfer-id' attribute can be used for		As a side effect, the 'file-transfer-id' attribute can be used for
	aborting and restarting again an ongoing file transfer. Assume that		aborting and restarting again an ongoing file transfer. Assume that
	two endpoints agree on a file transfer and the actual transfer of the		two endpoints agree on a file transfer and the actual transfer of the
	file is taking place. At some point in time in the middle of the		file is taking place. At some point in time in the middle of the
	file transfer, one endpoint sends a new SDP offer, equal to the		file transfer, one endpoint sends a new SDP offer, equal to the
	initial one, except for the value of the 'file-transfer-id'		initial one except for the value of the 'file-transfer-id' attribute,
	attribute, which is a new value within the session. This indicates		which is a new globally unique random value. This indicates that the
	that the offerer wants to abort the existing transfer and start a new		offerer wants to abort the existing transfer and start a new one,
	one, according to the SDP parameters. The SDP answerer SHOULD abort		according to the SDP parameters. The SDP answerer SHOULD abort the
	the ongoing file transfer, according to the procedures of the file		ongoing file transfer, according to the procedures of the file
	transfer protocol (e.g., MSRP), and start sending file once more from		transfer protocol (e.g., MSRP), and start sending file once more from
	the initial requested octet.		the initial requested octet. Section 8.4 further discusses file
			transfer abortion.
	In another scenario, an endpoint that has successfully transferred a		In another scenario, an endpoint that has successfully transferred a
	file wants to send an SDP due to other reasons than the transfer of a		file wants to send an SDP due to other reasons than the transfer of a
	file. The SDP offerer creates an SDP file description that maintains		file. The SDP offerer creates an SDP file description that maintains
	the media description line corresponding to the file transfer. The		the media description line corresponding to the file transfer. The
	SDP offerer MUST then set the port number to zero and MUST keep the		SDP offerer MUST then set the port number to zero and MUST keep the
	same value of the 'file-transfer-id' attribute that the initial file		same value of the 'file-transfer-id' attribute that the initial file
	transfer got.		transfer got.
	8.4. Indicating File Transfer Offer/Answer Capability		8.4. Aborting an ongoing file transfer operation
			A file sender that wishes to abort an ongoing file transfer operation
			without initiating an alternative file transfer, if an ongoing MSRP
			SEND request is being transmitted, aborts the MSRP message by
			including the '#' character in the continuation field of the end-line
			of a SEND request, according to the MSRP procedures (see Section 7.1
			of RFC 4975 [RFC4975]). Since a file is transmitted as one MSRP
			message, aborting the MSRP message effectively aborts the file
			transfer. Then the file sender SHOULD close the MSRP session. This
			is done by sending a new SDP offer that sets the port number to zero
			in the related "m=" line that describes the file transfer (see
			Section 8.2 of RFC 3264 [RFC3264]). This SDP offer MUST conform with
			the requirements of Section 8.1.1. The 'file-transfer-id' attribute
			MUST be the same that identifies the ongoing transfer. Then the file
			sender sends the SDP offer to the file recipient.
			A file receiver that receives the above SDP offer creates an SDP
			answer according to the procedures of the SDP offer/answer (RFC 3264
			[RFC3264]). This SDP answer MUST conform with the requirements of
			Section 8.2.1. Then the file recipient sends this SDP answer to the
			file sender.
			A file receiver that wishes to abort an ongoing transfer first must
			determine if the MSRP sender wishes to receive failure reports. If
			the current MSRP SEND request sets the Failure-Report header to a
			value different than "no", then the file receiver generates an MSRP
			413 response to the current MSRP SEND request (see Section 10.5 of
			RFC 4975 [RFC4975]). Then the file receiver SHOULD close the MSRP
			session. This is done by sending a new SDP offer that sets the port
			number to zero in the related "m=" line that describes the file
			transfer (see Section 8.2 of RFC 3264 [RFC3264]). This SDP offer
			MUST conform with the requirements expressed in Section 8.1.2. The
			'file-transfer-id' attribute MUST be the same that identifies the
			ongoing transfer. Then the file sender sends the SDP offer to the
			file receiver.
			A file sender that receives an SDP offer setting the port number to
			zero in the related "m=" line for file transfer, first, if an ongoing
			MSRP SEND request is being transmitted, it aborts the MSRP message by
			including the '#' character in the continuation field of the end-line
			of a SEND request, according to the MSRP procedures (see Section 7.1
			of RFC 4975 [RFC4975]). Since a file is transmitted as one MSRP
			message, aborting the MSRP message effectively aborts the file
			transfer. Then the file sender creates an SDP answer according to
			the procedures of the SDP offer/answer (RFC 3264 [RFC3264]). This
			SDP answer MUST conform with the requirements of Section 8.2.2. Then
			the file sender sends this SDP answer to the file receiver.
			8.5. Indicating File Transfer Offer/Answer Capability
	The SDP Offer/Answer Model [RFC3264] provides provisions for		The SDP Offer/Answer Model [RFC3264] provides provisions for
	indicating a capability to another endpoint (see Section 9 of RFC		indicating a capability to another endpoint (see Section 9 of RFC
	3264 [RFC3264]). The mechanism assumes a high-level protocol, such		3264 [RFC3264]). The mechanism assumes a high-level protocol, such
	as SIP [RFC3261], that provides a capability query (such as a SIP		as SIP [RFC3261], that provides a capability query (such as a SIP
	OPTIONS request). RFC 3264 [RFC3264] indicates how to build the SDP		OPTIONS request). RFC 3264 [RFC3264] indicates how to build the SDP
	that is included in the response to such request. As such, RFC 3264		that is included in the response to such request. As such, RFC 3264
	indicates that and endpoint builds an SDP body that contains an "m="		indicates that and endpoint builds an SDP body that contains an "m="
	line that contains the media type (message, for MSRP). An endpoint		line that contains the media type (message, for MSRP). An endpoint
	that implements the procedures specified in this document SHOULD also		that implements the procedures specified in this document SHOULD also
	add a 'file-selector' media attribute for the "m=message" line. The		add a 'file-selector' media attribute for the "m=message" line. The
	'file-selector' media attribute MUST be empty, i.e., it MUST NOT		'file-selector' media attribute MUST be empty, i.e., it MUST NOT
	contain any selector. The endpoint MUST NOT add any of the other		contain any selector. The endpoint MUST NOT add any of the other
	file attributes defined in this specification.		file attributes defined in this specification.
	8.5. Re-usage of Existing m= Lines in SDP		8.6. Re-usage of Existing "m=" Lines in SDP
	The SDP Offer/Answer Model [RFC3264] provides rules that allow SDP		The SDP Offer/Answer Model [RFC3264] provides rules that allow SDP
	offerers and answerers to modify an existing media line, i.e., re-use		offerers and answerers to modify an existing media line, i.e., re-use
	an existing media line with different attributes. The same is also		an existing media line with different attributes. The same is also
	possible when SDP signals a file transfer operation according to the		possible when SDP signals a file transfer operation according to the
	rules of this memo. Therefore, the procedures defined in RFC 3264		rules of this memo. Therefore, the procedures defined in RFC 3264
	[RFC3264], in particular those defined in Section 8.3, MUST apply for		[RFC3264], in particular those defined in Section 8.3, MUST apply for
	file transfer operations. An endpoint that wants to re-use an		file transfer operations. An endpoint that wants to re-use an
	existing m= line to start the file transfer of another file creates a		existing "m=" line to start the file transfer of another file creates
	different 'file-selector' attribute and a different value of the		a different 'file-selector' attribute and selects a new globally
	'file-transfer-id' attribute.		unique random value of the 'file-transfer-id' attribute.
	If the file offerer re-sends an SDP offer with a port different than		If the file offerer re-sends an SDP offer with a port different than
	zero, then the 'file-transfer-id' attribute determines whether a new		zero, then the 'file-transfer-id' attribute determines whether a new
	file transfer will start or whether the file transfer does not need		file transfer will start or whether the file transfer does not need
	to start. If the SDP answerer accepts the SDP, then file transfer		to start. If the SDP answerer accepts the SDP, then file transfer
	starts from the indicated byte (if a 'file-range' attribute is		starts from the indicated byte (if a 'file-range' attribute is
	present).		present).
	8.6. MSRP Usage		8.7. MSRP Usage
	The file transfer service specified in this document uses "m=" lines		The file transfer service specified in this document uses "m=" lines
	to describe the unidirectional transfer of a file. Consequently,		to describe the unidirectional transfer of a file. Consequently,
	each MSRP session established following the procedures in Section 8.1		each MSRP session established following the procedures in Section 8.1
	and Section 8.2 is only used to transfer a single file. So, senders		and Section 8.2 is only used to transfer a single file. So, senders
	MUST only use the dedicated MSRP session to send the file described		MUST only use the dedicated MSRP session to send the file described
	in the SDP offer or answer. That is, senders MUST NOT send		in the SDP offer or answer. That is, senders MUST NOT send
	additional files over the same MSRP session.		additional files over the same MSRP session.
	File transfer may be accomplished using a new multimedia session		File transfer may be accomplished using a new multimedia session
	skipping to change at page 24, line 32		skipping to change at page 24, line 12
	that MSRP does not require to wait for a 200-class response for a		that MSRP does not require to wait for a 200-class response for a
	chunk before sending the following one. Therefore, it is valid to		chunk before sending the following one. Therefore, it is valid to
	send pipelined MSRP SEND requests containing chunks of the same MSRP		send pipelined MSRP SEND requests containing chunks of the same MSRP
	message (the file). Section 9.1 contains an example of a file		message (the file). Section 9.1 contains an example of a file
	transfer using pipelined MSRP requests.		transfer using pipelined MSRP requests.
	The MSRP specification [RFC4975] defines a 'max-size' SDP attribute.		The MSRP specification [RFC4975] defines a 'max-size' SDP attribute.
	This attribute specifies the maximum number of octets of an MSRP		This attribute specifies the maximum number of octets of an MSRP
	message that the creator of the SDP is willing to receive (notice		message that the creator of the SDP is willing to receive (notice
	once more the definition of "MSRP message"). File receivers MAY add		once more the definition of "MSRP message"). File receivers MAY add
	a 'max-size' attribute to the MSRP m= line that specifies the file,		a 'max-size' attribute to the MSRP "m=" line that specifies the file,
	indicating the maximum number of octets of an MSRP message. File		indicating the maximum number of octets of an MSRP message. File
	senders MUST NOT exceed the 'max-size' limit for any message sent in		senders MUST NOT exceed the 'max-size' limit for any message sent in
	the resulting session.		the resulting session.
	In the absence of a 'file-range' attribute in the SDP, the MSRP file		In the absence of a 'file-range' attribute in the SDP, the MSRP file
	transfer MUST start with the first byte of the file and end with the		transfer MUST start with the first byte of the file and end with the
	last byte (i.e., the whole file is transferred). If a 'file-range'		last byte (i.e., the whole file is transferred). If a 'file-range'
	attribute is present in SDP, the file sender application MUST extract		attribute is present in SDP, the file sender application MUST extract
	the indicated range of bytes from the file (start and stop offset		the indicated range of bytes from the file (start and stop offset
	bytes). Then the file sender application MAY wrap those bytes in an		bytes). Then the file sender application MAY wrap those bytes in an
	skipping to change at page 25, line 8		skipping to change at page 24, line 36
	sender application delivers the content (e.g., the message/cpim body)		sender application delivers the content (e.g., the message/cpim body)
	to MSRP for transportation. MSRP will consider the delivered content		to MSRP for transportation. MSRP will consider the delivered content
	as a whole message, and will start numbering bytes with the number 1.		as a whole message, and will start numbering bytes with the number 1.
	Note that the default content disposition of MSRP bodies is 'render'.		Note that the default content disposition of MSRP bodies is 'render'.
	When MSRP is used to transfer files, the MSRP Content-Disposition		When MSRP is used to transfer files, the MSRP Content-Disposition
	header can also take the value 'attachment' as indicated in		header can also take the value 'attachment' as indicated in
	Section 7.		Section 7.
	Once the file transfer is completed, the file sender SHOULD close the		Once the file transfer is completed, the file sender SHOULD close the
	MSRP session, and MUST behave according to the MSRP [RFC4975]		MSRP session and MUST behave according to the MSRP [RFC4975]
	procedures with respect closing MSRP sessions.		procedures with respect closing MSRP sessions. Note that MSRP
			session management is not related to TCP connection management. As a
			matter of fact, MSRP allows multiple MSRP sessions to share the same
			TCP connection.
	8.7. Considerations about the 'file-icon' attribute		8.8. Considerations about the 'file-icon' attribute
	This specification allows a file sender to include a small preview of		This specification allows a file sender to include a small preview of
	an image file: an icon. A 'file-icon' attribute contains a CID URL		an image file: an icon. A 'file-icon' attribute contains a CID URL
	[RFC2392] that points to an additional body that contains the actual		[RFC2392] that points to an additional body that contains the actual
	icon. Since the icon is sent as a separate body along the SDP body,		icon. Since the icon is sent as a separate body along the SDP body,
	the file sender MUST wrap the SDP body and the icon bodies in a MIME		the file sender MUST wrap the SDP body and the icon bodies in a MIME
	multipart/related body. Therefore, implementations according to this		multipart/related body. Therefore, implementations according to this
	specification MUST implement the multipart/related MIME type		specification MUST implement the multipart/related MIME type
	[RFC2387]. When creating a multipart/related MIME wrapper, the SDP		[RFC2387]. When creating a multipart/related MIME wrapper, the SDP
	body MUST be the root body, which according to RFC 2387 [RFC2387] is		body MUST be the root body, which according to RFC 2387 [RFC2387] is
	skipping to change at page 39, line 28		skipping to change at page 39, line 28
	number of simultaneous file transfers.		number of simultaneous file transfers.
	File receivers MUST also sanitize all input, such as the local file		File receivers MUST also sanitize all input, such as the local file
	name, prior to making calls to the local file system to store a file.		name, prior to making calls to the local file system to store a file.
	This is to prevent the existence of meaningful characters to the		This is to prevent the existence of meaningful characters to the
	local operating system that could damage it.		local operating system that could damage it.
	Once a file has been transferred the file receiver must take care		Once a file has been transferred the file receiver must take care
	with it. Typically file transfer is a commonly used mechanism for		with it. Typically file transfer is a commonly used mechanism for
	transmitting computer virus, spyware, and other types of malware.		transmitting computer virus, spyware, and other types of malware.
	File recipients should apply all possible security technologies		File receivers should apply all possible security technologies (e.g.,
	(e.g., antivirus, antispaware, etc.) to dismiss the risk of damage at		antivirus, antispaware, etc.) to dismiss the risk of damage at their
	their host.		host.
	11. IANA Considerations		11. IANA Considerations
	This document instructs IANA to register a number of SDP attributes		This document instructs IANA to register a number of SDP attributes
	according to the following:		according to the following:
	11.1. Registration of new SDP attributes		11.1. Registration of new SDP attributes
	This memo provides instructions to IANA to register a number of media		This memo provides instructions to IANA to register a number of media
	level only attributes in the Session Description Protocol Parameters		level only attributes in the Session Description Protocol Parameters
	skipping to change at page 41, line 38		skipping to change at page 41, line 38
	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, and Eric Rescorla discussed and provided comments and		Rosenberg, Eric Rescorla, and Vikram Chhibber discussed and provided
	improvements to this document.		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 42, line 35		skipping to change at page 42, line 35
	[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO		[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
	10646", STD 63, RFC 3629, November 2003.		10646", STD 63, RFC 3629, November 2003.
	[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail		[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
	Extensions (S/MIME) Version 3.1 Message Specification",		Extensions (S/MIME) Version 3.1 Message Specification",
	RFC 3851, July 2004.		RFC 3851, July 2004.
	[RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant		[RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant
	Messaging (CPIM): Message Format", RFC 3862, August 2004.		Messaging (CPIM): Message Format", RFC 3862, August 2004.
	[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", RFC 4234, October 2005.
	[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session		[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
	Description Protocol", RFC 4566, July 2006.		Description Protocol", RFC 4566, July 2006.
	[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message		[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message
	Session Relay Protocol (MSRP)", RFC 4975, September 2007.		Session Relay Protocol (MSRP)", RFC 4975, September 2007.
			[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
			Specifications: ABNF", STD 68, RFC 5234, January 2008.
	13.2. Informational References		13.2. Informational References
	[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,		[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
	A., Peterson, J., Sparks, R., Handley, M., and E.		A., Peterson, J., Sparks, R., Handley, M., and E.
	Schooler, "SIP: Session Initiation Protocol", RFC 3261,		Schooler, "SIP: Session Initiation Protocol", RFC 3261,
	June 2002.		June 2002.
	[RFC4028] Donovan, S. and J. Rosenberg, "Session Timers in the		[RFC4028] Donovan, S. and J. Rosenberg, "Session Timers in the
	Session Initiation Protocol (SIP)", RFC 4028, April 2005.		Session Initiation Protocol (SIP)", RFC 4028, April 2005.
	skipping to change at page 43, line 28		skipping to change at page 43, line 28
	URIs		URIs
	[1] <http://www.iana.org/assignments/media-types/>		[1] <http://www.iana.org/assignments/media-types/>
	[2] <http://www.iana.org/assignments/hash-function-text-names>		[2] <http://www.iana.org/assignments/hash-function-text-names>
	[3] <http://www.iana.org/assignments/mail-cont-disp>		[3] <http://www.iana.org/assignments/mail-cont-disp>
	[4] <http://www.iana.org/assignments/sdp-parameters>		[4] <http://www.iana.org/assignments/sdp-parameters>
			Appendix A. Alternatives Considered
			The requirements are related to the description and negotiation of
			the session, not to the actual file transfer mechanism. Thus, it is
			natural that in order to meet them it is enough to define attribute
			extensions and usage conventions to SDP, while MSRP itself needs no
			extensions and can be used as it is. This is effectively the
			approach taken in this specification. Another goal has been to
			specify the SDP extensions in such a way that a regular MSRP endpoint
			which does not support them could still in some cases act as an
			endpoint in a file transfer session, albeit with a somewhat reduced
			functionality.
			In some ways the aim of this specification is similar to the aim of
			content indirection mechanism in the Session Initiation Protocol
			(SIP) [RFC4483]. Both mechanisms allow a user agent to decide
			whether or not to download a file based on information about the
			file. However, there are some differences. With content
			indirection, it is not possible for the other endpoint to explicitly
			accept or reject the file transfer. Also, it is not possible for an
			endpoint to request a file from another endpoint. Furthermore,
			content indirection is not tied to the context of a media session,
			which is sometimes a desirable property. Finally, content
			indirection typically requires some server infrastructure, which may
			not always be available. It is possible to use content indirection
			directly between the endpoints too, but in that case there is no
			definition for how it works for endpoints behind NATs. The level of
			requirements in implementations decides which solution meets the
			requirements.
			Based on the argumentation above, this document defines the SDP
			attribute extensions and usage conventions needed for meeting the
			requirements on file transfer services with the SDP offer/answer
			model, using MSRP as the transfer protocol within the session.
			In principle it is possible to use the SDP extensions defined here
			and replace MSRP with any other similar protocol that can carry
			MIME objects. This kind of specification can be written as a
			separate document if the need arises. Essentially, such protocol
			should be able to be negotiated on an SDP offer/answer exchange
			(RFC 3264 [RFC3264]), be able to describe the file to be
			transferred in SDP offer/answer exchange, be able to carry MIME
			objects between two endpoints, and use a reliable transport
			protocol (e.g., TCP).
			This specification defines a set of SDP attributes that describe a
			file to be transferred between two endpoints. The information needed
			to describe a file could be potentially encoded in a few different
			ways. The MMUSIC working group considered a few alternative
			approaches before deciding to use the encoding described in
			Section 6. In particular, the working group looked at the MIME
			'external-body' type and the use of a single SDP attribute or
			parameter.
			A MIME 'external-body' could potentially be used to describe the file
			to be transferred. In fact, many of the SDP parameters this
			specification defines are also supported by 'external-body' body
			parts. The MMUSIC working group decided not to use 'external-body'
			body parts because a number of existing offer/answer implementations
			do not support multipart bodies.
			The information carried in the SDP attributes defined in Section 6
			could potentially be encoded in a single SDP attribute. The MMUSIC
			working group decided not to follow this approach because it is
			expected that implementations support only a subset of the parameters
			defined in Section 6. Those implementations will be able to use
			regular SDP rules in order to ignore non-supported SDP parameters.
			If all the information was encoded in a single SDP attribute, those
			rules, which relate to backwards compatibility, would need to be
			redefined specifically for that parameter.
	Authors' Addresses		Authors' Addresses
	Miguel A. Garcia-Martin		Miguel A. Garcia-Martin
	Nokia Siemens Networks		Nokia Siemens Networks
	P.O.Box 6		P.O.Box 6
	Nokia Siemens Networks, FIN 02022		Nokia Siemens Networks, FIN 02022
	Finland		Finland
	Phone: +358-71400-4000		Phone: +358-71400-4000
	Email: miguel.garcia@nsn.com		Email: miguel.garcia@nsn.com
	skipping to change at page 45, line 7		skipping to change at page 46, line 7
	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		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	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
	skipping to change at page 45, line 44		skipping to change at line 2010
	attempt made to obtain a general license or permission for the use of		attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Acknowledgment
	Funding for the RFC Editor function is provided by the IETF
	Administrative Support Activity (IASA).
End of changes. 48 change blocks.
	241 lines changed or deleted		301 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/