Ok, I own this part ... please see below.
On Fri, Jun 1, 2018, 19:10 Nico Williams <nico@xxxxxxxxxxxxxxxx> 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
--
