David Shaw wrote:
...
but, as Ian pointed out, if the maximum number of columns is
limited to the minimum number of columns in an armored message
(i.e., 64 characters)
then any 'wrap' that accepts the message block, would have no
problems
with the comment or version lines,
That is not true. Armor does not allow spaces, so it's essentially a
64 character long "word". Most editors only break on spaces. They
won't break words to wrap them.
The operative word there is 'most'. In email
for example, URLs that go over the length limit
are often sliced, hence some people send "tiny"
URLs.
Also, there is another artifact. Even if the
transporting app doesn't slice your armour lines
in half, it may insert extra lines or spaces as
if it was slicing it in half.
Which brings me to another point: Whatever slicing
it does, if it *only* inserts whitespace, what you
can then do is strip out *all* whitespace and you
are left with pure armour. It's possible to parse
that as a single block, as the original line length
is not part of the armour itself.
However, this strategy is only possible if you can
easily identify the start and end of the armour.
Which means we have to be quite clear about how
the BEGIN, END and Comments: sections are organised.
The less flexibility the better there - I'd not be
keen on any multiline MIME-style overflow.
Just some thoughts.
iang