Re: fixing the current email module

On Oct 9, 2009, at 7:20 PM, R. David Murray wrote:

> IMO, the appropriate way for the email package to provide the API you
> are talking about is it provide the client with a way to get at the  
> raw
> byte string, which I think everyone agrees on.  If the client wants to
> decode it as if it were latin-1 to process it, it can then do that.

I agree.  I'm running out of time to participate in this lengthy  
thread, but I just wanted to say that of the 3 accessors (raw,  
transport-decoded, fully-decoded) I'm not sure transport-decoded is  
all that interesting.  I wouldn't support it directly in the API.  I  
think they library's clients are mostly going to be interested in raw  
or fully-decoded values, and there will be plenty of library utilities  
to get from raw to transport-decoded if they really want it.

-Barry