Re: Additional thoughts on text transfers

[nico <nico%verizon.net@localhost>]

On Tue, Apr 02, 2002 at 09:00:25AM -0500, Richard Whalen wrote:
> > Then why does everybody write lines and lines of email instead of
> > writing a draft using the mechanisms provided by
> > 	draft-ietf-secsh-filexfer-02.txt
> > 
> 
> The mechanisms provided by draft-ietf-secsh-filexfer-02.txt fall short of
> what is needed to provide a text transfer mechanism.
> 
> The file attributes mechanism has plenty of flexibilty to present
> information about the type of information in the file, and whether or not
> any translations can be provided.  Right now it says nothing about the type
> and that no translations are available.

I don't see why the attributes wouldn't suffice for the case of ASCII
text files:

Unix client: open(some file, write|create|trunc, attrs: {..., content-type:
			text, encoding: ASCII, eol: LF, ...}, ...)

VMS server: OK, handle

client: write(handle, ...)
client: write(handle, ...)
..
server: OK
server: OK
..
client: close(handle)
server: OK
server: <create/truncate the file, write text sans LF and marking the
	 record boundaries where the LF characters were in the original>

client: open(some other file, read)
server: OK, handle
client: stat(handle)
server: OK, attrs: ... content-type: test, encoding: ASCII, eol: X, ...
client: read(handle,...)
..
client: close(handle)
server: OK

Note that the VMS server has to select some sort of EOL marker,
preferably LF :)

> The OPEN/READ/WRITE mechanism is where the problem lies.  It specifies
> particular bytes from the file, and on some systems those bytes may contain
> a mixture of actual data and system specific details.  When those system
> specific details are transfered to a dissimilar system they become at best
> useless. In the worst case they make the entire file useless, as programs on
> the second system do not know to ignore the system specific details and
> declare the file to be corrupt.

If the issue is primarily about VMS text files being record-oriented
with variable length records, one record per line with no EOL
characters, I think that problem can be dealt with as above.

But if you want to generally support record-oriented files, both with
fixed- and variable-sized records, then the file xfer protocol does,
indeed, need to specifically support such semantics. But then, the
necessary changes might be few, particularly if random-access can be
maintained even when reading/writing files with variable record sizes.

A canonical file format (preferably as a stream of octets) is needed for
checksumming.

Perhaps SFTP should move to a different working group :)

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


Cheers,

Nico