Werner Koch wrote:
line<CR> <LF><CR><LF>
It is easier for systems where the line ending is just one character
;-) In practise most systems do that and use LF (is it CR on Macs?).
Life would indeed be easier if everyone
just got the religion, yes. Macs switched
to BSD for OSX, since about 2001, so they
now use LF for many things. No doubt there
is some legacy CR Mac stuff floating around.
Java tries to use LF internally, but sometimes
there are messy conversions and assumptions
applied in some routines that interface with
the outside world.
coding up that sort of thing, I've adopted the strategy
of saying that any change in the nature of the line
endings is treated immediately as a panic (caller to
However we are talking about what we need to hash and we explicitly
want to convert the line for this purposes - that is what textmode is
about.
Reflecting on this, it matters less how it is
defined in the ID on this particular point,
as there will be a signature verify failure
regardless if the recovery goes wrong.
So I withdraw my previous comments w.r.t.
CR/NL being in the list.
In sum, I'm not sure that we want to define whitespace
in this immediate context as including the legal line
ending characters... Comments?
1. Determine the length of the line (according to the convention of
the system the application runs).
Which system? The OS? The language? The
message delivery program? How about this:
1. Convert bytes into character stream
(characters being Unicode).
2. Determine the nature of the line endings
(by reference to the system convention,
to inspection: CR, LF, CR/LF).
3. Break into an array of lines, separating
on the line ending in 2.
4. Trim all trailing whitespace (sp,tab,cr,lf).
5. Add cr/lf to every line except the last.
6. Concatonate the array.
7. Hash.
Mind you, we are now into implementation, which
goes beyond the ID unless people think an
explanatory psuedocode note would help.
iang
PS: btw, I just got a bounce of a mail sent to you
(and CC'd to the PGP users group) in 1997. It came
from some german mail list at
smurf-news-smurf-list-gnupg-devel(_at_)smurf(_dot_)noris(_dot_)de
... what's happening over there?