I-D Action:draft-alvestrand-idna-bidi-04.txt (fwd)

[John C Klensin]

--On Friday, 15 February, 2008 09:09 +0530 Harald Tveit
Alvestrand <harald at alvestrand.no> wrote:

> 
> 
> --On 14. februar 2008 14:02 -0800 Erik van der Poel
> <erikv at google.com> wrote:
> 
>> Harald, Patrik and John,
>> 
>> Thanks for posting the new version of the IDNA200X bidi spec.
>> 
>> I see that you have a recommendation for registries in the
>> final paragraph of section 6.1. So a registry only needs to
>> be concerned about the next level up from the label being
>> registered, if that label contains any "right-to-left"
>> characters. We may need to tighten that up to say R, AL or
>> AN? Or just R and AL?
> 
> When I wrote it, I thought R, AL and AN.
> 
>> Also, what would the recommendation be for resolvers? I
>> suppose they would have a similar rule for the next level up,
>> but there is also the rule "ES and ON, followed by zero or
>> more NSM, is not allowed in the last position", so a resolver
>> may also need to look at the next level *down*, right?
> 
> Yes, it does. I think the defensive test (and the one that is
> simplest to code) for a resolver would be to flag anything
> where the whole domain name contains a R/AL/AN and where any
> label violates the bidi rule as "possibly confusing".
> 
> Is it OK to say that one should refuse to look up any such
> name?

Given especially the DNAME-related cases, I think not.  There
are too many legitimate names that can be suspicious ("possibly
confusing") under this sort of rule.

>> ES is European number separator (such as + and -) while ON is
>> other neutral (such as @ and &), so maybe we could simplify
>> the resolver's job by making ES and ON DISALLOWED in the
>> Table spec (except for hyphen (-), which would be CONTEXTO).

I see no imaginable reason to make + anything but DISALLOWED.
Hyphen is already CONTEXTO, with the contextual rule to enforce
"no leading, no trailing"

>> This way, a resolver can process labels in (logical) order,
>> and would not have to backtrack to the previous label if the
>> current label contains any R/AL/AN.
> 
> Back to the discussion about special treatment of the
> hyphen.... it would make the overall spec more orthogonal if
> the hyphen and the middle dot (which is an ON) was CONTEXTO
> and listed as exceptions, while the general class they belong
> to is DISALLOWED (middle dot already is).

See above.

> But currently, the tables document doesn't touch the bidi
> properties at all - so putting ES and ON into DISALOWED would
> be introducing a new class of criteria into the document. Do
> we need to do that?

Probably.   If "+", which under our normal definitions is a
symbol, is treated as PVALID, then we have a problem independent
of bidi.  I'm away from documents with with I could study either
the ES or ON list, but suspect that both are symbols in that
sense.

      john