Re: Latest sftp draft-draft...

["Joseph Galbraith" <galb-list%vandyke.com@localhost>]

Since the "newline" extension is sent as part of the
servers version packet to the client, there is not
response.

Since it is sent to the client, there is no request
id to put in a status or SSH_FXP_EXTENDED_REPLY.

So basically, extensions sent as part of the
server version packet are always "informational".

Any other extension must be initiated by the client.
(Well, excpect ATTR extensions.)

- Joseph

----- Original Message -----
From: "Richard Whalen" <Whalenr%process.com@localhost>
To: "'Joseph Galbraith'" <galb-list%vandyke.com@localhost>; <ietf-ssh%netbsd.org@localhost>
Sent: Monday, October 07, 2002 15:16
Subject: RE: Latest sftp draft-draft...


> 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.
>
>