RTL labels and numbers?
Erik van der Poel
erikv at google.com
Wed Oct 14 18:00:12 CEST 2009
There may be different kinds of "inter-label tests", but the current
draft does contain the following:
An RTL label is a label that contains at least one character of type
R, AL or AN.
A "BIDI domain name" is a domain name that contains at least one RTL
label. (Note: This definition includes domain names containing only
dots and right-to-left characters. Providing a separate category of
"RTL domain names" would not make this specification simpler, so has
not been done.)
The following rule, consisting of six conditions, applies to labels
in BIDI domain names.
In other words, the implementation is looking at an entire domain
name, potentially consisting of multiple labels. Now, I'm not sure
whether there are rules about displaying the "before" or "after"
domain name, i.e. before resolving CNAME and DNAME or after resolving
CNAME and DNAME, but whichever one the client chooses to display, the
IDNAbis bidi tests can be performed just before displaying the domain
name, and if the tests fail, the client may choose not to display the
domain name in Unicode form. It might display the domain name in
A-label form, or it might not display it at all, or it might not even
use the IP address returned by DNS (if any).
In other words, it may be impossible to perform inter-label tests on
the "registry side", but it appears to be possible to perform them on
the client side.
On Wed, Oct 14, 2009 at 7:41 AM, Andrew Sullivan <ajs at shinkuro.com> wrote:
> On Wed, Oct 14, 2009 at 08:57:53AM -0400, Vint Cerf wrote:
>> There was endless discussion on this particular question (inter-label
>> rules) and the group consensus was that this added too much complexity.
>> The existence of DNAMES that you cannot test before registration was a
>> major argument against using inter-label methods to qualify a label's
> Worse, you can't test them _after_ registration, either. There is in
> fact no way to produce inter-label tests that work predictably,
> consistently, and reliably. Even if you didn't have the DNAME
> problem, you have issues resulting from wildcards too.
> And remember, this rule is not just for the meanings of "registry"
> that mean "top-level domain zone operators". In our context,
> "registry" means "zone operator", at any level in the tree. That's
> what the rule constrains.
> Andrew Sullivan
> ajs at shinkuro.com
> Shinkuro, Inc.
> Idna-update mailing list
> Idna-update at alvestrand.no
More information about the Idna-update