[issue11783] email parseaddr and formataddr should be IDNA aware

New submission from R. David Murray : The patch for issue 1690608 adds support for unicode in the realname field to formataddr. To complete the currently-workable internationalization of address specs, both parseaddr and formataddr should be made IDNA aware. It is probably a good idea to do

[issue11783] email parseaddr and formataddr should be IDNA aware

Steffen Daode Nurpmeso added the comment: If Torsten does not have time for this i'll do that next. I hate this useless Punycode (but for nameprep), so it's exactly the right thing for me to do next in 2011. Unless someone complains. I've not looked at formataddr/parseaddr, so that's a motivatio

[issue11783] email parseaddr and formataddr should be IDNA aware

R. David Murray added the comment: I believe Torsten is interested, but he can of course speak for himself. Just to make sure you are aware: Python has a built in idna codec, so this should be a fairly simple patch. -- ___ Python tracker

[issue11783] email parseaddr and formataddr should be IDNA aware

Torsten Becker added the comment: I was about to look into this over the weekend, but of course I don't want to steal your fun, Steffen. :) -- ___ Python tracker ___ ___

[issue11783] email parseaddr and formataddr should be IDNA aware

Steffen Daode Nurpmeso added the comment: On Fri, Apr 08, 2011 at 09:03:51PM +, Torsten Becker wrote: > I was about to look into this over the weekend, but of course I don't > want to steal your fun, Steffen. :) Toll, toll, toll!! Still cherry blossom, thanks to the weather, apple blossom

[issue11783] email parseaddr and formataddr should be IDNA aware

Torsten Becker added the comment: > Have a nice weekend! Thank you for the wishes, I hope yours is going well, too! I added IDNA awareness to formataddr() and parseaddr(), updated the docs and wrote 2 tests for it. I wasn't sure if the IDNA awareness should be optional via a argument or alwa

[issue11783] email parseaddr and formataddr should be IDNA aware

R. David Murray added the comment: Patch mostly looks good to me, modulo some English wording that I'll fix up when I commit it. The issue with the '@' is that it might not be there. So you do need to check for that case (it means the domain part defaults to the 'local' domain). I should d

[issue11783] email parseaddr and formataddr should be IDNA aware

Torsten Becker added the comment: > modulo some English wording that I'll fix up when I commit it. Yeah, sorry for that, I seem to have trouble with writing good documentation. :) I'll have a look at the documents referenced by [1] to improve my writing. > The issue with the '@' is that it m

[issue11783] email parseaddr and formataddr should be IDNA aware

R. David Murray added the comment: Hmm. You are correct. I thought the RFC's covered this case, but apparently they don't. The email package gets used in MUA contexts, where the domain part of the address may be omitted and the MUA must fill it in before transmitting the message to the MTA

[issue11783] email parseaddr and formataddr should be IDNA aware

R. David Murray added the comment: OK, so when I went to apply this, I figured out that the patch isn't quite right. I've redone the doc updates, and am attaching a version of the patch containing them. The issue is that the place that the IDNA decode support needs to be added isn't in pars

[issue11783] email parseaddr and formataddr should be IDNA aware

Torsten Becker added the comment: > OK, so when I went to apply this, I figured out that the patch isn't quite > right.  I've redone the doc updates, and am attaching a version of the patch > containing them. > > The issue is that the place that the IDNA decode support needs to be added > isn

[issue11783] email parseaddr and formataddr should be IDNA aware

R. David Murray added the comment: Yes, putting the function in _parseaddr is fine. And yes, 232 looks like a good place. The alternative would be understanding the rfc822 parser, which is pretty mind bending, and of doubtful additional benefit. (At most it would save a pair of split/join

[issue11783] email parseaddr and formataddr should be IDNA aware

Steffen Daode Nurpmeso added the comment: On Wed, Apr 13, 2011 at 09:42:22PM +, Torsten Becker wrote: > So if anybody wants to work on this before that time, > please feel free to fix it properly. :) (The word anybody made me think. But "fix properly" ... i'm sure you cannot refer to myself

[issue11783] email parseaddr and formataddr should be IDNA aware

Torsten Becker added the comment: > (The word anybody made me think. > But "fix properly" ... i'm sure you cannot refer to myself. > :)) "fix properly" referred to my inferior implementation and "anybody" should probably have been worded "Steffen or David". So sure .. go ahead. :) --

[issue11783] email parseaddr and formataddr should be IDNA aware

Steffen Daode Nurpmeso added the comment: On Thu, Apr 14, 2011 at 06:05:59PM +, Torsten Becker wrote: > So sure .. go ahead. :) Gr Wuah, Wuuuah, Wuuh! No. Now i'm exhausted. -- ___ Python tracker

[issue11783] email parseaddr and formataddr should be IDNA aware

Steffen Daode Nurpmeso added the comment: On Thu, Apr 14, 2011 at 06:05:59PM +, Torsten Becker wrote: > :) Mumble... :) -- ___ Python tracker ___ __

[issue11783] email parseaddr and formataddr should be IDNA aware

Torsten Becker added the comment: Hi, here is my revised patch with email.utils.getaddresses() also decoding IDNs. I decided to integrate IDN decoding in AddrlistClass.getaddress() instead of AddrlistClass.getaddrlist() since that function is one level lower and if somebody should ever all it

[issue11783] email parseaddr and formataddr should be IDNA aware

R. David Murray added the comment: Thanks. I should be able to look at this tomorrow. You are correct about the fact that Message currently doesn't do any decoding. That is part of the design: you get the string out of Message and use the helper decoding functions (decode_header, getaddress

[issue11783] email parseaddr and formataddr should be IDNA aware

Changes by R. David Murray : -- components: +email -Library (Lib) nosy: +barry ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue11783] email parseaddr and formataddr should be IDNA aware

R. David Murray added the comment: I'm finally getting back around to this. Torsten, could you submit a contributor agreement, please? (http://www.python.org/psf/contrib/) And to answer the question you had about the 'still failing' test, parseaddr isn't currently doing the encoded-word dec

[issue11783] email parseaddr and formataddr should be IDNA aware

Changes by R. David Murray : -- assignee: r.david.murray -> ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: ht

[issue11783] email parseaddr and formataddr should be IDNA aware

Christian Heimes added the comment: 3.3 is in feature freeze mode. This new feature has to go into 3.4. -- nosy: +christian.heimes versions: +Python 3.4 -Python 3.3 ___ Python tracker __