Subject: Re: [Idna-update] [I18nrp] Last Call: <draft-faltstrom-unicode11-05.txt> (IDNA2008 and Unicode 11.0.0) to Informational RFC

From: John C Klensin <[email-masked]>
Date: Wed, 05 Dec 2018 16:46:45 -0500

--On Wednesday, December 5, 2018 08:56 +0100 Patrik Fältström
<paf=[email-masked]> wrote:

> 3. Registries should not "just" allow all PVALID (etc) code
> points, but also include a conservative registration policy
> 
> I do though not see (3) is in violation with other documents.
> It just emphasizes the same thing already said elsewhere. For
> example in the "troublesome characters" draft there is a
> suggestion on a method to use when developing one such policy.

It is also an existing requirement.  See discussion and
references in draft-klensin-idna-rfc5891bis but that I-D doesn't
actually change anything other than clarifying the existing
rules.   So, whether (3) should be said here may be
controversial unless it is clearly stated as restating rules
established elsewhere (a reference to
draft-klensin-idna-rfc5891bis would help with that, but
certainly is not essential).  On the other hand, if you were to
say anything about registry policies that changed that rule or
encouraged a belief that anything authorized by the 5892 rules
was ok, that would not only clearly update several other
documents but be very controversial.

     john

p.s. addressing another issue, I don't believe we've ever made a
document Historic that is part of the record of evolution of a
Standards Track specification that is not itself considered
Historic.   Even if we had, I think it would be really
unfortunate in this case.

---

From: John C Klensin <[email-masked]>
Date: Fri, 07 Dec 2018 00:39:26 -0500

Larry,

The theory about registries in the current IDNA RFCs was to
impose a strong requirement that they be conservative including,
but not limited to, understanding the scripts they are
permitting.  That requirement is, I believe, consistent with
both what you are saying and what Asmus appears to be saying on
that subject.   The details about how to best accomplish that--
to convince them to actually do so-- seem to be a more
complicated matter.  

As I've said in other, probably too-long, notes, most registries
who manage zones within an enterprise or other organization have
been fairly good about it; many of the second-level registries
and others whose business and operational model involves selling
names to unrelated parties have tended to adopt the least
restrictive policies they believe they can get away with.

Part of the problem with the IDNA RFCs is that the requirement
for registry conservatism and responsibility is too scattered
through several documents to come across as important as I think
we all believe it is.   draft-klensin-idna-rfc5891bis (now
expired, but waiting in the wings) was intended to address that
issue.  I haven't looked at the text for a while but strongly
suspect it does not identify and stress labels being
"re-enterable" and "retypable" as you suggest.   It should.  If
you don't mind taking a look at it, I'd appreciate recommended
text.   Or, if that isn't convenient, I'll try to remember to
say something when I next open the document.

thanks,
    john

--On Thursday, December 6, 2018 16:59 -0800 Larry Masinter
<[email-masked]> wrote:

> Registries should be conservative in the sense of advising
> their clients about the likely usability of the registered
> name among their target audience.
> I don't think the IDNA RFCs currently are conservative enough.
> As I've noted before, usability includes "re-enterable"
> (including "retypable") .
> 
> 
> 
>> -----Original Message-----
>> From: i18nRP <[email-masked]> On Behalf Of Patrik
>> Fältström Sent: Thursday, December 6, 2018 2:44 AM
>> To: Asmus Freytag <[email-masked]>
>> Cc: [email-masked]; Paul Hoffman <[email-masked]>
>> Subject: Re: [I18nrp] Last Call:
>> <draft-faltstrom-unicode11-05.txt>
> (IDNA2008
>> and Unicode 11.0.0) to Informational RFC
>> 
>> On 5 Dec 2018, at 19:03, Asmus Freytag (c) wrote:
>> 
>> >> 
>> >>     3. Registries should not "just" allow all PVALID
>> >>     (etc.) code
> points, but also
>> include a conservative registration policy
>> >> 
>> > 
>> > add:
>> > 
>> > "as mandated in RFCs <get the IDNA RFC citations from John
>> > Klensin's
> draft
>> here>."
>> 
>> Correct, I blame my Swenglish dialect for the mistake in
>> wording I did.
>> 
>>    paf
> 
> _______________________________________________
> i18nRP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i18nrp

---

From: John C Klensin <[email-masked]>
Date: Fri, 07 Dec 2018 01:12:47 -0500

--On Friday, December 7, 2018 05:43 +0100 Patrik Fältström
<paf=[email-masked]> wrote:

