Re: Email::Address::XS

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

* [email protected] [2016-08-08T17:41:04]
> Here we are need to deal with objects which internally needs to be MIME=
=20
> encoded and objects which mustn't.

I don't think this matters.

If an object is passed in, it must be able to produce a MIME encoded form.
Even if you say:

  header_str =3D> [ header =3D> $obj_based_on_text ]

=2E..the object will be required to have an as_mime_header method, which mu=
st
produce an encoded form.

The point was to make the behavior of objects unambiguous no matter where y=
ou
put them, not to multiply the possible semantics of objects by two.

The only difference between header and header_str, I said, would be how they
treated plain strings.

> If I create Email::MIME object from input string, I would like to get:
>=20
> 1) Raw (ASCII) string representation of To: field
>=20
> 2) Unicode string representation of To: field
>=20
> 3) List of Email::Address::XS objects which are in To: field
>=20
> 4) List of named groups with Email::Address::XS objects of To: field
>=20
> For 1) and 2) I can use ->header_raw and ->header_str methods. For 3)=20
> and 4) are needed new method(s). Ideally if caller is able to get=20
> original MIME encoded objects (where in ->phrase part of address object=
=20
> is still MIME encoded) and also if objects strings are Unicode.

As you say, 1 and 2 are dealt with.  For 3 or 4, you want to have an object=
 in
the header slot, rather than a string.  Once you've done that, you use its
methods.  If the object's To field stores a string, you "upgrade" it with
something like:

  $email->header(To =3D> mailbox_headers_from( $email->header('To') );

=2E..and it seems like one would quickly amass some sort of routine like:

  upgrade_headers($email);

=2E..that would upgrade all the headers it knows about.

> I can accept that both "header" and "header_str" will work with objects,=
=20
> but I think that my suggestion about do not encoding "phrase" string=20
> part of object passed to "header" is useful...

I agree that if you provide an object, Email::MIME should not try to further
encode anything, and that it should trust the object to provide its own enc=
oded
form.  (Email::MIME will line-fold, though, as discussed.)

--=20
rjbs

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

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

iQEcBAEBAgAGBQJXtibYAAoJEOYby6cMccU5qbwH/14Wvde2FVj0Pg7mt24wxxZ7
WyRSHvKJGZax5Z81hhuvqNlS3RpTy4uQ9oDz6m8I2RyjuRCVGHk4mbxC1ZMAwlxV
Qg0+k/gVpvj8QUIOd+CVDQ/Dczwgv/kD5Eo6fTZbLQoVr76vOZVpvZNgerwZ8buQ
Cuo0O0+dZ5sIb+q07qleZ4uwIqc+YXlonVhewZR5I44NpQk5Ew0kustDN/HwC0S+
vCKe5Em1jbCVq2c+5MwrL7Ausw5X18CnEqo6SiuixbJiLRuX15i4AJPtE92pUvhC
27cyn9jAKwr2v7iW9ZaTFBM4z6Y6mwkvorPNwCarv0cd6jas/5zGpijeUpJgWHE=
=rQi9
-----END PGP SIGNATURE-----

--GvXjxJ+pjyke8COw--