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

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

der Mouse wrote:
> I don't know what you think a text file is, but back when I used VMS,
> and as I understand the terms, it had record-format files that *were*
> text files: one of the ways of storing a text file - the commonest, if
> my memory from then is accurate - involved records with lengths
> associated with them, each line being its own record.

Yes.  Each 'line' is preceeded by a two-byte, big endian, length
field, and has no delimitting sequence.  An interesting side effect
is that if you accidentally transfer a binary file in text-mode, it
can often be repaired.

Shall I include this format in the draft and require that
implementations be able to read files in such a format?

I believe that the current draft specifies cr, crlf, or lf for
a very good reason--

I suppose we could have require that any transport translate
from the source to the destination text formats.  In which
case we could omit specifying how lines are delimitted and
leave that as an implemenation detail.

However, that wasn't the route we chose to take.

> > [...] and I don't care how it stores its files, this isn't an issue.
>
>
> So anything you don't care about isn't an issue?  That's
> an..interesting..point of view.
>
> But your remark actually reinforces my point of view: you *don't* care
> how it stores its files - so why should the the publickeyfile spec?
>
>
> > Thus my comment that your objection is ridiculously pedantic - I can
> > claim (for example) that QNX version 2 and earlier use record
> > separators instead of CR or LF and that the spec is therefore
> > completely unworkable for people running QNX on their PC AT, but in
> > practice I think if anyone's still using that they'll be able to
> > cope.
>
> Yes - but they will do so by ignoring that aspect of the spec.

No.  QNX version 2 may not consider a publickey file as a text
file, but that is irrelevant.

SSH implementations on QNX version 2 will read the *binary*
(from QNX's point of view) file containing \r, \n, \r\n.

Such an implementation, if it wishes, might convert publickey files
files to a a format the QNX does consider to be a text file
(by removing the \r, \n, or \r\n delimiters and inserting
record seperators) but this is an implementation detail.

Such an implementation might also choose to support reading
files stored in the QNX native format... again, an implementation
detail.

The whole purpose of the spec is to define a file format that
can be read by multiple implementations, spanning multiple
platforms.

Thanks,

Joseph