<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Harald Alvestrand wrote:
<blockquote cite="mid:48C0F52F.70809@alvestrand.no" type="cite">Alireza
Saleh wrote:
<br>
<blockquote type="cite"><br>
I think the your client for viewing email did something to my original
email , I'm attaching images of my original examples.
<br>
</blockquote>
Thank you - I now understand the issue!
<br>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><br>
After the label checks in IDNA2008 there are many unfixed and known
issues
<br>
that remain to be done somewhere else, such as at the application level
or
<br>
at the registry. For example the Registry should also apply more
<br>
restrictive rules during the registration to make their TLD safe but
this
<br>
will not assure safety beyond the second level. Here applications will
be
<br>
expected to take on the safety problems.
<br>
<br>
<br>
After the introduction of IDNA, most application developers have been
<br>
thinking about secure ways to make sure users will see the correct
<br>
domain Some applications may also change direction from LTR to RTL
based
<br>
on what they detect from the domain's direction. In that case it would
be
<br>
no risk to have a U-label that starts with numbers or contains only
<br>
numbers. Thus it may be possible to relax the current proposed rule in
<br>
IDNA2008.
<br>
</blockquote>
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.
<br>
</blockquote>
</blockquote>
</blockquote>
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.<br>
<br>
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. <br>
<blockquote cite="mid:48C0F52F.70809@alvestrand.no" type="cite">
<blockquote type="cite">
<blockquote type="cite"><br>
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?
<br>
</blockquote>
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 )
<br>
</blockquote>
It seems that we agree on this point, then.
<br>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><br>
So my suggestion is: Those problems which cannot be almost completely
<br>
resolved at the protocol level should be dealt with only at the
<br>
informational level, and no rules should be specified about them in the
<br>
protocol. One such example is to relax the BIDI rule about numbers,
which
<br>
I mentioned above.
<br>
</blockquote>
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?
<br>
<br>
Harald
<br>
<br>
</blockquote>
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.
<br>
</blockquote>
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).
<br>
<br>
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?
<br>
</blockquote>
If the application changes the text direction within the address-bar
from LTR to RTL then : <br>
1) There is NO visual problem if you don't mix RTL with LTR <b>lables</b>
within the domain, regardless of position of the numbers. <br>
<p dir="rtl">۱۲۳آزمایشی.۴۵۶.کام
<br>
</p>
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.<br>
<br>
<p dir="rtl">123آزمایشی.4test.com
</p>
The original domain in the first example is : <123test in ARABIC
SCRIPT>.<456 in ARABIC SCRIPT>.<com in ARABIC SCRIPT><br>
The original domain in the second example is : <123test in ARABIC
SCRIPT>.4test.com<br>
<br>
<blockquote cite="mid:48C0F52F.70809@alvestrand.no" type="cite">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.
<br>
<br>
But I could be wrong.
<br>
<br>
Harald
<br>
</blockquote>
<br>
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. <br>
<br>
<br>
Best<br>
Alireza<br>
<br>
</body>
</html>