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!ALPERN%SJRLVM4.BITNET@WISCVM.ARPA From: David AlpernNewsgroups: net.mail.headers Subject: Re: RFC 934 - Message Encapsulation Message-ID: <8251@brl-tgr.ARPA> Date: Mon, 11-Feb-85 19:30:24 EST Article-I.D.: brl-tgr.8251 Posted: Mon Feb 11 19:30:24 1985 Date-Received: Thu, 14-Feb-85 02:58:24 EST Sender: news@brl-tgr.ARPA Organization: Ballistic Research Lab Lines: 52 Marshall, I understand your point, in that no digests that I know of prevent a message sender from including a line of 30 hyphens that is not meant as a separator. On the other hand, I don't forsee us ever getting all mail sending and reading programs on the net to "stuff". To do this properly, it would have to be not only digestifiers/ undigestifiers, but all sending/receiving programs since nothing other than the presence of a separator indicates a forwarded message. I disagree that one could use the 30 hyphen field simply as one special case of the single hyphen definition. The problem here is that not all software will be changed at once - you will be lucky if most ever is. How will the first "unstuffer" tell if it has a separator or a text hyphen - i.e. if the sender "stuffed"? Maybe the right thing is to ask all digest creators and mail forwarders to add a hyphen to any line containing exactly 30 hyphens alone in an entering message. This will help avoid the ambiguity, and will be useful even if accomplished in a very gradual manner. I doubt many will care if a line they send as 30 hyphens gets seen as 31, although there always will be somebody. This does lead to a question however -- how do we want to handle a forwarded message being sent to a digest, or otherwise reforwarded? I, for one, would first want to see the complete message (both forwarded and surrounding) as a single entity within a burst digest, and yet would like the ability to burst it again when I desired. Any bright ideas? Maybe using Barry Margolin's header-line specification of separator, combined with some "lenghten the separator for each embedded message level" algorithm will permit this. Regarding the other aspects of the RFC, i.e. treating forwarded messages in the same manner as digests -- I LIKE! I agree that currently forwarded messages are not too useful until one does separate the original text from the surrounding message. There are, however, cases where one would like to reply to both the original sender and the forwarder at once, which is not easy with your scheme as is. As an informal suggestion, I'll comment that both my undigestifier and the similar code I use for forwarded messages (less useful because of less of a pseudo-standard) add a LIST: field to the header of the embedded messages to specify either the discussion group or the forwarding sender, and my reply code notices this. - Dave David Alpern IBM San Jose Research Laboratory, K65/282 5600 Cottle Road, San Jose, CA 95193 Phone: (408) 284-6521 Bitnet: ALPERN@SJRLVM4 CSnet: ALPERN@IBM-SJ