I'm gearing up to implement RFC1153 digest generation and full digest
delivery. I've cut a new snapshot, which is in
ftp://ftp.hpc.uh.edu/pub/majordomo/ to get all of the bug fixes that I've
made recently out to non-CVS-users. Things are likely to destabilize a bit
while this delivery engine overhaul happens.
I'm disturbed by the toxicity to MIME that RFC1153 seems to mandate. This
is the relevant text:
Each enclosed message is a conventional message consisting of a header
and body, separated by a blank line. If they exist in the original
message header, the following lines must be retained as-is in the
reconstructed header: Date:, From:, To:, Cc:, Subject:, Message-ID:, and
Keywords:, rearranged to appear in that order. Retaining the Summary:
line is optional. Lines include continuation lines as defined in the
RFCs. All other header lines should be discarded, especially Received
lines. All leading and trailing blank lines should be removed from the
message body. The message body may be scanned to replace with a blank
the first character of any lines of exactly and only 30 hyphens.
Note that Content-*: and MIME-Version: "should" not be included. I wonder
if it warrants bending the "should" in this case isn't warranted given the
benefits of allowing MIME to pass without being screwed up. Are there any
clients that can deal with MIME in 1153-type digests? Are there clients
that simply can't handle them if they're there? Are there any MLMs that
pass the MIME headers through in 1153-type digests?
If there are clients that can deal with it, the argument is strong. There
is no 'must', just a 'should' (which could be interpreted as allowing
future standard headers if necessary), and the document was written before
the days of MIME. I'm generally for strict standards adherence, but I
wonder if in this case it isn't doing more harm than good.
- J<
|
|
