Andre.. well said.. this is exactly the way we present on our business cards .. see on the right-bottom of the card.. its in Hindi.. Thanks. On 30 December 2017 22:05:39 GMT+05:30, Andre Schappo <A.Schappo@lboro.ac.uk> 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

Korea NIC ➜ 한국인터넷정보센터.한국<https://xn--3e0bx5euxnjje69i70af08bea817g.xn--3e0b707e> Korea University ➜ 고려대학교.한국<http://xn--299a9hr4mn4fgs6b.xn--3e0b707e>

André Schappo

On 30 Dec 2017, at 11:18, Andre Schappo <A.Schappo@lboro.ac.uk<mailto:A.Schappo@lboro.ac.uk>> wrote:

Really good to see UA on wikipedia. It feels like UA has made the mainstream.

2 suggestions:-

1️⃣ In the wikipedia article there are indirect references to https://uasg.tech<https://uasg.tech/> eg https://uasg.tech/wp-content/uploads/2017/09/UASG-Report-UASG016.pdf I think there should be a direct reference to uasg home page in the wikipedia article ie https://uasg.tech<https://uasg.tech/>

2️⃣ drop the www — eg in the wikipedia article there is the link https://www.icann.org/resources/pages/universal-acceptance-2012-02-25-en I suggest using https://icann.org/resources/pages/universal-acceptance-2012-02-25-en instead. My experience is that the majority of people think the initial www is necessary but in the majority of web addresses the www is not necessary. My reasoning is that having the www prefix is contrary to IDNs because one then has mixed scripts in an IDN. Take Korea NIC. Their IDN is https://한국인터넷정보센터.한국<https://xn--3e0bx5euxnjje69i70af08bea817g.xn--3e0b707e/> They do support https://www.한국인터넷정보센터.한국<https://www.xn--3e0bx5euxnjje69i70af08bea817g.xn--3e0b707e/> but they do not make the www necessary and they do not redirect to the www form.

Now, what I have written is also contradictory because I have used https:// so that my Apple Mail App will linkify. When I put links in my webpages I would only display to users 한국인터넷정보센터.한국 My hope for the future is that linkification will become more sophisticated and be able linkify 한국인터넷정보센터.한국 without the need for www or https:// thus resulting, in this case, a fully korean hangeul domain name.

So, I suggest the working practice — when possible (which I think is most of the time), drop both the www and https:// when presenting the domain name to end users.

André Schappo

On 30 Dec 2017, at 08:15, Don Hollander <don.hollander@icann.org<mailto:don.hollander@icann.org>> wrote:

A nice way to end a fairly productive year.

🌏 🌍 🌎 André Schappo https://schappo.blogspot.co.uk https://twitter.com/andreschappo https://weibo.com/andreschappo https://groups.google.com/forum/#!forum/computer-science-curriculum-internat...

-- Sent from my Android device with XGenPlus.

Andrew, 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. --Rich -----Original Message----- From: UA-discuss [mailto:ua-discuss-bounces@icann.org] On Behalf Of Andrew Sullivan Sent: Sunday, December 31, 2017 12:12 PM To: ua-discuss@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, A -- Andrew Sullivan ajs@anvilwalrusden.com

Most of the query capacity of authority servers is dedicated to mitigate denial-of-service attacks, and most of them operate at less than 1% of capacity. That said, I don't know if this also applies to recursive servers of ISPs, so such an advice should come with a warning on how to use the DNS system in this case. But neither the available capacity or the usage warning would solve the usual issue programmers have with DNS is that DNS is considered slow. That was said to be the main reason for browsers not supporting DANE (DNSSEC-based certificates), so this might be hard to overcome. Rubens

On 8 Jul 2020, at 19:44, Edmon <edmon@registry.asia> wrote:

Perhaps we can say that before linkification automagically happens, a DNS lookup should be done to confirm that the domain exists? Or would that unnecessarily burden the DNS? Modern instant messengers do try to grab the web information too in fact when something gets linkified.

Edmon

...

-----Original Message----- From: UA-discuss <ua-discuss-bounces@icann.org> On Behalf Of Andrew Sullivan Sent: Monday, January 1, 2018 2:12 AM To: ua-discuss@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,

A

-- Andrew Sullivan ajs@anvilwalrusden.com

_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.

I sincerely hope that linkification of bare domain names does _not_ take over, because it gets in the way. The Internet is bigger than the web, and we aim for something too poor if we nail ourselves forever and only to https. A -- Please excuse my clumbsy thums ---------- On December 30, 2017 6:19:11 AM Andre Schappo <A.Schappo@lboro.ac.uk> wrote:

