On Thu, 21 Sep 1995 12:24:04 PST, you said:
The multipart/alternative construct was deemed more useful for backward
compatability to non-MIME readers. This is because the "alternative" part
is in readable ASCII. The use of multipart/signed infers a requirement
that the "signed" text be transported from sender to recipient intact. In
practice, this would cause a tendency to encode the text for transport
rendering it unreadable by non-MIME readers.
A crock, pure and simple.
Either (a) the signed data is text, and can be dealt with as such by non-MIME
readers, or (b) it's a binary object. Not many people can read uuencode
without assistance.
Think about it - if you support MIME, multipart/signed is required to Do The
Right Thing (act as multipart/mixed), so multipart/alternative is not required.
If you don't support MIME, multipart/anything will lose, and you may as well
just send a multipart/signed with a text/plain as the first part. All that
you get out of multipart/alternative is a 133% increase in overhead to support
those lame vendors who do /alternative correctly but botch /multipart.
And I've yet to see *ANY* indications that any vendor actually gets this wrong.
multipart/signed - it's just the right thing to do.
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech