Re: Possible BofF question -- I18n (was: Re: Possible OBF question -- I18n)

[Nico Williams <[e-mail]>]

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
--