🚀 go-pugleaf

Frank,

    I am aware of the software you mentioned (in particular Mike's
    code), and it is true that everyone who posts digests seems to be
    using the same rules for encapsulating messages into digests. In
    this case perhaps the use of the term "pseudo-standard" by the RFC
    is unfortunate.  Stef and I did not (at least intentionally) ignore
    what others had done and decide to introduce "Yet Another Standard"
    that ignores what's working now.  We went to great lengths to try
    and remain compatible with existing Internet software to minimize
    compliance problems.

    However, there is a larger issue which I am apparently missing in
    the your and Doug's and Barry's comments:

	 It really is unimportant as to the precise string that is used
	 for an EB.  The important thing is that when that string
	 appears in a message being encapsulated into a digest (or
	 forwarding in general), that the encapsulation agent use some
	 escape mechanism to prevent the bursting agent from declaring
	 an end-of-message prematurely.

    Now, if the BABYL software (and any other software used to do
    encapsulation) does that correctly, then the primary motivation for
    the RFC is a non-problem.  Hurrah.  However, I have noticed in the
    past that every now and then a message containing a blank line, a
    line of dashes, another blank line, and a line with something that
    remotely looks like a header slips through digests like HUMAN-NETS
    and TELECOM.  (This isn't an attack against either group, I just
    happen to recall a couple of instances in each list about six to
    eight months ago where this happened). So, there might exist
    "working software", but if EBs aren't byte-stuffed then you can't
    unambiguously de-capsulated messages and "it doesn't work right".

    To repeat (though re-phrase) what the RFCs says and what my last
    message said:

	 All I really want is encapsulation agents to byte-stuff their
	 EBs.  If you want to use 30 or 50 dashes on a line as an EB
	 fine.  That isn't prohibited by the RFC.

    If everyone does the byte-stuffing, then the choice of an EB
    becomes moot.

    As I clear my throat to change the subject, I'm interested if there
    are comments on the unification of forwardings, distributions, and
    blind-carbon-copies.  The latest (and hopefully last) release of
    MH, MH.5 uses encapsulation in the generation of Forwardings and
    BCC:s.  Although it sounds esoteric, being able to recursively
    forward forwarded messages is rather neat.

/mtr