RE: Latest sftp draft-draft...

[Richard Whalen <Whalenr%process.com@localhost>]

The response to the "newline" extension is not defined.

Clearly, an implementation that doesn't include this will respond with
SSH_FXP_STATUS of SSH_FX_OP_UNSUPPORTED, but should an implementation that
supports it respond with SSH_FXP_STATUS of SSH_FX_OK, or
SSH_FXP_EXTENDED_REPLY plus some undefined request-specific data.

4.3 Determining Server Newline Convention

   In order to correctly process text files in a cross platform
   compatible way, the newline convention must be converted from that of
   the server to that of the client, or, during an upload, from that of
   the client to that of the server.

   Versions 3 and prior of this protocol made no provisions for
   processing text files.  Many clients implemented some sort of
   conversion algorithm, but without either a 'canonical' on the wire
   format or knowledge of the servers newline convention, correct
   conversion was not always possible.

   Starting with Version 4, the SSH_FXF_TEXT file open flag (Section
   6.3) makes it possible to request that the server translate a file to
   a 'canonical' on the wire format.  This format uses \r\n as the line
   separator.

   Servers for systems using multiple newline characters (for example,
   Mac OS X or VMS) or systems using counted records, MUST translate to
   the canonical form.

   However, to ease the burden of implementation on servers that use a
   single, simple separator sequence, the following extension allows the
   canonical format to be changed.

   	string "newline"
   	string new-canonical-separator (usually "\r" or "\n" or "\r\n")

   All clients MUST support this extension.

   When processing text files, clients SHOULD NOT translate any
   character or sequence that is not an exact match of the servers
   newline separator.

   In particular, if the newline sequence being used is the canonical
   "\r\n" sequence, a lone \r or a lone \n SHOULD be written through
   without change.