Re: Email::Address::XS

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

* [email protected] [2016-07-03T08:39:22]
> On Friday 01 July 2016 02:51:31 Ricardo Signes wrote:
>=20
> > What if we defined a role (here, just a well-known name) called
> > Email::MIME::Header::Value, which is used to signal that a particular
> > method, say "as_mime_header", should be used to stringify?
>=20
> In this case, do we need role at all? Is not existence of method=20
> "as_mime_header" enough?

That method alone is fine with me.

> And all this would be passed via header or header_str?

I'd stick to header_str, I think, but I'm not sure.  At any rate: yes.

> If address(), addrlist() and addrgroup() returns those objects (with=20
> as_mime_header() method) it could be usable...
>=20
> But I was thinking about using same syntax in Email::MIME for passing=20
> addrlist/addrgroup as is in Email::Address::XS format_email_addresses=20
> and format_email_groups functions.

I'm afraid I don't understand what you mean.

> In my opinion folding and unfolding should be done in Email::Simple. I'm=
=20
> not huge fan of adding folding and CRLF code into Email::Address::XS as=
=20
> it has nothing to do with it. That module parse and format one line of=20
> list of addresses.

I agree.  I think if we start with the API described above, and leave the
folding for the message to perform, we'll be okay.  We can certainly find o=
ut
by writing the code!

> > What do you think of this all?
>=20
> Still do not know how to handle non-MIME headers correctly in=20
> Email::MIME module. We can either create blacklist of non-MIME headers=20
> and extend it every time when somebody report problem or create=20
> whitelist of MIME headers... Or let caller to decide if his header must=
=20
> be MIME-encoded or not.

I'm sorry, I don't understand.  Could you elaborate?

> Basically we need unambiguous way to specify:
>=20
> * ascii string which will never be MIME-encoded (error for unicode char)
> * unicode string which will be MIME-encoded if contains unicode char
> * addresses/groups - but again with ability to specify if do MIME-encode

We have that, right?

"header" is "already encoded", which is another way of saying "do not encode
this."

"header_str" is "text string" which means it will get encoded.

The address or groups thing falls under "object."  I had assumed it would,
itself, know how to become MIME encoded.  This is important, because the
semantics of what gets encoded differ per field type.  So, as_mime_header is
the encoded form.  If you want to offer an unencoded form, as_string seems =
like
the obvious method.

--=20
rjbs

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

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

iQEcBAEBAgAGBQJXeaVJAAoJEOYby6cMccU5/+EIANc53cDDlpz8bXNAhpBEIfMN
acjyq05eG18Jj0/ZiduNzp+C4aCKQN/9Y+9PhxVKy1t8RYhTTcEhGL4sLEJqlUtc
mkm/v5k5ggchz4x32ovTCrBBoHai6G07Jp8u4QZNu0NDG/Tw/aEIeSUFO9dO6dwL
PM6ACpGB/tlUFnNMqXlZt/9HSk5KA/W8jYSe//oXmbIFF6FXDCVPTadcKEkYTOaq
i38bAkHxKPFfjK/FxLWfVLShXouhBS3lTpBokAzzSYbOpJ/6nRPHZYJEuSx6pGEW
2p+3T1s/WsN9xgEMNIo+pMR3zNdEiZAfZVwA7ADch93o8l6Xq84lMA9tCKFcMW8=
=G3zU
-----END PGP SIGNATURE-----

--h31gzZEtNLTqOjlF--