Special case for Bidi in draft-ietf-idnabis-protocol-14

["Martin J. Dürst"]

Hello Andrew, John,

On 2009/09/08 0:46, John C Klensin wrote:
>
> --On Monday, September 07, 2009 11:16 AM -0400 Andrew Sullivan
> <ajs at shinkuro.com>  wrote:
>
>> On Mon, Sep 07, 2009 at 06:49:55PM +0900, "Martin J. Dürst"
>> wrote:
>>> I agree with Mati. I think in protocol, checking the BIDI
>>> constraints  should just be a MUST. BIDI then can say (as it
>>> already does) that these  constraints are essentially
>>> irrelevant for LTR-only domain names.
>> I can think of a case where not checking BIDI rules would be
>> justified.  Suppose a system is configured such that it is
>> impossible to enter RTL characters, and there are no fonts for
>> displaying RTL characters either.  In this case, actually
>> performing the BIDI check would just be a waste of cycles:
>> they're effectively impossible anyway.

In this case, in my understanding, the BIDI check has essentially been 
carried out, so I don't see a problem with a MUST here. The rules are 
checked automatically and implicitly.

A different case would be that there is a chance for RTL characters, but 
for some reason, it's difficult or impossible to get this implemented. 
Now my understanding is that the various properties needed for 
implementing the checks prescribed in the table document are more data, 
and more work to implement, than those for bidi (and that implementing 
both "in parallel" will save quite a bit of work because there are 
similarities in where you have to get the data from, how you may be able 
to compact it, and so on. So I don't think the "difficult or impossible 
to implement" argument carries that far.

Anyway, I'm okay with a SHOULD for lookup, too, should that turn out to 
be the consensus of the WG.

Regards,   Martin.

>> (The purpose of the
>> BIDI rule, after all, derives primarily from the display
>> characteristics of RTL versus LTR.  Therefore, if no RTL is
>> possibly displayed, then there are no display characteristics.)
>>
>> Such a clear exception justifies a SHOULD, I think.  I am,
>> however, not wedded to this position.
>
> FWIW, while I'm not opposed to a MUST, a close approximation to
> the argument above was the reason for more relaxed language in
> the current text.
>
> --On Monday, September 07, 2009 11:19 AM -0400 Andrew Sullivan
> <ajs at shinkuro.com>  wrote:
>
>> On Mon, Sep 07, 2009 at 06:46:12PM +1000, Wil Tan wrote:
>>> I concur, especially given the fact that Bidi labels
>>> registered at lower levels of the tree (thus outside the
>>> control of parent registries) could possibly be used to
>>> render confusing domain names.
>> Let us not open this debate again, please.  We have explicitly
>> decided that confusability is not a criterion for
>> acceptability.  Just because registries can act badly is not a
>> reason to set protocol rules, and we have been quite clear
>> that we expect registries to have a policy (even if that
>> expectation is likely to be unrealised in practice).
>
> Yes.   We have concluded, several times, that "it will prevent
> confusability and bad behavior" is at best a side-benefit for a
> decision that is mostly made for other reasons unless the
> dangers are very real as obvious (as they are with invisible
> characters). Confusing, by itself, does not ascend to
> "dangerous".  I could, however, be persuaded that Bidi
> characters in odd contexts pose as much of a problem as those
> invisible characters but, fwiw, I'm not quite persuaded yet.
> What would actually go a long way to persuade me personally
> would be a lurid, but plausible, example or two that I could
> drop into Rationale as a reason for this extra level of
> precaution.
>
> FWIW, I was presented with an opportunity at the recent APNIC
> meeting that I turned into an example that seems to have gotten
> the point across to many people.   On the sponsor sign at the
> front of the room were three instances of the letter "A" at the
> front of a work or abbreviation.   One appeared in APNIC in a
> fairly blocky san-serif font; another was also APNIC but in a
> slightly more decorative serif font, and the third was in the
> logo for .ASIA, in which the initial "A" character is written in
> a moderately elaborate script-like font where it looks a bit
> like a star symbol.    I asked people to pretend that they
> weren't used to Latin-based scripts and that they didn't know
> what the words/abbreviations were and then to think about
> whether they were sure that all three were the same character of
> if they could be convinced that they are not.   As I said, it
> was pretty persuasive and that was with undecorated Latin --
> supposedly the most distinguishable of modern scripts.
>
> I can find a picture of the sign and post it if anyone would
> find that helpful.
>
>       john
>
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst at it.aoyama.ac.jp