BIDI rules

Alireza Saleh saleh at nic.ir
Fri Sep 5 10:27:59 CEST 2008


Harald Tveit Alvestrand wrote:
> Alireza Saleh skrev:
>> I did some tests on domain visualization when we have RTL characters 
>> in the
>> label. Some issues arise when you mix the scripts within a domain.
>>
>>
>> As the group decided to eliminate the inter-label checking within the
>> protocol in Dublin, and inter-label checks are quite essential, it is
>> necessary that these be done SOMEWHERE. Consider, for example, the
>> following where LTR and RTL cannot be distinguished:
>>
>>
>> 1) http://3.ا.com = http://3.<ALEF>.com
>> 2) http://ا.3.com = http://<ALEF>.3.com
>>   
> Alireza,
>
> I am confused by this example - on my screen, the left hand side of 
> example 2) contains two non-ASCII charcters and no digit 3, so the two 
> are quite visually distinct to me. Could you explain a bit more?
>
> Since I don't understand your example, it's possible that I'm entirely 
> off track in my responses below - so please consider these only 
> preliminary musings.
Harold,

I think the your client for viewing email did something to my original 
email , I'm attaching images of my original examples.
>>
>> 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.
>
> 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 )
>>
>> 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.

Alireza

P.S.  Here is the URL for convert text to image :
http://www.nic.ir/Show_Text?c=http://3.%D8%A7.com&s=14&b=ffffff7f&f=01292200&t=DejaVuSans
http://www.nic.ir/Show_Text?c=http://%D8%A7.3.com&s=14&b=ffffff7f&f=01292200&t=DejaVuSans
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 3dotAlef
Type: image/png
Size: 457 bytes
Desc: not available
Url : http://www.alvestrand.no/pipermail/idna-update/attachments/20080905/3fb363db/attachment.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Alefdot3
Type: image/png
Size: 457 bytes
Desc: not available
Url : http://www.alvestrand.no/pipermail/idna-update/attachments/20080905/3fb363db/attachment-0001.png 


More information about the Idna-update mailing list