RE: Text file type hint proposal for filexfer

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

> > It might be worth spelling out that in the absence of 
> > either of these bits being set, the client SHOULD NOT
> > automatically assume anything about the textiness or
> > otherwise of the file. (The user can tell it, of
> > course.)
> 
> All right; I'll do that.

I would like to note that checking whether the file is textual or not is a
cheap operation only on VMS.

Defining the text/binary hint as a file attribute makes it less likely that
Unix and Windows servers will implement this.

I think we would benefit if it were possible for a client to query the likely
textual or binary state of a file independently of anything else. In other
words, without obliging the server to either show this possibly expensive
information as part of regular easily-obtainable attrib-bits, or not support
this feature at all.

I think the attribute hints are a nice idea and will work for VMS. However for
Unix and Windows servers, we might also benefit from a way for the client to
prompt the server to determine on the fly whether the file is textual or
binary, if the server has not indicated the file type in attrib-bits. This
query would be done right before downloading the file.

If the spec does not provide for this, and only defines the text hints in
attrib-bits, then a complete client implementation wishing to implement
automatic file type conversion will look as follows:
- if server gives text hint, open file in text mode and download;
- if server gives binary hint, open file in binary mode and download;
- if server gives no hint, open in binary mode, then scan bytes received, see
if the file can be recognized as textual, and do conversion on the fly.

Granted, this is much better than what we have now.

However if there was widespread server-side support for a query to determine
file type, the detection and conversion algorithms could be entirely removed
from the client.

The spec already requires servers to implement text file -> canonical format
conversion (the SSH_FXF_TEXT flag). But this feature is useless if the client
cannot query the server for the file type. The attrib-bits hint does not solve
this for Unix and Windows servers because they are unlikely to be able to give
this information as part of attrib-bits. It requires a dedicated request.

My thinking is, either we require Unix and Windows servers to implement both
(a) conversion - SSH_FXF_TEXT flag, AND (b) file type detection; or we should
require them to do neither.

The corresponding solutions are:

(a) Specify attrib-bits as you propose, but also a dedicated file type query
request in case this determination is more expensive.

(b) Say in the spec that SSH_FXF_TEXT need not be supported by servers that
don't send the text hint. The binary hint in this case is also not necessary.
No text hint -> open the file in binary, detect and convert if you please.

The idea is, let's be consistent, and let's not specify things halfway through.

denis