Front page | perl.pep |
Postings from July 2016
From: Ricardo Signes
July 3, 2016 23:52
Message ID: 20160703235241.GA26626@debian
* email@example.com [2016-07-03T08:39:22]
> On Friday 01 July 2016 02:51:31 Ricardo Signes wrote:
> > 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?
> In this case, do we need role at all? Is not existence of method
> "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
> as_mime_header() method) it could be usable...
> But I was thinking about using same syntax in Email::MIME for passing
> addrlist/addrgroup as is in Email::Address::XS format_email_addresses
> 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
> not huge fan of adding folding and CRLF code into Email::Address::XS as
> it has nothing to do with it. That module parse and format one line of
> 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 out
by writing the code!
> > What do you think of this all?
> Still do not know how to handle non-MIME headers correctly in
> Email::MIME module. We can either create blacklist of non-MIME headers
> and extend it every time when somebody report problem or create
> whitelist of MIME headers... Or let caller to decide if his header must
> be MIME-encoded or not.
I'm sorry, I don't understand. Could you elaborate?
> Basically we need unambiguous way to specify:
> * 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
"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.