Konrad Rosenbaum wrote:
On Thursday 11 December 2003 19:04, David Shaw wrote:
I disagree we need to change anything here. There is already only one
separator permitted. Using your example:
Version: 1.0.0 non-commercial, upgrade to Version: 2.0.0-commercial
The second instance of colon-space is NOT a separator. It's just part
of the value.
As long as the line is not split, you are correct.
Knowing how coders make different assumptions, and have
different scanning tools available to them, even this could
cause some surprises. For e.g., in list based languages,
popping is more natural than parsing left-to-right.
Here's some perl:
perl -e ' $x = "Version: 1.0.0 non-commercial, upgrade to Version:
2.0.0-commercial"; @a = (split(": ", $x)); $_ = shift(@a); print "$_\n";
/Version/ && print pop(@a), "\n"; '
...
I'm a newbie to implementing OpenPGP - so please forgive me, if my question is
stupid: why consider the additional headers at all? They seem to me to only
have any value to human readers and none at all to OpenPGP itself, since all
important information is already encoded into the binary message blocks (once
you got them out of their armor). Is there any technical reason for the RFC
not saying "Implementations shall ignore header lines."?
This is meta-part of the issue. Currently, the ID says:
"OpenPGP should consider improperly
formatted Armor Headers to be
corruption of the ASCII Armor."
I wonder whether that is too strong. It seems reasonable
to say that implementations may attempt to parse beyond and
ignore improperly formatted headers. Perhaps with warnings.
As we have not gone to any great extent to define why the
optional ascii armour headers are important, it seems odd
to treat them as if they are important enough to be capable
of breaking the armoured message.
iang