Special case for Bidi in draft-ietf-idnabis-protocol-14
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"
>>>> 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,
> 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
> 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
> to compact it, and so on. So I don't think the "difficult or
> to implement" argument carries that far.
> Anyway, I'm okay with a SHOULD for lookup, too, should that turn out
> 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
>> 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.
>> Idna-update mailing list
>> Idna-update at alvestrand.no
> #-# 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
More information about the Idna-update