Subject: draft-ietf-secsh-publickeyfile-00.txt

From: "Todd T. Fries" <[email-masked]>
Date: Wed, 24 Jan 2001 10:38:57 -0600

It's been brought to my attention that this draft is still open for comment.

I come from a UNIX background (OpenBSD specifically) and it seems rather
strange for a standard to state:

	`MUST be terminated with a <CR><LF>'

then later

   Because current practice is to terminate lines with <LF> only,
   implementations SHOULD be able to read files with lines terminated
   only by a <LF> for backwards compatibility reasons.

Ok, so we are suggesting that we have a file that is readable with <LF> eol,
and the clients should always, for backwards compatibility, be able to
read that file, but new files should be generated with `<CR><LF>'?

I fail to see the necessity or logic this follows.  If the client should
read either format, then it would be my two cents worth that the draft
should allow either format, given the obvious benifit of allowing files
to be exchanged between different os types that prefer different `native'
textfile formats.  Why should you mandate one over the other?  And if
you were to mandate one, why pick the one that carries extra size with it?

Besides my not liking <CR><LF> on unix, there exists a behavior of many
unix people that might cause problems if the mandated format ends in
<CR><LF>.  That is to remove the <CR> every time a text file is
encountered that contains one, since it wastes space and looks rather
ugly in editors.

So not only does it not make sense with respect to filesize increase,
it also will cause problems for users of unix everywhere if they don't
know that the <CR> really belongs in a text file.

Please reconsider the manditory <CR><LF> and allow either, suggested
new wording:

3. Key File Format

   SECSH implementations must share public key files between the client
   and the server in order interoperate.

   A key file consists of a sequence of lines, each of which MUST be
   terminated with a <CR><LF> or a <LF> and MUST NOT exceed 72 bytes in
   length (excluding the <CR><LF> or <LF> line terminator.)

   Implementations MUST be able to read files with lines terminated
   by a <LF> or a <CR><LF> for compatibility reasons.

There are other locations where <CR><LF> exists in the document, I
am certain that if the above is accepted that they will be changed
similarly.

The other alternative is to not deviate from the current practice
referred in the original wording:

	Because current practice is to terminate lines with <LF> only

Either way makes sense to me, but if people desire <CR><LF>, I hardly
think it should be a mandate; rather an option.

Thanks,
-- 
Todd Fries .. [email-masked]

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 24 Jan 2001 16:53:28 -0500

I think a better way out of the line-terminator morass is for the
draft to say as little as possible about line termination and just
specify that this is a text file format.

Files in this format should therefore be transferred as text files
(sequences of lines, which are sequences of printable characters), not
binary files.

Since people commonly forget to do this, implementations SHOULD be
robust in the face of unexpected line terminators (CR only, LF only,
or CR LF).

					- Bill

---

From: "Jeff P. Van Dyke" <[email-masked]>
Date: Wed, 24 Jan 2001 18:47:48 -0700

> specify that this is a text file format.

I think just saying it is a text file is a mistake.

> (sequences of lines, which are sequences of printable characters), not

Unlike FTP, sftp doesn't distinguish between ASCII
and BINARY.

If you're going to upload your public key with sftp
or scp2 from a Windows box to a UNIX box (or visa versa),
where does the line terminator get fixed?

> robust in the face of unexpected line terminators (CR only, LF only,

Protocols like SMTP, IMAP and SSH2 (at least for the ident
string) require both <CR><LF>.

If the current draft requiring <CR><LF> as the line terminator
isn't acceptable to majority of the WG, I think we should require
implementors to support both <CR><LF> and <LF> .

Jeff P. Van Dyke
[email-masked]

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 24 Jan 2001 21:36:26 -0500

> Unlike FTP, sftp doesn't distinguish between ASCII

maybe we should fix this rather than overspecifying things in the key
file format..

						- Bill

---

From: "Jeff P. Van Dyke" <[email-masked]>
Date: Wed, 24 Jan 2001 20:01:27 -0700

> maybe we should fix this rather than overspecifying things in the key

I consider mentioning this.  I'm not sure which is a
bigger can of worms.  Maybe one of the authors of the
sftp draft could comment...

Jeff P. Van Dyke
[email-masked]

---

From: David Terrell <[email-masked]>
Date: Wed, 24 Jan 2001 19:48:22 -0800

> string) require both <CR><LF>.

This is on the wire, not a local file.  And yes, <CR><LF> is the
common EOL for wire protocols.

> implementors to support both <CR><LF> and <LF> .

And <CR> for Macintosh-origin files, so we're right back to what
Bill suggested.

Dave, not a mac bigot, just amused at EOL madness.

-- 
David Terrell   | "The reasons for my decision to quit were myriad, but 
Nebcorp PM      | central to the decision was the realization that there are 
[email-masked]    | two kinds of companies:  Good ones ask you to think for 
wwn.nebcorp.com | them.  The others tell you to think like them." -Benjy Feen

---

From: Tatu Ylonen <[email-masked]>
Date: Thu, 25 Jan 2001 15:35:19 +0200 (EET)

> maybe we should fix this rather than overspecifying things in the key

The file transfer protocol was designed to handle all files as binary
data.  In my opinion this was one of the best things in the original
Unix file system design.  The client is free to implement any
conversions locally, but such conversions will not affect the protocol
or the server.  This was a conscious design choice in the protocol.

Doing e.g. newline conversions at the server would e.g.

  - make it very hard to restart large transfers which may have been
    aborted

  - break the file offset addressing model used in the protocol (note that
    it is essentially the same model used in POSIX file I/O)

  - increase cpu consumption on the server (probably not significant)

Most MSDOS programmers I know of automatically add the "b" (binary) flag
to every fopen call they write...

Anyway, I think the client is the right place to do the conversions.

    Tatu

---

From: "Jeff P. Van Dyke" <[email-masked]>
Date: Thu, 25 Jan 2001 06:43:27 -0700

> Anyway, I think the client is the right place to do the conversions.

How does the client know if the text file is being transferred
to a server running Windows NT, UNIX or ...?

Jeff P. Van Dyke
[email-masked]

---

From: Markus Friedl <[email-masked]>
Date: Fri, 26 Jan 2001 11:49:43 +0100

> to a server running Windows NT, UNIX or ...?

i think this is what SSH_FILEXFER_ATTR_EXTENDED is for.

-m