FW: I-D Action: draft-klensin-idna-rfc5891bis-00.txt
FYI, too much stuff from John for me to dig into this a.m. -----Original Message----- From: Idna-update [mailto:idna-update-bounces@alvestrand.no] On Behalf Of John C Klensin Sent: Saturday, March 11, 2017 8:25 AM To: idna-update@alvestrand.no Subject: FWD: I-D Action: draft-klensin-idna-rfc5891bis-00.txt Hi. For the information of those who may be watching this list but not the IETF announcement one... Asmus Freytag and I have started to put together a draft that addresses a problem with the IDNA2008 specs, specifically that we failed to make the responsibility of registries to define code point and label acceptability rules that were considerably more narrow (and better understood by them) than the full set of labels allowed by RFC 5891-5893. It doesn't actually change anything because that requirement is in the existing specs; it just makes (or tries to make) the requirements painfully clear to those who have been missing or misreading them. It also provides an explicit link between IDNA2008 requirements and ICANN work on repertoires and label generation rules without endorsing that work as more than one thoughtful approach that might be examined for either reference or inspiration. Comments (obviously) welcome. For anyone who might wonder, this document avoids the more controversial IDNA2008 issues including: * Multiple suggestions that we should add emoji, a subset of code points with General Category "So", to the list of code points allowed by IDNA. There are many reasons to not do that but it seems clear that, at some point, the IETF will need to either document those reasons or make the change. Volunteers to put together or work on a document would be welcome. * The non-decomposing code point problem, formerly (and incorrectly) known as the Hamza problem. There has been no discernable activity on this since the IAB Statement and LUCID BOF almost exactly two years ago. I've further updated the working copy of draft-klensin-idna-5892upd-unicode70 to cover additional cases and issues, but, in part because it is clearly inappropriate for a quick-patch individual submission, have been advised to not post it until we have a plan to make progress. So far, there is no such plan. * The (IMO, growing) problem of multiple and inconsistent specifications for IDNs and IDN handling, with different ones being used in different higher-level protocols and areas of the Internet. The use of different specifications and definitions creates opportunities for user and implementer confusion, interoperability difficulties, domain names that cannot be resolved under some circumstances, and various sorts of attacks. The specifications involved include IDNA2008, IDNA2003, assorted local "updates" to IDNA2003 that use versions of Stringprep locally updated to assorted versions of Unicode, and the various versions of UTR#46. The latest version of the latter explicitly allows emoji along with other symbols. A few months ago, I suggested to the IAB I18N program that a document be produced that at least pointed out the problems associated with multiple divergent specifications, but the idea got no traction. It appears to me that, although almost everyone agrees that IDNs, and well- and clearly-functional IDNs, are important, virtually no one is willing to do the hard work, at least unless they are being supported by ICANN (disclosure: I am not) or organizations whose interests lie in selling names, preferably as many of them as possible (I have no support from any of them either). Until and unless that changes, I don't see much prospect for getting those other issues addressed in a way that might lead to consensus documents. john ---------- Forwarded Message ---------- Date: Saturday, March 11, 2017 07:22 -0800 From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-klensin-idna-rfc5891bis-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Internationalized Domain Names in Applications (IDNA): Registry Restrictions and Recommendations Authors : John C Klensin Asmus Freytag Filename : draft-klensin-idna-rfc5891bis-00.txt Pages : 10 Date : 2017-03-11 Abstract: The IDNA specifications for internationalized domain names combine rules that determine the labels that are allowed in the DNS without violating the protocol itself and an assignment of responsibility, consistent with earlier specifications, for determining the labels that are allowed in particular zones. Conformance to IDNA by registries and other implementations requires both parts. Experience strongly suggests that the language describing those responsibility was insufficiently clear to promote safe and interoperable use of the specifications and that more details and some specific examples would have been helpful. This specification updates the earlier ones to provide that guidance and to correct some technical errors in the descriptions. It does not alter the protocols and rules themselves in any way. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-klensin-idna-rfc5891bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-klensin-idna-rfc5891bis-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ---------- End Forwarded Message ---------- _______________________________________________ Idna-update mailing list Idna-update@alvestrand.no http://www.alvestrand.no/mailman/listinfo/idna-update
Thanks for forwarding this Mark, This seems to be something useful for UA, perhaps we should work with the IDN team at ICANN (along with the communities networked from the LGR work) to see where we can best support. Edmon
-----Original Message----- From: ua-discuss-bounces@icann.org [mailto:ua-discuss-bounces@icann.org] On Behalf Of Mark Svancarek via UA-discuss Sent: Sunday, 12 March 2017 12:58 PM To: UA-discuss@icann.org Cc: Shawn Steele <Shawn.Steele@microsoft.com> Subject: [UA-discuss] FW: I-D Action: draft-klensin-idna-rfc5891bis-00.txt
FYI, too much stuff from John for me to dig into this a.m.
-----Original Message----- From: Idna-update [mailto:idna-update-bounces@alvestrand.no] On Behalf Of John C Klensin Sent: Saturday, March 11, 2017 8:25 AM To: idna-update@alvestrand.no Subject: FWD: I-D Action: draft-klensin-idna-rfc5891bis-00.txt
Hi.
For the information of those who may be watching this list but not the IETF announcement one...
Asmus Freytag and I have started to put together a draft that addresses a problem with the IDNA2008 specs, specifically that we failed to make the responsibility of registries to define code point and label acceptability rules that were considerably more narrow (and better understood by them) than the full set of labels allowed by RFC 5891-5893. It doesn't actually change anything because that requirement is in the existing specs; it just makes (or tries to make) the requirements painfully clear to those who have been missing or misreading them.
It also provides an explicit link between IDNA2008 requirements and ICANN work on repertoires and label generation rules without endorsing that work as more than one thoughtful approach that might be examined for either reference or inspiration.
Comments (obviously) welcome.
For anyone who might wonder, this document avoids the more controversial IDNA2008 issues including:
* Multiple suggestions that we should add emoji, a subset of code points with General Category "So", to the list of code points allowed by IDNA. There are many reasons to not do that but it seems clear that, at some point, the IETF will need to either document those reasons or make the change. Volunteers to put together or work on a document would be welcome.
* The non-decomposing code point problem, formerly (and incorrectly) known as the Hamza problem. There has been no discernable activity on this since the IAB Statement and LUCID BOF almost exactly two years ago. I've further updated the working copy of draft-klensin-idna-5892upd- unicode70 to cover additional cases and issues, but, in part because it is clearly inappropriate for a quick-patch individual submission, have been advised to not post it until we have a plan to make progress. So far, there is no such plan.
* The (IMO, growing) problem of multiple and inconsistent specifications for IDNs and IDN handling, with different ones being used in different higher-level protocols and areas of the Internet. The use of different specifications and definitions creates opportunities for user and implementer confusion, interoperability difficulties, domain names that cannot be resolved under some circumstances, and various sorts of attacks. The specifications involved include IDNA2008, IDNA2003, assorted local "updates" to IDNA2003 that use versions of Stringprep locally updated to assorted versions of Unicode, and the various versions of UTR#46. The latest version of the latter explicitly allows emoji along with other symbols. A few months ago, I suggested to the IAB I18N program that a document be produced that at least pointed out the problems associated with multiple divergent specifications, but the idea got no traction.
It appears to me that, although almost everyone agrees that IDNs, and well- and clearly-functional IDNs, are important, virtually no one is willing to do the hard work, at least unless they are being supported by ICANN (disclosure: I am not) or organizations whose interests lie in selling names, preferably as many of them as possible (I have no support from any of them either). Until and unless that changes, I don't see much prospect for getting those other issues addressed in a way that might lead to consensus documents.
john
---------- Forwarded Message ---------- Date: Saturday, March 11, 2017 07:22 -0800 From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-klensin-idna-rfc5891bis-00.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories.
Title : Internationalized Domain Names in Applications (IDNA): Registry Restrictions and Recommendations Authors : John C Klensin Asmus Freytag Filename : draft-klensin-idna-rfc5891bis-00.txt Pages : 10 Date : 2017-03-11
Abstract: The IDNA specifications for internationalized domain names combine rules that determine the labels that are allowed in the DNS without violating the protocol itself and an assignment of responsibility, consistent with earlier specifications, for determining the labels that are allowed in particular zones. Conformance to IDNA by registries and other implementations requires both parts. Experience strongly suggests that the language describing those responsibility was insufficiently clear to promote safe and interoperable use of the specifications and that more details and some specific examples would have been helpful. This specification updates the earlier ones to provide that guidance and to correct some technical errors in the descriptions. It does not alter the protocols and rules themselves in any way.
The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-klensin-idna-rfc5891bis/
There's also a htmlized version available at: https://tools.ietf.org/html/draft-klensin-idna-rfc5891bis-00
Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.
Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/
_______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
---------- End Forwarded Message ----------
_______________________________________________ Idna-update mailing list Idna-update@alvestrand.no http://www.alvestrand.no/mailman/listinfo/idna-update
Agree, thanks for forwarding Mark This was a very cogent statement of affairs relative to the closing out of known IDN issues (or our current inability to do so). I agree with Edmon in that I think the UA effort should strive to be a catalyst here. --Rich From: <ua-discuss-bounces@icann.org> on behalf of Edmon Chung <edmon@registry.asia> Date: Sunday, March 12, 2017 at 7:11 AM To: 'Mark Svancarek' <marksv@microsoft.com>, "UA-discuss@icann.org" <UA-discuss@icann.org> Cc: 'Shawn Steele' <Shawn.Steele@microsoft.com> Subject: Re: [UA-discuss] FW: I-D Action: draft-klensin-idna-rfc5891bis-00.txt Thanks for forwarding this Mark, This seems to be something useful for UA, perhaps we should work with the IDN team at ICANN (along with the communities networked from the LGR work) to see where we can best support. Edmon -----Original Message----- From: ua-discuss-bounces@icann.org<mailto:ua-discuss-bounces@icann.org> [mailto:ua-discuss-bounces@icann.org] On Behalf Of Mark Svancarek via UA-discuss Sent: Sunday, 12 March 2017 12:58 PM To: UA-discuss@icann.org<mailto:UA-discuss@icann.org> Cc: Shawn Steele <Shawn.Steele@microsoft.com<mailto:Shawn.Steele@microsoft.com>> Subject: [UA-discuss] FW: I-D Action: draft-klensin-idna-rfc5891bis-00.txt FYI, too much stuff from John for me to dig into this a.m. -----Original Message----- From: Idna-update [mailto:idna-update-bounces@alvestrand.no] On Behalf Of John C Klensin Sent: Saturday, March 11, 2017 8:25 AM To: idna-update@alvestrand.no<mailto:idna-update@alvestrand.no> Subject: FWD: I-D Action: draft-klensin-idna-rfc5891bis-00.txt Hi. For the information of those who may be watching this list but not the IETF announcement one... Asmus Freytag and I have started to put together a draft that addresses a problem with the IDNA2008 specs, specifically that we failed to make the responsibility of registries to define code point and label acceptability rules that were considerably more narrow (and better understood by them) than the full set of labels allowed by RFC 5891-5893. It doesn't actually change anything because that requirement is in the existing specs; it just makes (or tries to make) the requirements painfully clear to those who have been missing or misreading them. It also provides an explicit link between IDNA2008 requirements and ICANN work on repertoires and label generation rules without endorsing that work as more than one thoughtful approach that might be examined for either reference or inspiration. Comments (obviously) welcome. For anyone who might wonder, this document avoids the more controversial IDNA2008 issues including: * Multiple suggestions that we should add emoji, a subset of code points with General Category "So", to the list of code points allowed by IDNA. There are many reasons to not do that but it seems clear that, at some point, the IETF will need to either document those reasons or make the change. Volunteers to put together or work on a document would be welcome. * The non-decomposing code point problem, formerly (and incorrectly) known as the Hamza problem. There has been no discernable activity on this since the IAB Statement and LUCID BOF almost exactly two years ago. I've further updated the working copy of draft-klensin-idna-5892upd- unicode70 to cover additional cases and issues, but, in part because it is clearly inappropriate for a quick-patch individual submission, have been advised to not post it until we have a plan to make progress. So far, there is no such plan. * The (IMO, growing) problem of multiple and inconsistent specifications for IDNs and IDN handling, with different ones being used in different higher-level protocols and areas of the Internet. The use of different specifications and definitions creates opportunities for user and implementer confusion, interoperability difficulties, domain names that cannot be resolved under some circumstances, and various sorts of attacks. The specifications involved include IDNA2008, IDNA2003, assorted local "updates" to IDNA2003 that use versions of Stringprep locally updated to assorted versions of Unicode, and the various versions of UTR#46. The latest version of the latter explicitly allows emoji along with other symbols. A few months ago, I suggested to the IAB I18N program that a document be produced that at least pointed out the problems associated with multiple divergent specifications, but the idea got no traction. It appears to me that, although almost everyone agrees that IDNs, and well- and clearly-functional IDNs, are important, virtually no one is willing to do the hard work, at least unless they are being supported by ICANN (disclosure: I am not) or organizations whose interests lie in selling names, preferably as many of them as possible (I have no support from any of them either). Until and unless that changes, I don't see much prospect for getting those other issues addressed in a way that might lead to consensus documents. john ---------- Forwarded Message ---------- Date: Saturday, March 11, 2017 07:22 -0800 From: internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> To: i-d-announce@ietf.org<mailto:i-d-announce@ietf.org> Subject: I-D Action: draft-klensin-idna-rfc5891bis-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Internationalized Domain Names in Applications (IDNA): Registry Restrictions and Recommendations Authors : John C Klensin Asmus Freytag Filename : draft-klensin-idna-rfc5891bis-00.txt Pages : 10 Date : 2017-03-11 Abstract: The IDNA specifications for internationalized domain names combine rules that determine the labels that are allowed in the DNS without violating the protocol itself and an assignment of responsibility, consistent with earlier specifications, for determining the labels that are allowed in particular zones. Conformance to IDNA by registries and other implementations requires both parts. Experience strongly suggests that the language describing those responsibility was insufficiently clear to promote safe and interoperable use of the specifications and that more details and some specific examples would have been helpful. This specification updates the earlier ones to provide that guidance and to correct some technical errors in the descriptions. It does not alter the protocols and rules themselves in any way. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-klensin-idna-rfc5891bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-klensin-idna-rfc5891bis-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org<mailto:I-D-Announce@ietf.org> https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ---------- End Forwarded Message ---------- _______________________________________________ Idna-update mailing list Idna-update@alvestrand.no<mailto:Idna-update@alvestrand.no> http://www.alvestrand.no/mailman/listinfo/idna-update
My concern is John’s emphasis on creating very restrictive character rule sets. The most restrictive rules created by IDNA2008 have been ignored because of user demand and backwards compatibility. Eg: no-emoji in labels. People want emoji, but IDNA2008 doesn’t permit it. Part of that is compatibility with the permitted IDNA2003 emoji, however there has also been demand for emoji characters newly added to Unicode. I think that it is appropriate to remind registrars that they are responsible for creating sane rules for their spaces, but it is clear that users do not want to be tied to the most restrictive demands of IDNA2008. Implementations appear to be settling on the Unicode provided idna data and I would much prefer to see the IETF standards point to the IDNA character sets provided by Unicode (while still encouraging registrars to do sane things that make sense for their domains). A good example of something a registrar might want to consider could be something like ü. Some spaces may allow ü without much restriction, however for .de, .ch, .at, etc. it might make sense to recognize that ü has an alternate ue spelling and to provide bundling or blocking of domains like müller.ch and mueller.ch. That kind of rule is very domain/language specific. Though it is not called out as some of the bidi rules are, the RFCs allow registrars to implement such a policy if it fits their purposes. Of course many other behaviors are called out by the IDNA2008 rules. Pretty much all of the concerns regarding the character repertoire can be resolved and the registrar level if the registrars would ensure that they did not allow registrations of multiple domain variations that might confuse their users. Or if they bundled those registrations. -Shawn From: Richard Merdinger [mailto:rmerdinger@godaddy.com] Sent: Saturday, March 11, 2017 11:35 PM To: Edmon Chung <edmon@registry.asia>; Mark Svancarek <marksv@microsoft.com>; UA-discuss@icann.org Cc: Shawn Steele <Shawn.Steele@microsoft.com> Subject: Re: [UA-discuss] FW: I-D Action: draft-klensin-idna-rfc5891bis-00.txt Agree, thanks for forwarding Mark This was a very cogent statement of affairs relative to the closing out of known IDN issues (or our current inability to do so). I agree with Edmon in that I think the UA effort should strive to be a catalyst here. --Rich From: <ua-discuss-bounces@icann.org<mailto:ua-discuss-bounces@icann.org>> on behalf of Edmon Chung <edmon@registry.asia<mailto:edmon@registry.asia>> Date: Sunday, March 12, 2017 at 7:11 AM To: 'Mark Svancarek' <marksv@microsoft.com<mailto:marksv@microsoft.com>>, "UA-discuss@icann.org<mailto:UA-discuss@icann.org>" <UA-discuss@icann.org<mailto:UA-discuss@icann.org>> Cc: 'Shawn Steele' <Shawn.Steele@microsoft.com<mailto:Shawn.Steele@microsoft.com>> Subject: Re: [UA-discuss] FW: I-D Action: draft-klensin-idna-rfc5891bis-00.txt Thanks for forwarding this Mark, This seems to be something useful for UA, perhaps we should work with the IDN team at ICANN (along with the communities networked from the LGR work) to see where we can best support. Edmon -----Original Message----- From: ua-discuss-bounces@icann.org<mailto:ua-discuss-bounces@icann.org> [mailto:ua-discuss-bounces@icann.org] On Behalf Of Mark Svancarek via UA-discuss Sent: Sunday, 12 March 2017 12:58 PM To: UA-discuss@icann.org<mailto:UA-discuss@icann.org> Cc: Shawn Steele <Shawn.Steele@microsoft.com<mailto:Shawn.Steele@microsoft.com>> Subject: [UA-discuss] FW: I-D Action: draft-klensin-idna-rfc5891bis-00.txt FYI, too much stuff from John for me to dig into this a.m. -----Original Message----- From: Idna-update [mailto:idna-update-bounces@alvestrand.no] On Behalf Of John C Klensin Sent: Saturday, March 11, 2017 8:25 AM To: idna-update@alvestrand.no<mailto:idna-update@alvestrand.no> Subject: FWD: I-D Action: draft-klensin-idna-rfc5891bis-00.txt Hi. For the information of those who may be watching this list but not the IETF announcement one... Asmus Freytag and I have started to put together a draft that addresses a problem with the IDNA2008 specs, specifically that we failed to make the responsibility of registries to define code point and label acceptability rules that were considerably more narrow (and better understood by them) than the full set of labels allowed by RFC 5891-5893. It doesn't actually change anything because that requirement is in the existing specs; it just makes (or tries to make) the requirements painfully clear to those who have been missing or misreading them. It also provides an explicit link between IDNA2008 requirements and ICANN work on repertoires and label generation rules without endorsing that work as more than one thoughtful approach that might be examined for either reference or inspiration. Comments (obviously) welcome. For anyone who might wonder, this document avoids the more controversial IDNA2008 issues including: * Multiple suggestions that we should add emoji, a subset of code points with General Category "So", to the list of code points allowed by IDNA. There are many reasons to not do that but it seems clear that, at some point, the IETF will need to either document those reasons or make the change. Volunteers to put together or work on a document would be welcome. * The non-decomposing code point problem, formerly (and incorrectly) known as the Hamza problem. There has been no discernable activity on this since the IAB Statement and LUCID BOF almost exactly two years ago. I've further updated the working copy of draft-klensin-idna-5892upd- unicode70 to cover additional cases and issues, but, in part because it is clearly inappropriate for a quick-patch individual submission, have been advised to not post it until we have a plan to make progress. So far, there is no such plan. * The (IMO, growing) problem of multiple and inconsistent specifications for IDNs and IDN handling, with different ones being used in different higher-level protocols and areas of the Internet. The use of different specifications and definitions creates opportunities for user and implementer confusion, interoperability difficulties, domain names that cannot be resolved under some circumstances, and various sorts of attacks. The specifications involved include IDNA2008, IDNA2003, assorted local "updates" to IDNA2003 that use versions of Stringprep locally updated to assorted versions of Unicode, and the various versions of UTR#46. The latest version of the latter explicitly allows emoji along with other symbols. A few months ago, I suggested to the IAB I18N program that a document be produced that at least pointed out the problems associated with multiple divergent specifications, but the idea got no traction. It appears to me that, although almost everyone agrees that IDNs, and well- and clearly-functional IDNs, are important, virtually no one is willing to do the hard work, at least unless they are being supported by ICANN (disclosure: I am not) or organizations whose interests lie in selling names, preferably as many of them as possible (I have no support from any of them either). Until and unless that changes, I don't see much prospect for getting those other issues addressed in a way that might lead to consensus documents. john ---------- Forwarded Message ---------- Date: Saturday, March 11, 2017 07:22 -0800 From: internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> To: i-d-announce@ietf.org<mailto:i-d-announce@ietf.org> Subject: I-D Action: draft-klensin-idna-rfc5891bis-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Internationalized Domain Names in Applications (IDNA): Registry Restrictions and Recommendations Authors : John C Klensin Asmus Freytag Filename : draft-klensin-idna-rfc5891bis-00.txt Pages : 10 Date : 2017-03-11 Abstract: The IDNA specifications for internationalized domain names combine rules that determine the labels that are allowed in the DNS without violating the protocol itself and an assignment of responsibility, consistent with earlier specifications, for determining the labels that are allowed in particular zones. Conformance to IDNA by registries and other implementations requires both parts. Experience strongly suggests that the language describing those responsibility was insufficiently clear to promote safe and interoperable use of the specifications and that more details and some specific examples would have been helpful. This specification updates the earlier ones to provide that guidance and to correct some technical errors in the descriptions. It does not alter the protocols and rules themselves in any way. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-klensin-idna-rfc5891bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-klensin-idna-rfc5891bis-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org<mailto:I-D-Announce@ietf.org> https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ---------- End Forwarded Message ---------- _______________________________________________ Idna-update mailing list Idna-update@alvestrand.no<mailto:Idna-update@alvestrand.no> http://www.alvestrand.no/mailman/listinfo/idna-update
At igf this year John basically argued that no one should use EAI because it's confusing for non-ascii users, and people in other zones might as well just get on the bus and use ascii for their email addresses, too. It was odd, though educational. So I am not especially surprised to see John proposing more restrictions. Sent from my Windows Phone ________________________________ From: Shawn Steele<mailto:Shawn.Steele@microsoft.com> Sent: 3/12/2017 7:33 PM To: Richard Merdinger<mailto:rmerdinger@godaddy.com>; Edmon Chung<mailto:edmon@registry.asia>; Mark Svancarek<mailto:marksv@microsoft.com>; UA-discuss@icann.org<mailto:UA-discuss@icann.org> Subject: RE: [UA-discuss] FW: I-D Action: draft-klensin-idna-rfc5891bis-00.txt My concern is John’s emphasis on creating very restrictive character rule sets. The most restrictive rules created by IDNA2008 have been ignored because of user demand and backwards compatibility. Eg: no-emoji in labels. People want emoji, but IDNA2008 doesn’t permit it. Part of that is compatibility with the permitted IDNA2003 emoji, however there has also been demand for emoji characters newly added to Unicode. I think that it is appropriate to remind registrars that they are responsible for creating sane rules for their spaces, but it is clear that users do not want to be tied to the most restrictive demands of IDNA2008. Implementations appear to be settling on the Unicode provided idna data and I would much prefer to see the IETF standards point to the IDNA character sets provided by Unicode (while still encouraging registrars to do sane things that make sense for their domains). A good example of something a registrar might want to consider could be something like ü. Some spaces may allow ü without much restriction, however for .de, .ch, .at, etc. it might make sense to recognize that ü has an alternate ue spelling and to provide bundling or blocking of domains like müller.ch and mueller.ch. That kind of rule is very domain/language specific. Though it is not called out as some of the bidi rules are, the RFCs allow registrars to implement such a policy if it fits their purposes. Of course many other behaviors are called out by the IDNA2008 rules. Pretty much all of the concerns regarding the character repertoire can be resolved and the registrar level if the registrars would ensure that they did not allow registrations of multiple domain variations that might confuse their users. Or if they bundled those registrations. -Shawn From: Richard Merdinger [mailto:rmerdinger@godaddy.com] Sent: Saturday, March 11, 2017 11:35 PM To: Edmon Chung <edmon@registry.asia>; Mark Svancarek <marksv@microsoft.com>; UA-discuss@icann.org Cc: Shawn Steele <Shawn.Steele@microsoft.com> Subject: Re: [UA-discuss] FW: I-D Action: draft-klensin-idna-rfc5891bis-00.txt Agree, thanks for forwarding Mark This was a very cogent statement of affairs relative to the closing out of known IDN issues (or our current inability to do so). I agree with Edmon in that I think the UA effort should strive to be a catalyst here. --Rich From: <ua-discuss-bounces@icann.org<mailto:ua-discuss-bounces@icann.org>> on behalf of Edmon Chung <edmon@registry.asia<mailto:edmon@registry.asia>> Date: Sunday, March 12, 2017 at 7:11 AM To: 'Mark Svancarek' <marksv@microsoft.com<mailto:marksv@microsoft.com>>, "UA-discuss@icann.org<mailto:UA-discuss@icann.org>" <UA-discuss@icann.org<mailto:UA-discuss@icann.org>> Cc: 'Shawn Steele' <Shawn.Steele@microsoft.com<mailto:Shawn.Steele@microsoft.com>> Subject: Re: [UA-discuss] FW: I-D Action: draft-klensin-idna-rfc5891bis-00.txt Thanks for forwarding this Mark, This seems to be something useful for UA, perhaps we should work with the IDN team at ICANN (along with the communities networked from the LGR work) to see where we can best support. Edmon -----Original Message----- From: ua-discuss-bounces@icann.org<mailto:ua-discuss-bounces@icann.org> [mailto:ua-discuss-bounces@icann.org] On Behalf Of Mark Svancarek via UA-discuss Sent: Sunday, 12 March 2017 12:58 PM To: UA-discuss@icann.org<mailto:UA-discuss@icann.org> Cc: Shawn Steele <Shawn.Steele@microsoft.com<mailto:Shawn.Steele@microsoft.com>> Subject: [UA-discuss] FW: I-D Action: draft-klensin-idna-rfc5891bis-00.txt FYI, too much stuff from John for me to dig into this a.m. -----Original Message----- From: Idna-update [mailto:idna-update-bounces@alvestrand.no] On Behalf Of John C Klensin Sent: Saturday, March 11, 2017 8:25 AM To: idna-update@alvestrand.no<mailto:idna-update@alvestrand.no> Subject: FWD: I-D Action: draft-klensin-idna-rfc5891bis-00.txt Hi. For the information of those who may be watching this list but not the IETF announcement one... Asmus Freytag and I have started to put together a draft that addresses a problem with the IDNA2008 specs, specifically that we failed to make the responsibility of registries to define code point and label acceptability rules that were considerably more narrow (and better understood by them) than the full set of labels allowed by RFC 5891-5893. It doesn't actually change anything because that requirement is in the existing specs; it just makes (or tries to make) the requirements painfully clear to those who have been missing or misreading them. It also provides an explicit link between IDNA2008 requirements and ICANN work on repertoires and label generation rules without endorsing that work as more than one thoughtful approach that might be examined for either reference or inspiration. Comments (obviously) welcome. For anyone who might wonder, this document avoids the more controversial IDNA2008 issues including: * Multiple suggestions that we should add emoji, a subset of code points with General Category "So", to the list of code points allowed by IDNA. There are many reasons to not do that but it seems clear that, at some point, the IETF will need to either document those reasons or make the change. Volunteers to put together or work on a document would be welcome. * The non-decomposing code point problem, formerly (and incorrectly) known as the Hamza problem. There has been no discernable activity on this since the IAB Statement and LUCID BOF almost exactly two years ago. I've further updated the working copy of draft-klensin-idna-5892upd- unicode70 to cover additional cases and issues, but, in part because it is clearly inappropriate for a quick-patch individual submission, have been advised to not post it until we have a plan to make progress. So far, there is no such plan. * The (IMO, growing) problem of multiple and inconsistent specifications for IDNs and IDN handling, with different ones being used in different higher-level protocols and areas of the Internet. The use of different specifications and definitions creates opportunities for user and implementer confusion, interoperability difficulties, domain names that cannot be resolved under some circumstances, and various sorts of attacks. The specifications involved include IDNA2008, IDNA2003, assorted local "updates" to IDNA2003 that use versions of Stringprep locally updated to assorted versions of Unicode, and the various versions of UTR#46. The latest version of the latter explicitly allows emoji along with other symbols. A few months ago, I suggested to the IAB I18N program that a document be produced that at least pointed out the problems associated with multiple divergent specifications, but the idea got no traction. It appears to me that, although almost everyone agrees that IDNs, and well- and clearly-functional IDNs, are important, virtually no one is willing to do the hard work, at least unless they are being supported by ICANN (disclosure: I am not) or organizations whose interests lie in selling names, preferably as many of them as possible (I have no support from any of them either). Until and unless that changes, I don't see much prospect for getting those other issues addressed in a way that might lead to consensus documents. john ---------- Forwarded Message ---------- Date: Saturday, March 11, 2017 07:22 -0800 From: internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> To: i-d-announce@ietf.org<mailto:i-d-announce@ietf.org> Subject: I-D Action: draft-klensin-idna-rfc5891bis-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Internationalized Domain Names in Applications (IDNA): Registry Restrictions and Recommendations Authors : John C Klensin Asmus Freytag Filename : draft-klensin-idna-rfc5891bis-00.txt Pages : 10 Date : 2017-03-11 Abstract: The IDNA specifications for internationalized domain names combine rules that determine the labels that are allowed in the DNS without violating the protocol itself and an assignment of responsibility, consistent with earlier specifications, for determining the labels that are allowed in particular zones. Conformance to IDNA by registries and other implementations requires both parts. Experience strongly suggests that the language describing those responsibility was insufficiently clear to promote safe and interoperable use of the specifications and that more details and some specific examples would have been helpful. This specification updates the earlier ones to provide that guidance and to correct some technical errors in the descriptions. It does not alter the protocols and rules themselves in any way. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-klensin-idna-rfc5891bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-klensin-idna-rfc5891bis-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org<mailto:I-D-Announce@ietf.org> https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ---------- End Forwarded Message ---------- _______________________________________________ Idna-update mailing list Idna-update@alvestrand.no<mailto:Idna-update@alvestrand.no> http://www.alvestrand.no/mailman/listinfo/idna-update
On Mon, Mar 13, 2017 at 12:14:31PM +0000, Mark Svancarek via UA-discuss wrote:
At igf this year John basically argued that no one should use EAI because it's confusing for non-ascii users, and people in other zones might as well just get on the bus and use ascii for their email addresses, too. It was odd, though educational.
I didn't actually understand John to be saying that at the IGF, but I grant that the message may not have come across perfectly. A -- Andrew Sullivan ajs@anvilwalrusden.com
Dear All, If I may, I’d like to add something to follow up on Shawn’s message about character confusion. At EURid, the .eu registry, we implemented IDNA2008 in early 2015 and did notice to possibility of user confusion with homoglyphs such as ü = ue or ß = ss. We therefore decided to offer homoglyph bundling. This entails: A. Visually similar characters across different scripts are bundled. a. Latin e versus Cyrillic е b. Latin a versus Greek α (uppercase) There are exceptions to this rule. Below you will be able to find a non-exhaustive list. (More detailed information can be found on our site): Latin ß and Latin ss, Latin ss and Greek β: these are characters from 2 different scripts, which are not visually similar, Greek ς and Greek σ, Greek α and Greek ἀ ἁ ἂ ἃ ἄ ἅ and Greek ᾀ ᾁ ᾂ ᾃ ᾄ ᾅ and Greek αi and Greek ἀi ἁi ἂi ἃi ἄi ἅi. B. B) If one domain name in a homoglyph bundle exists, none of the other domain names in that bundle can be registered. The word “exists” should be interpreted in the previous sentence as having either one of the following .eu domain name statuses: in use, registered (on hold, suspended, seized), withdrawn, quarantine. When querying a domain name that is in a bundle via the WHOIS, it will return the status “homoglyph blocked”. This application on the registry-side allows for a reduction in the risks of user confusion, and takes into account the characters in various scripts which are read in a similar manner. Of course this becomes more complicated as the quantity of languages in play increases, but I think this is one way to address the concerns Shawn raised. More info one this is available on EURid site here: https://eurid.eu/en/register-a-eu-domain/domain-names-with-special-character... Sincerely, Sebastien From: ua-discuss-bounces@icann.org [mailto:ua-discuss-bounces@icann.org] On Behalf Of Mark Svancarek via UA-discuss Sent: maandag 13 maart 2017 13:15 To: Shawn Steele <Shawn.Steele@microsoft.com>; Richard Merdinger <rmerdinger@godaddy.com>; Edmon Chung <edmon@registry.asia>; UA-discuss@icann.org Subject: Re: [UA-discuss] FW: I-D Action: draft-klensin-idna-rfc5891bis-00.txt At igf this year John basically argued that no one should use EAI because it's confusing for non-ascii users, and people in other zones might as well just get on the bus and use ascii for their email addresses, too. It was odd, though educational. So I am not especially surprised to see John proposing more restrictions. Sent from my Windows Phone ________________________________ From: Shawn Steele<mailto:Shawn.Steele@microsoft.com> Sent: 3/12/2017 7:33 PM To: Richard Merdinger<mailto:rmerdinger@godaddy.com>; Edmon Chung<mailto:edmon@registry.asia>; Mark Svancarek<mailto:marksv@microsoft.com>; UA-discuss@icann.org<mailto:UA-discuss@icann.org> Subject: RE: [UA-discuss] FW: I-D Action: draft-klensin-idna-rfc5891bis-00.txt My concern is John’s emphasis on creating very restrictive character rule sets. The most restrictive rules created by IDNA2008 have been ignored because of user demand and backwards compatibility. Eg: no-emoji in labels. People want emoji, but IDNA2008 doesn’t permit it. Part of that is compatibility with the permitted IDNA2003 emoji, however there has also been demand for emoji characters newly added to Unicode. I think that it is appropriate to remind registrars that they are responsible for creating sane rules for their spaces, but it is clear that users do not want to be tied to the most restrictive demands of IDNA2008. Implementations appear to be settling on the Unicode provided idna data and I would much prefer to see the IETF standards point to the IDNA character sets provided by Unicode (while still encouraging registrars to do sane things that make sense for their domains). A good example of something a registrar might want to consider could be something like ü. Some spaces may allow ü without much restriction, however for .de, .ch, .at, etc. it might make sense to recognize that ü has an alternate ue spelling and to provide bundling or blocking of domains like müller.ch and mueller.ch. That kind of rule is very domain/language specific. Though it is not called out as some of the bidi rules are, the RFCs allow registrars to implement such a policy if it fits their purposes. Of course many other behaviors are called out by the IDNA2008 rules. Pretty much all of the concerns regarding the character repertoire can be resolved and the registrar level if the registrars would ensure that they did not allow registrations of multiple domain variations that might confuse their users. Or if they bundled those registrations. -Shawn From: Richard Merdinger [mailto:rmerdinger@godaddy.com] Sent: Saturday, March 11, 2017 11:35 PM To: Edmon Chung <edmon@registry.asia<mailto:edmon@registry.asia>>; Mark Svancarek <marksv@microsoft.com<mailto:marksv@microsoft.com>>; UA-discuss@icann.org<mailto:UA-discuss@icann.org> Cc: Shawn Steele <Shawn.Steele@microsoft.com<mailto:Shawn.Steele@microsoft.com>> Subject: Re: [UA-discuss] FW: I-D Action: draft-klensin-idna-rfc5891bis-00.txt Agree, thanks for forwarding Mark This was a very cogent statement of affairs relative to the closing out of known IDN issues (or our current inability to do so). I agree with Edmon in that I think the UA effort should strive to be a catalyst here. --Rich From: <ua-discuss-bounces@icann.org<mailto:ua-discuss-bounces@icann.org>> on behalf of Edmon Chung <edmon@registry.asia<mailto:edmon@registry.asia>> Date: Sunday, March 12, 2017 at 7:11 AM To: 'Mark Svancarek' <marksv@microsoft.com<mailto:marksv@microsoft.com>>, "UA-discuss@icann.org<mailto:UA-discuss@icann.org>" <UA-discuss@icann.org<mailto:UA-discuss@icann.org>> Cc: 'Shawn Steele' <Shawn.Steele@microsoft.com<mailto:Shawn.Steele@microsoft.com>> Subject: Re: [UA-discuss] FW: I-D Action: draft-klensin-idna-rfc5891bis-00.txt Thanks for forwarding this Mark, This seems to be something useful for UA, perhaps we should work with the IDN team at ICANN (along with the communities networked from the LGR work) to see where we can best support. Edmon -----Original Message----- From: ua-discuss-bounces@icann.org<mailto:ua-discuss-bounces@icann.org> [mailto:ua-discuss-bounces@icann.org] On Behalf Of Mark Svancarek via UA-discuss Sent: Sunday, 12 March 2017 12:58 PM To: UA-discuss@icann.org<mailto:UA-discuss@icann.org> Cc: Shawn Steele <Shawn.Steele@microsoft.com<mailto:Shawn.Steele@microsoft.com>> Subject: [UA-discuss] FW: I-D Action: draft-klensin-idna-rfc5891bis-00.txt FYI, too much stuff from John for me to dig into this a.m. -----Original Message----- From: Idna-update [mailto:idna-update-bounces@alvestrand.no] On Behalf Of John C Klensin Sent: Saturday, March 11, 2017 8:25 AM To: idna-update@alvestrand.no<mailto:idna-update@alvestrand.no> Subject: FWD: I-D Action: draft-klensin-idna-rfc5891bis-00.txt Hi. For the information of those who may be watching this list but not the IETF announcement one... Asmus Freytag and I have started to put together a draft that addresses a problem with the IDNA2008 specs, specifically that we failed to make the responsibility of registries to define code point and label acceptability rules that were considerably more narrow (and better understood by them) than the full set of labels allowed by RFC 5891-5893. It doesn't actually change anything because that requirement is in the existing specs; it just makes (or tries to make) the requirements painfully clear to those who have been missing or misreading them. It also provides an explicit link between IDNA2008 requirements and ICANN work on repertoires and label generation rules without endorsing that work as more than one thoughtful approach that might be examined for either reference or inspiration. Comments (obviously) welcome. For anyone who might wonder, this document avoids the more controversial IDNA2008 issues including: * Multiple suggestions that we should add emoji, a subset of code points with General Category "So", to the list of code points allowed by IDNA. There are many reasons to not do that but it seems clear that, at some point, the IETF will need to either document those reasons or make the change. Volunteers to put together or work on a document would be welcome. * The non-decomposing code point problem, formerly (and incorrectly) known as the Hamza problem. There has been no discernable activity on this since the IAB Statement and LUCID BOF almost exactly two years ago. I've further updated the working copy of draft-klensin-idna-5892upd- unicode70 to cover additional cases and issues, but, in part because it is clearly inappropriate for a quick-patch individual submission, have been advised to not post it until we have a plan to make progress. So far, there is no such plan. * The (IMO, growing) problem of multiple and inconsistent specifications for IDNs and IDN handling, with different ones being used in different higher-level protocols and areas of the Internet. The use of different specifications and definitions creates opportunities for user and implementer confusion, interoperability difficulties, domain names that cannot be resolved under some circumstances, and various sorts of attacks. The specifications involved include IDNA2008, IDNA2003, assorted local "updates" to IDNA2003 that use versions of Stringprep locally updated to assorted versions of Unicode, and the various versions of UTR#46. The latest version of the latter explicitly allows emoji along with other symbols. A few months ago, I suggested to the IAB I18N program that a document be produced that at least pointed out the problems associated with multiple divergent specifications, but the idea got no traction. It appears to me that, although almost everyone agrees that IDNs, and well- and clearly-functional IDNs, are important, virtually no one is willing to do the hard work, at least unless they are being supported by ICANN (disclosure: I am not) or organizations whose interests lie in selling names, preferably as many of them as possible (I have no support from any of them either). Until and unless that changes, I don't see much prospect for getting those other issues addressed in a way that might lead to consensus documents. john ---------- Forwarded Message ---------- Date: Saturday, March 11, 2017 07:22 -0800 From: internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> To: i-d-announce@ietf.org<mailto:i-d-announce@ietf.org> Subject: I-D Action: draft-klensin-idna-rfc5891bis-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Internationalized Domain Names in Applications (IDNA): Registry Restrictions and Recommendations Authors : John C Klensin Asmus Freytag Filename : draft-klensin-idna-rfc5891bis-00.txt Pages : 10 Date : 2017-03-11 Abstract: The IDNA specifications for internationalized domain names combine rules that determine the labels that are allowed in the DNS without violating the protocol itself and an assignment of responsibility, consistent with earlier specifications, for determining the labels that are allowed in particular zones. Conformance to IDNA by registries and other implementations requires both parts. Experience strongly suggests that the language describing those responsibility was insufficiently clear to promote safe and interoperable use of the specifications and that more details and some specific examples would have been helpful. This specification updates the earlier ones to provide that guidance and to correct some technical errors in the descriptions. It does not alter the protocols and rules themselves in any way. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-klensin-idna-rfc5891bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-klensin-idna-rfc5891bis-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org<mailto:I-D-Announce@ietf.org> https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ---------- End Forwarded Message ---------- _______________________________________________ Idna-update mailing list Idna-update@alvestrand.no<mailto:Idna-update@alvestrand.no> http://www.alvestrand.no/mailman/listinfo/idna-update Disclaimer: This email and any attachment hereto is intended solely for the person to which it is addressed and may contain confidential and/or privileged information. If you are not the intended recipient or if you have received this email in error, please delete it and immediately contact the sender by telephone or email, and destroy any copies of this information. You should not use or copy it, nor disclose its content to any other person or rely upon this information. Please note that any views presented in the email and any attachment hereto are solely those of the author and do not necessarily represent those of EURid. While all care has been taken to avoid any known viruses, the recipient is advised to check this email and any attachment for presence of viruses. http://www.eurid.eu/en/legal-disclaimer
That’s great to hear! From: Sebastien Pensis [mailto:Sebastien.Pensis@eurid.eu] Sent: Monday, March 13, 2017 6:11 AM To: Mark Svancarek <marksv@microsoft.com>; Shawn Steele <Shawn.Steele@microsoft.com>; Richard Merdinger <rmerdinger@godaddy.com>; Edmon Chung <edmon@registry.asia> Cc: UA-discuss@icann.org Subject: RE: [UA-discuss] FW: I-D Action: draft-klensin-idna-rfc5891bis-00.txt Dear All, If I may, I’d like to add something to follow up on Shawn’s message about character confusion. At EURid, the .eu registry, we implemented IDNA2008 in early 2015 and did notice to possibility of user confusion with homoglyphs such as ü = ue or ß = ss. We therefore decided to offer homoglyph bundling. This entails: 1. Visually similar characters across different scripts are bundled. * Latin e versus Cyrillic е * Latin a versus Greek α (uppercase) There are exceptions to this rule. Below you will be able to find a non-exhaustive list. (More detailed information can be found on our site): Latin ß and Latin ss, Latin ss and Greek β: these are characters from 2 different scripts, which are not visually similar, Greek ς and Greek σ, Greek α and Greek ἀ ἁ ἂ ἃ ἄ ἅ and Greek ᾀ ᾁ ᾂ ᾃ ᾄ ᾅ and Greek αi and Greek ἀi ἁi ἂi ἃi ἄi ἅi. 1. B) If one domain name in a homoglyph bundle exists, none of the other domain names in that bundle can be registered. The word “exists” should be interpreted in the previous sentence as having either one of the following .eu domain name statuses: in use, registered (on hold, suspended, seized), withdrawn, quarantine. When querying a domain name that is in a bundle via the WHOIS, it will return the status “homoglyph blocked”. This application on the registry-side allows for a reduction in the risks of user confusion, and takes into account the characters in various scripts which are read in a similar manner. Of course this becomes more complicated as the quantity of languages in play increases, but I think this is one way to address the concerns Shawn raised. More info one this is available on EURid site here: https://eurid.eu/en/register-a-eu-domain/domain-names-with-special-character... Sincerely, Sebastien From: ua-discuss-bounces@icann.org<mailto:ua-discuss-bounces@icann.org> [mailto:ua-discuss-bounces@icann.org] On Behalf Of Mark Svancarek via UA-discuss Sent: maandag 13 maart 2017 13:15 To: Shawn Steele <Shawn.Steele@microsoft.com<mailto:Shawn.Steele@microsoft.com>>; Richard Merdinger <rmerdinger@godaddy.com<mailto:rmerdinger@godaddy.com>>; Edmon Chung <edmon@registry.asia<mailto:edmon@registry.asia>>; UA-discuss@icann.org<mailto:UA-discuss@icann.org> Subject: Re: [UA-discuss] FW: I-D Action: draft-klensin-idna-rfc5891bis-00.txt At igf this year John basically argued that no one should use EAI because it's confusing for non-ascii users, and people in other zones might as well just get on the bus and use ascii for their email addresses, too. It was odd, though educational. So I am not especially surprised to see John proposing more restrictions. Sent from my Windows Phone ________________________________ From: Shawn Steele<mailto:Shawn.Steele@microsoft.com> Sent: 3/12/2017 7:33 PM To: Richard Merdinger<mailto:rmerdinger@godaddy.com>; Edmon Chung<mailto:edmon@registry.asia>; Mark Svancarek<mailto:marksv@microsoft.com>; UA-discuss@icann.org<mailto:UA-discuss@icann.org> Subject: RE: [UA-discuss] FW: I-D Action: draft-klensin-idna-rfc5891bis-00.txt My concern is John’s emphasis on creating very restrictive character rule sets. The most restrictive rules created by IDNA2008 have been ignored because of user demand and backwards compatibility. Eg: no-emoji in labels. People want emoji, but IDNA2008 doesn’t permit it. Part of that is compatibility with the permitted IDNA2003 emoji, however there has also been demand for emoji characters newly added to Unicode. I think that it is appropriate to remind registrars that they are responsible for creating sane rules for their spaces, but it is clear that users do not want to be tied to the most restrictive demands of IDNA2008. Implementations appear to be settling on the Unicode provided idna data and I would much prefer to see the IETF standards point to the IDNA character sets provided by Unicode (while still encouraging registrars to do sane things that make sense for their domains). A good example of something a registrar might want to consider could be something like ü. Some spaces may allow ü without much restriction, however for .de, .ch, .at, etc. it might make sense to recognize that ü has an alternate ue spelling and to provide bundling or blocking of domains like müller.ch and mueller.ch. That kind of rule is very domain/language specific. Though it is not called out as some of the bidi rules are, the RFCs allow registrars to implement such a policy if it fits their purposes. Of course many other behaviors are called out by the IDNA2008 rules. Pretty much all of the concerns regarding the character repertoire can be resolved and the registrar level if the registrars would ensure that they did not allow registrations of multiple domain variations that might confuse their users. Or if they bundled those registrations. -Shawn From: Richard Merdinger [mailto:rmerdinger@godaddy.com] Sent: Saturday, March 11, 2017 11:35 PM To: Edmon Chung <edmon@registry.asia<mailto:edmon@registry.asia>>; Mark Svancarek <marksv@microsoft.com<mailto:marksv@microsoft.com>>; UA-discuss@icann.org<mailto:UA-discuss@icann.org> Cc: Shawn Steele <Shawn.Steele@microsoft.com<mailto:Shawn.Steele@microsoft.com>> Subject: Re: [UA-discuss] FW: I-D Action: draft-klensin-idna-rfc5891bis-00.txt Agree, thanks for forwarding Mark This was a very cogent statement of affairs relative to the closing out of known IDN issues (or our current inability to do so). I agree with Edmon in that I think the UA effort should strive to be a catalyst here. --Rich From: <ua-discuss-bounces@icann.org<mailto:ua-discuss-bounces@icann.org>> on behalf of Edmon Chung <edmon@registry.asia<mailto:edmon@registry.asia>> Date: Sunday, March 12, 2017 at 7:11 AM To: 'Mark Svancarek' <marksv@microsoft.com<mailto:marksv@microsoft.com>>, "UA-discuss@icann.org<mailto:UA-discuss@icann.org>" <UA-discuss@icann.org<mailto:UA-discuss@icann.org>> Cc: 'Shawn Steele' <Shawn.Steele@microsoft.com<mailto:Shawn.Steele@microsoft.com>> Subject: Re: [UA-discuss] FW: I-D Action: draft-klensin-idna-rfc5891bis-00.txt Thanks for forwarding this Mark, This seems to be something useful for UA, perhaps we should work with the IDN team at ICANN (along with the communities networked from the LGR work) to see where we can best support. Edmon -----Original Message----- From: ua-discuss-bounces@icann.org<mailto:ua-discuss-bounces@icann.org> [mailto:ua-discuss-bounces@icann.org] On Behalf Of Mark Svancarek via UA-discuss Sent: Sunday, 12 March 2017 12:58 PM To: UA-discuss@icann.org<mailto:UA-discuss@icann.org> Cc: Shawn Steele <Shawn.Steele@microsoft.com<mailto:Shawn.Steele@microsoft.com>> Subject: [UA-discuss] FW: I-D Action: draft-klensin-idna-rfc5891bis-00.txt FYI, too much stuff from John for me to dig into this a.m. -----Original Message----- From: Idna-update [mailto:idna-update-bounces@alvestrand.no] On Behalf Of John C Klensin Sent: Saturday, March 11, 2017 8:25 AM To: idna-update@alvestrand.no<mailto:idna-update@alvestrand.no> Subject: FWD: I-D Action: draft-klensin-idna-rfc5891bis-00.txt Hi. For the information of those who may be watching this list but not the IETF announcement one... Asmus Freytag and I have started to put together a draft that addresses a problem with the IDNA2008 specs, specifically that we failed to make the responsibility of registries to define code point and label acceptability rules that were considerably more narrow (and better understood by them) than the full set of labels allowed by RFC 5891-5893. It doesn't actually change anything because that requirement is in the existing specs; it just makes (or tries to make) the requirements painfully clear to those who have been missing or misreading them. It also provides an explicit link between IDNA2008 requirements and ICANN work on repertoires and label generation rules without endorsing that work as more than one thoughtful approach that might be examined for either reference or inspiration. Comments (obviously) welcome. For anyone who might wonder, this document avoids the more controversial IDNA2008 issues including: * Multiple suggestions that we should add emoji, a subset of code points with General Category "So", to the list of code points allowed by IDNA. There are many reasons to not do that but it seems clear that, at some point, the IETF will need to either document those reasons or make the change. Volunteers to put together or work on a document would be welcome. * The non-decomposing code point problem, formerly (and incorrectly) known as the Hamza problem. There has been no discernable activity on this since the IAB Statement and LUCID BOF almost exactly two years ago. I've further updated the working copy of draft-klensin-idna-5892upd- unicode70 to cover additional cases and issues, but, in part because it is clearly inappropriate for a quick-patch individual submission, have been advised to not post it until we have a plan to make progress. So far, there is no such plan. * The (IMO, growing) problem of multiple and inconsistent specifications for IDNs and IDN handling, with different ones being used in different higher-level protocols and areas of the Internet. The use of different specifications and definitions creates opportunities for user and implementer confusion, interoperability difficulties, domain names that cannot be resolved under some circumstances, and various sorts of attacks. The specifications involved include IDNA2008, IDNA2003, assorted local "updates" to IDNA2003 that use versions of Stringprep locally updated to assorted versions of Unicode, and the various versions of UTR#46. The latest version of the latter explicitly allows emoji along with other symbols. A few months ago, I suggested to the IAB I18N program that a document be produced that at least pointed out the problems associated with multiple divergent specifications, but the idea got no traction. It appears to me that, although almost everyone agrees that IDNs, and well- and clearly-functional IDNs, are important, virtually no one is willing to do the hard work, at least unless they are being supported by ICANN (disclosure: I am not) or organizations whose interests lie in selling names, preferably as many of them as possible (I have no support from any of them either). Until and unless that changes, I don't see much prospect for getting those other issues addressed in a way that might lead to consensus documents. john ---------- Forwarded Message ---------- Date: Saturday, March 11, 2017 07:22 -0800 From: internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> To: i-d-announce@ietf.org<mailto:i-d-announce@ietf.org> Subject: I-D Action: draft-klensin-idna-rfc5891bis-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Internationalized Domain Names in Applications (IDNA): Registry Restrictions and Recommendations Authors : John C Klensin Asmus Freytag Filename : draft-klensin-idna-rfc5891bis-00.txt Pages : 10 Date : 2017-03-11 Abstract: The IDNA specifications for internationalized domain names combine rules that determine the labels that are allowed in the DNS without violating the protocol itself and an assignment of responsibility, consistent with earlier specifications, for determining the labels that are allowed in particular zones. Conformance to IDNA by registries and other implementations requires both parts. Experience strongly suggests that the language describing those responsibility was insufficiently clear to promote safe and interoperable use of the specifications and that more details and some specific examples would have been helpful. This specification updates the earlier ones to provide that guidance and to correct some technical errors in the descriptions. It does not alter the protocols and rules themselves in any way. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-klensin-idna-rfc5891bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-klensin-idna-rfc5891bis-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org<mailto:I-D-Announce@ietf.org> https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ---------- End Forwarded Message ---------- _______________________________________________ Idna-update mailing list Idna-update@alvestrand.no<mailto:Idna-update@alvestrand.no> http://www.alvestrand.no/mailman/listinfo/idna-update Disclaimer: This email and any attachment hereto is intended solely for the person to which it is addressed and may contain confidential and/or privileged information. If you are not the intended recipient or if you have received this email in error, please delete it and immediately contact the sender by telephone or email, and destroy any copies of this information. You should not use or copy it, nor disclose its content to any other person or rely upon this information. Please note that any views presented in the email and any attachment hereto are solely those of the author and do not necessarily represent those of EURid. While all care has been taken to avoid any known viruses, the recipient is advised to check this email and any attachment for presence of viruses. Other languages: English<http://www.eurid.eu/en/legal-disclaimer> Estonian<http://www.eurid.eu/et/legal-disclaimer> Italian<http://www.eurid.eu/it/legal-disclaimer> Maltese<http://www.eurid.eu/mt/legal-disclaimer> Romanian<http://www.eurid.eu/ro/legal-disclaimer> Swedish<http://www.eurid.eu/sv/legal-disclaimer> Czech<http://www.eurid.eu/cs/legal-disclaimer> Spanish<http://www.eurid.eu/es/legal-disclaimer> Latvian<http://www.eurid.eu/lv/legal-disclaimer> Dutch<http://www.eurid.eu/nl/legal-disclaimer> Slovak<http://www.eurid.eu/sk/legal-disclaimer> Greek<http://www.eurid.eu/el/legal-disclaimer> Danish<http://www.eurid.eu/da/legal-disclaimer> French<http://www.eurid.eu/fr/legal-disclaimer> Lithuanian<http://www.eurid.eu/lt/legal-disclaimer> Polish<http://www.eurid.eu/pl/legal-disclaimer> Slovenian<http://www.eurid.eu/sl/legal-disclaimer> Bulgarian<http://www.eurid.eu/bg/legal-disclaimer> German<http://www.eurid.eu/de/legal-disclaimer> Gaelic<http://www.eurid.eu/ga/legal-disclaimer> Hungarian<http://www.eurid.eu/hu/legal-disclaimer> Portuguese<http://www.eurid.eu/pt/legal-disclaimer> Finnish<http://www.eurid.eu/fi/legal-disclaimer> Croatian<http://www.eurid.eu/hr/legal-disclaimer>
Verisign have explicit and exacting registration restrictions eg Russian https://www.verisign.com/assets/languagefiles/RUS.html André Schappo
Hello André, many Russian tables could be found here: https://www.iana.org/domains/idn-tables Sincerely Yours, Maxim Alzoba Special projects manager, International Relations Department, FAITID m. +7 916 6761580(+whatsapp) skype oldfrogger Current UTC offset: +3.00 (.Moscow)
On Mar 14, 2017, at 16:36, Andre Schappo <A.Schappo@lboro.ac.uk> wrote:
Verisign have explicit and exacting registration restrictions eg Russian https://www.verisign.com/assets/languagefiles/RUS.html <https://www.verisign.com/assets/languagefiles/RUS.html>
André Schappo
I beg pardon for necroposting, my mail went bit crazy after the last ICANN meeting Maxim
On Jul 6, 2017, at 14:11, Maxim Alzoba <m.alzoba@gmail.com> wrote:
Hello André,
many Russian tables could be found here: https://www.iana.org/domains/idn-tables <https://www.iana.org/domains/idn-tables>
Sincerely Yours,
Maxim Alzoba Special projects manager, International Relations Department, FAITID
m. +7 916 6761580(+whatsapp) skype oldfrogger
Current UTC offset: +3.00 (.Moscow)
On Mar 14, 2017, at 16:36, Andre Schappo <A.Schappo@lboro.ac.uk <mailto:A.Schappo@lboro.ac.uk>> wrote:
Verisign have explicit and exacting registration restrictions eg Russian https://www.verisign.com/assets/languagefiles/RUS.html <https://www.verisign.com/assets/languagefiles/RUS.html>
André Schappo
participants (8)
-
Andre Schappo -
Andrew Sullivan -
Edmon Chung -
Mark Svancarek -
Maxim Alzoba -
Richard Merdinger -
Sebastien Pensis -
Shawn Steele