On Fri, Jun 01, 2018 at 05:14:08PM -0400, John C Klensin wrote: > Now a few comments on recent postings (after I went to work on > the template). > * I think it would be a just dandy idea to require an "I18N > Considerations" section in every I-D or RFC. I see only two > problems with it. One is that we've had such a requirement for > documents that do have i18n issues for 20+ years and it hasn't > helped. [...] Please be specific. What failures have we had. > * Crypto expert mindsets -- I agree with John Levine on this. > FWIW, a few of us have made the observation that this i18n area > is easy to learn about for one class of people. Not impossible The condescension is thick in this one. > * Mentions of UTR#46 in general I18N contexts may be close to Finally. 900 words and this is the one specific thing, but not that specific either: > mentioning Hitler under Godwin's Law. It is strictly about IDNs > and not the general problem; its current version makes > assumptions equivalent to domain names not needing to be treated > as having important properties of identifiers; etc. As I said, > I don't think this BOF effort is about particular protocol > issues. However, as a non-protocol issue (and maybe the point > John Levine was trying to make) due in no small measure to > UTR#46 and the homebrew updates to IDNA2003 it has encouraged, > we have a large number (perhaps dozens) of interpretations about > what IDNA is "really" about and what the requirements "really" > are. That is an operational and user predictability problem, a > security problem, etc. > > "No urgency"? Only if one wants to see the IDN situation > deteriorate to the point that systems that are concerned about > privacy, malware, etc., will simply filter out all of them as a > good tradeoff against the risks. > > And, again, I see IDNs as one issue here among many, not the > only or even the key issue. Is this an elliptical way of alluding to confusables issues? Can you boil things down to a small set of bullet items? - IDNs and confusables? - I18N and human rights? (what's that got to do with Internet protocols? sure we have to make sure they internationalize, but we already knew that long before anyone made the connection to human rights) - something else? what? Please also list any high-profile failures of the IETF in this space. Keep it brief out of consideration for your readers' time. BTW, regarding IDNs and confusables, I'm going to restate my previous position on that: a) it _is_ possible to write code to detect confusables issues (lots of people are doing this; I've seen several repos in github implementing Unicode confusable detection) Of course, confusable detection is best done with UC standards (there is one, but is it complete?). There is no role for the IETF in this one. b) we can't make the registrars do the right thing c) we can't make the registries make the registrars do the right thing d) we can't make ICANN make the registries make the registrars do the right thing e) we _can_ give advice to ICANN and the registries, and the advice should be that they make up registry-specific policies as to confusables, and we should make up some sample policies f) besides giving ICANN and the registries advice, there is nothing for us to do here. It isn't possible to construct a one-size-fits-all-registries policy for IDNA -- the registries would reject such a thing. Dictating such a policy in IDNA would be inappropriate and very unpopular -- don't do it. g) the best default policy would be to construct a "canonicalized" form of any proposed domain and allow only one domain for each "canonicalized" form For example, "paypal" and "paypa1" could be considered equivalent in some policy, with "paypal" the canonical form, and only one of those two allowed in the given registry. A registrant could be allowed to have all equivalent forms of a domain's canonical form. Note that such a policy can be implemented (see (a)), but also that the uniqueness check can only be made by the registry, therefore we cannot dictate this in IDNA. Nico --
