Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA Path: utzoo!watmath!clyde!burl!ulysses!allegra!bellcore!decvax!genrad!panda!talcott!harvard!seismo!brl-tgr!tgr!mrose%udel-eecis2.delaware@UDEL-LOUIE.ARPA From: Marshall RoseNewsgroups: net.mail.headers Subject: Re: RFC 934 - Message Encapsulation Message-ID: <8216@brl-tgr.ARPA> Date: Sun, 10-Feb-85 22:32:09 EST Article-I.D.: brl-tgr.8216 Posted: Sun Feb 10 22:32:09 1985 Date-Received: Wed, 13-Feb-85 02:45:25 EST Sender: news@brl-tgr.ARPA Organization: Ballistic Research Lab Lines: 52 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