[Email-SIG] fixing the current email module

Glenn Linderman v+python at g.nevcal.com
Sat Oct 10 22:20:02 CEST 2009


On approximately 10/10/2009 8:40 AM, came the following characters from 
the keyboard of Stephen J. Turnbull:
> Glenn Linderman writes:
>  > On approximately 10/9/2009 3:08 PM, came the following characters from 
>  > the keyboard of Tokio Kikuchi:
>
>  > > Your suggestions 1)-4) are not accesptable to Japanese users at
>  > > all.
>
>  > 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 know a fair bit about Japanese (both the language and the users),
> and I'm having difficulty understanding what Tokio means, given your
> list of hypotheses.  I suspect he's basically rejecting the hypothesis
> that it can't be decoded -- if it can't be decoded, then learn how to
> do so!
>
>  > 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,
>
> I agree.  However, I think we're way out of bounds here.  We already
> know how to decode anything that RFC 2047 can throw at us in charsets
> that Python can handle.  Anything that can't be decoded then is
> seriously malformed from the point of view of the mailing list users.
> So why are we discussing this?  We don't even know what our mainline
> APIs are going to look like, why are we discussing forcibly operating
> on broken input?
>   

Use case generation.  If the only way to access header values is to 
successfully, fully, decode them, then some uses may be rendered 
impossible, or at least difficult, even by choice of APIs.


> [[ Aside:
>
>  > with an appropriate translation for "Re: ").
>
> "Re" is a Latin abbreviation; there is no appropriate translation. ;-)
>   

Nonetheless, I have seen both Re: and Fwd: translated to other languages 
(besides Latin or geek) :)
Communication to people with MUAs that do such translations tend to 
accumulate an alternating

Re: XRe: Re: XRe: Re: subject line

because neither MUA will recognize the other translation.

> ]]
>
>  > 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.
>
> Maybe they are, but the email module doesn't know or care about what
> they do.  Let's stick within what the email module is supposed to
> handle

Yep, this is just use case exploration.

-- 
Glenn -- http://nevcal.com/
===========================
A protocol is complete when there is nothing left to remove.
-- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking



More information about the Email-SIG mailing list