[UA-discuss] Universal Acceptance now on Wikipedia...https://en.wikipedia.org/wiki/Universal_Acceptance

Richard Merdinger rmerdinger at godaddy.com
Sun Dec 31 19:52:14 UTC 2017

I agree with your points, especially about potentially perpetuating the issue.  It reminds me of auto-correct in spell checkers.  So often we have odd-looking terms transformed into the "correct" work (well, "correct" in that it is commonly misspelled and 99% of the time is intended to be the suggested term).  

Having a setting in an app to assume a dominant protocol (https, for example) with the ability to turn it off seems to be a good direction for recommendation.

Using the iOS example of spell checking as an analog, suggesting linkification to the user with a default of https or the last protocol used in the current session, but with alternatives presented could be useful.

Having software save keystrokes for the masses while retaining the ability to disable/customize the helper-function seems appropriate to me.  


-----Original Message-----
From: UA-discuss [mailto:ua-discuss-bounces at icann.org] On Behalf Of Andrew Sullivan
Sent: Sunday, December 31, 2017 12:12 PM
To: ua-discuss at icann.org
Subject: Re: [UA-discuss] Universal Acceptance now on Wikipedia...https://en.wikipedia.org/wiki/Universal_Acceptance

On Sat, Dec 30, 2017 at 04:35:39PM +0000, Andre Schappo wrote:
> I have just worked how to properly present IDNs in Apple Mail. By properly present I mean without any ASCII, so no https:// or www

I already made a remark about this, but maybe I haven't stated it in a
way that is easily understood.

The current complaint -- the thing the USAG is attempting to fix -- is
that there are these old conventions on the Internet that got turned
into "rules" that programs enforce.  The consequence of this is, of
course, that innovation can't happen because the programs are
automatically doing "the right thing" that turn out to be wrong.
They're validating domain names using the LDH rule.  Or they're using
some static list of TLDs that do not reflect the correct current
contents of the root zone.  Or they're mistrusting IDNs that they
don't understand.  Or whatever.

When linkification assumes that every string of the form
substring1.substring2.substring3 (and so on) is actually the host-part
of a URI properly written as
https://substring1.substring2.substring3/, then it creates _the very
same_ kind of problem we are trying to combat.  That is, the program
is doing some automatic validation or modification of text in such a
way that perfectly legitimate uses are broken.  Not everything that is
an apparent hostname actually _is_ a hostname, and not every actual
hostname is the host-part of an http(s) URI/URL.  For instance, I
often find myself including host names for ssh access to people, and
when that gets linkified as http(s) it actually gets in the way of
using the infomation conveniently.

Presumably there will be future DNS uses that are also not https,
since there are present ones.

I think it is bad to recommend linkification at all for things that do
not have a scheme associated (i.e. that are not presented as URIs),
and I think the USAG should make clear ways in which such a practice
is harmful.

Best regards,


Andrew Sullivan
ajs at anvilwalrusden.com

More information about the UA-discuss mailing list