Remider: BIDI inter-label tests in -02

[Erik van der Poel]

Hi again Eric,

You cannot put <div mumble> in a plain text email, but you can put
LRO/PDF in there.

Anyway, I don't have time to pursue the LRO/PDF solution. It seems
like the WG is satisfied (if not happy) with the current IDNA200X bidi
draft, even if there are DNAME-related difficulties.

Erik

On Fri, Sep 12, 2008 at 3:37 PM, Eric Brunner-Williams
<ebw at abenaki.wabanaki.net> wrote:
> Erik
>
> I was being slightly sarcastic, since there have been quite a few
> suggestions in the past decade or so to somehow tag dns text as having
> some particular property other than uninterpreted existence, but just to
> be complete, the {LRO|RLO}-to-PDF markers aren't the only way to
> "outwit" the Unicode bidi algorithm, a <div mumble > can force the
> correct directionality also.
>
> Anyway, as thin as a non-spacing directionality marker is, and it
> displays wicked thin, it opens an set of choices previously discarded ab
> initio. Unless its cruft auto added by a revised punycode as a
> work-around on the broken bidi.
>
> Eric
>
> Erik van der Poel wrote:
>> Hi Eric,
>>
>> I only mentioned the LRO/PDF idea in an effort to consider other
>> alternatives when we were discussing "the DNAME problem". I don't know
>> whether we consider the DNAME problem to be big enough to cause us to
>> resort to a "metadata" approach like LRO/PDF. Perhaps many WG
>> participants believe that the DNAME problem is not a big deal, and
>> that we should just forge ahead with the current IDNA200X bidi draft.
>>
>> What other types of metadata do you have in mind, and what big
>> problems are solved by those?
>>
>> Erik
>>
>> On Wed, Sep 10, 2008 at 7:55 AM, Eric Brunner-Williams
>> <ebw at abenaki.wabanaki.net> wrote:
>>
>>> Erik,
>>>
>>> The same thought occured to me Monday afternoon as I sat in on Richard
>>> Ishida's bidi tutorial at ICU-32 and realized for the first time that
>>> the directionality leak we see is (a) common to a bunch of punctuation
>>> marks, and (b) been well known to the Unicode community for a dog's age,
>>> unlike the rest of us who "got it" more or less at Dublin. I've no
>>> excuse for being retarded, as 15 years ago I was on the bidi mailing list.
>>>
>>> But if we toss in meta-data, why stop there?
>>>
>>> Eric
>>>
>>> Erik van der Poel wrote:
>>>
>>>> Forgive for me not preparing detailed PowerPoint slides, but the basic
>>>> idea of the bidi override is that they force the direction to be RTL
>>>> (RLO = right to left override) or LTR (LRO = left to right override).
>>>> Their effect ends when you hit a PDF (pop directional format).
>>>>
>>>> Obviously, you can still have ambiguity if you use these carelessly.
>>>> The following two are displayed the same way:
>>>>
>>>> <LRO> a b c <PDF>
>>>> <RLO> c b a <PDF>
>>>>
>>>> These are both displayed as "abc". We could remove that ambiguity by
>>>> specifying that LRO is to be used when the first character in a bidi
>>>> string is LTR, RLO when the 1st character is RTL.
>>>>
>>>> However, if we put LRO or RLO at the beginning of every bidi label and
>>>> PDF at the end of every bidi label, we might still have re-ordering
>>>> among labels rather than characters. (I'm not sure about the bidi
>>>> algorithm here.)
>>>>
>>>> One way to overcome this problem is to have LRO or RLO at the
>>>> beginning of the FQDN, and PDF at the end, but this destroys the
>>>> property that each label fully describes itself, and besides, we
>>>> probably don't want to deal with PDF at the end of a TLD.
>>>>
>>>> So perhaps we would just specify that only LRO is to be used (to
>>>> harmonize with the current LTR DNS), and that it must be at the
>>>> beginning of a bidi label (containing at least one RTL character), and
>>>> that there must be a PDF at the end of that label.
>>>>
>>>> One big problem with LRO and PDF is that they are prohibited in
>>>> IDNA2003. However, we have other incompatibilities with IDNA2003 (such
>>>> as ZWJ and ZWNJ), so maybe we can use similar strategies to make the
>>>> transition.
>>>>
>>>> I'm probably missing several things, since it is getting late here too. :-)
>>>>
>>>> Erik
>>>>
>>>> On Mon, Sep 8, 2008 at 6:39 PM, JFC Morfin <jefsey at jefsey.com> wrote:
>>>>
>>>>
>>>>> Erik, Andrew,
>>>>> I am not sure everyone is with you. At this stage and time in the
>>>>> night I am not anymore. Would it not help everyone is using ppt
>>>>> slides (so everything is clearly displayed) to give a clear example,
>>>>> step by step, analysing where the problem occurs, how would work the
>>>>> over-rides ?
>>>>> jfc
>>>>>
>>>>>
>>>>> At 02:57 09/09/2008, Erik van der Poel wrote:
>>>>>
>>>>>
>>>>>> Well, I believe we're stuck between a rock and a hard place. On one
>>>>>> side, we have DNAME, which, if used carelessly, can result in FQDNs
>>>>>> that are displayed ambiguously by the Unicode bidi algorithm. On the
>>>>>> other side, we have RTL characters that we would like to use in domain
>>>>>> names, in such a way that their display is unambiguous even in running
>>>>>> text. It's pretty clear that we cannot stop people from using DNAMEs.
>>>>>> But it's also quite clear that we must allow RTL characters in domain
>>>>>> names if we're going to allow other non-ASCII characters too. Finally,
>>>>>> it's clear that bidi strings are most often displayed using the
>>>>>> Unicode bidi algorithm.
>>>>>>
>>>>>> We cannot change that algorithm, but we might be able to work around
>>>>>> it using bidi overrides (LRO and RLO), which get rid of the ambiguity.
>>>>>> I don't know whether the WG members like that idea though. We might
>>>>>> want to list the pros and cons of such a proposal.
>>>>>>
>>>>>> Erik
>>>>>> _______________________________________________
>>>>>> Idna-update mailing list
>>>>>> Idna-update at alvestrand.no
>>>>>> http://www.alvestrand.no/mailman/listinfo/idna-update
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> Idna-update mailing list
>>>>> Idna-update at alvestrand.no
>>>>> http://www.alvestrand.no/mailman/listinfo/idna-update
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Idna-update mailing list
>>>> Idna-update at alvestrand.no
>>>> http://www.alvestrand.no/mailman/listinfo/idna-update
>>>>
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> Idna-update mailing list
>>> Idna-update at alvestrand.no
>>> http://www.alvestrand.no/mailman/listinfo/idna-update
>>>
>>>
>> _______________________________________________
>> Idna-update mailing list
>> Idna-update at alvestrand.no
>> http://www.alvestrand.no/mailman/listinfo/idna-update
>>
>>
>>
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>