Additional thoughts on text transfers

[Richard Whalen <Whalenr%process.com@localhost>]

Since modern day files may be encoded in a variety of textual formats the
client and server need to come to an agreement on a format when exchanging
text files.

To provide a mechanism in which methods acceptable to both the client and
server can be negotiated, I suggest the following extension data be defined
for the SSH_FXP_INIT and SSH_FXP_VERSION packets
	extension_name TEXT-TRANSFERS
	extension_data <comma separated list of ISO Latin 1 names for text
formats>  (e.g. ASCII, ISO-LATIN-1, UNICODE, EBCDIC)

The INIT packet may contain the list of formats that it would like to
support. The VERSON packet contains the list of formats that server can
support that are in the list that the client asked for.  If none are
presented, then ISO-LATIN-1 is assumed.

Add an extended file attribute with the name (type) TEXT and the data
consisting of a comma separated string in which the first element is the
format that the file is currently stored in, and the following elements are
formats that the file can be translated to by the OPEN/READ/WRITE functions.

To the OPEN packet add an extended attribute of TEXT that specifies the text
format desired for opening the file.  If the file can not be opened in the
requested format, the unsupported status is returned.

Add FXP_TEXT_READ (as Simon Tatham suggested) that specifies the file
handle, an opaque file position, and the maximum number of 8 bit bytes that
should be returned in the FXP_TEXT_DATA function.  The file position is a 32
bit integer with the value 0 (zero) defined to be the start of the file.
All other values are considered to be opaque and manipulation of them by the
client may cause an error or unpredictable results.  Multiple reads with the
same file position value will return the same data, as long as the file has
not been modified by an I/O stream. While not all characters in all sets
will be specified in an 8 bit byte, it places an upper bound on the amount
of buffers that should be committed.

The FXP_TEXT_DATA returns the file handle, the opaque file position for the
start of the next read, an integer that specifies the number of lines of
text, and a string for each line of text.  By specifying separate strings
for each line of text the client does not need to scan the data to insert
the appropriate line separating sequence for a file stored on its system.
It also provides a method for an implementation to store data with line
separators even if it can not interpret the data provided that the file
attributes can be properly set to note the type of data stored in the file.

The FXP_TEXT_WRITE packet contains the file handle, an opaque file position,
the number of lines of text present, and a string for each line of text.
Again, this allows the system storing the data to store it in an appropriate
manner without scanning.  If the file position has the value zero, then the
beginning of the file is being specified, all other values can not be
interpreted.

The FXP_STATUS response to the FXP_TEXT_WRITE would need to carry an new
value for the file position that is the next available position to write
when the file is being accessed sequentially.

----------------------
Richard Whalen
Process Software