🚀 go-pugleaf

I have to agree with David Alpern.  A common two-character sequence
should not be pre-empted this way.  A longer sequence is less likely to
be used in messages.

Actually, the problem is not in the sequence chosen.  The problem is
that it is not possible for the Bursting Agent to tell whether the
sending software includes an Forwarding Agent.  If not, then the sender
won't have translated lines beginning with a hyphen, but your reader
will decide that the message contains encapsulated messages and burst
it.  The right solution is to require Encapsulation Agents to add a
header field, such as

Encapsulation-Boundary:  <string>

If this header field is not present, then the message does not contain
an RFC934-conformant encapsulation, and the Bursting Agent should just
pass it through unchanged.  If it does, then a line beginning with
<string> is an encapsulation boundary.  As in the original RFC, if the
<string> is followed immediately by a space then it is an escape prefix
and the Bursting Agent should merely remove it from the text.

I don't really think it is important that the EB be variable, as in my
example.  The only reason I included that capability was because I was
inventing a header field and I couldn't think of anything else to put
there.  Another possibility is:

Encapsulation-Mode:  RFC-934

which allows for future enhancement of this protocol.
                                        barmar