Re: [UA-discuss] Fw: Re: IDN Implementation Guidelines [RE: Re : And now about phishing...]
From: Andrew Sullivan <ajs@anvilwalrusden.com> Subject: Re: [UA-discuss] Fw: Re: IDN Implementation Guidelines [RE: Re : And now about phishing...] To: ua-discuss@icann.org Date: Saturday, April 22, 2017, 9:16 AM On Sat, Apr 22, 2017 at 01:32:08PM +0000, nalini.elkins@insidethestack.com wrote>
For example, you may wish to see the following permutations which have already been obtained. (And, it appears not by Apple)
www.applé.com www.xn--appl-epa.com www.xn--appl-epa.com www.applê.com www.xn--appl-jpa.com www.xn--appl-jpa.com www.applė.com www.xn--appl-yva.com www.xn--appl-yva.com www.applę.com www.xn--appl-8va.com www.xn--appl-8va.com
Do you think that those qualify as "homographs"? I suppose they might, as might àpple.com and so on, but these at least don't seem to me to be any different than app1e.com, which we decided long ago was Apple's problem and nobody else's.
I guess so. It is just that because of internationalization, so many more of such permutations are possible. I think it might be useful to have another term for this: Here is an attempt: Homograph: a domain name that has characters that are visually indistinguishable (I am intentionally leaving out the font issues) Resembler: a domain name that can be easily visually confused for another well-known domain
From talking to various organizations, "Resemblers" are very definitely a concern. Whether this should be a policy from ICANN, someone else, or left to independent software vendors ala NaliniResemblerAndHomographFinder (tm), is an interesting question.
This is quite different to the case of true homoglyphs of the sort that Asmus is talking about, where the very same glyph is normally used in two different scripts such that nobody would be able to tell the difference. One maybe could argue that "аррӏе" is pure homoglyphs (0430,0440,0440,04CF, 0435), but I think it's tough to argue for it.
Remember, the IDNA rules are really _quite_restrictive, and if registries also require "same script per label" those restrictions catch an _awful_ lot of corner cases (that was the outcome of the "paypal" controversy some time ago).
If you want to argue that policy should be different, that's fine, but it seems to me to require some PDP within ICANN. Note that ICANN is probably going to propose some rules for variant handling, and combined with the LGR stuff that is working its way through the system we may find an awful lot of stuff is blocked.
One of my guys is working in the LatinGeneration panel if that is what you are talking about. So far, I believe they are at the TLD level.
In any case, I think our purpose is very badly served by conflating these two different kinds of issues.
Sure.
On Sat, Apr 22, 2017 at 04:49:20PM +0000, nalini.elkins@insidethestack.com wrote:
Here is an attempt:
Homograph: a domain name that has characters that are visually indistinguishable (I am intentionally leaving out the font issues)
Resembler: a domain name that can be easily visually confused for another well-known domain
I think that Unicode calls these "confusables", but some of my discussion with UTC members makes me think that they regard them all as more or less the same thing.
From talking to various organizations, "Resemblers" are very definitely a concern. Whether this should be a policy from ICANN, someone else, or left to independent software vendors ala NaliniResemblerAndHomographFinder (tm), is an interesting question.
Well, we do already have running code for this, because we don't seem to think that app1e.com requires anything except the ability of the trademark holder to take enforcement action. I don't get why these additional cases are supposed to be different.
One of my guys is working in the LatinGeneration panel if that is what you are talking about. So far, I believe they are at the TLD level.
And that, of course, is where they will stop. ICANN is capable of making rules about the root zone, but it cannot set policies for the zones below -- that's up to the operators of those zones. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
Andrew Sullivan writes:
And that, of course, is where they will stop. ICANN is capable of making rules about the root zone, but it cannot set policies for the zones below -- that's up to the operators of those zones.
And maybe the contractual arrangments they have with these operators? jaap
Monday, April 24, 2017, 12:16:54 AM, you wrote:
Andrew Sullivan writes:
And that, of course, is where they will stop. ICANN is capable of making rules about the root zone, but it cannot set policies for the zones below -- that's up to the operators of those zones.
not simply - ICANN is capable of making rules about the root zone - ICANN is capable of making at last the unified rules on the root zone and in absolutely ICANN cannot set policies for the zones below -- that's up to the Administrators of Registries of those zones. In paradigm split-off the roles of Administrator (setting and establishment of policies) and Technical Operator (technical support and maintenance) of the Registry
And maybe the contractual arrangments they have with these operators? Jaap, soory, what kinds of operators?
jaap
-- Yuri mailto:yvk@uanic.net
Well not entirely true either. There are ccTLDs, to which ICANN can make just recommendations. But, our world have gTLDs, where ICANN can set the rules for the zones bellow. :) It's not just black or white. :) Dusan -----Original Message----- From: ua-discuss-bounces@icann.org [mailto:ua-discuss-bounces@icann.org] On Behalf Of Yuriy Kargapolov Sent: Sunday, April 23, 2017 11:33 PM To: Jaap Akkerhuis <jaap@NLnetLabs.nl>; ua-discuss@icann.org Subject: Re: [UA-discuss] Fw: Re: IDN Implementation Guidelines [RE: Re : And now about phishing...] Monday, April 24, 2017, 12:16:54 AM, you wrote:
Andrew Sullivan writes:
And that, of course, is where they will stop. ICANN is capable of >> making rules about the root zone, but it cannot set policies for the >> zones below -- that's up to the operators of those zones.
not simply - ICANN is capable of making rules about the root zone - ICANN is capable of making at last the unified rules on the root zone and in absolutely ICANN cannot set policies for the zones below -- that's up to the Administrators of Registries of those zones. In paradigm split-off the roles of Administrator (setting and establishment of policies) and Technical Operator (technical support and maintenance) of the Registry
And maybe the contractual arrangments they have with these operators? Jaap, soory, what kinds of operators?
jaap
-- Yuri mailto:yvk@uanic.net --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
All, I've started to put together a list of tentative cross script homoglyphs. This is based partially on tables published by Unicode and data found in LGR proposals for the Root Zone. I've augmented the set with some of my own research. I've also indicated whether a code point was considered to be in likely widespread modern use as indicated by its inclusion into the Maximal Starting Repertoire for the Root Zone, MSR-2. Unicode's data cover code points that are "intentional" (that is expected to look the same). Unfortunately for anyone working with IDNA 2008, they contain a lot of irrelevant entries (which might be useful for other types of identifiers, perhaps) and they are presented in a format that requires knowing the NFD decomposition for all code points; easy for an algorithm, difficult for human reviewers working off IDNA 2008 PVALID lists (which are in NFC, that is composed). Finally, there are some curious omissions in the data. (Unicode publishes a rather larger list of "confusables", but my take is that there, the signal to noise ratio is unfavorable). I have removed the few items that constituted pure in-script duplication. The LGR data contain some additional suggested homoglyphs. Some of these are not as purely "intentional" as the Unicode set, but as they have been reviewed by the relevant communities, I've added them here. I have not added homoglyphs across script boundaries but inside multi-script writing systems, like the homoglyphs set of code points that link Hiragana and Katakana. However, it might be useful to add the set of Kana to Han homoglyphs (because they might be usable to spoof Chinese-only domains). Whether or not that is useful is one of the questions I hope to get answered by sharing the collection at this stage. (So far, they are not listed). Comments welcome, A./ PS: I have, as of yet, not provided the full listing of homoglyph relations where one script has a precomposed a code point and the other has a combining sequence. (Many of these code points are not in the widest use, so they do not constitute a priority). PPS: I'm using an RFC7940-based tool suite, so the result is formatted and looks like an LGR, but that's not the point. It's just like the guy with the hammer, to whom everything looked like a nail. The match is not really that bad in this case; the formatting gives some nice freebies like automatic display of Unicode names, script values and the like. However, a final collection might look very different, so I request feedback on the contents and scope, not the layout.
This is an amazing effort. Thank you. Definitely going into my references category. Is there perhaps a way for the infrastructure to limit to a smaller set of Unicode based on living languages (those with active readers above a specific value)? That would eliminate some of the code points. Put another way, is the intent of universal acceptance to support all languages used today in the world or all code points in Unicode? A supplemental aspect to consider in isolating the problem space might be whether the font(s) used for the address bar should have extra effort taken to ensure that these are not confusable. That might help in cases where the instances are in the same script. You can see an example of this with the capital i, lowercase L, and the one in the Edge (IE) font address bar (though the Il difference could / should likely be greater). Is there any value in pursuing this? -Stuart -----Original Message----- From: ua-discuss-bounces@icann.org [mailto:ua-discuss-bounces@icann.org] On Behalf Of Asmus Freytag Sent: Sunday, April 23, 2017 5:43 PM To: ua-discuss@icann.org Subject: Re: [UA-discuss] Cross-script Homoglyphs All, I've started to put together a list of tentative cross script homoglyphs. This is based partially on tables published by Unicode and data found in LGR proposals for the Root Zone. I've augmented the set with some of my own research. I've also indicated whether a code point was considered to be in likely widespread modern use as indicated by its inclusion into the Maximal Starting Repertoire for the Root Zone, MSR-2. Unicode's data cover code points that are "intentional" (that is expected to look the same). Unfortunately for anyone working with IDNA 2008, they contain a lot of irrelevant entries (which might be useful for other types of identifiers, perhaps) and they are presented in a format that requires knowing the NFD decomposition for all code points; easy for an algorithm, difficult for human reviewers working off IDNA 2008 PVALID lists (which are in NFC, that is composed). Finally, there are some curious omissions in the data. (Unicode publishes a rather larger list of "confusables", but my take is that there, the signal to noise ratio is unfavorable). I have removed the few items that constituted pure in-script duplication. The LGR data contain some additional suggested homoglyphs. Some of these are not as purely "intentional" as the Unicode set, but as they have been reviewed by the relevant communities, I've added them here. I have not added homoglyphs across script boundaries but inside multi-script writing systems, like the homoglyphs set of code points that link Hiragana and Katakana. However, it might be useful to add the set of Kana to Han homoglyphs (because they might be usable to spoof Chinese-only domains). Whether or not that is useful is one of the questions I hope to get answered by sharing the collection at this stage. (So far, they are not listed). Comments welcome, A./ PS: I have, as of yet, not provided the full listing of homoglyph relations where one script has a precomposed a code point and the other has a combining sequence. (Many of these code points are not in the widest use, so they do not constitute a priority). PPS: I'm using an RFC7940-based tool suite, so the result is formatted and looks like an LGR, but that's not the point. It's just like the guy with the hammer, to whom everything looked like a nail. The match is not really that bad in this case; the formatting gives some nice freebies like automatic display of Unicode names, script values and the like. However, a final collection might look very different, so I request feedback on the contents and scope, not the layout.
On 4/24/2017 6:57 AM, Stuart Stuple wrote:
This is an amazing effort. Thank you. Definitely going into my references category. Stuart,
thanks, this is far from finalized, so I hope I can get feedback on the concept and its details and then update you all with a revision.
Is there perhaps a way for the infrastructure to limit to a smaller set of Unicode based on living languages (those with active readers above a specific value)? That would eliminate some of the code points. Put another way, is the intent of universal acceptance to support all languages used today in the world or all code points in Unicode?
This is an excellent question. The root zone LGR project is designed to support as many languages as is feasible. There are no easily available data on the use of writing systems, but SIL's EGIDS is a good proxy: it gives the status of a language based on the mode of transmission, the degree to which it is supported by public and private institutions for example. Unfortunately, that resource just disappeared behind a paywall.
A supplemental aspect to consider in isolating the problem space might be whether the font(s) used for the address bar should have extra effort taken to ensure that these are not confusable. That might help in cases where the instances are in the same script. You can see an example of this with the capital i, lowercase L, and the one in the Edge (IE) font address bar (though the Il difference could / should likely be greater). Is there any value in pursuing this?
Consolas, to give one example, makes many distinctions not found in ordinary text. But would users expect to see them? However, even that font does not make all distinctions (and I'm not sure how many scripts it supports). Some of the code points I included in my list are not distinguished by it. Ohters were only distinguished by it. As long as one can't reliably predict that all (or at least overwhelmingly most) users can see a certain distinction (that is, actually get presented with glyphs that differ) then the conservative approach would be to treat the code points in question as homoglyphs. A./
-Stuart
-----Original Message----- From: ua-discuss-bounces@icann.org [mailto:ua-discuss-bounces@icann.org] On Behalf Of Asmus Freytag Sent: Sunday, April 23, 2017 5:43 PM To: ua-discuss@icann.org Subject: Re: [UA-discuss] Cross-script Homoglyphs
All,
I've started to put together a list of tentative cross script homoglyphs.
This is based partially on tables published by Unicode and data found in LGR proposals for the Root Zone. I've augmented the set with some of my own research. I've also indicated whether a code point was considered to be in likely widespread modern use as indicated by its inclusion into the Maximal Starting Repertoire for the Root Zone, MSR-2.
Unicode's data cover code points that are "intentional" (that is expected to look the same). Unfortunately for anyone working with IDNA 2008, they contain a lot of irrelevant entries (which might be useful for other types of identifiers, perhaps) and they are presented in a format that requires knowing the NFD decomposition for all code points; easy for an algorithm, difficult for human reviewers working off IDNA 2008 PVALID lists (which are in NFC, that is composed).
Finally, there are some curious omissions in the data. (Unicode publishes a rather larger list of "confusables", but my take is that there, the signal to noise ratio is unfavorable). I have removed the few items that constituted pure in-script duplication.
The LGR data contain some additional suggested homoglyphs. Some of these are not as purely "intentional" as the Unicode set, but as they have been reviewed by the relevant communities, I've added them here.
I have not added homoglyphs across script boundaries but inside multi-script writing systems, like the homoglyphs set of code points that link Hiragana and Katakana. However, it might be useful to add the set of Kana to Han homoglyphs (because they might be usable to spoof Chinese-only domains). Whether or not that is useful is one of the questions I hope to get answered by sharing the collection at this stage. (So far, they are not listed).
Comments welcome,
A./
PS: I have, as of yet, not provided the full listing of homoglyph relations where one script has a precomposed a code point and the other has a combining sequence. (Many of these code points are not in the widest use, so they do not constitute a priority).
PPS: I'm using an RFC7940-based tool suite, so the result is formatted and looks like an LGR, but that's not the point. It's just like the guy with the hammer, to whom everything looked like a nail. The match is not really that bad in this case; the formatting gives some nice freebies like automatic display of Unicode names, script values and the like. However, a final collection might look very different, so I request feedback on the contents and scope, not the layout.
Unfortunately, that resource just disappeared behind a paywall. I am sure Don can scrape up some $$ to pay 😊 -----Original Message----- From: ua-discuss-bounces@icann.org [mailto:ua-discuss-bounces@icann.org] On Behalf Of Asmus Freytag (c) Sent: Monday, April 24, 2017 8:41 AM To: Stuart Stuple <stuartst@microsoft.com>; ua-discuss@icann.org Subject: Re: [UA-discuss] Cross-script Homoglyphs On 4/24/2017 6:57 AM, Stuart Stuple wrote:
This is an amazing effort. Thank you. Definitely going into my references category.
Stuart, thanks, this is far from finalized, so I hope I can get feedback on the concept and its details and then update you all with a revision.
Is there perhaps a way for the infrastructure to limit to a smaller set of Unicode based on living languages (those with active readers above a specific value)? That would eliminate some of the code points. Put another way, is the intent of universal acceptance to support all languages used today in the world or all code points in Unicode?
This is an excellent question. The root zone LGR project is designed to support as many languages as is feasible. There are no easily available data on the use of writing systems, but SIL's EGIDS is a good proxy: it gives the status of a language based on the mode of transmission, the degree to which it is supported by public and private institutions for example. Unfortunately, that resource just disappeared behind a paywall.
A supplemental aspect to consider in isolating the problem space might be whether the font(s) used for the address bar should have extra effort taken to ensure that these are not confusable. That might help in cases where the instances are in the same script. You can see an example of this with the capital i, lowercase L, and the one in the Edge (IE) font address bar (though the Il difference could / should likely be greater). Is there any value in pursuing this?
Consolas, to give one example, makes many distinctions not found in ordinary text. But would users expect to see them? However, even that font does not make all distinctions (and I'm not sure how many scripts it supports). Some of the code points I included in my list are not distinguished by it. Ohters were only distinguished by it. As long as one can't reliably predict that all (or at least overwhelmingly most) users can see a certain distinction (that is, actually get presented with glyphs that differ) then the conservative approach would be to treat the code points in question as homoglyphs. A./
-Stuart
-----Original Message-----
From: ua-discuss-bounces@icann.org<mailto:ua-discuss-bounces@icann.org>
[mailto:ua-discuss-bounces@icann.org] On Behalf Of Asmus Freytag
Sent: Sunday, April 23, 2017 5:43 PM
To: ua-discuss@icann.org<mailto:ua-discuss@icann.org>
Subject: Re: [UA-discuss] Cross-script Homoglyphs
All,
I've started to put together a list of tentative cross script homoglyphs.
This is based partially on tables published by Unicode and data found in LGR proposals for the Root Zone. I've augmented the set with some of my own research. I've also indicated whether a code point was considered to be in likely widespread modern use as indicated by its inclusion into the Maximal Starting Repertoire for the Root Zone, MSR-2.
Unicode's data cover code points that are "intentional" (that is
expected to look the same). Unfortunately for anyone working with IDNA
2008, they contain a lot of irrelevant entries (which might be useful
for other types of identifiers, perhaps) and they are presented in a
format that requires knowing the NFD decomposition for all code
points; easy for an algorithm, difficult for human reviewers working
off IDNA
2008 PVALID lists (which are in NFC, that is composed).
Finally, there are some curious omissions in the data. (Unicode publishes a rather larger list of "confusables", but my take is that there, the signal to noise ratio is unfavorable). I have removed the few items that constituted pure in-script duplication.
The LGR data contain some additional suggested homoglyphs. Some of these are not as purely "intentional" as the Unicode set, but as they have been reviewed by the relevant communities, I've added them here.
I have not added homoglyphs across script boundaries but inside multi-script writing systems, like the homoglyphs set of code points that link Hiragana and Katakana. However, it might be useful to add the set of Kana to Han homoglyphs (because they might be usable to spoof Chinese-only domains). Whether or not that is useful is one of the questions I hope to get answered by sharing the collection at this stage. (So far, they are not listed).
Comments welcome,
A./
PS: I have, as of yet, not provided the full listing of homoglyph relations where one script has a precomposed a code point and the other has a combining sequence. (Many of these code points are not in the widest use, so they do not constitute a priority).
PPS: I'm using an RFC7940-based tool suite, so the result is formatted and looks like an LGR, but that's not the point. It's just like the guy with the hammer, to whom everything looked like a nail. The match is not really that bad in this case; the formatting gives some nice freebies like automatic display of Unicode names, script values and the like.
However, a final collection might look very different, so I request feedback on the contents and scope, not the layout.
For Microsoft, I have some influence on the font design and would definitely advocate for changes or addition if we see value. -Stuart -----Original Message----- From: Asmus Freytag (c) [mailto:asmusf@ix.netcom.com] Sent: Monday, April 24, 2017 8:41 AM To: Stuart Stuple <stuartst@microsoft.com>; ua-discuss@icann.org Subject: Re: [UA-discuss] Cross-script Homoglyphs On 4/24/2017 6:57 AM, Stuart Stuple wrote:
This is an amazing effort. Thank you. Definitely going into my references category. Stuart,
thanks, this is far from finalized, so I hope I can get feedback on the concept and its details and then update you all with a revision.
Is there perhaps a way for the infrastructure to limit to a smaller set of Unicode based on living languages (those with active readers above a specific value)? That would eliminate some of the code points. Put another way, is the intent of universal acceptance to support all languages used today in the world or all code points in Unicode?
This is an excellent question. The root zone LGR project is designed to support as many languages as is feasible. There are no easily available data on the use of writing systems, but SIL's EGIDS is a good proxy: it gives the status of a language based on the mode of transmission, the degree to which it is supported by public and private institutions for example. Unfortunately, that resource just disappeared behind a paywall.
A supplemental aspect to consider in isolating the problem space might be whether the font(s) used for the address bar should have extra effort taken to ensure that these are not confusable. That might help in cases where the instances are in the same script. You can see an example of this with the capital i, lowercase L, and the one in the Edge (IE) font address bar (though the Il difference could / should likely be greater). Is there any value in pursuing this?
Consolas, to give one example, makes many distinctions not found in ordinary text. But would users expect to see them? However, even that font does not make all distinctions (and I'm not sure how many scripts it supports). Some of the code points I included in my list are not distinguished by it. Ohters were only distinguished by it. As long as one can't reliably predict that all (or at least overwhelmingly most) users can see a certain distinction (that is, actually get presented with glyphs that differ) then the conservative approach would be to treat the code points in question as homoglyphs. A./
-Stuart
-----Original Message----- From: ua-discuss-bounces@icann.org [mailto:ua-discuss-bounces@icann.org] On Behalf Of Asmus Freytag Sent: Sunday, April 23, 2017 5:43 PM To: ua-discuss@icann.org Subject: Re: [UA-discuss] Cross-script Homoglyphs
All,
I've started to put together a list of tentative cross script homoglyphs.
This is based partially on tables published by Unicode and data found in LGR proposals for the Root Zone. I've augmented the set with some of my own research. I've also indicated whether a code point was considered to be in likely widespread modern use as indicated by its inclusion into the Maximal Starting Repertoire for the Root Zone, MSR-2.
Unicode's data cover code points that are "intentional" (that is expected to look the same). Unfortunately for anyone working with IDNA 2008, they contain a lot of irrelevant entries (which might be useful for other types of identifiers, perhaps) and they are presented in a format that requires knowing the NFD decomposition for all code points; easy for an algorithm, difficult for human reviewers working off IDNA 2008 PVALID lists (which are in NFC, that is composed).
Finally, there are some curious omissions in the data. (Unicode publishes a rather larger list of "confusables", but my take is that there, the signal to noise ratio is unfavorable). I have removed the few items that constituted pure in-script duplication.
The LGR data contain some additional suggested homoglyphs. Some of these are not as purely "intentional" as the Unicode set, but as they have been reviewed by the relevant communities, I've added them here.
I have not added homoglyphs across script boundaries but inside multi-script writing systems, like the homoglyphs set of code points that link Hiragana and Katakana. However, it might be useful to add the set of Kana to Han homoglyphs (because they might be usable to spoof Chinese-only domains). Whether or not that is useful is one of the questions I hope to get answered by sharing the collection at this stage. (So far, they are not listed).
Comments welcome,
A./
PS: I have, as of yet, not provided the full listing of homoglyph relations where one script has a precomposed a code point and the other has a combining sequence. (Many of these code points are not in the widest use, so they do not constitute a priority).
PPS: I'm using an RFC7940-based tool suite, so the result is formatted and looks like an LGR, but that's not the point. It's just like the guy with the hammer, to whom everything looked like a nail. The match is not really that bad in this case; the formatting gives some nice freebies like automatic display of Unicode names, script values and the like. However, a final collection might look very different, so I request feedback on the contents and scope, not the layout.
yes, perhaps I should clarify - I mean only ccTLD within two conditions of "unified rules on the root zone" and "absolutely ICANN cannot set policies for the zones below" but to my mind condition on split-off the roles of Administrator and Technical Operator should be implemented at least in the form of best practices for both - ccTLD and gTLD Monday, April 24, 2017, 1:41:28 AM, you wrote:
Well not entirely true either. There are ccTLDs, to which ICANN can make just recommendations. But, our world have gTLDs, where ICANN can set the rules for the zones bellow. :) It's not just black or white. :)
Dusan
-----Original Message----- From: ua-discuss-bounces@icann.org [mailto:ua-discuss-bounces@icann.org] On Behalf Of Yuriy Kargapolov Sent: Sunday, April 23, 2017 11:33 PM To: Jaap Akkerhuis <jaap@NLnetLabs.nl>; ua-discuss@icann.org Subject: Re: [UA-discuss] Fw: Re: IDN Implementation Guidelines [RE: Re : And now about phishing...]
Monday, April 24, 2017, 12:16:54 AM, you wrote:
Andrew Sullivan writes:
And that, of course, is where they will stop. ICANN is capable of >> making rules about the root zone, but it cannot set policies for the >> zones below -- that's up to the operators of those zones.
not simply - ICANN is capable of making rules about the root zone - ICANN is capable of making at last the unified rules on the root zone and in absolutely ICANN cannot set policies for the zones below -- that's up to the Administrators of Registries of those zones. In paradigm split-off the roles of Administrator (setting and establishment of policies) and Technical Operator (technical support and maintenance) of the Registry
And maybe the contractual arrangments they have with these operators? Jaap, soory, what kinds of operators?
jaap
-- З повагою, Ю. Каргаполов mailto:yvk@uanic.net
Actually, the ICANN IDN Implementation Guidelines apply to gTLDs as well as IDN ccTLDs for 2nd level (or 3rd level for which registrations are accepted by the registry). All IDN ccTLDs to date (as far as I understsand) are required to confirm that they will abide by the ICANN IDN Implementation Guidelines through the application for delegation process. ASCII ccTLDs are of course not required to do so. Edmon
-----Original Message----- From: ua-discuss-bounces@icann.org [mailto:ua-discuss-bounces@icann.org] On Behalf Of Yuriy Kargapolov Sent: Monday, 24 April 2017 15:42 PM To: Dusan Stojicevic <dusan@dukes.in.rs>; 'Jaap Akkerhuis' <jaap@NLnetLabs.nl>; ua-discuss@icann.org Subject: Re: [UA-discuss] Fw: Re: IDN Implementation Guidelines [RE: Re : And now about phishing...]
yes, perhaps I should clarify - I mean only ccTLD within two conditions of "unified rules on the root zone" and "absolutely ICANN cannot set policies for the zones below" but to my mind condition on split-off the roles of Administrator and Technical Operator should be implemented at least in the form of best practices for both - ccTLD and gTLD
Monday, April 24, 2017, 1:41:28 AM, you wrote:
Well not entirely true either. There are ccTLDs, to which ICANN can make just recommendations. But, our world have gTLDs, where ICANN can set the rules for the zones bellow. :) It's not just black or white. :)
Dusan
-----Original Message----- From: ua-discuss-bounces@icann.org [mailto:ua-discuss-bounces@icann.org] On Behalf Of Yuriy Kargapolov Sent: Sunday, April 23, 2017 11:33 PM To: Jaap Akkerhuis <jaap@NLnetLabs.nl>; ua-discuss@icann.org Subject: Re: [UA-discuss] Fw: Re: IDN Implementation Guidelines [RE: Re : And now about phishing...]
Monday, April 24, 2017, 12:16:54 AM, you wrote:
Andrew Sullivan writes:
And that, of course, is where they will stop. ICANN is capable of
making rules about the root zone, but it cannot set policies for the >> zones below -- that's up to the operators of those zones.
not simply - ICANN is capable of making rules about the root zone - ICANN is capable of making at last the unified rules on the root zone and in absolutely ICANN cannot set policies for the zones below -- that's up to the Administrators of Registries of those zones. In paradigm split-off the roles of Administrator (setting and establishment of policies) and Technical Operator (technical support and maintenance) of the Registry
And maybe the contractual arrangments they have with these operators? Jaap, soory, what kinds of operators?
jaap
--
З повагою, Ю. Каргаполов mailto:yvk@uanic.net
Not sure about ccTLDs as well as latin (classic :) ) and IDN At first, there are any "country code" TLDs should follow the provisions of national legislation Second, if we talk about IDN - does it mean that IDN in any latin ccTLD should follow by ICANN IDN Implementation Guidelines? I mean that some ccTLD in latin allows registration IDN in second and higher levels, please see https://hostmaster.ua/UAstat/?idn Yuri Monday, April 24, 2017, 10:52:38 AM, you wrote:
Actually, the ICANN IDN Implementation Guidelines apply to gTLDs as well as IDN ccTLDs for 2nd level (or 3rd level for which registrations are accepted by the registry). All IDN ccTLDs to date (as far as I understsand) are required to confirm that they will abide by the ICANN IDN Implementation Guidelines through the application for delegation process. ASCII ccTLDs are of course not required to do so.
Edmon
-----Original Message----- From: ua-discuss-bounces@icann.org [mailto:ua-discuss-bounces@icann.org] On Behalf Of Yuriy Kargapolov Sent: Monday, 24 April 2017 15:42 PM To: Dusan Stojicevic <dusan@dukes.in.rs>; 'Jaap Akkerhuis' <jaap@NLnetLabs.nl>; ua-discuss@icann.org Subject: Re: [UA-discuss] Fw: Re: IDN Implementation Guidelines [RE: Re : And now about phishing...]
yes, perhaps I should clarify - I mean only ccTLD within two conditions of "unified rules on the root zone" and "absolutely ICANN cannot set policies for the zones below" but to my mind condition on split-off the roles of Administrator and Technical Operator should be implemented at least in the form of best practices for both - ccTLD and gTLD
Monday, April 24, 2017, 1:41:28 AM, you wrote:
Well not entirely true either. There are ccTLDs, to which ICANN can make just recommendations. But, our world have gTLDs, where ICANN can set the rules for the zones bellow. :) It's not just black or white. :)
Dusan
-----Original Message----- From: ua-discuss-bounces@icann.org [mailto:ua-discuss-bounces@icann.org] On Behalf Of Yuriy Kargapolov Sent: Sunday, April 23, 2017 11:33 PM To: Jaap Akkerhuis <jaap@NLnetLabs.nl>; ua-discuss@icann.org Subject: Re: [UA-discuss] Fw: Re: IDN Implementation Guidelines [RE: Re : And now about phishing...]
Monday, April 24, 2017, 12:16:54 AM, you wrote:
Andrew Sullivan writes:
And that, of course, is where they will stop. ICANN is capable of
making rules about the root zone, but it cannot set policies for the >> zones below -- that's up to the operators of those zones.
not simply - ICANN is capable of making rules about the root zone - ICANN is capable of making at last the unified rules on the root zone and in absolutely ICANN cannot set policies for the zones below -- that's up to the Administrators of Registries of those zones. In paradigm split-off the roles of Administrator (setting and establishment of policies) and Technical Operator (technical support and maintenance) of the Registry
And maybe the contractual arrangments they have with these operators? Jaap, soory, what kinds of operators?
jaap
On Mon, Apr 24, 2017 at 03:52:38PM +0800, Edmon Chung wrote:
by the registry). All IDN ccTLDs to date (as far as I understsand) are required to confirm that they will abide by the ICANN IDN Implementation Guidelines through the application for delegation process.
Sure, but the traditional ISO-3166 ccTLDs are simply not subject to the Guidelines. (We can know this because of the emojis some of them are selling.) A -- Andrew Sullivan ajs@anvilwalrusden.com
Monday, April 24, 2017, 12:16:54 AM, you wrote:
Andrew Sullivan writes:
And that, of course, is where they will stop. ICANN is capable of making rules about the root zone, but it cannot set policies for the zones below -- that's up to the operators of those zones.
not simply - ICANN is capable of making rules about the root zone - ICANN is capable of making at last the unified rules on the root zone and in absolutely ICANN cannot set policies for the zones below -- that's up to the Administrators of Registries of those zones. In paradigm split-off the roles of Administrator (setting and establishment of policies) and Technical Operator (technical support and maintenance) of the Registry
And maybe the contractual arrangments they have with these operators? Jaap, soory, what kinds of operators?
jaap
-- Yuri mailto:yvk@uanic.net
On Sun, Apr 23, 2017 at 11:16:54PM +0200, Jaap Akkerhuis wrote:
And maybe the contractual arrangments they have with these operators?
That's how it's worked historically, yes. ICANN needs to be careful not to overstep its restricted mission, but within that it may make contractual arrangements that work well. A -- Andrew Sullivan ajs@anvilwalrusden.com
participants (11)
-
Andrew Sullivan -
Asmus Freytag -
Asmus Freytag (c)
-
Dusan Stojicevic -
Edmon Chung -
Jaap Akkerhuis -
Mark Svancarek -
nalini.elkins＠insidethestack.com -
Stuart Stuple -
Yuriy Kargapolov -
Yuriy Kargapolov