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

[der Mouse <mouse%Rodents.Montreal.QC.CA@localhost>]

>> (1) I point out to you the language about line termination
>> characters, which is unimplementable nonsense on OSes that don't use
>> line termination characters to delimit lines;
> Which OSes can't handle flat text files?

What is a "flat text file"?  You appear to be using it to mean
something close to "file which uses line termination characters to
delimit text lines", which seems..wrong.

> Yes, I know it's possible with a bit of effort to dig up some OS
> relic that has record-format files *alongside text files*,

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.

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

And that is why I think that aspect should be fixed: it unreasonably
and unnecessarily constrains implementations.  Writing the spec such
that the only reasonable way to approximate it on some OSes is by
violating part of it is a Bad Thing, it seems to me, unless of course
excluding those OSes is a deliberate goal.

> The text as is (that is, saying that you need to be able to handle CR
> and/or LF terminators) is just fine,

If that's what it's intended to say, it needs some touchup.  What it
actually says is

   Implementations are REQUIRED to read files using any of the common
   line termination sequence, <CR>, <LF> or <CR><LF>.

Reading this with your interpretation in mind, I can see how it can be
interpreted that way.  But it can also be interpreted as saying that
implementations must treat any of those octet sequences as a line
terminator, even if the file is such that lines are not normally
delimited with line termination octets, which is a peculiar and
unnecessary (and arguably wrong) thing to do for such files.

The rest of the draft also contains language that assumes line
termination characters are used, such as the next sentence

   Implementations may generate files using whichever of these line
   termination conventions is most convenient.

which I argue needs to be rewritten to take into account the
possibility that the "most convenient" format does not use line
terminations at all, but instead, say, record lengths.  As written, I
cannot but read it as specifying that one of those line termination
conventions be used, but exactly which one is chosen is up to the
implementation.  I do think it is possible to serve both this end and
the end this is apparently intended to serve, with language such as

   Implementations for text file formats using line termination
   characters MUST recognize any of the common line termination
   sequences (<CR>, <NL>, or <CR><LF>) as a line termination.  When
   generating such a file, implementations may use whichever sequence
   they find most convenient.

(Note the mnemonic change - when a bare 0x0a is a line termination, it
is more correctly called NL than LF.)

3.3 ("formed by removing the '\' and the line termination characters")
and 3.4 ("MUST NOT be longer than 72 characters excluding line
termination characters") also appear to be written in the assumption
that line termination is in use.  I argue that they should be modified
to fix this.  Specifically, I propose "...the '\' and any line
termination characters" and "...excluding line termination characters,
if any".

Your point about other specs is an interesting one.  It prompted me to
go read 2822 and 2045 with this in mind, and I am surprised and
discouraged to find that those specs do include such specification and
that when they are supposedly applied to local storage, they have thus
been (almost universally, in my experience) "implemented" by ignoring
their line-termination aspects.  Most such implementations are
therefore not implementations of those specs at all, but rather of
closely related specs, never formally codified, which use OS-native
conventions for representing line boundaries.  (The specs as written
generally do apply on the wire, which is the proper place for
specifying line boundary representation.)

I believe that this should be taken not as an indication that it's OK
to write another such spec which will undoubtedly draw similar
not-quite-implementations - especially since this one is not used by a
wire protocol, unlike 2045 and 2822 which are used by the wire protocol
defined by 2821 - but rather as an indication that attempts to specify
such things do not belong in a file-format spec, only in
wire-protocol-format specs.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse%rodents.montreal.qc.ca@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B