RE: Text file type hint proposal for filexfer

["denis bider" <ietf-ssh%denisbider.com@localhost>]

I guess then it would be wise to shorten my proposed addition and remove this
part:

  Files not advertised by the server as textual in the
  attrib flags MUST NOT be opened with the SSH_FXF_TEXT flag.

And leave only this:

  A server MAY fail textual open requests for files which
  were not advertised as textual in attrib-flags.

I.e. make it clear that the server only NEEDS to support SSH_FXF_TEXT for files
it advertises as textual in attrib-flags. For files of unknown text/bin
disposition, the server MAY support SSH_FXF_TEXT, but does not need to...


> -----Original Message-----
> From: ietf-ssh-owner%NetBSD.org@localhost 
> [mailto:ietf-ssh-owner%NetBSD.org@localhost] On Behalf Of Albert Lunde
> Sent: Monday, October 11, 2004 15:02
> To: ietf-ssh%netbsd.org@localhost
> Subject: Re: Text file type hint proposal for filexfer
> 
> 
> On Mon, Oct 11, 2004 at 04:47:56AM +0200, denis bider wrote:
> > My above proposal is ill-conceived only if there is a 
> platform where:
> > * file type (text/bin) is not determined, and
> > * line endings are not one of LF/CR or a combination (CRLF, LFCR).
> > 
> > If anyone is aware of such a platform, please let me know. 
> If there isn't one
> > though, I suggest the server shouldn't have to support 
> SSH_FXF_TEXT if file
> > type isn't determined. The client can read binary and 
> convert line endings if
> > it so pleases.
> 
> If your are looking for cases that are unlike Unix semantics, I'd
> suggest looking at the IBM mainframe operating systems: CMS,
> TSO, MVS, etc.  One of the cases that appears there is fixed-length
> records with no delimiters in the binary representation.
> This may be blocked (though that's more common on tape devices).
> 
> I think there are also variable-length records with a none-of-
> the-above line representation.
> 
> There are various file attributes, but I wouldn't promise
> that there are no cases where the file format is ambiguous.
> (And of course, the default encoding was EBCDIC.)
> (I, thankfully, haven't had to work on those systems for several
> years, so I can't provide too many details.)
>