Re: SFTP File open modes

[Jeffrey Altman <jaltman%columbia.edu@localhost>]

Nico:

With all due respect, the only entity that can determine the file type
is the system that is sending the file.  What mode the receiver
chooses to store the file with is irrelevant. 

- Jeff


> 
> 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
> > > 
> > 
> 



 Jeffrey Altman * Sr.Software Designer      C-Kermit 8.0 available now!!!
 The Kermit Project @ Columbia University   includes Telnet, FTP and HTTP
 http://www.kermit-project.org/             secured with Kerberos, SRP, and 
 kermit-support%columbia.edu@localhost                OpenSSL. Interfaces with OpenSSH