Subject: I-D ACTION:draft-ietf-secsh-filexfer-00.txt

From: [email-masked]
Date: Wed, 10 Jan 2001 06:46:16 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Secure Shell Working Group of the IETF.

	Title		: SSH File Transfer Protocol
	Author(s)	: T. Ylonen, S. Lehtinen
	Filename	: draft-ietf-secsh-filexfer-00.txt
	Pages		: 18
	Date		: 09-Jan-01
	
The SSH File Transfer Protocol provides secure file transfer functional-
ity over any reliable data stream.  It is the standard file transfer
protocol for use with the SSH2 protocol.  This document describes the
file transfer protocol and its interface to the SSH2 protocol suite.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-secsh-filexfer-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-secsh-filexfer-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-secsh-filexfer-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: [email-masked] (Niels M�ller)
Date: 11 Jan 2001 14:37:09 +0100

I've read the draft, and I have a few comments. First, the
presentation:

* In section 3, the packet format is describes as follows:

: 3.  General Packet Format
: 
: All packets transmitted over the secure connection are of the following
: format:
: 
:   uint32             length
:   byte               type
:   byte[length - 1]   data payload

Then particular messages are described as for example

: Files are opened and created using the SSH_FXP_OPEN message, whose data
: part is as follows:
: 
:   uint32        id
:   string        filename
:   uint32        pflags
:   ATTRS         attrs

I think it would be clearer, and more consistent with the other secsh
documents, to include the type byte in the payload. The descriptions
would be changed to

:   uint32             length
:   byte[length]       data payload (first byte is a type identifier)

...

: Files are opened and created using the SSH_FXP_OPEN message, whose data
: part is as follows:
: 
:   byte          SSH_FXP_OPEN
:   uint32        id
:   string        filename
:   uint32        pflags
:   ATTRS         attrs

* The document would be easier to read if the response (server to
  client) messages were described first. There are a large number of
  forward references to SSH_FXP_STATUS.

I also have some comments on the protocol itself, which I'll write in
a separate message.

/Niels

---

From: [email-masked] (Niels Möller)
Date: 11 Jan 2001 16:48:59 +0100

> I've read the draft, and I have a few comments. First, the

One more comment:

I can't understand the final sentence in the description of
SSH_FXP_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."

/Niels

---

From: Tatu Ylonen <[email-masked]>
Date: Thu, 11 Jan 2001 23:20:25 +0200 (EET)

> but may also be longer if the data does not fit in the specified

First, the "Each file" should probably be "Each field".

The idea is that they are fixed-length fields, but if the value exceeds
the length of the field, the field will be longer than the standard
length.  For example, assume 9 characters was allocated for file length (I
don't remember how many the draft actually allocated), and the server used
64 bit file lengths and the file happened to be 1.5 terabytes (requiring
13 character positions).  In this case, the length field would be expanded
to 13 positions for that file, and the following fields would be shifted
right by the extra 3 positions (as opposed to e.g. truncating the field).

    Tatu

---

From: Sami Lehtinen <[email-masked]>
Date: Fri, 12 Jan 2001 01:08:43 +0200

Niels Möller, on January 11. 2001, wrote:
  : I've read the draft, and I have a few comments. First, the
  : presentation:
  : 
  : * In section 3, the packet format is describes as follows:
  : I think it would be clearer, and more consistent with the other secsh
  : documents, to include the type byte in the payload.

I agree with you, now that I think about this.

  : * The document would be easier to read if the response (server to
  :   client) messages were described first. There are a large number of
  :   forward references to SSH_FXP_STATUS.

I have no strong opinions about this.

-- 
[[email-masked]          --  Sami J. Lehtinen  --           [email-masked]]
[work:+358 9 85657425][gsm:+358 50 5170 258][http://www.iki.fi/~sjl]
[SSH Communications Security Corp               http://www.ssh.com/]

---

From: Sami Lehtinen <[email-masked]>
Date: Fri, 12 Jan 2001 01:58:49 +0200

Tatu Ylonen, on January 11. 2001, wrote:
  : > I can't understand the final sentence in the description of
  : > SSH_FXP_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."
  : 
  : First, the "Each file" should probably be "Each field".

Ok, changed that.

---

From: Markus Friedl <[email-masked]>
Date: Tue, 30 Jan 2001 11:08:07 +0100

> 6.6.  Creating and Deleting Directories
> 
> New directories can be created using the SSH_FXP_MKDIR request.  It has
> the following format:
> 
>   uint32     id
>   string     path

the existing clients sftp-also send file attributes when
creating a directory:

    ATTRS      attrs

does this behaviour changed with the draft? or is the draft
just incomplete?

i vote for including ATTRS (with SSH_FILEXFER_ATTR_PERMISSIONS)
in SSH_FXP_MKDIR, this is also consistent with SSH_FXP_OPEN.

-markus

---

From: Tatu Ylonen <[email-masked]>
Date: Wed, 31 Jan 2001 02:07:56 +0200 (EET)

I think it is an error in the draft.  I tried to make it upwards
compatible with current SCP, and apparently forgot the ATTRS for MKDIR.  
It clearly makes sense to send the attributes also when creating a
directory, since directories have permissions etc.

    Tatu