Really good to see UA on wikipedia. It feels like UA has made the mainstream.

2 suggestions:-

1️⃣ In the wikipedia article there are indirect references to https://uasg.tech eg https://uasg.tech/wp-content/uploads/2017/09/UASG-Report-UASG016.pdf I think there should be a direct reference to uasg home page in the wikipedia article ie https://uasg.tech

2️⃣ drop the www — eg in the wikipedia article there is the link https://www.icann.org/resources/pages/universal-acceptance-2012-02-25-en I suggest using https://icann.org/resources/pages/universal-acceptance-2012-02-25-en instead. My experience is that the majority of people think the initial www is necessary but in the majority of web addresses the www is not necessary. My reasoning is that having the www prefix is contrary to IDNs because one then has mixed scripts in an IDN. Take Korea NIC. Their IDN is https://한국인터넷정보센터.한국<https://xn--3e0bx5euxnjje69i70af08bea817g.xn--3e0b707e> They do support https://www.한국인터넷정보센터.한국<https://www.xn--3e0bx5euxnjje69i70af08bea817g.xn--3e0b707e> but they do not make the www necessary and they do not redirect to the www form.

Now, what I have written is also contradictory because I have used https:// so that my Apple Mail App will linkify. When I put links in my webpages I would only display to users 한국인터넷정보센터.한국 My hope for the future is that linkification will become more sophisticated and be able linkify 한국인터넷정보센터.한국 without the need for www or https:// thus resulting, in this case, a fully korean hangeul domain name.

So, I suggest the working practice — when possible (which I think is most of the time), drop both the www and https:// when presenting the domain name to end users.

André Schappo

On 30 Dec 2017, at 08:15, Don Hollander <don.hollander@icann.org<mailto:don.hollander@icann.org>> wrote:

A nice way to end a fairly productive year.

Have given more thought on user controlled linkification and there are other user options that may be useful Ⓐ Let the user select which TLDs will result in linkification of domain names. A user could, for example, choose not to allow linkification of domains names with the TLD .porn. Or a user could allow linkification of all domain names which have an India domain name, of which there are an impressive number. Ⓑ Let a user specify a fictious TLD which does not result in linkification of a domain name. I would find this useful because I often write fictious domain names which I do not want linkified. So I could setup a fictious TLD, say .example which would not get linkified. Then I could put such domain names in my teaching material without auto linkification rather than having, for example, https://label1.label2.example which auto linkifies in Apple Mail and many other Apps. Ⓒ Let a user disallow linkification of mixed script domain names, as in each label having different scripts eg hindi.arabic.chinese André Schappo On 31 Dec 2017, at 18:47, Andre Schappo <A.Schappo@lboro.ac.uk<mailto:A.Schappo@lboro.ac.uk>> wrote: Good point. Perhaps rather than more sophisticated linkification we need more sophisticated system wide user link settings/preferences ie settings under the control of the user. My first stab at such user link settings are:- ---------------------- Check to enable your preferred link settings 1️⃣ automatically linkify everything possible ⬜️ 2️⃣ automatically linkify (check all those from the following that apply) - 2️⃣ A. text having the form "http://a.domain.name<http://a.domain.name/> ⬜️ 2️⃣ B. text having the form https://a.domain.name<https://a.domain.name/> ⬜️ 2️⃣ C. text having the form www.a.domain.name<http://www.a.domain.name/> ⬜️ 2️⃣ D. text having the form a.domain.name.in.non.ascii.text ⬜️ 2️⃣ E. text having the form www.a.domain.name.in.non.ascii.text<http://www.a.domain.name.in.non.ascii.text/> ⬜️ ...etc... ---------------------- I would have 2️⃣ B checked and 2️⃣ A unchecked because when I have time I usually check if a site supports https when I have been given the http form. I will give it more thought tomorrow but now it is time for New Year celebrations. So, again, Happy New Year André Schappo On 30 Dec 2017, at 18:53, Andrew Sullivan <ajs@crankycanuck.ca<mailto:ajs@crankycanuck.ca>> wrote: I sincerely hope that linkification of bare domain names does _not_ take over, because it gets in the way. The Internet is bigger than the web, and we aim for something too poor if we nail ourselves forever and only to https. A -- Please excuse my clumbsy thums ________________________________ On December 30, 2017 6:19:11 AM Andre Schappo <A.Schappo@lboro.ac.uk<mailto:A.Schappo@lboro.ac.uk>> wrote: Really good to see UA on wikipedia. It feels like UA has made the mainstream. 2 suggestions:- 1️⃣ In the wikipedia article there are indirect references to https://uasg.tech<https://uasg.tech/> eg https://uasg.tech/wp-content/uploads/2017/09/UASG-Report-UASG016.pdf I think there should be a direct reference to uasg home page in the wikipedia article ie https://uasg.tech<https://uasg.tech/> 2️⃣ drop the www — eg in the wikipedia article there is the link https://www.icann.org/resources/pages/universal-acceptance-2012-02-25-en I suggest using https://icann.org/resources/pages/universal-acceptance-2012-02-25-en instead. My experience is that the majority of people think the initial www is necessary but in the majority of web addresses the www is not necessary. My reasoning is that having the www prefix is contrary to IDNs because one then has mixed scripts in an IDN. Take Korea NIC. Their IDN is https://한국인터넷정보센터한국<https://xn--3e0bx5euxnjje69i70af08bea817g.xn--3e0b707e/> They do support https://www.한국인터넷정보센터.한국<https://www.xn--3e0bx5euxnjje69i70af08bea817g.xn--3e0b707e/> but they do not make the www necessary and they do not redirect to the www form. Now, what I have written is also contradictory because I have used https:// so that my Apple Mail App will linkify. When I put links in my webpages I would only display to users 한국인터넷정보센터.한국 My hope for the future is that linkification will become more sophisticated and be able linkify 한국인터넷정보센터.한국 without the need for www or https:// thus resulting, in this case, a fully korean hangeul domain name. So, I suggest the working practice — when possible (which I think is most of the time), drop both the www and https:// when presenting the domain name to end users. André Schappo On 30 Dec 2017, at 08:15, Don Hollander <don.hollander@icann.org<mailto:don.hollander@icann.org>> wrote: A nice way to end a fairly productive year.

