draft-ietf-mmusic-file-transfer-mech-08.txt		draft-ietf-mmusic-file-transfer-mech-09.txt
	MMUSIC Working Group M. Garcia-Martin		MMUSIC Working Group M. Garcia-Martin
	Internet-Draft Nokia Siemens Networks		Internet-Draft Ericsson
	Intended status: Standards Track M. Isomaki		Intended status: Standards Track M. Isomaki
	Expires: November 21, 2008 Nokia		Expires: May 7, 2009 Nokia
	G. Camarillo		G. Camarillo
	S. Loreto		S. Loreto
	Ericsson		Ericsson
	P. Kyzivat		P. Kyzivat
	Cisco Systems		Cisco Systems
	May 20, 2008		November 3, 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-08.txt		draft-ietf-mmusic-file-transfer-mech-09.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 November 21, 2008.		This Internet-Draft will expire on May 7, 2009.
	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 15		skipping to change at page 3, line 15
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5		4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5
	5. File selector . . . . . . . . . . . . . . . . . . . . . . . . 7		5. File selector . . . . . . . . . . . . . . . . . . . . . . . . 7
	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. Offerer's Behavior . . . . . . . . . . . . . . . . . . . . 14		8.1. The 'file-transfer-id' attribute . . . . . . . . . . . . . 14
	8.1.1. The Offerer is a File Sender . . . . . . . . . . . . . 15		8.2. Offerer's Behavior . . . . . . . . . . . . . . . . . . . . 17
	8.1.2. The Offerer is a File Receiver . . . . . . . . . . . . 15		8.2.1. The Offerer is a File Sender . . . . . . . . . . . . . 17
	8.1.3. SDP Offer for Several Files . . . . . . . . . . . . . 16		8.2.2. The Offerer is a File Receiver . . . . . . . . . . . . 18
	8.2. Answerer's Behavior . . . . . . . . . . . . . . . . . . . 17		8.2.3. SDP Offer for Several Files . . . . . . . . . . . . . 19
	8.2.1. The Answerer is a File Receiver . . . . . . . . . . . 17		8.3. Answerer's Behavior . . . . . . . . . . . . . . . . . . . 19
	8.2.2. The Answerer is a File Sender . . . . . . . . . . . . 18		8.3.1. The Answerer is a File Receiver . . . . . . . . . . . 19
	8.3. The 'file-transfer-id' attribute . . . . . . . . . . . . . 19		8.3.2. The Answerer is a File Sender . . . . . . . . . . . . 20
	8.4. Aborting an ongoing file transfer operation . . . . . . . 21		8.4. Aborting an ongoing file transfer operation . . . . . . . 22
	8.5. Indicating File Transfer Offer/Answer Capability . . . . . 24		8.5. Indicating File Transfer Offer/Answer Capability . . . . . 25
	8.6. Re-usage of Existing "m=" Lines in SDP . . . . . . . . . . 25		8.6. Re-usage of Existing "m=" Lines in SDP . . . . . . . . . . 26
	8.7. MSRP Usage . . . . . . . . . . . . . . . . . . . . . . . . 25		8.7. MSRP Usage . . . . . . . . . . . . . . . . . . . . . . . . 26
	8.8. Considerations about the 'file-icon' attribute . . . . . . 27		8.8. Considerations about the 'file-icon' attribute . . . . . . 28
	9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 27		9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
	9.1. Offerer sends a file to the Answerer . . . . . . . . . . . 27		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 . . . . . . . . . . . . . . . . . . . . . . 32		file transfer . . . . . . . . . . . . . . . . . . . . . . 33
	9.3. Example of a capability indication . . . . . . . . . . . . 39		9.3. Example of a capability indication . . . . . . . . . . . . 40
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 40		10. Security Considerations . . . . . . . . . . . . . . . . . . . 41
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
	11.1. Registration of new SDP attributes . . . . . . . . . . . . 41		11.1. Registration of new SDP attributes . . . . . . . . . . . . 42
	11.1.1. Registration of the file-selector attribute . . . . . 41		11.1.1. Registration of the file-selector attribute . . . . . 42
	11.1.2. Registration of the file-transfer-id attribute . . . . 42		11.1.2. Registration of the file-transfer-id attribute . . . . 43
	11.1.3. Registration of the file-disposition attribute . . . . 42		11.1.3. Registration of the file-disposition attribute . . . . 43
	11.1.4. Registration of the file-date attribute . . . . . . . 42		11.1.4. Registration of the file-date attribute . . . . . . . 43
	11.1.5. Registration of the file-icon attribute . . . . . . . 43		11.1.5. Registration of the file-icon attribute . . . . . . . 44
	11.1.6. Registration of the file-range attribute . . . . . . . 43		11.1.6. Registration of the file-range attribute . . . . . . . 44
	12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43		12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43		13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44
	13.1. Normative References . . . . . . . . . . . . . . . . . . . 43		13.1. Normative References . . . . . . . . . . . . . . . . . . . 44
	13.2. Informational References . . . . . . . . . . . . . . . . . 44		13.2. Informational References . . . . . . . . . . . . . . . . . 45
	Appendix A. Alternatives Considered . . . . . . . . . . . . . . . 45		Appendix A. Alternatives Considered . . . . . . . . . . . . . . . 46
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48
	Intellectual Property and Copyright Statements . . . . . . . . . . 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 8, line 18		skipping to change at page 8, line 18
	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.5.		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 [RFC5234] 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 5322 [RFC5322].
	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 5234		; 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/%x26-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 5234		; 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
	skipping to change at page 9, line 20		skipping to change at page 9, line 20
	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 5322
	; numeric timezones (+HHMM or -HHMM)		; numeric timezones (+HHMM or -HHMM)
	; must be used		; must be used
	; DQUOTE defined in RFC 5234 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 / "*"
	skipping to change at page 11, line 25		skipping to change at page 11, line 25
	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 randomly chosen globally		The 'file-transfer-id' attribute provides a randomly chosen globally
	unique identification to the actual file transfer. It is used to		unique identification to the actual file transfer. It is used to
	distinguish a new file transfer request from a repetition of the SDP		distinguish a new file transfer request from a repetition of the SDP
	(or the fraction of the SDP that deals with the file description).		(or the fraction of the SDP that deals with the file description).
	This attribute is described in much greater detail in Section 8.3.		This attribute is described in much greater detail in Section 8.1.
	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
	combination of the 'creation', 'modification', and 'read' parameters,		combination of the 'creation', 'modification', and 'read' parameters,
	but MUST NOT contain more than one of each type .		but MUST NOT contain more than one of each type .
	The 'creation' parameter indicates the date at which the file was		The 'creation' parameter indicates the date at which the file was
	created. The value MUST be a quoted string which contains a		created. The value MUST be a quoted string which contains a
	representation of the creation date of the file in RFC 2822 [RFC2822]		representation of the creation date of the file in RFC 5322 [RFC5322]
	'date-time' format. Numeric timezones (+HHMM or -HHMM) MUST be used.		'date-time' format. Numeric timezones (+HHMM or -HHMM) MUST be used.
	The value of this parameter SHOULD be the same as the 'creation-date'		The value of this parameter SHOULD be the same as the 'creation-date'
	parameter of the Content-Disposition header field [RFC2183] that		parameter of the Content-Disposition header field [RFC2183] that
	would be signaled by the actual file transfer protocol.		would be signaled by the actual file transfer protocol.
	The 'modification' parameter indicates the date at which the file was		The 'modification' parameter indicates the date at which the file was
	last modified. The value MUST be a quoted string which contains a		last modified. The value MUST be a quoted string which contains a
	representation of the last modification date to the file in RFC 2822		representation of the last modification date to the file in RFC 5322
	[RFC2822] 'date-time' format. Numeric timezones (+HHMM or -HHMM)		[RFC5322] 'date-time' format. Numeric timezones (+HHMM or -HHMM)
	MUST be used. The value of this parameter SHOULD be the same as the		MUST be used. The value of this parameter SHOULD be the same as the
	'modification-date' parameter of the Content-Disposition header field		'modification-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 'read' parameter indicates the date at which the file was last		The 'read' parameter indicates the date at which the file was last
	read. The value MUST be a quoted string which contains a		read. The value MUST be a quoted string which contains a
	representation of the last date the file was read in RFC 2822		representation of the last date the file was read in RFC 5322
	[RFC2822] 'date-time' format. Numeric timezones (+HHMM or -HHMM)		[RFC5322] 'date-time' format. Numeric timezones (+HHMM or -HHMM)
	MUST be used. The value of this parameter SHOULD be the same as the		MUST be used. The value of this parameter SHOULD be the same as the
	'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.8 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 octet position of the file where
	file transfer should start. The first byte of a file is denoted by		the file transfer should start. The first octet of a file is denoted
	the ordinal number "1". The "stop offset" value refers position of		by the ordinal number "1". The "stop offset" value refers to the
	the file where the file transfer should stop. The "stop offset"		octet position of the file where the file transfer should stop,
	value MAY contain a "*" if the total size of the file is not known in		inclusive of this octet. The "stop offset" value MAY contain a "*"
	advance. The absence of this attribute indicates a complete file,		if the total size of the file is not known in advance. The absence
	i.e., as if the 'file-range' attribute would have been present with a		of this attribute indicates a complete file, i.e., as if the 'file-
	value "1-*". The 'file-range' attribute must not be confused with		range' attribute would have been present with a value "1-*". The
	the Byte-Range header in MSRP. The former indicates the portion of a		'file-range' attribute must not be confused with the Byte-Range
	file that the application would read and pass onto the MSRP stack for		header in MSRP. The former indicates the portion of a file that the
			application would read and pass onto the MSRP stack for
	transportation. From the point of view of MSRP, the portion of the		transportation. From the point of view of MSRP, the portion of the
	file is viewed as a whole message. The latter indicates the number		file is viewed as a whole message. The latter indicates the number
	of bytes of that message that are carried in a chunk and the total		of bytes of that message that are carried in a chunk and the total
	size of the message. Therefore, MSRP starts counting the delivered		size of the message. Therefore, MSRP starts counting the delivered
	message at byte number 1, independently of position of that byte in		message at octet number 1, independently of position of that octet in
	the file.		the file.
	The following is an example of an SDP body that contains the		The following is an example of an SDP body that contains the
	extensions defined in this memo:		extensions defined in this memo:
	v=0		v=0
	o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com		o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
	s=		s=
	c=IN IP4 host.atlanta.example.com		c=IN IP4 host.atlanta.example.com
	t=0 0		t=0 0
	skipping to change at page 14, line 45		skipping to change at page 14, line 45
	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. The 'file-transfer-id' attribute
			This specification creates an extension to the SDP Offer/Answer Model
			[RFC3264], and because of that, it is assumed that the existing SDP
			behavior is kept intact. The SDP behavior requires, for example,
			that SDP is sent again to the remote party in situations where the
			media description or perhaps other SDP parameters have not changed
			with respect a previous offer/answer exchange. Let's consider the
			SIP Session Timer (RFC 4028) [RFC4028], which uses re-INVITE requests
			to refresh sessions. RFC 4028 recommends to send unmodified SDP in a
			re-INVITE to refresh the session. Should this re-INVITE contain SDP
			describing a file transfer operation and occur while the file
			transfer was still going on, there would be no means to detect
			whether the SDP creator wanted to abort the current file transfer
			operation and initiate a new one or the SDP file description was
			included in the SDP due to other reasons (e.g., session timer
			refresh).
			A similar scenario occurs when two endpoints have successfully agreed
			on a file transfer, which is currently taking place when one of the
			endpoints wants to add additional media streams to the existing
			session. In this case, the endpoint sends a re-INVITE request that
			contains SDP. The SDP needs to maintain the media descriptions for
			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
			new file transfer is requested or not.
			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
			transfer, then the other endpoint wouldn't be able to determine
			whether a new file transfer should start or not.
			To address these scenarios this specification defines the 'file-
			transfer-id' attribute which contains a globally unique random
			identifier allocated to the file transfer operation. The file
			transfer identifier helps both endpoints to determine whether the SDP
			offer is requesting a new file transfer or it is a repetition of the
			SDP. A new file transfer is one that, in case of acceptance, will
			provoke the actual transfer of a file. This is typically the case of
			new offer/answer exchanges, or in cases where an endpoint wants to
			abort the existing file transfer and re-start the file transfer once
			more. On the other hand, the repetition of the SDP does not lead to
			any actual file to be transferred, potentially because the file
			transfer is still going on or because it has already finished. This
			is the case of repeated offer/answer exchanges, which can be due to a
			number of reasons (session timer, addition/removal of other media
			types in the SDP, update in SDP due to changes in other session
			parameters, etc.).
			Implementations according to this specification MUST include a 'file-
			transfer-id' attribute in SDP offers and answers. The SDP offerer
			MUST select a file transfer identifier according to the syntax and
			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.
			The file transfer identifier MUST be unique within the current
			session (never used before in this session), and it is RECOMMENDED to
			be unique across different sessions. It is RECOMMENDED to select a
			relatively big random identifier (e.g., 32 characters) to avoid
			duplications. The SDP answerer MUST keep track of the proposed file
			transfer identifiers in each session and copy the value of the
			received file transfer identifier in the SDP answer.
			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
			be transferred is the same), therefore, the SDP offerer MUST choose a
			new file transfer identifier.
			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
			transfer operation, then the SDP answer MUST mirror the value of the
			'file-transfer-id' attribute included in the SDP offer. This
			effectively means that setting a media stream to zero has higher
			precedence than any value that the 'file-transfer-id' attribute can
			take.
			As a side effect, the 'file-transfer-id' attribute can be used for
			aborting and restarting again an ongoing file transfer. Assume that
			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 transfer, one endpoint sends a new SDP offer, equal to the
			initial one except for the value of the 'file-transfer-id' attribute,
			which is a new globally unique random value. This indicates that the
			offerer wants to abort the existing transfer and start a new one,
			according to the SDP parameters. The SDP answerer SHOULD abort the
			ongoing file transfer, according to the procedures of the file
			transfer protocol (e.g., MSRP), and start sending file once more from
			the initial requested octet. Section 8.4 further discusses file
			transfer abortion.
			If an endpoint creates an SDP offer where the 'file-transfer-id'
			attribute value does not change with respect a previously sent one,
			but the file selector changes so that a new file is selected, then
			this is considered and error, and the SDP answerer MUST abort the
			file transfer operation (e.g., by setting the port number to zero in
			the SDP answer). Note that endpoints MAY change the 'file-selector'
			attribute as long as the selected file does not change (e.g., by
			adding a hash selector), however it is RECOMMENDED that endpoints do
			not change the value of the 'file-selector' attribute if it is
			requested to transfer the same file described in a previous SDP
			offer/answer exchange.
			Figure 3 summarizes the relation of the 'file-transfer-id' attribute
			with the file selector in subsequent SDP exchanges.
			\ | | |
			\ file selector | different | same |
			'file-transfer-id' \ | file | file |
			==================================+=============+===============+
			| new file | new file |
			changed | transfer | transfer |
			| operation | operation |
			----------------------------------+-------------+---------------+
			| | existing file |
			unchanged | error | transfer |
			| | operation |
			----------------------------------+-------------+---------------+
			Figure 3: Relation of the 'file-transfer-id' attribute with the
			selector of the file in a subsequent SDP exchange
			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. The SDP offerer creates an SDP file description that maintains
			the media description line corresponding to the file transfer. 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
			transfer got.
			8.2. Offerer's Behavior
	An offerer who wishes to send or receive one or more files to or from		An offerer who wishes to send or receive one or more files to or 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 "m=" line per file. When MSRP is used as the transfer		containing one "m=" line per file. When MSRP is used as the transfer
	mechanism, each "m=" line also describes a single MSRP session,		mechanism, each "m=" line also describes a single MSRP session,
	according to the MSRP [RFC4975] procedures. Any "m=" lines that may		according to the MSRP [RFC4975] procedures. Any "m=" lines that may
	have already been present in a previous SDP exchange are normally		have already been present in a previous SDP exchange are normally
	kept unmodified; the new "m=" lines are added afterwards (Section 8.6		kept unmodified; the new "m=" lines are added afterwards (Section 8.6
	describes cases when "m=" lines are re-used). All the media line		describes cases when "m=" lines are re-used). All the media line
	attributes specified and required by MSRP [RFC4975] (e.g., "a=path",		attributes specified and required by MSRP [RFC4975] (e.g., "a=path",
	"a=accept-types", etc.) MUST be included as well.		"a=accept-types", etc.) MUST be included as well.
	8.1.1. The Offerer is a File Sender		8.2.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. If the file sender wishes to start a new file		respectively. If the file sender wishes to start a new file
	transfer, the file sender MUST add a 'file-transfer-id' attribute		transfer, the file sender MUST add a 'file-transfer-id' attribute
	containing a new globally unique random identifier value.		containing a new globally unique random identifier value.
	Additionally, the file sender MUST add a session or media 'sendonly'		Additionally, the file sender MUST add a session or media 'sendonly'
	attribute to the SDP offer. Then the file sender sends the SDP offer		attribute to the SDP offer. Then the file sender sends 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
	skipping to change at page 15, line 46		skipping to change at page 18, line 31
	example: the file sender would like the file receiver to render the		example: the file sender would like the file receiver to render the
	file or not). The three date attributes provide the answerer with an		file or not). The three date attributes provide the answerer with an
	indication of the age of the file. The file sender MAY also add a		indication of the age of the file. The file sender 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.		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.1.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 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. 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 16, line 32		skipping to change at page 19, line 16
	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.
	8.1.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.
	Each file has its own file transfer identifier, which uniquely		Each file has its own file transfer identifier, which uniquely
	identifies each file transfer.		identifies each file transfer.
	Using an "m=" line per file implies that different files are		Using an "m=" line per file implies that different files are
	transferred using different MSRP sessions. However, all those MSRP		transferred using different MSRP sessions. However, all those MSRP
	sessions can be set up to run over a single TCP connection, as		sessions can be set up to run over a single TCP connection, as
	described in Section 8.1 of RFC 4975 [RFC4975]. The same TCP		described in Section 8.1 of RFC 4975 [RFC4975]. The same TCP
	connection can also be re-used for sequential file transfers.		connection can also be re-used for sequential file transfers.
	8.2. Answerer's Behavior		8.3. Answerer's Behavior
	If the answerer wishes to reject a file offered by the offerer, it		If the answerer wishes to reject a file offered by the offerer, it
	sets the port number of the "m=" line associated with the file to		sets the port number of the "m=" line associated with the file to
	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.3.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 port number.		file receiver gets the SDP offer, it first examines the port number.
	If the port number is set to zero, the file transfer operation is		If the port number is set to zero, the file transfer operation is
	closed, and no more data is expected over the media stream. Then, if		closed, and no more data is expected over the media stream. Then, if
	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
	skipping to change at page 18, line 6		skipping to change at page 20, line 34
	'file-icon', 'file-disposition', or 'file-date' attributes in the SDP		'file-icon', 'file-disposition', or 'file-date' attributes in the SDP
	answer.		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 octets declared in there,
	file receiver MUST include a 'file-range' attribute in the SDP answer		the file receiver MUST include a 'file-range' attribute in the SDP
	with the same range of values. If the file receiver does not accept		answer with the same range of values. If the file receiver does not
	the reception of that range of bytes, it SHOULD reject the transfer		accept the reception of that range of octets, it SHOULD reject the
	of the file.		transfer of the file.
	8.2.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
	actual file transfer is initiated or not, the file sender MUST create		actual file transfer is initiated or not, the file sender MUST create
	skipping to change at page 19, line 30		skipping to change at page 22, line 11
	choose one of them to be defined in the SDP answer. If that choice		choose one of them to be defined in the SDP answer. If that choice
	cannot be done, the answerer SHOULD reject the MSRP media stream for		cannot be done, the answerer SHOULD reject the MSRP media stream for
	file transfer (by setting the port number to zero).		file transfer (by setting the port number to zero).
	If the need arises, future specifications can provide a suitable		If the need arises, future specifications can provide a suitable
	mechanism that allows to either select multiple files or, e.g.,		mechanism that allows to either select multiple files or, e.g.,
	resolve ambiguities by returning a list of files that match the		resolve ambiguities by returning a list of files that match the
	file selector.		file selector.
	If the SDP offer contains a 'file-range' attribute and the file		If the SDP offer contains a 'file-range' attribute and the file
	sender accepts to send the range of bytes declared in there, the file		sender accepts to send the range of octets declared in there, the
	sender MUST include a 'file-range' attribute in the SDP answer with		file sender MUST include a 'file-range' attribute in the SDP answer
	the same range of values. If the file sender does not accept sending		with the same range of values. If the file sender does not accept
	that range of bytes, it SHOULD reject the transfer of the file.		sending that range of octets, it SHOULD reject the transfer of the
			file.
	8.3. The 'file-transfer-id' attribute
	This specification creates an extension to the SDP Offer/Answer Model
	[RFC3264], and because of that, it is assumed that the existing SDP
	behavior is kept intact. The SDP behavior requires, for example,
	that SDP is sent again to the remote party in situations where the
	media description or perhaps other SDP parameters have not changed
	with respect a previous offer/answer exchange. Let's consider the
	SIP Session Timer (RFC 4028) [RFC4028], which uses re-INVITE requests
	to refresh sessions. RFC 4028 recommends to send unmodified SDP in a
	re-INVITE to refresh the session. Should this re-INVITE contain SDP
	describing a file transfer operation and occur while the file
	transfer was still going on, there would be no means to detect
	whether the SDP creator wanted to abort the current file transfer
	operation and initiate a new one or the SDP file description was
	included in the SDP due to other reasons (e.g., session timer
	refresh).
	A similar scenario occurs when two endpoints have successfully agreed
	on a file transfer, which is currently taking place when one of the
	endpoints wants to add additional media streams to the existing
	session. In this case, the endpoint sends a re-INVITE request that
	contains SDP. The SDP needs to maintain the media descriptions for
	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
	new file transfer is requested or not.
	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
	transfer, then the other endpoint wouldn't be able to determine
	whether a new file transfer should start or not.
	To address these scenarios this specification defines the 'file-
	transfer-id' attribute which contains a globally unique random
	identifier allocated to the file transfer operation. The file
	transfer identifier helps both endpoints to determine whether the SDP
	offer is requesting a new file transfer or it is a repetition of the
	SDP. A new file transfer is one that, in case of acceptance, will
	provoke the actual transfer of a file. This is typically the case of
	new offer/answer exchanges, or in cases where an endpoint wants to
	abort the existing file transfer and re-start the file transfer once
	more. On the other hand, the repetition of the SDP does not lead to
	any actual file to be transferred, potentially because the file
	transfer is still going on or because it has already finished. This
	is the case of repeated offer/answer exchanges, which can be due to a
	number of reasons (session timer, addition/removal of other media
	types in the SDP, update in SDP due to changes in other session
	parameters, etc.).
	Implementations according to this specification MUST include a 'file-
	transfer-id' attribute in SDP offers and answers. The SDP offerer
	MUST select a file transfer identifier according to the syntax and
	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.
	The file transfer identifier MUST be unique within the current
	session (never used before in this session), and it is RECOMMENDED to
	be unique across different sessions. It is RECOMMENDED to select a
	relatively big random identifier (e.g., 32 characters) to avoid
	duplications. The SDP answerer MUST keep track of the proposed file
	transfer identifiers in each session and copy the value of the
	received file transfer identifier in the SDP answer.
	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
	be transferred is the same), therefore, the SDP offerer MUST choose a
	new file transfer identifier.
	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
	transfer operation, then the SDP answer MUST mirror the value of the
	'file-transfer-id' attribute included in the SDP offer. This
	effectively means that setting a media stream to zero has higher
	precedence than any value that the 'file-transfer-id' attribute can
	take.
	As a side effect, the 'file-transfer-id' attribute can be used for
	aborting and restarting again an ongoing file transfer. Assume that
	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 transfer, one endpoint sends a new SDP offer, equal to the
	initial one except for the value of the 'file-transfer-id' attribute,
	which is a new globally unique random value. This indicates that the
	offerer wants to abort the existing transfer and start a new one,
	according to the SDP parameters. The SDP answerer SHOULD abort the
	ongoing file transfer, according to the procedures of the file
	transfer protocol (e.g., MSRP), and start sending file once more from
	the initial requested octet. Section 8.4 further discusses file
	transfer abortion.
	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. The SDP offerer creates an SDP file description that maintains
	the media description line corresponding to the file transfer. 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
	transfer got.
	8.4. Aborting an ongoing file transfer operation		8.4. Aborting an ongoing file transfer operation
	Either the file sender or the file receiver can abort an ongoing file		Either the file sender or the file receiver can abort an ongoing file
	transfer at any time. Unless otherwise noted, the entity that aborts		transfer at any time. Unless otherwise noted, the entity that aborts
	an ongoing file transfer operation MUST follow the procedures at the		an ongoing file transfer operation MUST follow the procedures at the
	media level (e.g., MSRP) and at the signaling level (SDP Offer/		media level (e.g., MSRP) and at the signaling level (SDP Offer/
	answer), as described below.		answer), as described below.
	Assume the scenario depicted in Figure 3 where a file sender wishes		Assume the scenario depicted in Figure 4 where a file sender wishes
	to abort an ongoing file transfer without initiating an alternative		to abort an ongoing file transfer without initiating an alternative
	file transfer. Assume that an ongoing MSRP SEND request is being		file transfer. Assume that an ongoing MSRP SEND request is being
	transmitted. The file sender aborts the MSRP message by including		transmitted. The file sender aborts the MSRP message by including
	the '#' character in the continuation field of the end-line of a SEND		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		request, according to the MSRP procedures (see Section 7.1 of RFC
	4975 [RFC4975]). Since a file is transmitted as one MSRP message,		4975 [RFC4975]). Since a file is transmitted as one MSRP message,
	aborting the MSRP message effectively aborts the file transfer. The		aborting the MSRP message effectively aborts the file transfer. The
	file receiver acknowledges the MSRP SEND request with a 200 response.		file receiver acknowledges the MSRP SEND request with a 200 response.
	Then the file sender SHOULD close the MSRP session by creating a new		Then the file sender SHOULD close the MSRP session by creating a new
	SDP offer that sets the port number to zero in the related "m=" line		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		that describes the file transfer (see Section 8.2 of RFC 3264
	[RFC3264]). This SDP offer MUST conform with the requirements of		[RFC3264]). This SDP offer MUST conform with the requirements of
	Section 8.1.1. The 'file-transfer-id' attribute MUST be the same		Section 8.2.1. The 'file-transfer-id' attribute MUST be the same
	that identifies the ongoing transfer. Then the file sender sends		that identifies the ongoing transfer. Then the file sender sends
	this SDP offer to the file receiver.		this SDP offer to the file receiver.
			Rather than close the MSRP session by setting the port number to
			zero in the related "m=" line, the file sender could also tear
			down the whole session, e.g., by sending a SIP BYE request.
			Note that it is responsibility of the file sender to tear down the
			MSRP session. Implementations should be prepared for misbehaviors
			and implement measures to avoid hang states. For example, upon
			expiration of a timer the file receiver can close the aborted MSRP
			session by using regular MSRP procedures.
	A file receiver that receives the above SDP offer creates an SDP		A file receiver that receives the above SDP offer creates an SDP
	answer according to the procedures of the SDP offer/answer (RFC 3264		answer according to the procedures of the SDP offer/answer (RFC 3264
	[RFC3264]). This SDP answer MUST conform with the requirements of		[RFC3264]). This SDP answer MUST conform with the requirements of
	Section 8.2.1. Then the file receiver sends this SDP answer to the		Section 8.3.1. Then the file receiver sends this SDP answer to the
	file sender.		file sender.
	File sender File receiver		File sender File receiver
	| |		| |
	|\ |		|\ |
	| \ |		| \ |
	| \ |		| \ |
	| \ |		| \ |
	| \ |		| \ |
	| \ |		| \ |
	skipping to change at page 22, line 39		skipping to change at page 23, line 29
	| MSRP 200 |		| MSRP 200 |
	|<-----------------------|		|<-----------------------|
	| re-INVITE (SDP offer) |		| re-INVITE (SDP offer) |
	|----------------------->|		|----------------------->|
	| SIP 200 OK (SDP answer)|		| SIP 200 OK (SDP answer)|
	|<-----------------------|		|<-----------------------|
	| SIP ACK |		| SIP ACK |
	|----------------------->|		|----------------------->|
	| |		| |
	Figure 3: File sender aborts an ongoing file transfer		Figure 4: File sender aborts an ongoing file transfer
	When the file receiver wants to abort the file transfer, there are		When the file receiver wants to abort the file transfer, there are
	two possible scenarios, depending on the value of the Failure-Report		two possible scenarios, depending on the value of the Failure-Report
	header in the ongoing MSRP SEND request. Assume now the scenario		header in the ongoing MSRP SEND request. Assume now the scenario
	depicted in Figure 4 where the MSRP SEND request includes a Failure-		depicted in Figure 5 where the MSRP SEND request includes a Failure-
	Report header set to a value different than "no". When the file		Report header set to a value different than "no". When the file
	receiver wishes to abort the ongoing file transfer, the file receiver		receiver wishes to abort the ongoing file transfer, the file receiver
	generates an MSRP 413 response to the current MSRP SEND request (see		generates an MSRP 413 response to the current MSRP SEND request (see
	Section 10.5 of RFC 4975 [RFC4975]). Then the file receiver MUST		Section 10.5 of RFC 4975 [RFC4975]). Then the file receiver MUST
	close the MSRP session by generating a new SDP offer that sets the		close the MSRP session by generating a new SDP offer that sets the
	port number to zero in the related "m=" line that describes the file		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		transfer (see Section 8.2 of RFC 3264 [RFC3264]). This SDP offer
	MUST conform with the requirements expressed in Section 8.1.2. The		MUST conform with the requirements expressed in Section 8.2.2. The
	'file-transfer-id' attribute MUST be the same that identifies the		'file-transfer-id' attribute MUST be the same that identifies the
	ongoing transfer. Then the file receiver sends this SDP offer to the		ongoing transfer. Then the file receiver sends this SDP offer to the
	file sender.		file sender.
	File sender File receiver		File sender File receiver
	| |		| |
	|\ |		|\ |
	| \ MSRP SEND |		| \ MSRP SEND |
	| \ Failure-Report: yes |		| \ Failure-Report: yes |
	| \ |		| \ |
	skipping to change at page 23, line 33		skipping to change at page 24, line 28
	| \ (#) |		| \ (#) |
	| +----------->|		| +----------->|
	| re-INVITE (SDP offer) |		| re-INVITE (SDP offer) |
	|<-----------------------|		|<-----------------------|
	| SIP 200 OK (SDP answer)|		| SIP 200 OK (SDP answer)|
	|----------------------->|		|----------------------->|
	| SIP ACK |		| SIP ACK |
	|<-----------------------|		|<-----------------------|
	| |		| |
	Figure 4: File receiver aborts an ongoing file transfer. Failure-		Figure 5: File receiver aborts an ongoing file transfer. Failure-
	Report set to a value different than "no" in MSRP		Report set to a value different than "no" in MSRP
	In another scenario, depicted in Figure 5, an ongoing file transfer		In another scenario, depicted in Figure 6, an ongoing file transfer
	is taking place, where the MSRP SEND request contains a Failure-		is taking place, where the MSRP SEND request contains a Failure-
	Report header set to the value "no". When the file receiver wants to		Report header set to the value "no". When the file receiver wants to
	abort the ongoing transfer, it MUST close MSRP session by generating		abort the ongoing transfer, it MUST close MSRP session by generating
	a new SDP offer that sets the port number to zero in the related "m="		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		line that describes the file transfer (see Section 8.2 of RFC 3264
	[RFC3264]). This SDP offer MUST conform with the requirements		[RFC3264]). This SDP offer MUST conform with the requirements
	expressed in Section 8.1.2. The 'file-transfer-id' attribute MUST be		expressed in Section 8.2.2. The 'file-transfer-id' attribute MUST be
	the same that identifies the ongoing transfer. Then the file		the same that identifies the ongoing transfer. Then the file
	receiver sends this SDP offer to the file sender.		receiver sends this SDP offer to the file sender.
	File sender File receiver		File sender File receiver
	| |		| |
	|\ |		|\ |
	| \ MSRP SEND |		| \ MSRP SEND |
	| \ Failure-Report: no |		| \ Failure-Report: no |
	| \ |		| \ |
	| \ |		| \ |
	skipping to change at page 24, line 28		skipping to change at page 25, line 28
	| \ (#) |		| \ (#) |
	| +----------->|		| +----------->|
	| MSRP 200 |		| MSRP 200 |
	|<-----------------------|		|<-----------------------|
	| SIP 200 OK (SDP answer)|		| SIP 200 OK (SDP answer)|
	|----------------------->|		|----------------------->|
	| SIP ACK |		| SIP ACK |
	|<-----------------------|		|<-----------------------|
	| |		| |
	Figure 5: File receiver aborts an ongoing file transfer. Failure-		Figure 6: File receiver aborts an ongoing file transfer. Failure-
	Report set to "no" in MSRP		Report set to "no" in MSRP
	A file sender that receives an SDP offer setting the port number to		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		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		MSRP SEND request is being transmitted, it aborts the MSRP message by
	including the '#' character in the continuation field of the end-line		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 a SEND request, according to the MSRP procedures (see Section 7.1
	of RFC 4975 [RFC4975]). Since a file is transmitted as one MSRP		of RFC 4975 [RFC4975]). Since a file is transmitted as one MSRP
	message, aborting the MSRP message effectively aborts the file		message, aborting the MSRP message effectively aborts the file
	transfer. Then the file sender creates an SDP answer according to		transfer. Then the file sender creates an SDP answer according to
	the procedures of the SDP offer/answer (RFC 3264 [RFC3264]). This		the procedures of the SDP offer/answer (RFC 3264 [RFC3264]). This
	SDP answer MUST conform with the requirements of Section 8.2.2. Then		SDP answer MUST conform with the requirements of Section 8.3.2. Then
	the file sender sends this SDP answer to the file receiver.		the file sender sends this SDP answer to the file receiver.
	8.5. Indicating File Transfer Offer/Answer Capability		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 capability query. As such,		that is included in the response to such capability query. As such,
	skipping to change at page 25, line 28		skipping to change at page 26, line 28
	[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		existing "m=" line to start the file transfer of another file creates
	a different 'file-selector' attribute and selects a new globally		a different 'file-selector' attribute and selects a new globally
	unique random value of the '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 octet (if a 'file-range' attribute is
	present).		present).
	8.7. 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
	in SDP to describe the unidirectional transfer of a file.		in SDP to describe the unidirectional transfer of a file.
	Consequently, each MSRP session established following the procedures		Consequently, each MSRP session established following the procedures
	in Section 8.1 and Section 8.2 is only used to transfer a single		in Section 8.2 and Section 8.3 is only used to transfer a single
	file. So, senders MUST only use the dedicated MSRP session to send		file. So, senders MUST only use the dedicated MSRP session to send
	the file described in the SDP offer or answer. That is, senders MUST		the file described in the SDP offer or answer. That is, senders MUST
	NOT send additional files over the same MSRP session.		NOT send 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
	established for the purpose. Alternatively a file transfer may be		established for the purpose. Alternatively a file transfer may be
	conducted within an existing multimedia session, without regard for		conducted within an existing multimedia session, without regard for
	the media in use within that session. Of particular note, file		the media in use within that session. Of particular note, file
	transfer may be done within a multimedia session containing an MSRP		transfer may be done within a multimedia session containing an MSRP
	session used for regular instant messaging. If file transfer is		session used for regular instant messaging. If file transfer is
	skipping to change at page 26, line 29		skipping to change at page 27, line 29
	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 octet of the file and end with the
	last byte (i.e., the whole file is transferred). If a 'file-range'		last octet (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 octets from the file (start and stop offset
	bytes). Then the file sender application MAY wrap those bytes in an		octets, both inclusive). Then the file sender application MAY wrap
	appropriate wrapper. MSRP mandates implementations to implement the		those octets in an appropriate wrapper. MSRP mandates
	message/cpim wrapper [RFC3862]. Usage of a wrapper is negotiated in		implementations to implement the message/cpim wrapper [RFC3862].
	the SDP (see Section 8.6 in RFC 4975 [RFC4975]). Last, the file		Usage of a wrapper is negotiated in the SDP (see Section 8.6 in RFC
	sender application delivers the content (e.g., the message/cpim body)		4975 [RFC4975]). Last, the file sender application delivers the
	to MSRP for transportation. MSRP will consider the delivered content		content (e.g., the message/cpim body) to MSRP for transportation.
	as a whole message, and will start numbering bytes with the number 1.		MSRP will consider the delivered content 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 to closing MSRP sessions. Note that MSRP		procedures with respect to closing MSRP sessions. Note that MSRP
	session management is not related to TCP connection management. As a		session management is not related to TCP connection management. As a
	skipping to change at page 27, line 35		skipping to change at page 28, line 35
	that includes an SDP body part and an icon body part. The file		that includes an SDP body part and an icon body part. The file
	receiver, not supporting multipart MIME types, will reject the SDP		receiver, not supporting multipart MIME types, will reject the SDP
	offer via a higher protocol mechanism (e.g., SIP). In this case, it		offer via a higher protocol mechanism (e.g., SIP). In this case, it
	is RECOMMENDED that the file sender removes the icon body part,		is RECOMMENDED that the file sender removes the icon body part,
	creates a single SDP body (i.e., without multipart MIME) and re-sends		creates a single SDP body (i.e., without multipart MIME) and re-sends
	the SDP offer again. This provides some backwards compatibility with		the SDP offer again. This provides some backwards compatibility with
	file receives that do not implement this specification and increases		file receives that do not implement this specification and increases
	the chances of getting the SDP accepted at the file receiver.		the chances of getting the SDP accepted at the file receiver.
	Since the icon is sent as part of the signaling, it is RECOMMENDED to		Since the icon is sent as part of the signaling, it is RECOMMENDED to
	keep the size of icons restricted to the minimum number of bytes that		keep the size of icons restricted to the minimum number of octets
	provide significance.		that provide significance.
	9. Examples		9. Examples
	9.1. Offerer sends a file to the Answerer		9.1. Offerer sends a file to the Answerer
	This section shows an example flow for a file transfer scenario. The		This section shows an example flow for a file transfer scenario. The
	example assumes that SIP [RFC3261] is used to transport the SDP		example assumes that SIP [RFC3261] is used to transport the SDP
	offer/answer exchange, although the SIP details are briefly shown for		offer/answer exchange, although the SIP details are briefly shown for
	the sake of brevity.		the sake of brevity.
	Alice, the SDP offerer, wishes to send an image file to Bob (the		Alice, the SDP offerer, wishes to send an image file to Bob (the
	answerer). Alice's User Agent Client (UAC) creates a unidirectional		answerer). Alice's User Agent Client (UAC) creates a unidirectional
	SDP offer that contains the description of the file that she wants to		SDP offer that contains the description of the file that she wants to
	send to Bob's User Agent Server (UAS). The description also includes		send to Bob's User Agent Server (UAS). The description also includes
	an icon representing the contents of the file to be transferred. The		an icon representing the contents of the file to be transferred. The
	sequence flow is shown in Figure 6.		sequence flow is shown in Figure 7.
	Alice's UAC Bob's UAS		Alice's UAC Bob's UAS
	| |		| |
	|(1) (SIP) INVITE |		|(1) (SIP) INVITE |
	|----------------------->|		|----------------------->|
	|(2) (SIP) 200 OK |		|(2) (SIP) 200 OK |
	|<-----------------------|		|<-----------------------|
	|(3) (SIP) ACK |		|(3) (SIP) ACK |
	|----------------------->|		|----------------------->|
	| |		| |
	skipping to change at page 28, line 31		skipping to change at page 29, line 31
	|(7) (MSRP) 200 OK |		|(7) (MSRP) 200 OK |
	|<-----------------------|		|<-----------------------|
	| |		| |
	|(8) (SIP) BYE |		|(8) (SIP) BYE |
	|----------------------->|		|----------------------->|
	|(9) (SIP) 200 OK |		|(9) (SIP) 200 OK |
	|<-----------------------|		|<-----------------------|
	| |		| |
	| |		| |
	Figure 6: Flow diagram of an offerer sending a file to an answerer		Figure 7: Flow diagram of an offerer sending a file to an answerer
	F1: Alice constructs an SDP description of the file to be sent and		F1: Alice constructs an SDP description of the file to be sent and
	attaches it to a SIP INVITE request addressed to Bob.		attaches it to a SIP INVITE request addressed to Bob.
	INVITE sip:bob@example.com SIP/2.0		INVITE sip:bob@example.com SIP/2.0
	To: Bob <sip:bob@example.com>		To: Bob <sip:bob@example.com>
	From: Alice <sip:alice@example.com>;tag=1928301774		From: Alice <sip:alice@example.com>;tag=1928301774
	Call-ID: a84b4c76e66710		Call-ID: a84b4c76e66710
	CSeq: 1 INVITE		CSeq: 1 INVITE
	Max-Forwards: 70		Max-Forwards: 70
	skipping to change at page 29, line 51		skipping to change at page 30, line 51
	Content-Type: image/jpeg		Content-Type: image/jpeg
	Content-Transfer-Encoding: binary		Content-Transfer-Encoding: binary
	Content-ID: <id2@alicepc.example.com>		Content-ID: <id2@alicepc.example.com>
	Content-Length: [length of image]		Content-Length: [length of image]
	Content-Disposition: icon		Content-Disposition: icon
	[...small preview icon of the file...]		[...small preview icon of the file...]
	--boundary71--		--boundary71--
	Figure 7: INVITE request containing an SDP offer for file transfer		Figure 8: INVITE request containing an SDP offer for file transfer
	NOTE: The Content-Type header field and the 'file-selector'		NOTE: The Content-Type header field and the 'file-selector'
	attribute in the above figure are split in several lines for		attribute in the above figure are split in several lines for
	formatting purposes. Real implementations will encode it in a		formatting purposes. Real implementations will encode it in a
	single line.		single line.
	From now on we omit the SIP details for the sake of brevity.		From now on we omit the SIP details for the sake of brevity.
	F2: Bob receives the INVITE request, inspects the SDP offer and		F2: Bob receives the INVITE request, inspects the SDP offer and
	extracts the icon body, checks the creation date and file size, and		extracts the icon body, checks the creation date and file size, and
	decides to accept the file transfer. So Bob creates the following		decides to accept the file transfer. So Bob creates the following
	skipping to change at page 30, line 31		skipping to change at page 31, line 31
	m=message 8888 TCP/MSRP *		m=message 8888 TCP/MSRP *
	a=recvonly		a=recvonly
	a=accept-types:message/cpim		a=accept-types:message/cpim
	a=accept-wrapped-types:*		a=accept-wrapped-types:*
	a=path:msrp://bobpc.example.com:8888/9di4ea;tcp		a=path:msrp://bobpc.example.com:8888/9di4ea;tcp
	a=file-selector:name:"My cool picture.jpg" type:image/jpeg		a=file-selector:name:"My cool picture.jpg" type:image/jpeg
	size:4092 hash:sha-1:		size:4092 hash:sha-1:
	72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E		72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E
	a=file-transfer-id:Q6LMoGymJdh0IKIgD6wD0jkcfgva4xvE		a=file-transfer-id:Q6LMoGymJdh0IKIgD6wD0jkcfgva4xvE
	Figure 8: SDP answer accepting the SDP offer for file transfer		Figure 9: SDP answer accepting the SDP offer for file transfer
	NOTE: The 'file-selector' attribute in the above figure is split		NOTE: The 'file-selector' attribute in the above figure is split
	in three lines for formatting purposes. Real implementations will		in three lines for formatting purposes. Real implementations will
	encode it in a single line.		encode it in a single line.
	F4: Alice opens a TCP connection to Bob and creates an MSRP SEND		F4: Alice opens a TCP connection to Bob and creates an MSRP SEND
	request. This SEND request contains the first chunk of the file.		request. This SEND request contains the first chunk of the file.
	MSRP d93kswow SEND		MSRP d93kswow SEND
	To-Path: msrp://bobpc.example.com:8888/9di4ea;tcp		To-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
	skipping to change at page 31, line 23		skipping to change at page 32, line 23
	From: Alice <sip:alice@example.com>		From: Alice <sip:alice@example.com>
	DateTime: 2006-05-15T15:02:31-03:00		DateTime: 2006-05-15T15:02:31-03:00
	Content-Disposition: render; filename="My cool picture.jpg";		Content-Disposition: render; filename="My cool picture.jpg";
	creation-date="Mon, 15 May 2006 15:01:31 +0300";		creation-date="Mon, 15 May 2006 15:01:31 +0300";
	size=4092		size=4092
	Content-Type: image/jpeg		Content-Type: image/jpeg
	... first set of bytes of the JPEG image ...		... first set of bytes of the JPEG image ...
	-------d93kswow+		-------d93kswow+
	Figure 9: MSRP SEND request containing the first chunk of actual file		Figure 10: MSRP SEND request containing the first chunk of actual
			file
	F5: Alice sends the second and last chunk. Note that MSRP allows to		F5: Alice sends the second and last chunk. Note that MSRP allows to
	send pipelined chunks, so there is no need to wait for the 200 (OK)		send pipelined chunks, so there is no need to wait for the 200 (OK)
	response from the previous chunk.		response from the previous chunk.
	MSRP op2nc9a SEND		MSRP op2nc9a SEND
	To-Path: msrp://bobpc.example.com:8888/9di4ea;tcp		To-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
	From-Path: msrp://alicepc.example.com:7654/iau39;tcp		From-Path: msrp://alicepc.example.com:7654/iau39;tcp
	Message-ID: 12339sdqwer		Message-ID: 12339sdqwer
	Byte-Range: 2049-4385/4385		Byte-Range: 2049-4385/4385
	Content-Type: message/cpim		Content-Type: message/cpim
	... second set of bytes of the JPEG image ...		... second set of bytes of the JPEG image ...
	-------op2nc9a$		-------op2nc9a$
	Figure 10: MSRP SEND request containing the second chunk of actual		Figure 11: MSRP SEND request containing the second chunk of actual
	file		file
	F6: Bob acknowledges the reception of the first chunk.		F6: Bob acknowledges the reception of the first chunk.
	MSRP d93kswow 200 OK		MSRP d93kswow 200 OK
	To-Path: msrp://alicepc.example.com:7654/iau39;tcp		To-Path: msrp://alicepc.example.com:7654/iau39;tcp
	From-Path: msrp://bobpc.example.com:8888/9di4ea;tcp		From-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
	Byte-Range: 1-2048/4385		Byte-Range: 1-2048/4385
	-------d93kswow$		-------d93kswow$
	Figure 11: MSRP 200 OK response		Figure 12: MSRP 200 OK response
	F7: Bob acknowledges the reception of the second chunk.		F7: Bob acknowledges the reception of the second chunk.
	MSRP op2nc9a 200 OK		MSRP op2nc9a 200 OK
	To-Path: msrp://alicepc.example.com:7654/iau39;tcp		To-Path: msrp://alicepc.example.com:7654/iau39;tcp
	From-Path: msrp://bobpc.example.com:8888/9di4ea;tcp		From-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
	Byte-Range: 2049-4385/4385		Byte-Range: 2049-4385/4385
	-------op2nc9a$		-------op2nc9a$
	Figure 12: MSRP 200 OK response		Figure 13: MSRP 200 OK response
	F8: Alice terminates the SIP session by sending a SIP BYE request.		F8: Alice terminates the SIP session by sending a SIP BYE request.
	F9: Bob acknowledges the reception of the BYE request and sends a 200		F9: Bob acknowledges the reception of the BYE request and sends a 200
	(OK) response.		(OK) response.
	9.2. Offerer requests a file from the Answerer and second file transfer		9.2. Offerer requests a file from the Answerer and second file transfer
	In this example Alice, the SDP offerer, first wishes to fetch a file		In this example Alice, the SDP offerer, first wishes to fetch a file
	from Bob, the SDP answerer. Alice knows that Bob has a specific file		from Bob, the SDP answerer. Alice knows that Bob has a specific file
	she wants to download. She has learned the hash of the file by some		she wants to download. She has learned the hash of the file by some
	out-of-band mechanism. The hash selector is enough to produce a file		out-of-band mechanism. The hash selector is enough to produce a file
	selector that points to the specific file. So, Alice creates an SDP		selector that points to the specific file. So, Alice creates an SDP
	offer that contains the file descriptor. Bob accepts the file		offer that contains the file descriptor. Bob accepts the file
	transfer and sends the file to Alice. When Alice has completely		transfer and sends the file to Alice. When Alice has completely
	received Bob's file, she intends to send a new image file to Bob.		received Bob's file, she intends to send a new image file to Bob.
	Therefore Alice re-uses the existing SDP media line with different		Therefore Alice re-uses the existing SDP media line with different
	attributes and updates the description of the new file she wants to		attributes and updates the description of the new file she wants to
	send to Bob's User Agent Server (UAS). In particular, Alice creates		send to Bob's User Agent Server (UAS). In particular, Alice creates
	a new file transfer identifier since this is a new file transfer		a new file transfer identifier since this is a new file transfer
	operation. Figure 13 shows the sequence flow.		operation. Figure 14 shows the sequence flow.
	Alice's UAC Bob's UAS		Alice's UAC Bob's UAS
	| |		| |
	|(1) (SIP) INVITE |		|(1) (SIP) INVITE |
	|----------------------->|		|----------------------->|
	|(2) (SIP) 200 OK |		|(2) (SIP) 200 OK |
	|<-----------------------|		|<-----------------------|
	|(3) (SIP) ACK |		|(3) (SIP) ACK |
	|----------------------->|		|----------------------->|
	| |		| |
	skipping to change at page 33, line 38		skipping to change at page 34, line 38
	|(10) (MSRP) 200 OK |		|(10) (MSRP) 200 OK |
	|<-----------------------|		|<-----------------------|
	| |		| |
	|(11) (SIP) BYE |		|(11) (SIP) BYE |
	|<-----------------------|		|<-----------------------|
	|(12) (SIP) 200 OK |		|(12) (SIP) 200 OK |
	|----------------------->|		|----------------------->|
	| |		| |
	| |		| |
	Figure 13: Flow diagram of an offerer requesting a file from the		Figure 14: Flow diagram of an offerer requesting a file from the
	answerer and then sending a file to the answer		answerer and then sending a file to the answer
	F1: Alice constructs an SDP description of the file she wants to		F1: Alice constructs an SDP description of the file she wants to
	receive and attaches the SDP offer to a SIP INVITE request addressed		receive and attaches the SDP offer to a SIP INVITE request addressed
	to Bob.		to Bob.
	INVITE sip:bob@example.com SIP/2.0		INVITE sip:bob@example.com SIP/2.0
	To: Bob <sip:bob@example.com>		To: Bob <sip:bob@example.com>
	From: Alice <sip:alice@example.com>;tag=1928301774		From: Alice <sip:alice@example.com>;tag=1928301774
	Call-ID: a84b4c76e66710		Call-ID: a84b4c76e66710
	skipping to change at page 34, line 30		skipping to change at page 35, line 30
	t=0 0		t=0 0
	m=message 7654 TCP/MSRP *		m=message 7654 TCP/MSRP *
	a=recvonly		a=recvonly
	a=accept-types:message/cpim		a=accept-types:message/cpim
	a=accept-wrapped-types:*		a=accept-wrapped-types:*
	a=path:msrp://alicepc.example.com:7654/jshA7we;tcp		a=path:msrp://alicepc.example.com:7654/jshA7we;tcp
	a=file-selector:hash:sha-1:		a=file-selector:hash:sha-1:
	72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E		72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E
	a=file-transfer-id:aCQYuBRVoUPGVsFZkCK98vzcX2FXDIk2		a=file-transfer-id:aCQYuBRVoUPGVsFZkCK98vzcX2FXDIk2
	Figure 14: INVITE request containing an SDP offer for file transfer		Figure 15: INVITE request containing an SDP offer for file transfer
	NOTE: The 'file-selector' attribute in the above figure is split		NOTE: The 'file-selector' attribute in the above figure is split
	in two lines for formatting purposes. Real implementations will		in two lines for formatting purposes. Real implementations will
	encode it in a single line.		encode it in a single line.
	From now on we omit the SIP details for the sake of brevity.		From now on we omit the SIP details for the sake of brevity.
	F2: Bob receives the INVITE request, inspects the SDP offer, computes		F2: Bob receives the INVITE request, inspects the SDP offer, computes
	the file descriptor and finds a local file whose hash equals the one		the file descriptor and finds a local file whose hash equals the one
	indicated in the SDP. Bob accepts the file transfer and creates an		indicated in the SDP. Bob accepts the file transfer and creates an
	skipping to change at page 35, line 19		skipping to change at page 36, line 19
	t=0 0		t=0 0
	m=message 8888 TCP/MSRP *		m=message 8888 TCP/MSRP *
	a=sendonly		a=sendonly
	a=accept-types:message/cpim		a=accept-types:message/cpim
	a=accept-wrapped-types:*		a=accept-wrapped-types:*
	a=path:msrp://bobpc.example.com:8888/9di4ea;tcp		a=path:msrp://bobpc.example.com:8888/9di4ea;tcp
	a=file-selector:type:image/jpeg hash:sha-1:		a=file-selector:type:image/jpeg hash:sha-1:
	72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E		72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E
	a=file-transfer-id:aCQYuBRVoUPGVsFZkCK98vzcX2FXDIk2		a=file-transfer-id:aCQYuBRVoUPGVsFZkCK98vzcX2FXDIk2
	Figure 15: SDP answer accepting the SDP offer for file transfer		Figure 16: SDP answer accepting the SDP offer for file transfer
	NOTE: The 'file-selector' attribute in the above figure is split		NOTE: The 'file-selector' attribute in the above figure is split
	in two lines for formatting purposes. Real implementations will		in two lines for formatting purposes. Real implementations will
	encode it in a single line.		encode it in a single line.
	F4: Alice opens a TCP connection to Bob. Bob then creates an MSRP		F4: Alice opens a TCP connection to Bob. Bob then creates an MSRP
	SEND request that contains the file.		SEND request that contains the file.
	MSRP d93kswow SEND		MSRP d93kswow SEND
	To-Path: msrp://alicepc.example.com:7654/jshA7we;tcp		To-Path: msrp://alicepc.example.com:7654/jshA7we;tcp
	skipping to change at page 35, line 48		skipping to change at page 36, line 48
	Content-Disposition: render; filename="My cool photo.jpg";		Content-Disposition: render; filename="My cool photo.jpg";
	creation-date="Mon, 15 May 2006 15:01:31 +0300";		creation-date="Mon, 15 May 2006 15:01:31 +0300";
	modification-date="Mon, 15 May 2006 16:04:53 +0300";		modification-date="Mon, 15 May 2006 16:04:53 +0300";
	read-date="Mon, 16 May 2006 09:12:27 +0300";		read-date="Mon, 16 May 2006 09:12:27 +0300";
	size=1931		size=1931
	Content-Type: image/jpeg		Content-Type: image/jpeg
	...binary JPEG image...		...binary JPEG image...
	-------d93kswow$		-------d93kswow$
	Figure 16: MSRP SEND request containing the actual file		Figure 17: MSRP SEND request containing the actual file
	F5: Alice acknowledges the reception of the SEND request.		F5: Alice acknowledges the reception of the SEND request.
	MSRP d93kswow 200 OK		MSRP d93kswow 200 OK
	To-Path: msrp://bobpc.example.com:8888/9di4ea;tcp		To-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
	From-Path: msrp://alicepc.example.com:7654/jshA7we;tcp		From-Path: msrp://alicepc.example.com:7654/jshA7we;tcp
	Byte-Range: 1-2027/2027		Byte-Range: 1-2027/2027
	-------d93kswow$		-------d93kswow$
	Figure 17: MSRP 200 OK response		Figure 18: MSRP 200 OK response
	F6: Alice re-uses the existing SDP media line inserting the		F6: Alice re-uses the existing SDP media line inserting the
	description of the file to be sent and attaches it to a SIP re-INVITE		description of the file to be sent and attaches it to a SIP re-INVITE
	request addressed to Bob. Alice reuses the TCP port number for the		request addressed to Bob. Alice reuses the TCP port number for the
	MSRP stream, but changes the MSRP session and the 'file-transfer-id'		MSRP stream, but changes the MSRP session and the 'file-transfer-id'
	value according to this specification.		value according to this specification.
	INVITE sip:bob@example.com SIP/2.0		INVITE sip:bob@example.com SIP/2.0
	To: Bob <sip:bob@example.com>;tag=1928323431		To: Bob <sip:bob@example.com>;tag=1928323431
	From: Alice <sip:alice@example.com>;tag=1928301774		From: Alice <sip:alice@example.com>;tag=1928301774
	skipping to change at page 37, line 51		skipping to change at page 38, line 51
	Content-Type: image/jpeg		Content-Type: image/jpeg
	Content-Transfer-Encoding: binary		Content-Transfer-Encoding: binary
	Content-ID: <id3@alicepc.example.com>		Content-ID: <id3@alicepc.example.com>
	Content-Length: [length of image]		Content-Length: [length of image]
	Content-Disposition: icon		Content-Disposition: icon
	[..small preview icon...]		[..small preview icon...]
	--boundary71--		--boundary71--
	Figure 18: Reuse of the SDP in a second file transfer		Figure 19: Reuse of the SDP in a second file transfer
	NOTE: The Content-Type header field and the 'file-selector'		NOTE: The Content-Type header field and the 'file-selector'
	attribute in the above figure are split in several lines for		attribute in the above figure are split in several lines for
	formatting purposes. Real implementations will encode it in a		formatting purposes. Real implementations will encode it in a
	single line.		single line.
	F7: Bob receives the re-INVITE request, inspects the SDP offer and		F7: Bob receives the re-INVITE request, inspects the SDP offer and
	extracts the icon body, checks the creation date and the file size,		extracts the icon body, checks the creation date and the file size,
	and decides to accept the file transfer. So Bob creates an SDP		and decides to accept the file transfer. So Bob creates an SDP
	answer where he reuses the same TCP port number, but changes his MSRP		answer where he reuses the same TCP port number, but changes his MSRP
	session, according to the procedures of this specification.		session, according to the procedures of this specification.
	skipping to change at page 38, line 31		skipping to change at page 39, line 31
	a=recvonly		a=recvonly
	a=accept-types:message/cpim		a=accept-types:message/cpim
	a=accept-wrapped-types:*		a=accept-wrapped-types:*
	a=path:msrp://bobpc.example.com:8888/eh10dsk;tcp		a=path:msrp://bobpc.example.com:8888/eh10dsk;tcp
	a=file-selector:name:"sunset.jpg" type:image/jpeg		a=file-selector:name:"sunset.jpg" type:image/jpeg
	size:4096 hash:sha-1:		size:4096 hash:sha-1:
	58:23:1F:E8:65:3B:BC:F3:71:36:2F:86:D4:71:91:3E:E4:B1:DF:2F		58:23:1F:E8:65:3B:BC:F3:71:36:2F:86:D4:71:91:3E:E4:B1:DF:2F
	a=file-transfer-id:ZVE8MfI9mhAdZ8GyiNMzNN5dpqgzQlCO		a=file-transfer-id:ZVE8MfI9mhAdZ8GyiNMzNN5dpqgzQlCO
	a=file-disposition:render		a=file-disposition:render
	Figure 19: SDP answer accepting the SDP offer for file transfer		Figure 20: SDP answer accepting the SDP offer for file transfer
	NOTE: The 'file-selector' attribute in the above figure is split		NOTE: The 'file-selector' attribute in the above figure is split
	in three lines for formatting purposes. Real implementations will		in three lines for formatting purposes. Real implementations will
	encode it in a single line.		encode it in a single line.
	F9: If a TCP connection towards Bob is already open, Alice re-uses		F9: If a TCP connection towards Bob is already open, Alice re-uses
	that TCP connection to send an MSRP SEND request that contains the		that TCP connection to send an MSRP SEND request that contains the
	file.		file.
	MSRP d95ksxox SEND		MSRP d95ksxox SEND
	skipping to change at page 39, line 23		skipping to change at page 40, line 23
	From: Alice <sip:alice@example.com>		From: Alice <sip:alice@example.com>
	DateTime: 2006-05-21T13:02:15-03:00		DateTime: 2006-05-21T13:02:15-03:00
	Content-Disposition: render; filename="Sunset.jpg";		Content-Disposition: render; filename="Sunset.jpg";
	creation-date="Sun, 21 May 2006 13:02:15 -0300";		creation-date="Sun, 21 May 2006 13:02:15 -0300";
	size=1931		size=1931
	Content-Type: image/jpeg		Content-Type: image/jpeg
	...binary JPEG image...		...binary JPEG image...
	-------d95ksxox+		-------d95ksxox+
	Figure 20: MSRP SEND request containing the actual file		Figure 21: MSRP SEND request containing the actual file
	F10: Bob acknowledges the reception of the SEND request.		F10: Bob acknowledges the reception of the SEND request.
	MSRP d95ksxox 200 OK		MSRP d95ksxox 200 OK
	To-Path: msrp://alicepc.example.com:7654/iau39;tcp		To-Path: msrp://alicepc.example.com:7654/iau39;tcp
	From-Path: msrp://bobpc.example.com:8888/eh10dsk;tcp		From-Path: msrp://bobpc.example.com:8888/eh10dsk;tcp
	Byte-Range: 1-2027/2027		Byte-Range: 1-2027/2027
	-------d95ksxox$		-------d95ksxox$
	Figure 21: MSRP 200 OK response		Figure 22: MSRP 200 OK response
	F11: Then Bob terminates the SIP session by sending a SIP BYE		F11: Then Bob terminates the SIP session by sending a SIP BYE
	request.		request.
	F12: Alice acknowledges the reception of the BYE request and sends a		F12: Alice acknowledges the reception of the BYE request and sends a
	200 (OK) response.		200 (OK) response.
	9.3. Example of a capability indication		9.3. Example of a capability indication
	Alice sends an OPTIONS request to Bob (this request does not contain		Alice sends an OPTIONS request to Bob (this request does not contain
	SDP). Bob answers with a 200 (OK) response that contain the SDP		SDP). Bob answers with a 200 (OK) response that contain the SDP
	shown in Figure 23. The SDP indicates support for CPIM messages that		shown in Figure 24. The SDP indicates support for CPIM messages that
	can contain other MIME types. The maximum MSRP message size that the		can contain other MIME types. The maximum MSRP message size that the
	endpoint can receive is 20000 octets. The presence of the 'file-		endpoint can receive is 20000 octets. The presence of the 'file-
	selector' attribute indicates support for the file transfer offer/		selector' attribute indicates support for the file transfer offer/
	answer mechanism.		answer mechanism.
	Alice's UAC Bob's UAS		Alice's UAC Bob's UAS
	| |		| |
	|(1) (SIP) OPTIONS |		|(1) (SIP) OPTIONS |
	|----------------------->|		|----------------------->|
	|(2) (SIP) 200 OK |		|(2) (SIP) 200 OK |
	| with SDP |		| with SDP |
	|<-----------------------|		|<-----------------------|
	| |		| |
	| |		| |
	Figure 22: Flow diagram of a capability request		Figure 23: Flow diagram of a capability request
	v=0		v=0
	o=bob 2890844656 2890855439 IN IP4 bobpc.example.com		o=bob 2890844656 2890855439 IN IP4 bobpc.example.com
	s=-		s=-
	c=IN IP4 bobpc.example.com		c=IN IP4 bobpc.example.com
	t=0 0		t=0 0
	m=message 0 TCP/MSRP *		m=message 0 TCP/MSRP *
	a=accept-types:message/cpim		a=accept-types:message/cpim
	a=accept-wrapped-types:*		a=accept-wrapped-types:*
	a=max-size:20000		a=max-size:20000
	a=file-selector		a=file-selector
	Figure 23: SDP of the 200 (OK) response to an OPTIONS request		Figure 24: SDP of the 200 (OK) response to an OPTIONS request
	10. Security Considerations		10. Security Considerations
	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
	skipping to change at page 41, line 14		skipping to change at page 42, line 14
	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 measurements to		It is also RECOMMENDED that implementations take measures to avoid
	avoid attacks on resource exhaustion, for example, by limiting the		attacks on resource exhaustion, for example, by limiting the size of
	size of received files, verifying that there is enough space in the		received files, verifying that there is enough space in the file
	file system to store the file prior to its reception, or limiting the		system to store the file prior to its reception, or limiting the
	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 of		Once a file has been transferred the file receiver must take care of
	it. Typically file transfer is a commonly used mechanism for		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.
	skipping to change at page 41, line 49		skipping to change at page 42, line 49
	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
	registry [4]. The registration data, according to RFC 4566 [RFC4566]		registry [4]. The registration data, according to RFC 4566 [RFC4566]
	follows.		follows.
	Note to the RFC Editor: replace "RFC XXXX" with the RFC number of		Note to the RFC Editor: replace "RFC XXXX" with the RFC number of
	this specification.		this specification.
	11.1.1. Registration of the file-selector attribute		11.1.1. Registration of the file-selector attribute
	Contact: Miguel Garcia <miguel.garcia@nsn.com>		Contact: Miguel Garcia <miguel.a.garcia@ericsson.com>
	Phone: +358 71400 4000		Phone: +34 91 339 1000
	Attribute name: file-selector		Attribute name: file-selector
	Long-form attribute name: File Selector		Long-form attribute name: File Selector
	Type of attribute: media level only		Type of attribute: media level only
	This attribute is subject to the charset attribute		This attribute is subject to the charset attribute
	Description: This attribute unambiguously identify a file by		Description: This attribute unambiguously identify a file by
	indicating a combination of the 4-tuple composed of the name,		indicating a combination of the 4-tuple composed of the name,
	size, type, and hash of the file.		size, type, and hash of the file.
	Specification: RFC XXXX		Specification: RFC XXXX
	11.1.2. Registration of the file-transfer-id attribute		11.1.2. Registration of the file-transfer-id attribute
	Contact: Miguel Garcia <miguel.garcia@nsn.com>		Contact: Miguel Garcia <miguel.a.garcia@ericsson.com>
	Phone: +358 71400 4000		Phone: +34 91 339 1000
	Attribute name: file-transfer-id		Attribute name: file-transfer-id
	Long-form attribute name: File Transfer Identifier		Long-form attribute name: File Transfer Identifier
	Type of attribute: media level only		Type of attribute: media level only
	This attribute is subject to the charset attribute		This attribute is subject to the charset attribute
	Description: This attribute contains a unique identifier of the		Description: This attribute contains a unique identifier of the
	file transfer operation within the session.		file transfer operation within the session.
	Specification: RFC XXXX		Specification: RFC XXXX
	11.1.3. Registration of the file-disposition attribute		11.1.3. Registration of the file-disposition attribute
	Contact: Miguel Garcia <miguel.garcia@nsn.com>		Contact: Miguel Garcia <miguel.a.garcia@ericsson.com>
	Phone: +358 71400 4000		Phone: +34 91 339 1000
	Attribute name: file-disposition		Attribute name: file-disposition
	Long-form attribute name: File Disposition		Long-form attribute name: File Disposition
	Type of attribute: media level only		Type of attribute: media level only
	This attribute is not subject to the charset attribute		This attribute is not subject to the charset attribute
	Description: This attribute provides a suggestion to the other		Description: This attribute provides a suggestion to the other
	endpoint about the intended disposition of the file		endpoint about the intended disposition of the file
	Specification: RFC XXXX		Specification: RFC XXXX
	11.1.4. Registration of the file-date attribute		11.1.4. Registration of the file-date attribute
	Contact: Miguel Garcia <miguel.garcia@nsn.com>		Contact: Miguel Garcia <miguel.a.garcia@ericsson.com>
	Phone: +358 71400 4000		Phone: +34 91 339 1000
	Attribute name: file-date		Attribute name: file-date
	Long-form attribute name:		Long-form attribute name:
	Type of attribute: media level only		Type of attribute: media level only
	This attribute is not subject to the charset attribute		This attribute is not subject to the charset attribute
	Description: This attribute indicates the dates at which the file		Description: This attribute indicates the dates at which the file
	was created, modified, or last read.		was created, modified, or last read.
	Specification: RFC XXXX		Specification: RFC XXXX
	11.1.5. Registration of the file-icon attribute		11.1.5. Registration of the file-icon attribute
	Contact: Miguel Garcia <miguel.garcia@nsn.com>		Contact: Miguel Garcia <miguel.a.garcia@ericsson.com>
	Phone: +358 71400 4000		Phone: +34 91 339 1000
	Attribute name: file-icon		Attribute name: file-icon
	Long-form attribute name: File Icon		Long-form attribute name: File Icon
	Type of attribute: media level only		Type of attribute: media level only
	This attribute is not subject to the charset attribute		This attribute is not subject to the charset attribute
	Description: For image files, this attribute contains a pointer to		Description: For image files, this attribute contains a pointer to
	a body that includes a small preview icon representing the		a body that includes a small preview icon representing the
	contents of the file to be transferred		contents of the file to be transferred
	Specification: RFC XXXX		Specification: RFC XXXX
	11.1.6. Registration of the file-range attribute		11.1.6. Registration of the file-range attribute
	Contact: Miguel Garcia <miguel.garcia@nsn.com>		Contact: Miguel Garcia <miguel.a.garcia@ericsson.com>
	Phone: +358 71400 4000		Phone: +34 91 339 1000
	Attribute name: file-range		Attribute name: file-range
	Long-form attribute name: File Range		Long-form attribute name: File Range
	Type of attribute: media level only		Type of attribute: media level only
	This attribute is not subject to the charset attribute		This attribute is not subject to the charset attribute
	Description: it contains the range of transferred bytes of the		Description: it contains the range of transferred octets of the
	file		file
	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-
	skipping to change at page 44, line 15		skipping to change at page 45, line 15
	[RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating		[RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating
	Presentation Information in Internet Messages: The		Presentation Information in Internet Messages: The
	Content-Disposition Header Field", RFC 2183, August 1997.		Content-Disposition Header Field", RFC 2183, August 1997.
	[RFC2387] Levinson, E., "The MIME Multipart/Related Content-type",		[RFC2387] Levinson, E., "The MIME Multipart/Related Content-type",
	RFC 2387, August 1998.		RFC 2387, August 1998.
	[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource		[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource
	Locators", RFC 2392, August 1998.		Locators", RFC 2392, August 1998.
	[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
	April 2001.
	[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1		[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
	(SHA1)", RFC 3174, September 2001.		(SHA1)", RFC 3174, September 2001.
	[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model		[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
	with Session Description Protocol (SDP)", RFC 3264,		with Session Description Protocol (SDP)", RFC 3264,
	June 2002.		June 2002.
	[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.
	skipping to change at page 44, line 44		skipping to change at page 45, line 41
	[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		[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234, January 2008.		Specifications: ABNF", STD 68, RFC 5234, January 2008.
			[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
			October 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.
	[RFC4483] Burger, E., "A Mechanism for Content Indirection in		[RFC4483] Burger, E., "A Mechanism for Content Indirection in
	Session Initiation Protocol (SIP) Messages", RFC 4483,		Session Initiation Protocol (SIP) Messages", RFC 4483,
	May 2006.		May 2006.
	[RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions		[RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions
	for the Message Sessions Relay Protocol (MSRP)", RFC 4976,		for the Message Sessions Relay Protocol (MSRP)", RFC 4976,
	September 2007.		September 2007.
	[I-D.ietf-rmt-flute-revised]		[I-D.ietf-rmt-flute-revised]
	Paila, T., "FLUTE - File Delivery over Unidirectional		Luby, M., Lehtonen, R., Roca, V., and T. Paila, "FLUTE -
	Transport", draft-ietf-rmt-flute-revised-05 (work in		File Delivery over Unidirectional Transport",
	progress), October 2007.		draft-ietf-rmt-flute-revised-06 (work in progress),
			September 2008.
	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>
	skipping to change at page 47, line 8		skipping to change at page 48, line 8
	expected that implementations support only a subset of the parameters		expected that implementations support only a subset of the parameters
	defined in Section 6. Those implementations will be able to use		defined in Section 6. Those implementations will be able to use
	regular SDP rules in order to ignore non-supported SDP parameters.		regular SDP rules in order to ignore non-supported SDP parameters.
	If all the information was encoded in a single SDP attribute, those		If all the information was encoded in a single SDP attribute, those
	rules, which relate to backwards compatibility, would need to be		rules, which relate to backwards compatibility, would need to be
	redefined specifically for that parameter.		redefined specifically for that parameter.
	Authors' Addresses		Authors' Addresses
	Miguel A. Garcia-Martin		Miguel A. Garcia-Martin
	Nokia Siemens Networks		Ericsson
	P.O.Box 6		Calle Via de los Poblados 13
	Nokia Siemens Networks, FIN 02022		Madrid, ES 28033
	Finland		Spain
	Phone: +358-71400-4000		Email: miguel.a.garcia@ericsson.com
	Email: miguel.garcia@nsn.com
	Markus Isomaki		Markus Isomaki
	Nokia		Nokia
	Keilalahdentie 2-4		Keilalahdentie 2-4
	Espoo 02150		Espoo 02150
	Finland		Finland
	Email: markus.isomaki@nokia.com		Email: markus.isomaki@nokia.com
	Gonzalo Camarillo		Gonzalo Camarillo
End of changes. 78 change blocks.
	248 lines changed or deleted		293 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/