On approximately 10/9/2009 3:08 PM, came the following characters from
the keyboard of Tokio Kikuchi:
What you said in message-id: <4ace6f97.6010...@g.nevcal.com> was:
When it is not ASCII, it may still be
separated and recognizable.
and our discussion might be concluded that this is true 'not really, but
only theoretically.' Your suggestions 1)-4) are not accesptable to
Japanese users at all.
There's something I don't understand here, and I'll hope you'll take a
few moments to explain...
If a message with an encoded header arrives (like your number 2 sample)
but it cannot be decoded, what action _is_ acceptable to Japanese
users? And what action is implemented in Mailman (if different)?
I can think of a 5th technique... don't modify the header, and send it
through unchanged. Now I think I've covered the gamut of possibilities,
so if there is one I've missed, I'm extremely interested to learn (or be
reminded) of it.
What I meant by "may still be separated and recognizable", is, in fact,
somewhat theoretical. Since I can't type Japanese, I'll just use a
single accented non-ASCII character in my explanation, but here goes:
Message A arrives at Mailman for distribution. No subject prefix or
numbering. Since it is Mailman doing it, Mailman could notice that the
prefix is like [abcdéfg 126] and must be encoded. Mailman could encode
the prefix as a separate encoded word than the rest of the subject
value. Let's assume that it does.
The rest cannot be guaranteed, because we have no control over the MUA
of the person that replies. But it might come back in the same
manner... one encoded word with the prefix and then the rest of the
subject line, possibly encoded, possibly not. If it does, then if the
first encoded word can be decoded, and the prefix and numbering
recognized, then the modification to assign a new number can be done,
whether or not the remaining part of the subject line can be decoded or not.
So that is what I meant, by the above. It isn't a guarantee in any
manner. It could realistically happen, though, if an MUA simply adds
"Re: " to the front of the stuff that it is passed (or an encoded word
with an appropriate translation for "Re: ").
MUAs or mailing list handlers that decode, process, and reencode, will
probably not produce headers with that pattern, but more likely like the
one you showed in example 2. MUAs or mailing list handlers that attempt
to retain what was sent (idempotency or invertibility), would be more
likely to do what I describe, and are more robust when faced with new
character sets that they don't understand how to decode.
I couldn't resist writing because the discussion was important in
designing Mailman's subject prefixing and numbering. I'll shut up my
mouth again because I'm so busy.
Sorry for disturbing
Thanks for your contribution; I hope for one more, at least.
--
Glenn -- http://nevcal.com/
===========================
A protocol is complete when there is nothing left to remove.
-- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking
_______________________________________________
Email-SIG mailing list
Email-SIG@python.org
Your options:
http://mail.python.org/mailman/options/email-sig/archive%40mail-archive.com
