Remider: BIDI inter-label tests in -02

Erik van der Poel erikv at google.com
Sun Sep 7 20:47:44 CEST 2008


Harald,

I think the IDNAbis bidi draft is basically on the right track, since
a lot of existing software already uses the Unicode bidi algorithm to
display bidi text (and we don't expect that to change, nor can we work
around that, right?). I don't think that removing the bullet below is
the right solution. That's like taking the stance "We know there are
dragons here, but we're not going to warn you about them."

Instead, I think we should flesh out that bullet by giving specific
rules and recommendations for both registration-side and
resolution-side implementations. I don't think we're ready to write
the actual text yet, but I'd like to start discussing the items that
are related to this.

Resolution-side: Often, we have the entire FQDN, so we ought to just
specify that the implementation MUST check the bidi rules across all
of the labels. However, there are situations where the client starts
with a prefix of the FQDN, and does not know all of the labels at the
outset. For example, a browser inside Google headquarters may start a
lookup with "www" and then add ".internal.google.com" to it. We should
specify whether or not the client MUST apply the IDNAbis bidi rules to
the resulting "www.internal.google.com". We also need to specify
whether or not the rules MUST be applied to sequences of labels that
arise out of DNAME processing.

Registration-side: The registrant always knows where a label is being
registered, at least the immediate parent (right?). However, when one
or more DNAMEs are involved in all possible resolution paths to that
label, it does indeed seem too onerous to require that the registrant
MUST check all possible paths. The registrant certainly cannot check
against future DNAMEs that have not even been defined yet. So, we
should have a MUST for the immediate parent and a MAY for all possible
current resolution paths.

Generation-side: It is conceivable that some systems "generate" FQDNs
by combining various pieces related to DNAMEs. Here, I believe it is
reasonable to specify that generators MUST apply the bidi rules to all
of the labels of each generated FQDN.

Erik

On Fri, Sep 5, 2008 at 2:15 AM, Harald Alvestrand <harald at alvestrand.no> wrote:
> For all those of you who care about the bidi interlabel issue, the
> following text is in -02:
>
>   o  The BIDI test MAY return failure if the BIDI rule is not satisfied
>      by the label following the label that contains AL, AN or R in the
>      domain name.  For all the reasons given above, it may be
>      impossible to know the following label, but there seems no or
>      negative value to allowing the BIDI test to succeed if the
>      following label is known.  [[POSSIBLY CONTROVERSIAL]]
>
> In the example Alireza gave, this would mean that the bidi test is
> allowed to fail on the <ALEF>.3.com domain name, but won't fail on the
> 3.<ALEF>.com domain name - which would at least make sure the document
> gives guidance on the decision on which of the two names is going to be
> considered "valid" by whatever registry-specific or application-specific
> logic people implement to solve the problem elsewhere.
>
> (As a personal preference, I would prefer to make it a SHOULD, or even a
> "MUST if the following label is known by the BIDI test" - but that did
> not seem to be the WG's consensus in Dublin, so that's not what the text
> says).
>
> This editor needs WG direction on whether to either remove this bullet,
> reword this bullet, or remove the [[POSSIBLY CONTROVERSIAL]] tag.
>
>                   Harald
>
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>


More information about the Idna-update mailing list