Re: SFTP File open modes

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

On Sat, Mar 30, 2002 at 10:32:15AM -0600, Albert Lunde wrote:
> * First, one should distingush between a literal _ASCII_ mode, and a
> _text_ mode.
> 
> The most specific proposal posted suggested using Latin-1 as a
> least-common-denominator wire encoding, with a bunch of negotiated
> alternatives. In this day and age, I think it would make more sense
> to use something like UTF-8 (further spectified to reduce ambiguties).
> 
> I count at least three widely-used ways of encoding end-of-lines with
> characters (CR,LF, CRLF) plus fixed-length records, plus counted
> varable-length records: I don't know what you are thinking of in
> saying "two".

I confess: I was thinking DOS vs. Unix (CRLF vs. LF).

> * Text mode is a big win in the case of an OS which has files in some
> well-known but ideosyncratic format, because the clients don't have
> to say, know all the varients of EBCDIC or VMS record formats, just a
> single wire format.

As someone else just pointed out, nowadays text documents come in
complex binary formats such as PDF and what not.

I think having dos2unix and unix2dos support in the client would be nice
for us *nix types. But I can do without. And certainly I don't think
this belongs on the server side.

> * But I think you've got a point that a server may not _know_ the
> encoding of files, or may not want to support the overhead of a text
> mode.
> 
> I don't know any foolproof way to detect which files in my Mac are in
> Mac-extended-ASCII, which are in Latin1, and which are in Shift-JIS
> (because I've been running the Japaneses language kit on on of my
> Macs for years). The Mac type/creator scheme is more or less
> orthogonal to i18n issues.

Heh. Good luck.

> So this isn't something we should expect to be able to implement on
> every server, or for every file.

Or any file types at all, not in the server, or rather, not in the
protocol. Having the server identify file types would facilitate
client-side file type conversions - having the server do the type
conversions (as proposed) complicates the protocol. Any conversions
should be optional (i.e., MAY).

> -- 
>      Albert Lunde         Albert-Lunde%northwestern.edu@localhost (new address)
>                           Albert-Lunde%nwu.edu@localhost (old address)
> 

Cheers,

Nico