I'm amazed at the level of detail that you are proposing here. I'm sure it would allow and advanced user to get precisely the desired behavior - until the next update that erases all the preferences... In other words, I can see this level of control as useful for a "production" environment, like a word processing app, but most casual users would neither know that the behavior might be controlled by preferences nor have a systematic idea of how to translate any "this isn't working the way I want to" into settings. Skeptically, A./ On 1/1/2018 10:27 AM, Andre Schappo wrote:

I believe I can now address Andrew's concerns about schemes other than http and https

In the user linkification preferences, the user should be able to specify the presentation form.

So, for http://한국인터넷정보센터.한국 <http://xn--3e0bx5euxnjje69i70af08bea817g.xn--3e0b707e> I would specify that I wanted it presented as 한국인터넷정보센터.한국 <http://xn--3e0bx5euxnjje69i70af08bea817g.xn--3e0b707e>

But for a different scheme, say smb://label1.label.example <smb://label1.label.example> I could choose in my linkification preferences I do not want it to be linkified. I think that for other schemes, if I wanted it to be linkified, I would probably retain the scheme prefix ie smb://label1.label2.example in order to make it clear this is not a web address.

André Schappo

...

On 1 Jan 2018, at 15:36, Andre Schappo <A.Schappo@lboro.ac.uk <mailto:A.Schappo@lboro.ac.uk>> wrote:

Have given more thought on user controlled linkification and there are other user options that may be useful

Ⓐ Let the user select which TLDs will result in linkification of domain names. A user could, for example, choose not to allow linkification of domains names with the TLD .porn. Or a user could allow linkification of all domain names which have an India domain name, of which there are an impressive number. Ⓑ Let a user specify a fictious TLD which does not result in linkification of a domain name. I would find this useful because I often write fictious domain names which I do not want linkified. So I could setup a fictious TLD, say .example which would not get linkified. Then I could put such domain names in my teaching material without auto linkification rather than having, for example, https://label1.label2.example <https://label1.label2.example/> which auto linkifies in Apple Mail and many other Apps. Ⓒ Let a user disallow linkification of mixed script domain names, as in each label having different scripts eg hindi.arabic.chinese

André Schappo

...

On 31 Dec 2017, at 18:47, Andre Schappo <A.Schappo@lboro.ac.uk <mailto:A.Schappo@lboro.ac.uk>> wrote:

Good point.

Perhaps rather than more sophisticated linkification we need more sophisticated system wide user link settings/preferences ie settings under the control of the user.

My first stab at such user link settings are:-

