>>>>> "AK" == Anastasios Kotsikonas <tasos@cs.bu.edu> writes:
AK> I see no need to fake anything, or break RFC 2046.
I never proposed breaking 2046. It only gives an example, it does not
dictate what must be done. If you have no text/plain parts to include, you
don't have to do anything like what 2046 outlines.
AK> Perhaps I do not understand why 2046 is not good enough for you vis a
AK> vis MUAs who can decode it correctly.
2046 is great. The example given in 2046 is not so great, IMHO, because
it's needlessly complex. There's no point in _asking_ for MUAs to screw
things up.
AK> Yes I've seen the problems from the nesting, but that should not be
AK> *your* problem.
All problems resulting from messages I generate are indeed my problem, at
least from a user's standpoint. Whether I choose to do something about
them is another matter; I will make accommodations for stupid MUAs only as
far as it doesn't harm things for good MTAs. If possible, I think it smart
to at least make the effort to avoid breaking things when you can.
AK> The trouble with multipart/digest is that it does not allow for
AK> a prelude;
But if I put Date:, From:, To: and a blank line at the top of the index, it
becomes a legal message/rfc822 and can be placed in the digest without
violating RFC2046.
AK> you could of course use multipart/digest from the very start and force
AK> the first and last messages (your prelude and footer) to be text/plain
AK> instead of their default message/rfc822 but that's not the definition
AK> of multipart/digest.
That would be a violation of RFC2046, and I have no intention of doing it.
AK> Now, how do we get the &^%@#$% MS products to decode MIME digests?
Well, that's a more difficult subject. Probably as difficult as moving
Mt. Everest, or BillG's pile of cash (whichever is heaver; I suspect the
latter).
- J<
References:
|
|
