-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I see no problem here and no need for any change to the draft or a
product. 66 columns is at least 10 columns shorter than any
conventional recommended line length. If your mailer wrapped that line,
it would be almost equally likely to wrap the ASCII armor itself (65
columns -- 11 less than the OpenPGP limit).
In addition, your claims are patently contrary to the exact words and
spirit of the draft. Please see section 6.3 where it says: "The encoded
output stream must be represented in lines of no more than 76
characters each."
Thus, whatever the problem you are seeing is, and based on observing
the line length used in your own message on this topic, it appears to
be related specifically to a low limit somewhere in your configuration,
it is not a fault of PGP nor the OpenPGP draft.
- - Will
On Dec 9, 2003, at 10:37 AM, Ian Grigg wrote:
It appears that PGP 8 is breaking the spirit and intent
of the ascii armouring format, if not the "letter of the
law."
What it is doing is in essence putting in a Version that
is too long for some mailers' line slicing paramaters.
The result is that people receive this:
-----BEGIN PGP MESSAGE-----
Version: PGP 8.0.2 - not licensed for commercial use: www.pgp.com
qANQR1DBw04Dxrpn2akpjMkQD/457fxRygbnZG7jAssMb4JuMeXqZdXmMhcGetrm
...
-----END PGP MESSAGE-----
Now, reading from the 28th October 2003 draft, it appears
that there is no comment on line length - but there are
comments on the line sanctity and on UTF-8 in the Comment
field that are apropos.
To cut the gordian knot, I propose:
1. changing the comment at the end of p49 to
include a warning on line length:
... The
header lines, therefore, MUST start at the beginning of a line, and
MUST NOT have text following them on the same line (BEWARE OF
USING LINES THAT ARE LONG ENOUGH TO BE SLICED BY MAILERS).
(addition in caps...) (as a suggestion only).
2. moving the "Comment" comment out of that
section and/or expanding it to include a
comment about long lines. Something like:
Armor Header contents are not strictly defined, so may
include UTF-8 strings and long lines.
However, the point of Armoring is to provide a clean
textual representation that survives transport over
pernickety systems such as email. Consequently, if an
Armor Header includes such things as characters outside
the range of US-ASCII or too many characters, the Armored
message may not survive transport.
(At the bottom of page 50.) (because it seems
to apply equally to all armoured headers).
3. It also seemed plausible to put in
"rule of thumb" that the line length
of headers should be no longer than
the ascii armoured body line length.
I'm not wedded to any of those, just
thinking out aloud some thoughts on
improving the ID so it best serves.
iang
PS: To compound this, it appears that GPG
(1.2.2) is also rejecting these messages
out of hand. It would appear that GPG is
in the right here, as there is this strict
rule:
"OpenPGP should consider improperly formatted Armor Headers to be
corruption of the ASCII Armor. ..."
(top of page 50).
- --
Will Price, VP Engineering
PGP Corporation
-----BEGIN PGP SIGNATURE-----
Version: PGP Universal Satellite 1.1.0 (Build 411)
iQA/AwUBP9ZxOKy7FkvPc+xMEQLL6wCg32HE6JlNzuvWscDLSWB6uFiY2IgAn2Bz
QKDr+Pe9H5LUQTrGbbkHpzvf
=aof8
-----END PGP SIGNATURE-----