>...
> I might not agree with this, as for example very few
> characters in arabic script are "retypable" for me. So this is
> at least a separate issue. But what the registry chooses, I
> feel is up to them, as long as they do come up with a good
> repertoire.

Patrik,

I think your second point ("up to them" as long as it is "good"
--including sufficiently conservative) is the important one and
the one on which we can all agree.  But I still believe that,
with appropriate qualification, Larry is still correct.   The
very decision to move in the direction of IDNs meant that there
would be labels that would be much easier to read (and enter)
for some populations and other labels that would be easier for a
different population.  It seems to me that we just have to
accept that.  One think it implies is that, if a label is
written in a script one doesn't use frequently, "typing" may
require a character-picker.  Character-pickers are better than
nothing but no fun at all, especially if one does not easily
recognize the characters involved and differences between then
(and, to save Asmus pointing it out, complex scripts may
complicate both the recognition problem and the picking one).
We also need to remember, as Ted Hardie and others have reminded
us multiple times, that there are increasing moves toward voice
input, a trend that will de-emphasize typing and, most likely,
make the lives of those of us who can speak a given language
only with horrible accents much more "interesting".

However, to the extent to which one can sensibly use (including
simple reading of the characters) a label at all at all, I think
ability to re-enter it, to be assured that, insofar as possible,
there are no other labels in the zone that can easily be
mistaken for it, strings that are likely to be entered where it
is is intended, etc., are as important to a conservative
approach as things we've talked about more such as ensuring that
strings are well-formed for the script and that interactions
between RtoL characters and characters with neutral or LtoR
directionality don't cause, e.g., labels to appear in orders
that others might not predict.

I hope Larry has a better (and shorter) way to formulate that
than I do, which is why I'm hoping for text.

best,
    john

---

From: "Patrik Fältström" <[email-masked]>
Date: Fri, 07 Dec 2018 07:16:03 +0100

On 7 Dec 2018, at 7:12, John C Klensin wrote:

> But I still believe that, with appropriate qualification, Larry is still correct.

I think we dive into the details here.

1. I think the ability (for example) copy and paste, respond to, click on, save in bookmarks etc is the most important global requirement

2. The ability to type, to enter via a keyboard, read on a bus, etc is secondary and have localization issues so very much different than (1)

My point was that because of this, I think retypable is very very very much different than other, global, requirements, and the latter should not (I think) muddy the waters of the first requirement I list above.

   paf

---

From: John C Klensin <[email-masked]>
Date: Fri, 07 Dec 2018 01:33:49 -0500

--On Friday, December 7, 2018 07:16 +0100 Patrik Fältström
<[email-masked]> wrote:

> 1. I think the ability (for example) copy and paste, respond
> to, click on, save in bookmarks etc is the most important
> global requirement
> 
> 2. The ability to type, to enter via a keyboard, read on a
> bus, etc is secondary and have localization issues so very
> much different than (1)
> 
> My point was that because of this, I think retypable is very
> very very much different than other, global, requirements, and
> the latter should not (I think) muddy the waters of the first
> requirement I list above.

Agreed.  However, I still have this strange idea (very clear in
the now-ancient RFC 1591) that domains are expected to serve a
community that if often not global, a concept that is consistent
with Larry's more recent comment about "target audience".
Within such an audience, the sort of criteria Larry is talking
about are almost certainly helpful... again, as long as they
don't interfere with the sort of global ones you identify above.
Larry's criteria also make a strong argument for a clear target
audience for a given zone or hierarchy.  That is a problem for
registries that want to be able to register labels from every
possible script even if they put some restrictions on those
labels, but we have known about that problem since the very
first ICANN IDN study effort if not earlier.

So I think there are global criteria (I like your list but
imagine that we could improve it somewhat with more thought)
that every label and FQDN should support and that there are
relatively more local criteria that have to be evaluated against
a target audience.   I don't know if "primary" or "secondary"
are quite the right category names, but I think we agree about
the principle.   It is also clear to me that, independent of
anything that is done globally, someone is more likely to get
themselves into trouble (or be tricked into it whether the
tricks are intentional or not) with labels in a script that they
find incomprehensible that with a more familiar one... and that
is something we better just get used to because, beyond some
point, technology won't help.

best,
   john

---

From: Nico Williams <[email-masked]>
Date: Fri, 7 Dec 2018 00:41:47 -0600

On Fri, Dec 07, 2018 at 07:16:03AM +0100, Patrik Fältström wrote:
> 1. I think the ability (for example) copy and paste, respond to, click
> on, save in bookmarks etc is the most important global requirement

+1.

> 2. The ability to type, to enter via a keyboard, read on a bus, etc is
> secondary and have localization issues so very much different than (1)

