On Tue, May 6, 2025, at 10:46, Michael De Roover wrote:
> Take instant messaging applications, or even email clients for example. 
> Or 
> even word processors / office suites. When we paste a link in there, 
> how does it 
> determine that to be a link? The text that is inserted is still just 
> plain 
> text. Maybe it starts with http or https, that's a good heuristic 
> because 
> those are protocols. Or maybe it ends in a TLD, like .amsterdam or 
> another 
> public delegation. But what if it is .internal, should that be 
> recognized as 
> akin to .amsterdam, or as a TLD that isn't recognized like .lan?
>
> As an application developer, where would you find that list of domains that 
> are 
> globally recognized, and combine it with those that are domains but are for 
> whatever reason "special"? In that way, our web browsers did consider .onion 
> to be a domain name, even though it is not meant to exist in the traditional 
> sense. So the code would've made the decision that such domains are not 
> search 
> queries.
>
> So that is the decision that I would want applications dealing with domain 
> names to be able to make for .internal. Is that a domain name and how do we 
> handle this special case?

In my experience this is done using regular-expression matching, and that's 
all. They will highlight something as a hyperlink if it appears to be a 
validly-formed HTTPS URI, regardless of whether the 'domain name' present in 
the URI is valid at all. The ones which tried to be 'smarter' started failing 
when gTLDs appeared on the scene, many of which were far longer than the 4 
character maximum that the regexes had incorporated for years because "there 
are no TLDs longer than 4 characters".

If I type https://foo.bar.lan into LibreOffice Writer, it gets recognized as an 
HTTPS URI and highlighted accordingly.

_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to