---------------------- Check to enable your preferred link settings

1️⃣ automatically linkify everything possible ⬜️

2️⃣ automatically linkify (check all those from the following that apply)  - 2️⃣ A. text having the form "http://a.domain.name <http://a.domain.name/> ⬜️ 2️⃣ B. text having the form https://a.domain.name <https://a.domain.name/>  ⬜️ 2️⃣ C. text having the form www.a.domain.name <http://www.a.domain.name/>  ⬜️ 2️⃣ D. text having the form a.domain.name.in.non.ascii.text  ⬜️ 2️⃣ E. text having the form www.a.domain.name.in.non.ascii.text <http://www.a.domain.name.in.non.ascii.text/> ⬜️

...etc... ----------------------

I would have 2️⃣ B checked and 2️⃣ A unchecked because when I have time I usually check if a site supports https when I have been given the http form.

I will give it more thought tomorrow but now it is time for New Year celebrations.

So, again, Happy New Year

André Schappo

...

On 30 Dec 2017, at 18:53, Andrew Sullivan <ajs@crankycanuck.ca <mailto:ajs@crankycanuck.ca>> wrote:

I sincerely hope that linkification of bare domain names does _not_ take over, because it gets in the way. The Internet is bigger than the web, and we aim for something too poor if we nail ourselves forever and only to https.

A

-- Please excuse my clumbsy thums

------------------------------------------------------------------------

On December 30, 2017 6:19:11 AM Andre Schappo <A.Schappo@lboro.ac.uk <mailto:A.Schappo@lboro.ac.uk>> wrote:

...

Really good to see UA on wikipedia. It feels like UA has made the mainstream.

2 suggestions:-

1️⃣ In the wikipedia article there are indirect references to https://uasg.tech <https://uasg.tech/> eg https://uasg.tech/wp-content/uploads/2017/09/UASG-Report-UASG016.pdf I think there should be a direct reference to uasg home page in the wikipedia article ie https://uasg.tech <https://uasg.tech/>

2️⃣ drop the www —  eg in the wikipedia article there is the link https://www.icann.org/resources/pages/universal-acceptance-2012-02-25-en I suggest using https://icann.org/resources/pages/universal-acceptance-2012-02-25-en instead. My experience is that the majority of people think the initial www is necessary but in the majority of web addresses the www is not necessary. My reasoning is that having the www prefix is contrary to IDNs because one then has mixed scripts in an IDN. Take Korea NIC. Their IDN is https://한국인터넷정보센터한국 <https://xn--3e0bx5euxnjje69i70af08bea817g.xn--3e0b707e/> They do support https://www.한국인터넷정보센터.한국 <https://www.xn--3e0bx5euxnjje69i70af08bea817g.xn--3e0b707e/> but they do not make the www necessary and they do not redirect to the www form.

Now, what I have written is also contradictory because I have used https:// so that my Apple Mail App will linkify. When I put links in my webpages I would only display to users 한국인터넷정보센터.한국 My hope for the future is that linkification will become more sophisticated and be able linkify 한국인터넷정보센터.한국 without the need for www or https:// thus resulting, in this case, a fully korean hangeul domain name.

So, I suggest the working practice — when possible (which I think is most of the time), drop both the www and https:// when presenting the domain name to end users.

André Schappo

...

On 30 Dec 2017, at 08:15, Don Hollander <don.hollander@icann.org <mailto:don.hollander@icann.org>> wrote:

A nice way to end a fairly productive year.

🌏 🌍 🌎 André Schappo https://schappo.blogspot.co.uk https://twitter.com/andreschappo https://weibo.com/andreschappo https://groups.google.com/forum/#!forum/computer-science-curriculum-internat... <https://groups.google.com/forum/#%21forum/computer-science-curriculum-intern...>

With regards to Linkification… At its meeting in Dublin more than a year ago, the UASG developed some thoughts on Linkification. These were revised, slightly, after its meeting in Seattle in the first quarter of 2017. During the last quarter of 2017 we contracted Catalyst to do an evaluation of linkification, based on our expectations, of the top social media applications. The work has been done and a first draft will be out to the UASG community before the end of this quarter. This will provide a look at what actually happens in the real world. A sneak preview: - None created links with the open dot. - Some created no links at all to email addresses. Clearly a policy. - Some created links, but not for all the domain names in our test suite. From a UASG perspective, this is showing that these applications do not treat all domain names the same. I don’t mean to be a tease, but the report does need a bit of structural as well as style work before sharing it widely. Don

