DRAFT::DRAFT::DRAFT::DRAFT::DRAFT::DRAFT::DRAFT::DRAFT::
Universal Acceptance Steering Group
Quick Guide to Linkification
20 March 2016
Background
Universal Acceptance (UA) is the state where all valid domain names and
email addresses are accepted, validated, stored, processed and displayed correctly and consistently by all Internet- enabled applications, devices and systems.
Due to the rapidly changing domain name landscape, many systems do not
recognize or appropriately process new domain names, primarily because they may be more than three characters in length or in a non-ASCII format. The same is true for email addresses that incorporate these new extensions.
The Universal Acceptance Steering Group (UASG), supported by Internet
Corporation for Assigned Names and Numbers (ICANN), is a community-led, Internet industry-wide initiative working on creating awareness and identifying and resolving problems associated with the universal acceptance of domain names. The purpose of these efforts
is to help ensure a consistent and positive experience for Internet users globally.
For more information on the UASG and recent development, visit
www.uasg.tech.
Linkification
Modern software sometimes allows a user to create a hyperlink simply by typing in a string that looks like a web address, email name or network path.
For example, typing “www.icann.org” into an email message may result in a clickable link to
http://www.icann.org
being automatically created if the app treats “www.” as a special prefix or “.org” as a special suffix.
Linkification should work consistently for all well-formed web addresses,
email names or network paths.
Linkification is the action where an application accepts a string and
dynamically determines whether it should create a hyperlink to an Internet Location (URL) or an email address (mailto:)
Linkification uses algorithms and rules created by software developers
to determine whether
a string should be deemed a link – or not. Related to this is how people can identify a string as a domain name. While browsers, email clients
and word processors are obvious places, there are many more applications that make these decisions.
Good Practice Recommendations
-
Attempt to linkify based on protocol prefixes (e.g. “www”, “http://”, ftp://”, “mailto:”) but only complete
the action if the rest of the string is well formed (RFCXXXX?)
-
Do not require a DNS check.
Do we recommend validated the TLD?
-
Attempt to linkify any well formed string without a protocol prefix.
-
Label.label
-
Label.label/label
-
-
Do not assume a prefix if it is not explicitly stated (i.e. don’t automatically convert “icann.org”
to http://www.icann.org)
§ However,
is the average user expected to know what prefix to use?
IS
THIS RIGHT
-
Map the Ideographic Full Stop “。” (U+3002) to Full Stop “.” (U+002E) (e.g.
http://田中。com à
http://田中.com) if string is well formed (RFCXXXX?)
-
BIDI – What are the unique challenges with BIDI?