The ability to type in domainnames you see in ads is not that
interesting for the obvious reason that advertisers would not
choose to use domainnames that their targets cannot type in!

As to domainnames seen elsewhere than in ads... typing them in is still
not that interesting: there's always OCR (just point your smartphone at
it and click) and QR codes (same thing).

Besides, not concerning ourselves so much with the ability to type in a
domainname is a very good simplification to make.  In general most of us
cannot type in more than a very small number of scripts -- the ability
to type in any domainname is basically an oxymoron.  We couldn't even
require that users only ever see A-labels, which most users (perhaps!)
could type in, because that would utterly defeat the whole point of
IDNA.

> My point was that because of this, I think retypable is very very very
> much different than other, global, requirements, and the latter should
> not (I think) muddy the waters of the first requirement I list above.

+1.

Nico
--

---

From: Vint Cerf <[email-masked]>
Date: Fri, 7 Dec 2018 01:45:02 -0500

VGC: I am not so sure advertisers are that smart...

v

On Fri, Dec 7, 2018 at 1:42 AM Nico Williams <[email-masked]> wrote:

> IDNA-UPDATE mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idna-update
>

-- 
New postal address:
Google
1875 Explorer Street, 10th Floor
Reston, VA 20190

---

From: Nico Williams <[email-masked]>
Date: Fri, 7 Dec 2018 00:50:08 -0600

> VGC: I am not so sure advertisers are that smart...

I am quite certain that they are, or if not, will be.  They spend lots
of money, and they hate to spend it badly.  They even spend lots of
money on how to spend lots more money well.

Nico
--

---

From: John C Klensin <[email-masked]>
Date: Fri, 07 Dec 2018 02:26:55 -0500

--On Friday, December 7, 2018 00:50 -0600 Nico Williams
<[email-masked]> wrote:

>> > The ability to type in domainnames you see in ads is not
>> > that interesting for the obvious reason that advertisers
>> > would not choose to use domainnames that their targets
>> > cannot type in!
>> 
> I am quite certain that they are, or if not, will be.  They
> spend lots of money, and they hate to spend it badly.  They
> even spend lots of money on how to spend lots more money well.

Nico,

While I tend to agree with Vint -- not because of smartness or
the lack thereof but because many advertisers have, empirically,
found it much cheaper to register a lot of domain names than to
spend time and energy trying to protect trademarks, worrying
about competitors trying to capture or squat on names, etc.--
this is not a problem we need to solve.  There are many reasons
why we should encourage both registrants and registries to be
conservative, whether the advice we give about conservatism
involves only the global criteria that Patrik believes (and I
agree) should be primary or we expand that advice to include
some or all of the considerations Larry, Asmus, and I have been
advocating.  If the labels that are actually registered (whether
actively used or not) are a subset of what our conservative
guidance would suggest, that is great and no harm has been done.

On the other hand, we've seen names registered, and registered
as SLDs as well as further down in the tree, that clearly won't
meet even global criteria for conservatism and responsible
behavior. much less guidance focused on relevant target
communities.  Some of those registrations have clearly been the
result of a shortage of thinking or an excess of cleverness or
cuteness, not just the result of various forms of malice.  There
has been a lot of the latter too and we can at least hope that
more conservative registry policies would stop some of it.   So
I don't think an argument that we don't need to say something
(and say it very clearly) about the importance of conservative
behavior holds up ... and I hope you were not intending to make
that argument.

best,
    john

---

From: "Asmus Freytag (c)" <[email-masked]>
Date: Fri, 7 Dec 2018 00:41:48 -0800

> say something when I next open the document.

