Re: SFTP File open modes

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

This can work:

 - clients (optinally) tell the server the content-type/encoding of any
   files the clients open for writing, with an option available for the
   client to specify that no conversions must take place (the
   content-type/encoding may be useful even if no conversions are
   allowed or possible)

 - servers (optionally) tell the clients the content-type/encoding of
   any files that the clients open for reading

 - both clients and servers are allowed to perform conversions
   before/after the file xfer, but neither is required to; clients are
   responsible for any conversions when they read files and servers are
   responsible for any conversions on files written to by clients.

 - VMS servers, for example, would set the file type and record lengths
   appropriately when clients write ASCII text to them, and Windows
   servers might convert LF to CR/LF when clients write Unix ASCII text.
   Similarly for clients.

 - perhaps an additional message by which clients/servers can tell each
   other what content-type/encoding they intend to convert a given file
   would be useful as well

The only new requirement imposed by the above on implementations is that
they parse the new open message file attrs. The spec would absolutely
not require that implementations support any kinds of conversions.

The file xfer protocol would be left pretty much alone - only the file
open protocol would be modified, and then only in a way that makes
sense.

Besides, this can be done with new file attribute definitions. The
protocol can already handle this.

Cheers,

Nico


On Mon, Apr 01, 2002 at 09:51:18AM -0500, Richard Whalen wrote:
> Since both the client and server access files, you can not put the
> responsibility for doing conversions on either and "solve" the problem.
> Requiring the client to do it means that the client must know about all
> possible formats.
> 
> You can say that encoding conversions are the responsibility of the reader
> (or writer, take your pick) of the file if a common wire format is agreed
> upon for certain types of files. (Text in this discussion.)
> 
> > -----Original Message-----
> > From: nico [mailto:nico%verizon.net@localhost]
> > Sent: Friday, March 29, 2002 10:13 PM
> > To: Richard Whalen
> > Cc: 'ietf-ssh%netbsd.org@localhost'
> > Subject: Re: SFTP File open modes
> > 
> > 
> > 
> > How many well-known and often utilized ways of encoding ASCII 
> > text files
> > are there (answer: two)? Is an ASCII mode as you suggest likely to be
> > useful? Or do we want a mode for UTF-8 and UTF-16, EBCEDIC, and so on?
> > 
> > Perhaps it would be best to add an operation by which the 
> > client can ask
> > the server for a given file's content type and encoding. The server's
> > response should indicate whether it knows, whether it knows 
> > for certain
> > and, if it knows at all, what the content type is.
> > 
> > All encoding conversions though should be left to the client though.
> > 
> > IMHO. Cheers,
> > 
> > Nico
> > 
> > On Wed, Mar 27, 2002 at 02:36:06PM -0500, Richard Whalen wrote:
> > > The current specification of SFTP states that files are 
> > always opened in
> > > "binary" mode - no translations between different character 
> > sets and newline
> > > encodings.
> > 
> > [...]
> > 
> > > ----------------------
> > > Richard Whalen
> > > Process Software
> > > 508-879-6994
> > 
>