David Shaw wrote:
...
Sorry, I should have spelt this out:
On reflection, I think it should not be permitted.
The reason for this is that when you combine
it with the line slicing behaviour, then some
games are possible:
Version: 1.0.0 non-commercial, upgrade to Version: 2.0.0-commercial
Could result in an embarressing split.
Such as:
Version: 1.0.0 non-commercial, upgrade to
Version: 2.0.0-commercial
When the line slicing behaviour is set to (about) column 42.
This isn't very complicated. I'd be quite surprised to hear of any
parser that didn't do:
a) Find the leftmost colon-space.
b) The string to the left is the key.
c) The string to the right is the value.
How do parsers handle the above case? Not that it's
important. The thing to realise here is that the
additional separator's presence, coupled with the
ability of line slicing by mailers, introduces an
exceptional case that's simply better off made
illegal.
The spirit of ascii armouring is to get the message
through in the face of aggressive and unpredictable
actions of many users' mailers. In this case, I
think this spirit is preserved by making the optional
Armor Headings as simple as possible, and encouraging
strict legality.
iang
PS: actually, the above case is "legal". If there
was no separator in the second split line, then
the armouring is broken ("OpenPGP should consider
improperly formatted Armor Headers to be corruption
of the ASCII Armor."), and the message should not be
accepted. But that's hardly a reliable strategy.