Re: Email::Address::XS

--C7zPtVaVf+AK4Oqc
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* [email protected] [2016-09-18T11:40:53]
> Currently passing string values of From/To/Cc/Bcc/... headers into=20
> header_str() method is broken in Email::MIME. That is because=20
> Email::MIME currently uses Email::Address for generating those header=20
> values (which is broken) and then MIME encode those broken outputs.
>=20
> Email::Address::XS has (looks like) correctly implemented formatter and=
=20
> so it is needed to correctly MIME encode From/To/Cc/Bcc headers.

I suggest making Email::MIME use Email::Address::XS if it is available, and
adding Email::Address::XS to the recommended prereqs of Email::MIME.
The right behavior will be easy to get, and usually be installed, but it wi=
ll
be possible to proceed with less correct behavior if you haven't got a comp=
iler
(for some sad reason).

Part of the question is: how wrong do things go, in what circumstances, if
Email::Address is substituted for Email::Address::XS.

> As compromise could be: Whole Email::MIME will not depends on module=20
> Email::Address::XS. But if somebody want to pass Unicode string (via=20
> header_str) to Email::MIME then MIME encoding will be done via=20
> Email::MIME::Header::AddressList (which will use Email::Address::XS). So=
=20
> if caller encodes manually From/To/Cc/... headers and pass them via=20
> header_raw() then Email::Address::XS will not be needed.

Specifically, I think, a non-ASCII string.  I'm guessing that most/many use=
rs
are really just passing in fixed ASCII strings, so this rule wouldn't affect
them at all.  Users passing in non-ASCII would start getting a "automatic
encoding of non-ASCII $field header requires ...." error.  Seems okay.

> And can be Email::MIME::Header::AddressList part of Email-MIME=20
> distribution (even if only this module will depends on XS)?

I guess so.  We need to mark this stuff experimental for a while, I think, =
too.

--=20
rjbs

--C7zPtVaVf+AK4Oqc
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJX68W4AAoJEOYby6cMccU5WhsIAMZ9vw0v2/QoPVbrnYLgfix0
DqN3G/SksA9vCmjRg3rUw50RnDn0hssNNJZdKxhdOJ3/voWeH5XuA7WtBcEFWcZp
BIGVlkaYXS5xBg3ihRgZEmg+P9BqNoAol8Wx5LbLH71/44h0t1BjI36DaoQEjUIk
2JyZt8sU7MsEoKI6RzNFOjm1HFBpg7DFcJSgalZaQ7qT8X22DXdFwlhVE4gM80ua
H+ziamL7BttHiHZme0Mes9Puy6JS0Q8eW8hTx4SMbmpN+OWQsTdpDPQeEuYSfhzh
szb/A37+YQHj9LedAErnCPmG68bn0PTi+BO/1n/JfzCpidj68XcTFJ7aNr9mwAQ=
=nitB
-----END PGP SIGNATURE-----

--C7zPtVaVf+AK4Oqc--