On 2/01/2018, at 10:20 PM, Asmus Freytag <asmusf@ix.netcom.com> wrote:

On 1/2/2018 1:07 AM, Asmus Freytag wrote:

...

I'm amazed at the level of detail that you are proposing here. I'm sure it would allow and advanced user to get precisely the desired behavior - until the next update that erases all the preferences...

In other words, I can see this level of control as useful for a "production" environment, like a word processing app, but most casual users would neither know that the behavior might be controlled by preferences nor have a systematic idea of how to translate any "this isn't working the way I want to" into settings.

Skeptically, A./

And I fully agree with Andrew Sullivan's remarks. Nothing irks me as much as having software that assumes B) is alsways an emoticon, so formal legalese texts that have clauses numbered wit (B) all turn into nonsense. Runaway linkification promises to be similarly painful whenever you are dealing with texts where x.y.y isn't an internet address....

...

On 1/1/2018 10:27 AM, Andre Schappo wrote:

...

I believe I can now address Andrew's concerns about schemes other than http and https

In the user linkification preferences, the user should be able to specify the presentation form.

So, for http://한국인터넷정보센터.한국[xn--3e0bx5euxnjje69i70af08bea817g.xn--3e0b707e] <https://urldefense.proofpoint.com/v2/url?u=http-3A__xn-2D-2D3e0bx5euxnjje69i...> I would specify that I wanted it presented as 한국인터넷정보센터.한국[xn--3e0bx5euxnjje69i70af08bea817g.xn--3e0b707e] <https://urldefense.proofpoint.com/v2/url?u=http-3A__xn-2D-2D3e0bx5euxnjje69i...>

But for a different scheme, say smb://label1.label.example <smb://label1.label.example> I could choose in my linkification preferences I do not want it to be linkified. I think that for other schemes, if I wanted it to be linkified, I would probably retain the scheme prefix ie smb://label1.label2.example <smb://label1.label2.example> in order to make it clear this is not a web address.

André Schappo

...

On 1 Jan 2018, at 15:36, Andre Schappo <A.Schappo@lboro.ac.uk <mailto:A.Schappo@lboro.ac.uk>> wrote:

Have given more thought on user controlled linkification and there are other user options that may be useful

Ⓐ Let the user select which TLDs will result in linkification of domain names. A user could, for example, choose not to allow linkification of domains names with the TLD .porn. Or a user could allow linkification of all domain names which have an India domain name, of which there are an impressive number. Ⓑ Let a user specify a fictious TLD which does not result in linkification of a domain name. I would find this useful because I often write fictious domain names which I do not want linkified. So I could setup a fictious TLD, say .example which would not get linkified. Then I could put such domain names in my teaching material without auto linkification rather than having, for example, https://label1.label2.example[label1.label2.example] <https://urldefense.proofpoint.com/v2/url?u=https-3A__label1.label2.example_&...> which auto linkifies in Apple Mail and many other Apps. Ⓒ Let a user disallow linkification of mixed script domain names, as in each label having different scripts eg hindi.arabic.chinese

André Schappo

...

On 31 Dec 2017, at 18:47, Andre Schappo <A.Schappo@lboro.ac.uk <mailto:A.Schappo@lboro.ac.uk>> wrote:

Good point.

Perhaps rather than more sophisticated linkification we need more sophisticated system wide user link settings/preferences ie settings under the control of the user.

My first stab at such user link settings are:-

---------------------- Check to enable your preferred link settings

1️⃣ automatically linkify everything possible ⬜️

2️⃣ automatically linkify (check all those from the following that apply) - 2️⃣ A. text having the form "http://a.domain.name[a.domain.name] <https://urldefense.proofpoint.com/v2/url?u=http-3A__a.domain.name_&d=DwMDaQ&...> ⬜️ 2️⃣ B. text having the form https://a.domain.name[a.domain.name] <https://urldefense.proofpoint.com/v2/url?u=https-3A__a.domain.name_&d=DwMDaQ...> ⬜️ 2️⃣ C. text having the form www.a.domain.name[a.domain.name] <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.a.domain.name_&d=DwM...> ⬜️ 2️⃣ D. text having the form a.domain.name.in.non.ascii.text ⬜️ 2️⃣ E. text having the form www.a.domain.name.in.non.ascii.text[a.domain.name.in.non.ascii.text] <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.a.domain.name.in.non...> ⬜️

...etc... ----------------------

