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

Vint Cerf vint at google.com
Tue Sep 8 05:18:49 CEST 2009

well I think we have basically heard from only a few WG members but  
the general trend is roughly:

1. arguments for MUST
2. arguments for SHOULD
3. "I am ok with either one"

If I am detecting the rough consensus, I would say that SHOULD  
probably gets the preference since it requires no change to the  
documents and is somewhat less restrictive.


On Sep 7, 2009, at 9:57 PM, Martin J. Dürst wrote:

> 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
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update

More information about the Idna-update mailing list