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