Article View: net.mail.headers
Article #428Re: RFC 934 - Message Encapsulation
From: David Alpern
Date: Tue, 12 Feb 1985 00:30
Date: Tue, 12 Feb 1985 00:30
52 lines
3332 bytes
3332 bytes
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
Technical Details
Message-ID:
<8251@brl-tgr.ARPA>Path:
arc1-ca.pugleaf.net!utzoo!watmath!clyde!bonnie!akgua!sdcsvax!dcdwest!ittvax!decvax!genrad!panda!talcott!harvard!seismo!brl-tgr!tgr!ALPERN%SJRLVM4.BITNET@WISCVM.ARPAShow Full Headers
Complete Article Headers
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: arc1-ca.pugleaf.net!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 <ALPERN%SJRLVM4.BITNET@WISCVM.ARPA> 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