To "typable", you might add "processable" and "renderable", not to 
mention "human-readable". (Where multiple languages/scripts are 
supported, "typable" should obviously mean"typable by a native user of 
that language/script").

Allowing certain specialized or historical forms that are not part of 
the modern orthographic repertoire would allow characters that are 
unlikely to be supported by keyboards (or even fonts). (Some such 
characters are effectively not recognized by modern readers, or simply 
mistaken for more familiar characters).

Allowing "do not use" sequences renders labels not processable by 
processes that do expect data to not contain effectively deprecated 
content.  (They are also structurally unsound, see next).

Allowing structurally unsound sequences for any of the fifteen or so 
complex scripts risks data not being renderable, as neither layout 
systems or fonts are (universally) expecting to deal with them (or do it 
differently in unpredictable ways). T

Allowing arbitrary sequences can lead to strings that human readers are 
not prepared to recognize because they violate deep-seated assumption of 
what is possible. Linearly progressing, non-connecting scripts tend to 
not have that issue; ASCII certainly doesn't, but already with Latin 
combining marks you enter territory where fully random sequences can't 
be supported.

Then you get into the issue of substitutable code points/labels that 
should not be simultaneously allowed (aka "blocked" variants) -- the 
other type of variants ("allocatable") is more of a usability issue, 
which for some scripts can be critical but is not strictly required 
under the heading of "Conservatism".

Allowing two labels that even reasonably observant readers will 
substitute for one another, because different abstract text elements in 
Unicode may have identical (or very near identical) appearance when 
presented in typical user interfaces, adds no value, only security 
risks. (Yes this is a subset of the wider issue of labels that are 
merely similar, but that's not an excuse to take well-known an 
unambiguous cases off the table at the policy level).

Spelling out these considerations would go beyond what is currently 
scattered through the IDNA RFCs, but would be a first step to putting 
the Registries on notice what their responsibility actually entails.

Now that we have the Root Zone LGR giving practical examples (and the 
emerging reference LGRs doing the same for the second level), there's 
less excuse for registries not doing the right thing - good approximate 
solutions exist.

A./

---

From: "Asmus Freytag (c)" <[email-masked]>
Date: Fri, 7 Dec 2018 00:49:04 -0800

> 2. The ability to type, to enter via a keyboard, read on a bus, etc is secondary and have localization issues so very much different than (1)

A longer reply to this in my prev. note, but I emphatically disagree.

If you are dealing with a foreign language / script to you, then you 
will be reduced to selecting or perhaps copying; but for your own 
language and script (and for too many of the modern scripts) there are 
many possible sequences that so deeply violate the reader's expectation 
(or the systems' expectations) that they can effectively not be 
understood (read and remembered) by the users or displayed or processed 
by the system (or not reliably so across systems).

For many scripts, allowing too much will make labels every bit as 
unusable as allowing too little.

> My point was that because of this, I think retypable is very very very much different than other, global, requirements, and the latter should not (I think) muddy the waters of the first requirement…

Your item (1) addresses much more the level of implementation of the 
user presentation of IDNs, and less what should be allowed in IDN 
labels. Apples and oranges, it seems to me.

Item 1 is what the UASG should be concerned with, Item 2 is what IDNA 
should be concerned with (at the guidance level).

A./

---

From: "Asmus Freytag (c)" <[email-masked]>
Date: Fri, 7 Dec 2018 00:52:20 -0800

> money on how to spend lots more money well.

It may not be advertisers that use such 'broken' labels. All sorts of 
mischief can be created with stuff that your system won't let you type 
(even if you are a native user on a "native" system).

A./

---

From: Nico Williams <[email-masked]>
Date: Fri, 7 Dec 2018 10:42:07 -0600

> about competitors trying to capture or squat on names, etc.--

But what has that got to do with whether advertisers are smart enough to
use domainnames in advertisements that users can type in?

> this is not a problem we need to solve.  There are many reasons

Good.  Not having to solve it is a big win.

> conservative, whether the advice we give about conservatism

Indeed.  I've long been saying that registries should produce policies
appropriate to their domains.

> guidance would suggest, that is great and no harm has been done.

Yes.  Registrants might not agree, but they can always negotiate with
the registries or pick a registry that works for them.

> behavior holds up ... and I hope you were not intending to make

I only said that we shouldn't have to address the side-of-the-bus
problem.  You seem to have read into that more than I wrote, or perhaps
you're remembering things I've said before?

Registry policies that apply all the way down the tree would be an
innovation.  I'm not sure how I feel about that yet.  I do recognize the
problems with confusables, but as I've said before, that feels like a
losing battle.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 7 Dec 2018 10:45:47 -0600

On Fri, Dec 07, 2018 at 12:52:20AM -0800, Asmus Freytag (c) wrote:
> >I am quite certain that they are, or if not, will be.  They spend
> >lots of money, and they hate to spend it badly.  They even spend lots
> >of money on how to spend lots more money well.
> 

Anyone who wants their target audience to be able to type in a label
will pick labels wisely.

Anyone who does not care whether their target audience is able to type
in a label will be free to construct more interesting labels.

I see nothing wrong with that.

Of course, we weren't discussing malicious use of confusables.  That's
another story.

Nico
--

---

From: Shawn Steele <[email-masked]>
Date: Fri, 7 Dec 2018 18:19:50 +0000

> I might not agree with this, as for example very few characters in 
> arabic script are "retypable" for me. So this is at least a separate 
> issue. But what the registry chooses, I feel is up to them, as long as 
> they do come up with a good repertoire.

IMO that's not a requirement for non-language-speakers.  The intent of IDN is to enable language communities to use their own services, not necessarily that all resources be accessible to users of any other language.

Resources that are keen to provide content more broadly would, I think, best be served by using multiple names, with localized ones for native speaker usability and perhaps an ASCII one for the international audience.

I could even imagine something like a company with a Mongolian URL for Mongolian speakers, a Simplified Chinese URL for the rest of their Chinese customers, and an ASCII URL for their international partners.

-Shawn

---

From: Larry Masinter <[email-masked]>
Date: Fri, 7 Dec 2018 10:23:53 -0800

Look at RFC1736 , Functional Recommendations for Internet Resource Locators”, section 4.6: Locators are human transcribable

https://tools.ietf.org/html/rfc1736#section-4.6

   Users can copy Internet locators from one medium to another (such as

   voice to paper, or paper to keyboard) without loss or corruption of

   information.  This process is not required to be comfortable.

Changing Internet locators to allow for Internationalization need not necessarily eliminate this valuable property.

Larry
--
https://LarryMasinter.net

From: Asmus Freytag (c) <[email-masked]> 
Sent: Friday, December 7, 2018 12:49 AM
To: Patrik Fältström <[email-masked]>; John C Klensin <[email-masked]>
Cc: Larry Masinter <[email-masked]>; [email-masked]; [email-masked]; Paul Hoffman <[email-masked]>
Subject: Re: [I18nrp] Last Call: <draft-faltstrom-unicode11-05.txt> (IDNA2008 and Unicode 11.0.0) to Informational RFC

 

If you are dealing with a foreign language / script to you, then you will be reduced to selecting or perhaps copying; but for your own language and script (and for too many of the modern scripts) there are many possible sequences that so deeply violate the reader's expectation (or the systems' expectations) that they can effectively not be understood (read and remembered) by the users or displayed or processed by the system (or not reliably so across systems).

For many scripts, allowing too much will make labels every bit as unusable as allowing too little.

Your item (1) addresses much more the level of implementation of the user presentation of IDNs, and less what should be allowed in IDN labels. Apples and oranges, it seems to me.

Item 1 is what the UASG should be concerned with, Item 2 is what IDNA should be concerned with (at the guidance level).

A./

---

From: Martin J. Dürst <[email-masked]>
Date: Mon, 10 Dec 2018 08:41:17 +0000

> Anyone who wants their target audience to be able to type in a label

Yes. My way to say this is that not all advertisers are that smart, but 
those that aren't will sooner or later disappear (*). Similar for 
non-advertisers: If they come up with a good domain name, or (part of) 
an URI, they'll be remembered and found easily, if they don't, they'll 
just be ignored.

I don't think the IETF should be doing the advertisers' work, and even 
if we would, I feel very strongly that none of this would belong into 
Patrik's draft, which is about the update of the repertoire.

> I see nothing wrong with that.

Me neither.

> Of course, we weren't discussing malicious use of confusables.  That's

Yes indeed.

Regards,   Martin.

(*) Of course, because advertising is a rather vague and fuzzy business, 
the elimination doesn't work very quickly :-(.

---

From: Martin J. Dürst <[email-masked]>
Date: Mon, 10 Dec 2018 09:09:57 +0000

> Changing Internet locators to allow for Internationalization need not necessarily eliminate this valuable property.

And it doesn't. People get confused because they think differently about 
scripts they are not familiar with (where they often assume the worst, 
and are explicit about it) than about scripts they are familiar with 
(where they make the right assumptions implicitly, often without even 
being able to say what these assumptions are).

I have just searched through all of RFC 3986, but I have nowhere found 
anything telling people not familiar with ASCII that they should be 
careful not to create domain labels such as "L0CAT0R". That's because 
writers of RFC 3986 assumed that it would be quite obvious that letters 
and (more-or-less) lookalike digits shouldn't be mixed needlessly. And 
even more, nowhere in RFC 3986 does it say to be careful not to confuse 
'b', 'd', 'p', and 'q', even if these characters look quite the same up 
to only a rotation/reflection. (I remembered being confused about these 
for a while in primary school.)

The same is true for other scripts. Users of Japanese know to not mix up 
Kanji, Hiragana, and Katakana needlessly (*). Users of any script know 
where the potential confusables are, and how to deal with them in daily 
life. There is no need to tell them about the details.

What is desirable are restrictions such as those that Asmus has 
described, on the registry level, to help avoid inadvertent or malicious 
collisions, and to buffer for cases where repertoire-only limitations 
are not enough.

But these are separate from the draft under discussion now.

Regards,   Martin.