draft-ietf-secsh-filexfer-00.txt		draft-ietf-secsh-filexfer-01.txt
	Network Working Group T. Ylonen and S. Lehtinen		Network Working Group T. Ylonen and S. Lehtinen
	INTERNET-DRAFT SSH Communications Security		INTERNET-DRAFT SSH Communications Security
	Expires: 9 July, 2001		Expires: 2 September, 2001
	SSH File Transfer Protocol		Secure Shell File Transfer Protocol
	Status of This Memo		Status of This Memo
	This document is an Internet-Draft and is in full conformance		This document is an Internet-Draft and is in full conformance
	with all provisions of Section 10 of RFC2026.		with all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as		other groups may also distribute working documents as
	Internet-Drafts.		Internet-Drafts.
	skipping to change at page 1, line 33		skipping to change at page 1, line 33
	"work in progress."		"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.
	Abstract		Abstract
	The SSH File Transfer Protocol provides secure file transfer functional-		The Secure Shell File Transfer Protocol provides secure file transfer
	ity over any reliable data stream. It is the standard file transfer		functionality over any reliable data stream. It is the standard file
	protocol for use with the SSH2 protocol. This document describes the		transfer protocol for use with the Secure Shell Remote Login Protocol.
	file transfer protocol and its interface to the SSH2 protocol suite.		This document describes the file transfer protocol and its interface to
			the Secure Shell protocol suite.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Use with the SSH Connection Protocol . . . . . . . . . . . . . . 3		2. Use with the Secure Shell Connection Protocol . . . . . . . . . 3
	3. General Packet Format . . . . . . . . . . . . . . . . . . . . . 3		3. General Packet Format . . . . . . . . . . . . . . . . . . . . . 3
	4. Protocol Initialization . . . . . . . . . . . . . . . . . . . . 4		4. Protocol Initialization . . . . . . . . . . . . . . . . . . . . 4
	5. File Attributes . . . . . . . . . . . . . . . . . . . . . . . . 5		5. File Attributes . . . . . . . . . . . . . . . . . . . . . . . . 5
	6. Requests From the Client to the Server . . . . . . . . . . . . . 6		6. Responses from the Server to the Client . . . . . . . . . . . . 6
	6.1. Request Synchronization and Reordering . . . . . . . . . . . 7		7. Requests From the Client to the Server . . . . . . . . . . . . . 9
	6.2. File Names . . . . . . . . . . . . . . . . . . . . . . . . . 7		7.1. Request Synchronization and Reordering . . . . . . . . . . . 10
	6.3. Opening, Creating, and Closing Files . . . . . . . . . . . . 8		7.2. File Names . . . . . . . . . . . . . . . . . . . . . . . . . 10
	6.4. Reading and Writing . . . . . . . . . . . . . . . . . . . . 9		7.3. Opening, Creating, and Closing Files . . . . . . . . . . . . 11
	6.5. Removing and Renaming Files . . . . . . . . . . . . . . . . 10		7.4. Reading and Writing . . . . . . . . . . . . . . . . . . . . 12
	6.6. Creating and Deleting Directories . . . . . . . . . . . . . 10		7.5. Removing and Renaming Files . . . . . . . . . . . . . . . . 13
	6.7. Scanning Directories . . . . . . . . . . . . . . . . . . . . 11		7.6. Creating and Deleting Directories . . . . . . . . . . . . . 14
	6.8. Retrieving File Attributes . . . . . . . . . . . . . . . . . 12		7.7. Scanning Directories . . . . . . . . . . . . . . . . . . . . 14
	6.9. Setting File Attributes . . . . . . . . . . . . . . . . . . 12		7.8. Retrieving File Attributes . . . . . . . . . . . . . . . . . 15
	6.10. Canonicalizing the Server-Side Path Name . . . . . . . . . 13		7.9. Setting File Attributes . . . . . . . . . . . . . . . . . . 16
	7. Responses from the Server to the Client . . . . . . . . . . . . 13		7.10. Dealing with Symbolic links . . . . . . . . . . . . . . . . 16
	8. Vendor-Specific Extensions . . . . . . . . . . . . . . . . . . . 16		7.11. Canonicalizing the Server-Side Path Name . . . . . . . . . 17
	9. Security Considerations . . . . . . . . . . . . . . . . . . . . 17		8. Vendor-Specific Extensions . . . . . . . . . . . . . . . . . . . 17
	10. Trademark Issues . . . . . . . . . . . . . . . . . . . . . . . 17		9. Security Considerations . . . . . . . . . . . . . . . . . . . . 18
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17		10. Changes from previous protocol versions . . . . . . . . . . . . 18
	12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18		10.1. Changes between versions 3 and 2 . . . . . . . . . . . . . 18
			10.2. Changes between versions 2 and 1 . . . . . . . . . . . . . 18
			10.3. Changes between versions 1 and 0 . . . . . . . . . . . . . 18
			11. Trademark Issues . . . . . . . . . . . . . . . . . . . . . . . 18
			12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
			13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19
	1. Introduction		1. Introduction
	This protocol provides secure file transfer (and more generally file		This protocol provides secure file transfer (and more generally file
	system access) functionality over a reliable data stream, such as a		system access) functionality over a reliable data stream, such as a
	channel in the SSH2 protocol [SSH-ARCH].		channel in the Secure Shell Remote Login Protocol [SECSH-ARCH].
	This protocol is designed so that it could be used to implement a secure		This protocol is designed so that it could be used to implement a secure
	remote file system service, as well as a secure file transfer service.		remote file system service, as well as a secure file transfer service.
	This protocol assumes that it runs over a secure channel, and that the		This protocol assumes that it runs over a secure channel, and that the
	server has already authenticated the user at the client end, and that		server has already authenticated the user at the client end, and that
	the identity of the client user is externally available to the server		the identity of the client user is externally available to the server
	implementation.		implementation.
	In general, this protocol follows a simple request-response model. Each		In general, this protocol follows a simple request-response model. Each
	request and response contains a sequence number and multiple requests		request and response contains a sequence number and multiple requests
	may be pending simultaneously. There are a relatively large number of		may be pending simultaneously. There are a relatively large number of
	different request messages, but a small number of possible response		different request messages, but a small number of possible response
	messages. Each request has one or more response messages that may be		messages. Each request has one or more response messages that may be
	returned in result (e.g., a read either returns data or reports error		returned in result (e.g., a read either returns data or reports error
	status).		status).
	The packet format descriptions in this specification follow the notation		The packet format descriptions in this specification follow the notation
	presented in [SSH-ARCH].		presented in [SECSH-ARCH].
	Even though this protocol is described in the context of the SSH2
	protocol, this protocol is general and independent of the rest of the		Even though this protocol is described in the context of the Secure
	SSH2 protocol suite. It could be used in a number of different		Shell Remote Login Protocol, this protocol is general and independent of
	applications, such as secure file transfer over TLS [RFC-2246] and		the rest of the Secure Shell protocol suite. It could be used in a
	transfer of management information in VPN applications.		number of different applications, such as secure file transfer over TLS
			[RFC-2246] and transfer of management information in VPN applications.
	2. Use with the SSH Connection Protocol		2. Use with the Secure Shell Connection Protocol
	When used with the SSH2 Protocol suite, this protocol is intended to be		When used with the Secure Shell protocol suite, this protocol is
	used from the SSH Connection Protocol as a subsystem, as described in		intended to be used from the Secure Shell Connection Protocol as a
	[SSH-CONN], Section ``Starting a Shell or a Command''. The subsystem		subsystem, as described in [SECSH-CONN], Section ``Starting a Shell or a
	name used with this protocol is "sftp".		Command''. The subsystem name used with this protocol is "sftp".
	3. General Packet Format		3. General Packet Format
	All packets transmitted over the secure connection are of the following		All packets transmitted over the secure connection are of the following
	format:		format:
	uint32 length		uint32 length
	byte type		byte type
	byte[length - 1] data payload		byte[length - 1] data payload
	skipping to change at page 4, line 18		skipping to change at page 4, line 23
	#define SSH_FXP_SETSTAT 9		#define SSH_FXP_SETSTAT 9
	#define SSH_FXP_FSETSTAT 10		#define SSH_FXP_FSETSTAT 10
	#define SSH_FXP_OPENDIR 11		#define SSH_FXP_OPENDIR 11
	#define SSH_FXP_READDIR 12		#define SSH_FXP_READDIR 12
	#define SSH_FXP_REMOVE 13		#define SSH_FXP_REMOVE 13
	#define SSH_FXP_MKDIR 14		#define SSH_FXP_MKDIR 14
	#define SSH_FXP_RMDIR 15		#define SSH_FXP_RMDIR 15
	#define SSH_FXP_REALPATH 16		#define SSH_FXP_REALPATH 16
	#define SSH_FXP_STAT 17		#define SSH_FXP_STAT 17
	#define SSH_FXP_RENAME 18		#define SSH_FXP_RENAME 18
			#define SSH_FXP_READLINK 19
			#define SSH_FXP_SYMLINK 20
	#define SSH_FXP_STATUS 101		#define SSH_FXP_STATUS 101
	#define SSH_FXP_HANDLE 102		#define SSH_FXP_HANDLE 102
	#define SSH_FXP_DATA 103		#define SSH_FXP_DATA 103
	#define SSH_FXP_NAME 104		#define SSH_FXP_NAME 104
	#define SSH_FXP_ATTRS 105		#define SSH_FXP_ATTRS 105
	#define SSH_FXP_EXTENDED 200		#define SSH_FXP_EXTENDED 200
	#define SSH_FXP_EXTENDED_REPLY 201		#define SSH_FXP_EXTENDED_REPLY 201
	Additional packet types should only be defined if the protocol version		Additional packet types should only be defined if the protocol version
	number (see Section ``Protocol Initialization'') is incremented, and		number (see Section ``Protocol Initialization'') is incremented, and
	skipping to change at page 5, line 53		skipping to change at page 6, line 4
	uint32 extended_count present only if flag		uint32 extended_count present only if flag
	SSH_FILEXFER_ATTR_EXTENDED		SSH_FILEXFER_ATTR_EXTENDED
	string extended_type		string extended_type
	string extended_data		string extended_data
	... more extended data (extended_type - extended_data pairs),		... more extended data (extended_type - extended_data pairs),
	so that number of pairs equals extended_count		so that number of pairs equals extended_count
	The `flags' specify which of the fields are present. Those fields for		The `flags' specify which of the fields are present. Those fields for
	which the corresponding flag is not set are not present (not included in		which the corresponding flag is not set are not present (not included in
	the packet). New flags can only be added by incrementing the protocol		the packet). New flags can only be added by incrementing the protocol
	version number (or by using the extension mechanism described below).		version number (or by using the extension mechanism described below).
	The `size' field specifies the size of the file in bytes.		The `size' field specifies the size of the file in bytes.
	The `uid' and `gid' fields contain numeric Unix-like user and group		The `uid' and `gid' fields contain numeric Unix-like user and group
	identifiers, respectively.		identifiers, respectively.
	The `permissions' field contains a bit mask of file permissions as		The `permissions' field contains a bit mask of file permissions as
	defined by [POSIX].		defined by [POSIX].
	The `atime' and `mtime' contain the access and modification times of the		The `atime' and `mtime' contain the access and modification times of the
	files, respectively. They are represented as seconds from Jan 1, 1970.		files, respectively. They are represented as seconds from Jan 1, 1970
			in UTC.
	The SSH_FILEXFER_ATTR_EXTENDED flag provides a general extension		The SSH_FILEXFER_ATTR_EXTENDED flag provides a general extension
	mechanism for vendor-specific extensions. If the flag is specified,		mechanism for vendor-specific extensions. If the flag is specified,
	then the `extended_count' field is present. It specifies the number of		then the `extended_count' field is present. It specifies the number of
	extended_type-extended_data pairs that follow. Each of these pairs		extended_type-extended_data pairs that follow. Each of these pairs
	specifies an extended attribute. For each of the attributes, the		specifies an extended attribute. For each of the attributes, the
	extended_type field should be a string of the format "name@domain",		extended_type field should be a string of the format "name@domain",
	where "domain" is a valid, registered domain name and "name" identifies		where "domain" is a valid, registered domain name and "name" identifies
	the method. The IETF may later standardize certain names that deviate		the method. The IETF may later standardize certain names that deviate
	from this format (e.g., that do not contain the "@" sign). The		from this format (e.g., that do not contain the "@" sign). The
	skipping to change at page 6, line 42		skipping to change at page 6, line 48
	if a packet with unsupported protocol bits is received.		if a packet with unsupported protocol bits is received.
	The flags bits are defined to have the following values:		The flags bits are defined to have the following values:
	#define SSH_FILEXFER_ATTR_SIZE 0x00000001		#define SSH_FILEXFER_ATTR_SIZE 0x00000001
	#define SSH_FILEXFER_ATTR_UIDGID 0x00000002		#define SSH_FILEXFER_ATTR_UIDGID 0x00000002
	#define SSH_FILEXFER_ATTR_PERMISSIONS 0x00000004		#define SSH_FILEXFER_ATTR_PERMISSIONS 0x00000004
	#define SSH_FILEXFER_ATTR_ACMODTIME 0x00000008		#define SSH_FILEXFER_ATTR_ACMODTIME 0x00000008
	#define SSH_FILEXFER_ATTR_EXTENDED 0x80000000		#define SSH_FILEXFER_ATTR_EXTENDED 0x80000000
	6. Requests From the Client to the Server		6. Responses from the Server to the Client
			The server responds to the client using one of a few response packets.
			All requests can return a SSH_FXP_STATUS response upon failure. When
			the operation is successful, any of the responses may be returned
			(depending on the operation). If no data needs to be returned to the
			client, the SSH_FXP_STATUS response with SSH_FX_OK status is
			appropriate. Otherwise, the SSH_FXP_HANDLE message is used to return a
			file handle (for SSH_FXP_OPEN and SSH_FXP_OPENDIR requests),
			SSH_FXP_DATA is used to return data from SSH_FXP_READ, SSH_FXP_NAME is
			used to return one or more file names from a SSH_FXP_READDIR or
			SSH_FXP_REALPATH request, and SSH_FXP_ATTRS is used to return file
			attributes from SSH_FXP_STAT, SSH_FXP_LSTAT, and SSH_FXP_FSTAT requests.
			Exactly one response will be returned for each request. Each response
			packet contains a request identifier which can be used to match each
			response with the corresponding request. Note that it is legal to have
			several requests outstanding simultaneously, and the server is allowed
			to send responses to them in a different order from the order in which
			the requests were sent (the result of their execution, however, is
			guaranteed to be as if they had been processed one at a time in the
			order in which the requests were sent).
			Response packets are of the same general format as request packets.
			Each response packet begins with the request identifier.
			The format of the data portion of the SSH_FXP_STATUS response is as
			follows:
			uint32 id
			uint32 error/status code
			string error message (ISO-10646 UTF-8 [RFC-2279])
			string language tag (as defined in [RFC-1766])
			where `id' is the request identifier, and `error/status code' indicates
			the result of the requested operation. The value SSH_FX_OK indicates
			success, and all other values indicate failure. Currently, the follow-
			ing values are defined (other values may be defined by future versions
			of this protocol):
			#define SSH_FX_OK 0
			#define SSH_FX_EOF 1
			#define SSH_FX_NO_SUCH_FILE 2
			#define SSH_FX_PERMISSION_DENIED 3
			#define SSH_FX_FAILURE 4
			#define SSH_FX_BAD_MESSAGE 5
			#define SSH_FX_NO_CONNECTION 6
			#define SSH_FX_CONNECTION_LOST 7
			#define SSH_FX_OP_UNSUPPORTED 8
			SSH_FX_OK
			Indicates successful completion of the operation.
			SSH_FX_EOF
			indicates end-of-file condition; for SSH_FX_READ it means that no
			more data is available in the file, and for SSH_FX_READDIR it
			indicates that no more files are contained in the directory.
			SSH_FX_NO_SUCH_FILE
			is returned when a reference is made to a file which should exist
			but doesn't.
			SSH_FX_PERMISSION_DENIED
			is returned when the authenticated user does not have sufficient
			permissions to perform the operation.
			SSH_FX_FAILURE
			is a generic catch-all error message; it should be returned if an
			error occurs for which there is no more specific error code
			defined.
			SSH_FX_BAD_MESSAGE
			may be returned if a badly formatted packet or protocol
			incompatibility is detected.
			SSH_FX_NO_CONNECTION
			is a pseudo-error which indicates that the client has no
			connection to the server (it can only be generated locally by the
			client, and MUST NOT be returned by servers).
			SSH_FX_CONNECTION_LOST
			is a pseudo-error which indicates that the connection to the
			server has been lost (it can only be generated locally by the
			client, and MUST NOT be returned by servers).
			SSH_FX_OP_UNSUPPORTED
			indicates that an attempt was made to perform an operation which
			is not supported for the server (it may be generated locally by
			the client if e.g. the version number exchange indicates that a
			required feature is not supported by the server, or it may be
			returned by the server if the server does not implement an
			operation).
			The SSH_FXP_HANDLE response has the following format:
			uint32 id
			string handle
			where `id' is the request identifier, and `handle' is an arbitrary
			string that identifies an open file or directory on the server. The
			handle is opaque to the client; the client MUST NOT attempt to interpret
			or modify it in any way. The length of the handle string MUST NOT
			exceed 256 data bytes.
			The SSH_FXP_DATA response has the following format:
			uint32 id
			string data
			where `id' is the request identifier, and `data' is an arbitrary byte
			string containing the requested data. The data string may be at most
			the number of bytes requested in a SSH_FXP_READ request, but may also be
			shorter if end of file is reached or if the read is from something other
			than a regular file.
			The SSH_FXP_NAME response has the following format:
			uint32 id
			uint32 count
			repeats count times:
			string filename
			string longname
			ATTRS attrs
			where `id' is the request identifier, `count' is the number of names
			returned in this response, and the remaining fields repeat `count' times
			(so that all three fields are first included for the first file, then
			for the second file, etc). In the repeated part, `filename' is a file
			name being returned (for SSH_FXP_READDIR, it will be a relative name
			within the directory, without any path components; for SSH_FXP_REALPATH
			it will be an absolute path name), `longname' is an expanded format for
			the file name, similar to what is returned by "ls -l" on Unix systems,
			and `attrs' is the attributes of the file as described in Section ``File
			Attributes''.
			The format of the `longname' field is unspecified by this protocol. It
			MUST be suitable for use in the output of a directory listing command
			(in fact, the recommended operation for a directory listing command is
			to simply display this data). However, clients SHOULD NOT attempt to
			parse the longname field for file attributes; they SHOULD use the attrs
			field instead.
			The recommended format for the longname field is as follows:
			-rwxr-xr-x 1 mjos staff 348911 Mar 25 14:29 t-filexfer
			1234567890 123 12345678 12345678 12345678 123456789012
			Here, the first line is sample output, and the second field indicates
			widths of the various fields. Fields are separated by spaces. The
			first field lists file permissions for user, group, and others; the sec-
			ond field is link count; the third field is the name of the user who
			owns the file; the fourth field is the name of the group that owns the
			file; the fifth field is the size of the file in bytes; the sixth field
			(which actually may contain spaces, but is fixed to 12 characters) is
			the file modification time, and the seventh field is the file name.
			Each field is specified to be a minimum of certain number of character
			positions (indicated by the second line above), but may also be longer
			if the data does not fit in the specified length.
			The SSH_FXP_ATTRS response has the following format:
			uint32 id
			ATTRS attrs
			where `id' is the request identifier, and `attrs' is the returned file
			attributes as described in Section ``File Attributes''.
			7. Requests From the Client to the Server
	Requests from the client to the server represent the various file system		Requests from the client to the server represent the various file system
	operations. Each request begins with an `id' field, which is a 32-bit		operations. Each request begins with an `id' field, which is a 32-bit
	identifier identifying the request (selected by the client). The same		identifier identifying the request (selected by the client). The same
	identifier will be returned in the response to the request. One		identifier will be returned in the response to the request. One
	possible implementation of it is a monotonically increasing request		possible implementation of it is a monotonically increasing request
	sequence number (modulo 2^32).		sequence number (modulo 2^32).
	Many operations in the protocol operate on open files. The SSH_FXP_OPEN		Many operations in the protocol operate on open files. The SSH_FXP_OPEN
	request can return a file handle (which is an opaque variable-length		request can return a file handle (which is an opaque variable-length
	string) which may be used to access the file later (e.g. in a read		string) which may be used to access the file later (e.g. in a read
	operation). The client MUST NOT send requests the server with bogus or		operation). The client MUST NOT send requests the server with bogus or
	skipping to change at page 7, line 13		skipping to change at page 10, line 26
	handle in order to avoid security risks due to fabricated handles.		handle in order to avoid security risks due to fabricated handles.
	This design allows either stateful and stateless server implementation,		This design allows either stateful and stateless server implementation,
	as well as an implementation which caches state between requests but may		as well as an implementation which caches state between requests but may
	also flush it. The contents of the file handle string are entirely up		also flush it. The contents of the file handle string are entirely up
	to the server and its design. The client should not modify or attempt		to the server and its design. The client should not modify or attempt
	to interpret the file handle strings.		to interpret the file handle strings.
	The file handle strings MUST NOT be longer than 256 bytes.		The file handle strings MUST NOT be longer than 256 bytes.
	6.1. Request Synchronization and Reordering		7.1. Request Synchronization and Reordering
	The protocol and implementations MUST process requests relating to the		The protocol and implementations MUST process requests relating to the
	same file in the order in which they are received. In other words, if		same file in the order in which they are received. In other words, if
	an application submits multiple requests to the server, the results in		an application submits multiple requests to the server, the results in
	the responses will be the same as if it had sent the requests one at a		the responses will be the same as if it had sent the requests one at a
	time and waited for the response in each case. For example, the server		time and waited for the response in each case. For example, the server
	may process non-overlapping read/write requests to the same file in		may process non-overlapping read/write requests to the same file in
	parallel, but overlapping reads and writes cannot be reordered or		parallel, but overlapping reads and writes cannot be reordered or
	parallelized. However, there are no ordering restrictions on the server		parallelized. However, there are no ordering restrictions on the server
	for processing requests from two different file transfer connections.		for processing requests from two different file transfer connections.
	The server may interleave and parallelize them at will.		The server may interleave and parallelize them at will.
	There are no restrictions on the order in which responses to outstanding		There are no restrictions on the order in which responses to outstanding
	requests are delivered to the client, except that the server must ensure		requests are delivered to the client, except that the server must ensure
	fairness in the sense that processing of no request will be indefinitely		fairness in the sense that processing of no request will be indefinitely
	delayed even if the client is sending other requests so that there are		delayed even if the client is sending other requests so that there are
	multiple outstanding requests all the time.		multiple outstanding requests all the time.
	6.2. File Names		7.2. File Names
	This protocol represents file names as strings. File names are assumed		This protocol represents file names as strings. File names are assumed
	to use the slash ('/') character as a directory separator.		to use the slash ('/') character as a directory separator.
	File names starting with a slash are "absolute", and are relative to the		File names starting with a slash are "absolute", and are relative to the
	root of the file system. Names starting with any other character are		root of the file system. Names starting with any other character are
	relative to the user's default directory (home directory). Note that		relative to the user's default directory (home directory). Note that
	identifying the user is assumed to take place outside of this protocol.		identifying the user is assumed to take place outside of this protocol.
	Servers SHOULD interpret a path name component ".." as referring to the		Servers SHOULD interpret a path name component ".." as referring to the
	skipping to change at page 8, line 4		skipping to change at page 11, line 18
	An empty path name is valid, and it refers to the user's default		An empty path name is valid, and it refers to the user's default
	directory (usually the user's home directory).		directory (usually the user's home directory).
	Otherwise, no syntax is defined for file names by this specification.		Otherwise, no syntax is defined for file names by this specification.
	Clients should not make any other assumptions; however, they can splice		Clients should not make any other assumptions; however, they can splice
	path name components returned by SSH_FXP_READDIR together using a slash		path name components returned by SSH_FXP_READDIR together using a slash
	('/') as the separator, and that will work as expected.		('/') as the separator, and that will work as expected.
	It is understood that the lack of well-defined semantics for file names		It is understood that the lack of well-defined semantics for file names
	may cause interoperability problems between clients and servers using		may cause interoperability problems between clients and servers using
	radically different operating systems. However, this approach is known		radically different operating systems. However, this approach is known
	to work acceptably with most systems, and alternative approaches that		to work acceptably with most systems, and alternative approaches that
	e.g. treat file names as sequences of structured components are quite		e.g. treat file names as sequences of structured components are quite
	complicated.		complicated.
	6.3. Opening, Creating, and Closing Files		7.3. Opening, Creating, and Closing Files
	Files are opened and created using the SSH_FXP_OPEN message, whose data		Files are opened and created using the SSH_FXP_OPEN message, whose data
	part is as follows:		part is as follows:
	uint32 id		uint32 id
	string filename		string filename
	uint32 pflags		uint32 pflags
	ATTRS attrs		ATTRS attrs
	The `id' field is the request identifier as for all requests.		The `id' field is the request identifier as for all requests.
	skipping to change at page 9, line 27		skipping to change at page 12, line 40
	A file is closed by using the SSH_FXP_CLOSE request. Its data field has		A file is closed by using the SSH_FXP_CLOSE request. Its data field has
	the following format:		the following format:
	uint32 id		uint32 id
	string handle		string handle
	where `id' is the request identifier, and `handle' is a handle previ-		where `id' is the request identifier, and `handle' is a handle previ-
	ously returned in the response to SSH_FXP_OPEN or SSH_FXP_OPENDIR. The		ously returned in the response to SSH_FXP_OPEN or SSH_FXP_OPENDIR. The
	handle becomes invalid immediately after this request has been sent.		handle becomes invalid immediately after this request has been sent.
	The response to this request will be a SSH_FXP_STATUS message. One		The response to this request will be a SSH_FXP_STATUS message. One
	should note that on some server platforms even a close can fail. This		should note that on some server platforms even a close can fail. This
	can happen e.g. if the server operating system caches writes, and an		can happen e.g. if the server operating system caches writes, and an
	error occurs while flushing cached writes during the close.		error occurs while flushing cached writes during the close.
	6.4. Reading and Writing		7.4. Reading and Writing
	Once a file has been opened, it can be read using the SSH_FXP_READ		Once a file has been opened, it can be read using the SSH_FXP_READ
	message, which has the following format:		message, which has the following format:
	uint32 id		uint32 id
	string handle		string handle
	uint64 offset		uint64 offset
	uint32 len		uint32 len
	where `id' is the request identifier, `handle' is an open file handle		where `id' is the request identifier, `handle' is an open file handle
	skipping to change at page 10, line 22		skipping to change at page 13, line 37
	the file where to start writing, and `data' is the data to be written.		the file where to start writing, and `data' is the data to be written.
	The write will extend the file if writing beyond the end of the file.		The write will extend the file if writing beyond the end of the file.
	It is legal to write way beyond the end of the file; the semantics are		It is legal to write way beyond the end of the file; the semantics are
	to write zeroes from the end of the file to the specified offset and		to write zeroes from the end of the file to the specified offset and
	then the data. On most operating systems, such writes do not allocate		then the data. On most operating systems, such writes do not allocate
	disk space but instead leave "holes" in the file.		disk space but instead leave "holes" in the file.
	The server responds to a write request with a SSH_FXP_STATUS message.		The server responds to a write request with a SSH_FXP_STATUS message.
	6.5. Removing and Renaming Files		7.5. Removing and Renaming Files
	Files can be removed using the SSH_FXP_REMOVE message. It has the		Files can be removed using the SSH_FXP_REMOVE message. It has the
	following format:		following format:
	uint32 id		uint32 id
	string filename		string filename
	where `id' is the request identifier and `filename' is the name of the		where `id' is the request identifier and `filename' is the name of the
	file to be removed. See Section ``File Names'' for more information.		file to be removed. See Section ``File Names'' for more information.
	This request cannot be used to remove directories.		This request cannot be used to remove directories.
	skipping to change at page 10, line 52		skipping to change at page 14, line 14
	where `id' is the request identifier, `oldpath' is the name of an exist-		where `id' is the request identifier, `oldpath' is the name of an exist-
	ing file or directory, and `newpath' is the new name for the file or		ing file or directory, and `newpath' is the new name for the file or
	directory. It is an error if there already exists a file with the name		directory. It is an error if there already exists a file with the name
	specified by newpath. The server may also fail rename requests in other		specified by newpath. The server may also fail rename requests in other
	situations, for example if `oldpath' and `newpath' point to different		situations, for example if `oldpath' and `newpath' point to different
	file systems on the server.		file systems on the server.
	The server will respond to this request with a SSH_FXP_STATUS message.		The server will respond to this request with a SSH_FXP_STATUS message.
	6.6. Creating and Deleting Directories		7.6. Creating and Deleting Directories
	New directories can be created using the SSH_FXP_MKDIR request. It has		New directories can be created using the SSH_FXP_MKDIR request. It has
	the following format:		the following format:
	uint32 id		uint32 id
	string path		string path
			ATTRS attrs
	where `id' is the request identifier and `path' specifies the directory		where `id' is the request identifier, `path'and `attrs' specifies the
	to be created. See Section ``File Names'' for more information on file		modifications to be made to its attributes. See Section ``File Names''
	names. An error will be returned if a file or directory with the speci-		for more information on file names. Attributes are discussed in more
	fied path already exists. The server will respond to this request with		detail in Section ``File Attributes''. specifies the directory to be
	a SSH_FXP_STATUS message.		created. An error will be returned if a file or directory with the
			specified path already exists. The server will respond to this request
			with a SSH_FXP_STATUS message.
	Directories can be removed using the SSH_FXP_RMDIR request, which has		Directories can be removed using the SSH_FXP_RMDIR request, which has
	the following format:		the following format:
	uint32 id		uint32 id
	string path		string path
	where `id' is the request identifier, and `path' specifies the directory		where `id' is the request identifier, and `path' specifies the directory
	to be removed. See Section ``File Names'' for more information on file		to be removed. See Section ``File Names'' for more information on file
	names. An error will be returned if no directory with the specified		names. An error will be returned if no directory with the specified
	path exists, or if the specified directory is not empty, or if the path		path exists, or if the specified directory is not empty, or if the path
	specified a file system object other than a directory. The server		specified a file system object other than a directory. The server
	responds to this request with a SSH_FXP_STATUS message.		responds to this request with a SSH_FXP_STATUS message.
	6.7. Scanning Directories		7.7. Scanning Directories
	The files in a directory can be listed using the SSH_FXP_OPENDIR and		The files in a directory can be listed using the SSH_FXP_OPENDIR and
	SSH_FXP_READDIR requests. Each SSH_FXP_READDIR request returns one or		SSH_FXP_READDIR requests. Each SSH_FXP_READDIR request returns one or
	more file names with full file attributes for each file. The client		more file names with full file attributes for each file. The client
	should call SSH_FXP_READDIR repeatedly until it has found the file it is		should call SSH_FXP_READDIR repeatedly until it has found the file it is
	looking for or until the server responds with a SSH_FXP_STATUS message		looking for or until the server responds with a SSH_FXP_STATUS message
	indicating an error (normally SSH_FX_EOF if there are no more files in		indicating an error (normally SSH_FX_EOF if there are no more files in
	the directory). The client should then close the handle using the		the directory). The client should then close the handle using the
	SSH_FXP_CLOSE request.		SSH_FXP_CLOSE request.
	skipping to change at page 12, line 17		skipping to change at page 15, line 35
	The server responds to this request with either a SSH_FXP_NAME or a		The server responds to this request with either a SSH_FXP_NAME or a
	SSH_FXP_STATUS message. One or more names may be returned at a time.		SSH_FXP_STATUS message. One or more names may be returned at a time.
	Full status information is returned for each name in order to speed up		Full status information is returned for each name in order to speed up
	typical directory listings.		typical directory listings.
	When the client no longer wishes to read more names from the directory,		When the client no longer wishes to read more names from the directory,
	it SHOULD call SSH_FXP_CLOSE for the handle. The handle should be		it SHOULD call SSH_FXP_CLOSE for the handle. The handle should be
	closed regardless of whether an error has occurred or not.		closed regardless of whether an error has occurred or not.
	6.8. Retrieving File Attributes		7.8. Retrieving File Attributes
	Very often, file attributes are automatically returned by		Very often, file attributes are automatically returned by
	SSH_FXP_READDIR. However, sometimes there is need to specifically		SSH_FXP_READDIR. However, sometimes there is need to specifically
	retrieve the attributes for a named file. This can be done using the		retrieve the attributes for a named file. This can be done using the
	SSH_FXP_STAT, SSH_FXP_LSTAT and SSH_FXP_FSTAT requests.		SSH_FXP_STAT, SSH_FXP_LSTAT and SSH_FXP_FSTAT requests.
	SSH_FXP_STAT and SSH_FXP_LSTAT only differ in that SSH_FXP_STAT follows		SSH_FXP_STAT and SSH_FXP_LSTAT only differ in that SSH_FXP_STAT follows
	symbolic links on the server, whereas SSH_FXP_LSTAT does not follow		symbolic links on the server, whereas SSH_FXP_LSTAT does not follow
	symbolic links. Both have the same format:		symbolic links. Both have the same format:
	skipping to change at page 12, line 46		skipping to change at page 16, line 10
	information for an open file (identified by the file handle). Its		information for an open file (identified by the file handle). Its
	format is as follows:		format is as follows:
	uint32 id		uint32 id
	string handle		string handle
	where `id' is the request identifier and `handle' is a file handle		where `id' is the request identifier and `handle' is a file handle
	returned by SSH_FXP_OPEN. The server responds to this request with		returned by SSH_FXP_OPEN. The server responds to this request with
	SSH_FXP_ATTRS or SSH_FXP_STATUS.		SSH_FXP_ATTRS or SSH_FXP_STATUS.
	6.9. Setting File Attributes		7.9. Setting File Attributes
	File attributes may be modified using the SSH_FXP_SETSTAT and		File attributes may be modified using the SSH_FXP_SETSTAT and
	SSH_FXP_FSETSTAT requests. These requests are used for operations such		SSH_FXP_FSETSTAT requests. These requests are used for operations such
	as changing the ownership, permissions or access times, as well as for		as changing the ownership, permissions or access times, as well as for
	truncating a file.		truncating a file.
	The SSH_FXP_SETSTAT request is of the following format:		The SSH_FXP_SETSTAT request is of the following format:
	uint32 id		uint32 id
	string path		string path
	skipping to change at page 13, line 28		skipping to change at page 16, line 46
	uint32 id		uint32 id
	string handle		string handle
	ATTRS attrs		ATTRS attrs
	where `id' is the request identifier, `handle' (MUST be returned by		where `id' is the request identifier, `handle' (MUST be returned by
	SSH_FXP_OPEN) identifies the file whose attributes are to be modified,		SSH_FXP_OPEN) identifies the file whose attributes are to be modified,
	and `attrs' specifies the modifications to be made to its attributes.		and `attrs' specifies the modifications to be made to its attributes.
	Attributes are discussed in more detail in Section ``File Attributes''.		Attributes are discussed in more detail in Section ``File Attributes''.
	The server will respond to this request with SSH_FXP_STATUS.		The server will respond to this request with SSH_FXP_STATUS.
	6.10. Canonicalizing the Server-Side Path Name		7.10. Dealing with Symbolic links
	The SSH_FXP_REALPATH request can be used to have the server canonicalize		The SSH_FXP_READLINK request may be used to read the target of a
	any given path name to an absolute path. This is useful for converting		symbolic link. It would have a data part as follows:
	path names containing ".." components or relative pathnames without a
	leading slash into absolute paths. The format of the request is as
	follows:
	uint32 id		uint32 id
	string path		string path
	where `id' is the request identifier and `path' specifies the path name		where `id' is the request identifier and `path' specifies the path name
	to be canonicalized. The server will respond with a SSH_FXP_NAME packet		of the symlink to be read.
	containing only one name and a dummy attributes value. The name is the
	returned packet will be in canonical form. If an error occurs, the
	server may also respond with SSH_FXP_STATUS.
	7. Responses from the Server to the Client
	The server responds to the client using one of a few response packets.
	All requests can return a SSH_FXP_STATUS response upon failure. When
	the operation is successful, any of the responses may be returned
	(depending on the operation). If no data needs to be returned to the
	client, the SSH_FXP_STATUS response with SSH_FX_OK status is
	appropriate. Otherwise, the SSH_FXP_HANDLE message is used to return a
	file handle (for SSH_FXP_OPEN and SSH_FXP_OPENDIR requests),
	SSH_FXP_DATA is used to return data from SSH_FXP_READ, SSH_FXP_NAME is
	used to return one or more file names from a SSH_FXP_READDIR or
	SSH_FXP_REALPATH request, and SSH_FXP_ATTRS is used to return file
	attributes from SSH_FXP_STAT, SSH_FXP_LSTAT, and SSH_FXP_FSTAT requests.
	Exactly one response will be returned for each request. Each response
	packet contains a request identifier which can be used to match each
	response with the corresponding request. Note that it is legal to have
	several requests outstanding simultaneously, and the server is allowed
	to send responses to them in a different order from the order in which
	the requests were sent (the result of their execution, however, is
	guaranteed to be as if they had been processed one at a time in the
	order in which the requests were sent).
	Response packets are of the same general format as request packets.
	Each response packet begins with the request identifier.
	The format of the data portion of the SSH_FXP_STATUS response is as
	follows:
	uint32 id
	uint32 error/status code
	where `id' is the request identifier, and `error/status code' indicates
	the result of the requested operation. The value SSH_FX_OK indicates
	success, and all other values indicate failure. Currently, the follow-
	ing values are defined (other values may be defined by future versions
	of this protocol):
	#define SSH_FX_OK 0
	#define SSH_FX_EOF 1
	#define SSH_FX_NO_SUCH_FILE 2
	#define SSH_FX_PERMISSION_DENIED 3
	#define SSH_FX_FAILURE 4
	#define SSH_FX_BAD_MESSAGE 5
	#define SSH_FX_NO_CONNECTION 6
	#define SSH_FX_CONNECTION_LOST 7
	#define SSH_FX_OP_UNSUPPORTED 8
	SSH_FX_OK
	Indicates successful completion of the operation.
	SSH_FX_EOF
	indicates end-of-file condition; for SSH_FX_READ it means that no
	more data is available in the file, and for SSH_FX_READDIR it
	indicates that no more files are contained in the directory.
	SSH_FX_NO_SUCH_FILE
	is returned when a reference is made to a file which should exist
	but doesn't.
	SSH_FX_PERMISSION_DENIED
	is returned when the authenticated user does not have sufficient
	permissions to perform the operation.
	SSH_FX_FAILURE
	is a generic catch-all error message; it should be returned if an
	error occurs for which there is no more specific error code
	defined.
	SSH_FX_BAD_MESSAGE
	may be returned if a badly formatted packet or protocol
	incompatibility is detected.
	SSH_FX_NO_CONNECTION
	is a pseudo-error which indicates that the client has no
	connection to the server (it can only be generated locally by the
	client, and MUST NOT be returned by servers).
	SSH_FX_CONNECTION_LOST
	is a pseudo-error which indicates that the connection to the
	server has been lost (it can only be generated locally by the
	client, and MUST NOT be returned by servers).
	SSH_FX_OP_UNSUPPORTED
	indicates that an attempt was made to perform an operation which
	is not supported for the server (it may be generated locally by
	the client if e.g. the version number exchange indicates that a
	required feature is not supported by the server, or it may be
	returned by the server if the server does not implement an
	operation).
	The SSH_FXP_HANDLE response has the following format:
	uint32 id
	string handle
	where `id' is the request identifier, and `handle' is an arbitrary
	string that identifies an open file or directory on the server. The
	handle is opaque to the client; the client MUST NOT attempt to interpret
	or modify it in any way. The length of the handle string MUST NOT
	exceed 256 data bytes.
	The SSH_FXP_DATA response has the following format:
	uint32 id
	string data
	where `id' is the request identifier, and `data' is an arbitrary byte		The server will respond with a SSH_FXP_NAME packet containing only one
	string containing the requested data. The data string may be at most		name and a dummy attributes value. The name in the returned packet
	the number of bytes requested in a SSH_FXP_READ request, but may also be		contains the target of the link. If an error occurs, the server may
	shorter if end of file is reached or if the read is from something other		respond with SSH_FXP_STATUS.
	than a regular file.
	The SSH_FXP_NAME response has the following format:		The SSH_FXP_SYMLINK request will create a symbolic link on the server.
			It is of the following format
	uint32 id		uint32 id
	uint32 count		string linkpath
	repeats count times:		string targetpath
	string filename
	string longname
	ATTRS attrs
	where `id' is the request identifier, `count' is the number of names
	returned in this response, and the remaining fields repeat `count' times
	(so that all three fields are first included for the first file, then
	for the second file, etc). In the repeated part, `filename' is a file
	name being returned (for SSH_FXP_READDIR, it will be a relative name
	within the directory, without any path components; for SSH_FXP_REALPATH
	it will be an absolute path name), `longname' is an expanded format for
	the file name, similar to what is returned by "ls -l" on Unix systems,
	and `attrs' is the attributes of the file as described in Section ``File
	Attributes''.
	The format of the `longname' field is unspecified by this protocol. It
	MUST be suitable for use in the output of a directory listing command
	(in fact, the recommended operation for a directory listing command is
	to simply display this data). However, clients SHOULD NOT attempt to
	parse the longname field for file attributes; they SHOULD use the attrs
	field instead.
	The recommended format for the longname field is as follows:
	-rwxr-xr-x 1 mjos staff 348911 Mar 25 14:29 t-filexfer		where `id' is the request identifier, `linkpath' specifies the path name
	1234567890 123 12345678 12345678 12345678 123456789012		of the symlink to be created and `targetpath' specifies the target of
			the symlink. The server shall respond with a SSH_FXP_STATUS indicating
			either success (SSH_FX_OK) or an error condition.
	Here, the first line is sample output, and the second field indicates		7.11. Canonicalizing the Server-Side Path Name
	widths of the various fields. Fields are separated by spaces. The
	first field lists file permissions for user, group, and others; the sec-
	ond field is link count; the third field is the name of the user who
	owns the file; the fourth field is the name of the group that owns the
	file; the fifth field is the size of the file in bytes; the sixth field
	(which actually may contain spaces, but is fixed to 12 characters) is
	the file modification time, and the seventh field is the file name.
	Each file is specified to be a minimum of certain number of character
	positions (indicated by the second line above), but may also be longer
	if the data does not fit in the specified length.
	The SSH_FXP_ATTRS response has the following format:		The SSH_FXP_REALPATH request can be used to have the server canonicalize
			any given path name to an absolute path. This is useful for converting
			path names containing ".." components or relative pathnames without a
			leading slash into absolute paths. The format of the request is as
			follows:
	uint32 id		uint32 id
	ATTRS attrs		string path
	where `id' is the request identifier, and `attrs' is the returned file		where `id' is the request identifier and `path' specifies the path name
	attributes as described in Section ``File Attributes''.		to be canonicalized. The server will respond with a SSH_FXP_NAME packet
			containing only one name and a dummy attributes value. The name is the
			returned packet will be in canonical form. If an error occurs, the
			server may also respond with SSH_FXP_STATUS.
	8. Vendor-Specific Extensions		8. Vendor-Specific Extensions
	The SSH_FXP_EXTENDED request provides a generic extension mechanism for		The SSH_FXP_EXTENDED request provides a generic extension mechanism for
	adding vendor-specific commands. The request has the following format:		adding vendor-specific commands. The request has the following format:
	uint32 id		uint32 id
	string extended-request		string extended-request
	... any request-specific data ...		... any request-specific data ...
	skipping to change at page 17, line 35		skipping to change at page 18, line 26
	This protocol assumes that it is run over a secure channel and that the		This protocol assumes that it is run over a secure channel and that the
	endpoints of the channel have been authenticated. Thus, this protocol		endpoints of the channel have been authenticated. Thus, this protocol
	assumes that it is externally protected from network-level attacks.		assumes that it is externally protected from network-level attacks.
	This protocol provides file system access to arbitrary files on the		This protocol provides file system access to arbitrary files on the
	server (only constrained by the server implementation). It is the		server (only constrained by the server implementation). It is the
	responsibility of the server implementation to enforce any access		responsibility of the server implementation to enforce any access
	controls that may be required to limit the access allowed for any		controls that may be required to limit the access allowed for any
	particular user (the user being authenticated externally to this		particular user (the user being authenticated externally to this
	protocol, typically using the SSH User Authentication Protocol [SSH-		protocol, typically using the Secure Shell User Authentication Protocol
	USERAUTH].		[SECSH-USERAUTH].
	Care must be taken in the server implementation to check the validity of		Care must be taken in the server implementation to check the validity of
	received file handle strings. The server should not rely on them		received file handle strings. The server should not rely on them
	directly; it MUST check the validity of each handle before relying on		directly; it MUST check the validity of each handle before relying on
	it.		it.
	10. Trademark Issues		10. Changes from previous protocol versions
	SSH is a registered trademark and Secure Shell is a trademark of SSH		The Secure Shell File Transfer Protocol has changed over time, before
	Communications Security Corp. SSH Communications Security Corp permits		it's standardization. The following is a description of the
	the use of these trademarks as the name of this standard and protocol,		incompatible changes between different versions.
	and permits their use to describe that a product conforms to this
	standard, provided that the following acknowledgement is included where
	the trademarks are used: ``SSH is a registered trademark and Secure
	Shell is a trademark of SSH Communications Security Corp
	(www.ssh.com)''. These trademarks may not be used as part of a product
	name or in otherwise confusing manner without prior written permission
	of SSH Communications Security Corp.
	11. References		10.1. Changes between versions 3 and 2
			o The SSH_FXP_READLINK and SSH_FXP_SYMLINK mesages were added.
			o The SSH_FXP_EXTENDED and SSH_FXP_EXTENDED_REPLY messages were added.
			o The SSH_FXP_STATUS message was changed to include fields `error
			message' and `language tag'.
			10.2. Changes between versions 2 and 1
			o The SSH_FXP_RENAME message was added.
			10.3. Changes between versions 1 and 0
			o Implementation changes, no actual protocol changes.
			11. Trademark Issues
			"ssh" is a registered trademark of SSH Communications Security Corp in
			the United States and/or other countries.
			12. References
	[RFC-2246] Dierks, T. and Allen, C.: "The TLS Protocol Version 1.0",		[RFC-2246] Dierks, T. and Allen, C.: "The TLS Protocol Version 1.0",
	January 1999		January 1999
	[POSIX] ISO/IEC Std 9945-1, ANSI/IEEE Std 1003.1 Information technology		[POSIX] ISO/IEC Std 9945-1, ANSI/IEEE Std 1003.1 Information technology
	-- Portable Operating System Interface (POSIX)-Part 1: System		-- Portable Operating System Interface (POSIX)-Part 1: System
	Application Program Interface (API) [C Language], July 1996.		Application Program Interface (API) [C Language], July 1996.
	[SSH-ARCH] Ylonen, T., et al: "SSH Protocol Architecture", Internet-		[SECSH-ARCH] Ylonen, T., et al: "Secure Shell Protocol Architecture",
	Draft, draft-ietf-secsh-architecture-07.txt		Internet-Draft, draft-ietf-secsh-architecture-08.txt
	[SSH-TRANSPORT] Ylonen, T., et al: "SSH Transport Protocol", Internet-		[SECSH-TRANSPORT] Ylonen, T., et al: "Secure Shell Transport Protocol",
	Draft, draft-ietf-secsh-transport-09.txt		Internet-Draft, draft-ietf-secsh-transport-10.txt
	[SSH-USERAUTH] Ylonen, T., et al: "SSH Authentication Protocol",		[SECSH-USERAUTH] Ylonen, T., et al: "Secure Shell Authentication
	Internet-Draft, draft-ietf-secsh-userauth-09.txt		Protocol", Internet-Draft, draft-ietf-secsh-userauth-10.txt
	[SSH-CONNECT] Ylonen, T., et al: "SSH Connection Protocol", Internet-		[SECSH-CONNECT] Ylonen, T., et al: "Secure Shell Connection Protocol",
	Draft, draft-ietf-secsh-connect-09.txt		Internet-Draft, draft-ietf-secsh-connect-10.txt
	12. Authors' Addresses		13. Authors' Addresses
	Tatu Ylonen		Tatu Ylonen
	SSH Communications Security Corp		SSH Communications Security Corp
	Fredrikinkatu 42		Fredrikinkatu 42
	FIN-00100 HELSINKI		FIN-00100 HELSINKI
	Finland		Finland
	E-mail: ylo@ssh.com		E-mail: ylo@ssh.com
	Sami Lehtinen		Sami Lehtinen
	SSH Communications Security Corp		SSH Communications Security Corp
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/