Content type hint proposal for filexfer

[Jacob Nevins <jacobn+secsh%chiark.greenend.org.uk@localhost>]

SFTP v4 (draft-ietf-secsh-filexfer-04) added the FXF_TEXT flag to OPEN
to allow the client to request that the server open a file in text
mode.

However, no means is provided for the server to advise the client on
whether this transfer mode is appropriate. In all cases it is likely
up to the user to manually specify which mode to use.

In FTP, this has tended to lead to corrupted file transfers when
unintentional translation took place, etc.

The following proposal allows the server to optionally communicate
this information to the client via attributes. (Since it's an
attribute, the client can also manipulate it on the server as far as
is specified here if it corresponds to metadata there.)

To section 5 "File attributes", 2nd para, add:

        byte     content_type         present only if flag CONTENT_TYPE

To section 5.1 "Flags", add:

        #define SSH_FILEXFER_ATTR_CONTENT_TYPE      0x00000004

Add new section after section 5.7 "ACL":

5.x Content type

   The `content_type' field, if present, indicates whether the file is
   known to be a text file, known _not_ to be a text file, or is of
   unknown content.  When sent from server to client, it acts as a
   hint to the client as to whether a file should be opened in
   SSH_FXF_TEXT mode.  The following values are defined:

        #define SSH_FILEXFER_CTYPE_UNKNOWN         0
        #define SSH_FILEXFER_CTYPE_BINARY          1
        #define SSH_FILEXFER_CTYPE_TEXT            2

and probably add some words to the description of SSH_FXF_TEXT in
section 6.3 "Opening, Creating, and Closing Files" -- something like
"Clients MAY decide whether to use SSH_FXF_TEXT based on a previously
seen `content_type' attribute."

(Of course, this could all be easily reformulated as an extension
attribute if desired.)

Warts with this proposal:

It's unfortunate that this can't be made atomic within the existing
protocol design; it requires participating clients to do a STAT or
similar before OPEN.
(In fact, perhaps there should be some guidance on which of STAT or
LSTAT to do in this case.)
I don't know whether the non-atomicity would be a problem in practice.

It's rather tempting to use the IETF's usual content-type notation,
"MIME types" (RFCs 2045-9 and related standards). However:
 - I don't know of any real filesystems which use it.
 - Consider "multipart/mixed" and friends.
 - Does everything in "text/*" want to be opened FXF_TEXT?
 - Does everything outside "text/*" _not_ want to be opened FXF_TEXT?
   (Excluding composite types like multipart.)
 - It risks adding further to SFTP's bloat if not specified carefully.
   We don't want to end up accidentally requiring implementations to
   contain entire MIME implementations (or more likely, ill-defined
   subsets thereof with poor interoperability).