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

[Spencer Dawkins at IETF <[e-mail]>]

Ok, I own this part ... please see below.

On Fri, Jun 1, 2018, 19:10 Nico Williams <[e-mail]> wrote:

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

I pointed out that the Human Rights Review Team included consideration of
i18n when they reviewed an IAB draft I'm editing, within the past month. My
understanding was that people were looking for ways to get i18n reviews,
and that's the only formal mechanism I've encountered since the IAB
concluded their internationalization program over a year ago.

Perhaps that wasn't helpful. As far as I can see, it wasn't.

I'll wait for the BoF.

Spencer

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