Tim Legant <[EMAIL PROTECTED]> writes:
> Do you have any reason to believe there would be more than two?
I think the most common usage will be one or two only, but the
possibility is there for more should the user desire this.
> In other words, are you planning on using the domain of the sender
> address to grab one language and add English on top of that
I don't think I'll build this into TMDA as it will be so easy to do
from the user's .tmda/config. I'll probably just provide some sample
code or something. Otherwise, I'd have to guess again whether English
should come first or last, and I don't want to do that.
> I ask because I'm curious just how many parts are likely to be
> included in the mail. If there are only two or three, multipart/mixed
> doesn't seem too onerous.
Take a looksee at rfc 1892 (it's short) if you're curious. That rfc
defines 2-3 parts:
1. The report (like the confirmation request)
2. A machine parsable message/delivery-status part containing
processing details.
3. Optionally, the sender's original message or message headers.
Part 1 can in turn have multiple subparts if multiple translations of
the report are included. MUA's show multipart/alternative as only one
part, so no matter how many translated subparts are included, the
whole will still only have 3 parts.
On the other hand, if a multipart/mixed part is used for #1 instead,
all subparts will be expanded adding to the whole.
Even with multipart/mixed, I'm thinking the vast majority of messages
will only contain 4 parts max (2 languages + the rest). The
possibility exists for more, but I don't think it's necessary. Most
Internet e-mail users are able to read English, and the native
language is just gravy. This can be mentioned in the documentation to
deter users from adding 15 languages.
> Also, is it true that if the MUA doesn't understand MIME they'll see
> the first one?
Depends on how the MIME message is constructed. In the rfc 1892 thing
I'm considering, they will be shown the first text/plain subpart as
the raw text is spit out.
multipart/report (top level container)
multipart/alternative (one or more confirmation requests)
text/plain (confirmation request #1)
text/plain (confirmation request #2)
message/delivery-status (delivery status report)
message/rfc822 or text/rfc822-headers (sender's original)
I don't want to leave non-MIME readers out in the cold, but I wonder
how many really exist? I'd say very few these days.
> I thought there was a non-MIME section, before the MIME parts, that
> is the traditional text body of a message and MIME-unaware MUAs
> generally showed that.
I'm not sure what you mean.
_________________________________________________
tmda-workers mailing list ([EMAIL PROTECTED])
http://tmda.net/lists/listinfo/tmda-workers
