Re: backwards incompatible asciihood change in Email::Address

2012-01-15 Thread Ruslan Zakirov
On Sun, Jan 15, 2012 at 19:24, Ruslan Zakirov r...@bestpractical.com wrote:
 Please let me know if this helps, and if so, I will add some tests, adjust 
 the
 docs, and release.

 I can test later tonight.

This helps :) Thank you.


-- 
Best regards, Ruslan.


Re: backwards incompatible asciihood change in Email::Address

2012-01-15 Thread Ricardo Signes
* Ruslan Zakirov r...@bestpractical.com [2012-01-15T10:24:59]
 On Sun, Jan 15, 2012 at 19:09, Ricardo Signes perl@rjbs.manxome.org 
 wrote:
  I've updated Github's repo with a change to only reject non-ASCII in the
  email address, which really is a problem.  My guess is that you were having
  a problem with the decoded phrase legally containing non-ASCII.
 
 Right guess. Is it legal? I don't think it is legal according to the
 spec to have non-ascii phrase. As far as I recall it should be encoded
 with Q/B.

Sure, but people aren't (I hope) passing the mime-header-encoded content to
-parse.  That will parse, but give you crap.  They should be passing the
decoded character string, at which point the non-ASCII phrase is legal.

i.e., Email::Address parses the header's decoded character data, not its raw
encoded data.

I will make a release in a few hours.

-- 
rjbs


Re: backwards incompatible asciihood change in Email::Address

2012-01-15 Thread Ruslan Zakirov
On Sun, Jan 15, 2012 at 22:13, Ricardo Signes perl@rjbs.manxome.org wrote:
 * Ruslan Zakirov r...@bestpractical.com [2012-01-15T10:24:59]
 On Sun, Jan 15, 2012 at 19:09, Ricardo Signes perl@rjbs.manxome.org 
 wrote:
  I've updated Github's repo with a change to only reject non-ASCII in the
  email address, which really is a problem.  My guess is that you were having
  a problem with the decoded phrase legally containing non-ASCII.

 Right guess. Is it legal? I don't think it is legal according to the
 spec to have non-ascii phrase. As far as I recall it should be encoded
 with Q/B.

 Sure, but people aren't (I hope) passing the mime-header-encoded content to
 -parse.  That will parse, but give you crap.  They should be passing the
 decoded character string, at which point the non-ASCII phrase is legal.

Good to know this.

 i.e., Email::Address parses the header's decoded character data, not its raw
 encoded data.

May be at some point we should release E::A::Liberal that parses
encoded string to E::A objects. We saw mails where phrase wrapped into
two  (Ivan Ivanov ...), Q/B used to hide comas and other
characters (Ivanov, Ivan ... with phrase encoded), probably code and
tests can show more cases.


 I will make a release in a few hours.

Thanks.


 --
 rjbs

-- 
Best regards, Ruslan.