I would have 2️⃣ B checked and 2️⃣ A unchecked because when I have time I usually check if a site supports https when I have been given the http form.

I will give it more thought tomorrow but now it is time for New Year celebrations.

So, again, Happy New Year

André Schappo

...

On 30 Dec 2017, at 18:53, Andrew Sullivan <ajs@crankycanuck.ca <mailto:ajs@crankycanuck.ca>> wrote:

I sincerely hope that linkification of bare domain names does _not_ take over, because it gets in the way. The Internet is bigger than the web, and we aim for something too poor if we nail ourselves forever and only to https.

A

-- Please excuse my clumbsy thums On December 30, 2017 6:19:11 AM Andre Schappo <A.Schappo@lboro.ac.uk <mailto:A.Schappo@lboro.ac.uk>> wrote:

> Really good to see UA on wikipedia. It feels like UA has made the mainstream. > > 2 suggestions:- > > 1️⃣ In the wikipedia article there are indirect references to https://uasg.tech[uasg.tech] <https://urldefense.proofpoint.com/v2/url?u=https-3A__uasg.tech_&d=DwMDaQ&c=F...> eg https://uasg.tech/wp-content/uploads/2017/09/UASG-Report-UASG016.pdf[uasg.tech] <https://urldefense.proofpoint.com/v2/url?u=https-3A__uasg.tech_wp-2Dcontent_...> I think there should be a direct reference to uasg home page in the wikipedia article ie https://uasg.tech[uasg.tech] <https://urldefense.proofpoint.com/v2/url?u=https-3A__uasg.tech_&d=DwMDaQ&c=F...> > > 2️⃣ drop the www — eg in the wikipedia article there is the link https://www.icann.org/resources/pages/universal-acceptance-2012-02-25-en[icann.org] <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resources...> I suggest using https://icann.org/resources/pages/universal-acceptance-2012-02-25-en[icann.org] <https://urldefense.proofpoint.com/v2/url?u=https-3A__icann.org_resources_pag...> instead. My experience is that the majority of people think the initial www is necessary but in the majority of web addresses the www is not necessary. My reasoning is that having the www prefix is contrary to IDNs because one then has mixed scripts in an IDN. Take Korea NIC. Their IDN is https://한국인터넷정보센터한국[xn--3e0bx5euxnjje69i70af08bea817g.xn--3e0b707e] <https://urldefense.proofpoint.com/v2/url?u=https-3A__xn-2D-2D3e0bx5euxnjje69...> They do supporthttps://www.한국인터넷정보센터.한국[xn--3e0bx5euxnjje69i70af08bea817g.xn--3e0b707e] <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.xn-2D-2D3e0bx5euxnj...> but they do not make the www necessary and they do not redirect to the www form. > > Now, what I have written is also contradictory because I have used https://[] <https://urldefense.proofpoint.com/v2/url?u=https-3A__&d=DwMDaQ&c=FmY1u3PJp6w...> so that my Apple Mail App will linkify. When I put links in my webpages I would only display to users 한국인터넷정보센터.한국 My hope for the future is that linkification will become more sophisticated and be able linkify 한국인터넷정보센터.한국 without the need for www or https://[] <https://urldefense.proofpoint.com/v2/url?u=https-3A__&d=DwMDaQ&c=FmY1u3PJp6w...> thus resulting, in this case, a fully korean hangeul domain name. > > So, I suggest the working practice — when possible (which I think is most of the time), drop both the www and https://[] <https://urldefense.proofpoint.com/v2/url?u=https-3A__&d=DwMDaQ&c=FmY1u3PJp6w...> when presenting the domain name to end users. > > André Schappo > >> On 30 Dec 2017, at 08:15, Don Hollander <don.hollander@icann.org <mailto:don.hollander@icann.org>> wrote: >> >> A nice way to end a fairly productive year. >> >

🌏 🌍 🌎 André Schappo https://schappo.blogspot.co.uk[schappo.blogspot.co.uk] <https://urldefense.proofpoint.com/v2/url?u=https-3A__schappo.blogspot.co.uk&...> https://twitter.com/andreschappo[twitter.com] <https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_andreschapp...> https://weibo.com/andreschappo[weibo.com] <https://urldefense.proofpoint.com/v2/url?u=https-3A__weibo.com_andreschappo&...> https://groups.google.com/forum/#!forum/computer-science-curriculum-internationalization[groups.google.com] <https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_forum...>

Don Hollander Universal Acceptance Steering Group www.uasg.tech don.hollander@icann.org Skype: don_hollander