Subject: RE: Line termination philosophy [Re: I-D ACTION:draft-ietf-secsh-publickeyfile-08.txt]

From: "Glen Matthews" <[email-masked]>
Date: Fri, 8 Apr 2005 09:38:40 -0400

Hi,

>Is anyone on this list (which seems to include most SSH implementors)
going >to
>have their SSH implementation inconvenienced by the current text?  That
is,
>does it affect any real SSH implementation?  If it directly affects
your >code,
>please let us know.

  I agree the debate is silly, but I certainly don't want to have to
support so-called flat files using the equivalent of lrecl and recfm (I
used to program on MVS a few, well, quite a few, years ago). I did this
once for an ftp implementation and would rather never do it again. To
convert data between systems is damn annoying, frankly - eg ASCII vs.
EBCDIC - and why we'd wish this upon ourselves is mystifying. I supposed
the point of standards was to make specs system independent. 

  As far as I am concerned, to support anything *other* than the current
draft recommendations of <CR> and <LF> combinations would seriously
inconvenience my implementation. And I frankly probably wouldn't bother
unless a customer specifically requested this. 

  Clearly, the ambiguity in the <CR> and <LF> characters is designed to
satisfy *nix and MS systems. I'd prefer just one, and don't care which.

Glen Matthews
Hummingbird

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 08 Apr 2005 13:06:14 -0400

> satisfy *nix and MS systems. I'd prefer just one, and don't care which.

OK; this is starting to get out of hand.  We are debating a solution 
without a clear or consistent view of the requirements.  So, let me ask a 
question...

Are we specifying a local storage format, or a portable interchange format?

If we're specifying a local storage format, then it should be defined in 
terms of lines, using whatever the local conventions happen to be.  The 
document should make no mention of line terminators.

If we're specifying a portable interchange format, then it is essentially a 
wire protocol, and we must specify the exact format of the octet stream 
that will actually be exchanged, via whatever protocol (http, ftp, scp, 
email).  If it's going to be text-based, then we should REQUIRE that lines 
be separated by the Internet-standard line terminator, which is CRLF.  We 
should also RECOMMEND that implemenations be able to handle CR-only and 
LF-only line terminators, because doing so will likely increase 
interoperability.  We should probably also consider registering a MIME 
type.  (application/ssh-public-key ?)

Now, which is it?

-- Jeff

---

From: Joseph Galbraith <[email-masked]>
Date: Fri, 08 Apr 2005 11:17:56 -0600

> without a clear or consistent view of the requirements.  So, let me ask 
> a question...
> 

portable interchange format.

> If we're specifying a portable interchange format, then it is 
> essentially a wire protocol, and we must specify the exact format of the 
> octet stream that will actually be exchanged, via whatever protocol 
> (http, ftp, scp, email).

Exactly.

> If it's going to be text-based, then we should 
> REQUIRE that lines be separated by the Internet-standard line 
> terminator, which is CRLF.

This is what I'm leaning towards doing.

 > We should also RECOMMEND that implemenations
> be able to handle CR-only and LF-only line terminators, because doing so 
> will likely increase interoperability.

This seems reasonable... so basically, we are just relaxing the
requirement to be able to read all three formats to requiring
CRLF, but recommending the other two.

> We should probably also consider 
> registering a MIME type.  (application/ssh-public-key ?)

How do we do this?  Do I just add a note in the iana consideration
section, or is there other stuff that needs doing?

Thanks,

Joseph

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 08 Apr 2005 13:23:33 -0400

> section, or is there other stuff that needs doing?

See RFC2048 and the other references mentioned in
<http://www.iana.org/cgi-bin/mediatypes.pl>

---

From: [email-masked] (Markus Gyger)
Date: Fri, 8 Apr 2005 23:34:05 +0200 (CEST)

Jeffrey Hutzelman writes:
> If it's going to be text-based, then we should REQUIRE that lines 
> interoperability.

Unicode has also some recommendations in the 4.0
book chapter 5 ("5.8 Newline Guidelines" pg 116):
http://unicode.org/versions/Unicode4.0.0/ch05.pdf

Markus

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 09 Apr 2005 22:05:55 +1200

"Glen Matthews" <[email-masked]> writes:

>I agree the debate is silly, but I certainly don't want to have to support
>so-called flat files using the equivalent of lrecl and recfm (I used to
>program on MVS a few, well, quite a few, years ago).

Even under MVS, wouldn't "rb,byteseek" (for read) and "wb,byteseek,recfm=*"
(for write) take care of it?  That's what I've been using, and it works fine
(at least for OpenPGP, S/MIME, and PKCS #15 files), provided you remember to
convert the charset to/from EBCDIC, which is another thing the spec would have
to cover if you wanted to get that pedantic about it.

Actually come to think of it [pause, sfx = keyboard allegro prestissimo] yep,
my code's been using SSH text-format keys under MVS since one of the early
drafts for this appeared, despite the potential file-format and EBCDIC issues
this hasn't caused any problems.

Peter.