Front page | perl.pep |
Postings from August 2016
From: Ricardo Signes
August 18, 2016 21:21
Message ID: 20160818212128.GA29265@debian
* firstname.lastname@example.org [2016-08-08T17:41:04]
> Here we are need to deal with objects which internally needs to be MIME
> 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 => [ header => $obj_based_on_text ]
...the object will be required to have an as_mime_header method, which must
produce an encoded form.
The point was to make the behavior of objects unambiguous no matter where you
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:
> 1) Raw (ASCII) string representation of To: field
> 2) Unicode string representation of To: field
> 3) List of Email::Address::XS objects which are in To: field
> 4) List of named groups with Email::Address::XS objects of To: field
> For 1) and 2) I can use ->header_raw and ->header_str methods. For 3)
> and 4) are needed new method(s). Ideally if caller is able to get
> original MIME encoded objects (where in ->phrase part of address object
> 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
$email->header(To => mailbox_headers_from( $email->header('To') );
...and it seems like one would quickly amass some sort of routine like:
...that would upgrade all the headers it knows about.
> I can accept that both "header" and "header_str" will work with objects,
> but I think that my suggestion about do not encoding "phrase" string
> 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 encoded
form. (Email::MIME will line-fold, though, as discussed.)