BIDI rules

Alireza Saleh saleh at nic.ir
Fri Sep 5 22:57:37 CEST 2008


Harald Alvestrand wrote:
> Alireza Saleh wrote:
>>
>> I think the your client for viewing email did something to my 
>> original email , I'm attaching images of my original examples.
> Thank you - I now understand the issue!
>>>>
>>>> After the label checks in IDNA2008 there are many unfixed and known 
>>>> issues
>>>> that remain to be done somewhere else, such as at the application 
>>>> level or
>>>> at the registry. For example the Registry should also apply more
>>>> restrictive rules during the registration to make their TLD safe 
>>>> but this
>>>> will not assure safety beyond the second level. Here applications 
>>>> will be
>>>> expected to take on the safety problems.
>>>>
>>>>
>>>> After the introduction of IDNA, most application developers have been
>>>> thinking about secure ways to make sure users will see the correct
>>>> domain  Some applications may also change direction from LTR to RTL 
>>>> based
>>>> on what they detect from the domain's direction. In that case it 
>>>> would be
>>>> no risk to have a U-label that starts with numbers or contains only
>>>> numbers. Thus it may be possible to relax the current proposed rule in
>>>> IDNA2008.
>>>>   
>>> This requires that applications identify correctly all instances of 
>>> domain names - my thinking when writing -bidi was that it would be 
>>> extremely confusing for users to have a domain name display in one 
>>> order when in the address bar, and in another order when in running 
>>> text, so I argued that these should be treated identically (last 
>>> paragraph of section 6 of -bidi-02), and - based on that argument - 
>>> the behaviour of domain names in running text was the behaviour that 
>>> it was important to write rules for.
Dear Harold, just forgot to say, almost all text editors that want to 
support RTL scripts have an option to set the direction of the text to RTL.

Currently we don't have such support in address bars, so  what native 
RTL users see in the address bar is different from what is in the 
running RTL-texts.
>>>
>>> I haven't heard anyone argue the opposite position yet, although 
>>> I've heard many people wistfully wish that they could make it so. Do 
>>> you wish to reopen this argument?
>> I think that it doesn't matter where you see the URL, it is important 
>> for the users to see the correct URL when they want to use it. Almost 
>> all  URL-aware  application more or less process the URL. ( for 
>> example thunderbird did it already with this email )
> It seems that we agree on this point, then.
>>>>
>>>> So my suggestion is: Those problems which cannot be almost completely
>>>> resolved at the protocol level should be dealt with only at the
>>>> informational level, and no rules should be specified about them in 
>>>> the
>>>> protocol. One such example is to relax the BIDI rule about numbers, 
>>>> which
>>>> I mentioned above.
>>> I do not understand what you are asking here - what rule (referring 
>>> to the numbered list in section 4 of -bidi-02) do you wish to relax, 
>>> and which requirement in section 3 of -bidi-02 (which is the basis 
>>> on which these rules were designed) do you think we can live without?
>>>
>>>                          Harald
>>>
>> I mean, the rule that limited the RTL labels to only start with  RTL 
>> characters. I specifically talk  about the rule number 7 in section 
>> 04 of the bidi-02 document.  We can not  live  without them but there 
>> are some issues that have to be solved somewhere. By resolving those 
>> issues some of the current concerns also will be solved, and there 
>> will be no need to have some limiting rules within the document. My 
>> suggestion is to relax those rules as we know their related problems 
>> can be solved within the applications.
> Thank you - as far as I understand, you identify an inter-label 
> problem that can't be solved by intra-label rules. One solution is, of 
> course, to go back to inter-label rules and saying that the label '3' 
> can't occur next to the label '<ALEF>'; the other solution (which the 
> current document advocates in section 5; your example is a perfect 
> illustration (except that in this case, the number moved right over 
> the label and out on the other side, which I hadn't anticipated).
>
> However, I don't understand how the intra-label problem can be solved 
> within the application either.... could you give an example of an 
> usage of labels with RTL characters inside them, and a leading EN or 
> AN, and a way in which applications can be coded to guarantee that 
> there won't be a problem?
If the application changes the text direction within the address-bar 
from LTR to RTL then :
1) There is NO visual problem if you don't mix RTL with LTR *lables* 
within the domain, regardless of position of the numbers.

۱۲۳آزمایشی.۴۵۶.کام

2) It will cause confusion if you mix RTL with LTR lables within the 
domain but it is readable by native RTL text reader and this confusion 
is less than my earlier example about 3.com.

123آزمایشی.4test.com

The original domain in the first example is : <123test in ARABIC 
SCRIPT>.<456 in ARABIC SCRIPT>.<com in ARABIC SCRIPT>
The original domain in the second example is : <123test in ARABIC 
SCRIPT>.4test.com

> It seems to me that if a problem cannot be solved fully at all, and we 
> can limit the size of the problem by imposing rules at a given level, 
> and those rules don't inhibit any large number of nonproblematic 
> usages, we should keep those rules.
>
> But I could be wrong.
>
>                     Harald

After the Dublin meeting I really think that there is possible to remove 
the bidi document from the protocol or make it very relax. The current 
ASCII-DNS protocol doesn't deal with visual problems and I think why 
IDNA couldn't follow this strategy.


Best
Alireza

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20080906/8815bc44/attachment-0001.htm 


More information about the Idna-update mailing list