Re: [I18nrp] [art] Use Unicode if Using Unicode?

[Asmus Freytag <[e-mail]>]

On 10/11/2018 9:52 PM, Larry Masinter wrote:
>
> No matter what path you take for new RFCs, implementations will lag, 
> and some choices for strings used for domain names, (LHS of) email 
> addresses and short URLs will have problems
>
>  1. When put through different implementations of normalization
>     (IDNA2008 vs 2003 vs. some exceptions)
>  2. When used in user interfaces for comparison or validation or
>     comparison (in the address bar or rollover links)
>  3. When scanning text for picking out URLS
>  4. when used in print or other media (in an ad or written on a napkin)
>
> These are in order of decreasing specificity, increasing “liberal 
> displacement”.
>

That sounds vaguely political :)

Not sure what you mean with that expression, actually.

> I think those who are choosing names to use (as domain name, email 
> address, short url) will want to use (4), no matter what rules the 
> registry applies. Anyone registering a domain name, a user name at a 
> mail host, or a (short) URL will want to choose names that they can 
> print on a business card or an ad or a roster and believe that their 
> target audience can enter and get the string intended.
>
> And 1 < 2 < 3 < 4 as equivalence goes.
>
> I don’t think it’s practical to redo all the protocols that use these 
> strings to pass along a tuple of string and context.
>
You can avoid certain problems by limiting what a registry (or mail 
server) allow to be registered. This limitation does not belong in the 
protocol, but is a separate layer of the architecture (label generation 
rules).

With label generation rules you can restrict strings to those that can 
be rendered unambiguously, and should display technology change over 
time, you can relax those constraints without affecting other 
implementations of the protocol.

Many of these kinds of constraints are (largely) generic to certain 
scripts. It would therefore be possible to address them by informational 
RFCs laying out "best practices" that can serve as a starting point.

To some extent, similar mechanisms can be used to address discrepancies 
between IDNA2003 and IDNA2008 - in some cases affected code points could 
either be restricted or equivalenced.

Am I on the right track, or were you trying to address something different.

A./

> Larry
>
> --
>
> https://LarryMasinter.net
>
>
> _______________________________________________
> i18nRP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i18nrp