Re: Email::Address::XS

On Sunday 11 September 2016 18:58:42 Ricardo Signes wrote:
> * [email protected] [2016-09-05T04:25:11]
> > I do not want to add ->as_mime_header (or other function) which will do
> > MIME encoding/decoding into Email::Address::XS. That module is for
> > formating and parsing email addresses headers, not for MIME
> > encoding/decoding. Same as it is for Email::Address module.
> 
> The best way to know how to properly encode a structured header field is to
> know both its structure and the way that the structure ie meant to be encoded.
> For example, to know that a `mailboxes` structure may have a display-name,
> which would be words, which can be encoded, and may have an addr-spec, which is
> not words, and so cannot be encoded.
> 
> Parsing and encoding are not separable concerns, here, because to know whether
> to decode a part, one most know what part it is, which means it has been
> parsed.  You can only properly decode the structured data by knowing the
> relationship between structure and encoding.  Then, you can only encode the
> data by knowing the same.  This means that any interface between Email::MIME
> and some structured field representation has a much more complex API, if
> Email::MIME is responsible for the encoding and decoding.  It doesn't just need
> a map of field name to class name, but also instructions on how structured data
> are encoded and decoded.
> 
> This seems like it becomes a nasty mess of deep coupling.  Am I making some
> fundamental mistake, here?
> 
> Anyway, isn't it certain that people who parse addresses from headers will want
> to get a decoded form?  Surely this will be common:
> 
>   my @recipients = map {; $_->phrase_str // $_->address }
>                    Address->parse( $email->header('To') );
> 
> The Dovecot parser (as I recall) does not decode encoded-words, so phrase_str
> is easy to write.  Does every consumer of Address need to know how to decode?
> Further, won't people want to write:
> 
>   my $to = Address->new("김정은", "[email protected]");
> 
> ...and then pass that object on to something that knows what to do with it?
> Does every possible consumer of Address need to know how to encode an Address
> object?

Yes, this is what I already wrote. User of Email::MIME and Address
modules just want to construct Unicode Address object and pass it into
Email module, without calling any encode/decode functions.

Something like this:

  my $to = Address->new("김정은", "[email protected]");
  $email->header("To", $to);

$to is internally stored as Unicode (no MIME) and $email in final must
be MIME-encoded. So either $email or something between must do that MIME
encoding.

  $to->format()       # will produce  '"김정은" <[email protected]>'
  $email->as_string() # will contains 'To: =?UTF-8?B?6rmA7KCV7J2A?= <[email protected]>'

But as I wrote I do not want to add MIME encode/decode functions into
Address classes and I think that whole MIME encode/decode procedure
should be at one place (something like encode("MIME-Header", $str)).

Currently encoding and decoding MIME words is broken in perl,
Encode::MIME::Header has bugs, so I do not want to see that every
module will be its own decoding and encoding (plus badly).

Email::MIME is good place where can be correct encode/decode
implemented... Btw, I have prepared patches for Encode::MIME::Header so
I hope bugs will be out of perl...

And as I wrote if Email::MIME is not good place, then what about other
modules like Email::MIME::Header::Address (or invent other name) which
will use Address parse/format functions and will also do that MIME
encode/decode procedure? We can maybe add classes also for other headers
(like you suggested for DKIM signatures, etc...).

Dovecot parser does not do anything with MIME. Upper 8bit characters
stay as is unchanged.