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!bonnie!akgua!sdcsvax!dcdwest!ittvax!decvax!genrad!panda!talcott!harvard!seismo!brl-tgr!tgr!Margolin@MIT-MULTICS.ARPA From: Barry MargolinNewsgroups: net.mail.headers Subject: Re: RFC 934 - Message Encapsulation Message-ID: <8164@brl-tgr.ARPA> Date: Sat, 9-Feb-85 17:24:38 EST Article-I.D.: brl-tgr.8164 Posted: Sat Feb 9 17:24:38 1985 Date-Received: Mon, 11-Feb-85 04:52:42 EST Sender: news@brl-tgr.ARPA Organization: Ballistic Research Lab Lines: 30 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: 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 is an encapsulation boundary. As in the original RFC, if the 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