* p...@cpan.org [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 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. -- rjbs
signature.asc
Description: Digital signature
