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 Alpern 
Newsgroups: 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