BIDI rules

[Eric Brunner-Williams]

...  issues in domain names ...
and
...  the complicated areas ... are holding up the rest of ... in domain 
names.
and
...  keep discussing ... until we have perfect specs for them, or can we 
publish the uncontroversial parts ...

Months ago I tried to find the source(s) for requirements, and 
discovered by asking that they didn't arise from "ICANN" (and I checked 
within the GNSO where the answer was "no one asked the IETF to do 
anything"), and they don't just involve domain names. There are other 
rationals (with apologies for the abuse of notation to John) than domain 
names, with or without ICANN, and with or without "fast track".

I appreciate the expression of desire, but until we know why the unknown 
consumers are satisfied with the uncontroversial parts, or demand 
perfect specs, other than the personal relief of doing something, which 
is the correct choice?

nok Eric


 
Erik van der Poel wrote:
> On Fri, Sep 5, 2008 at 12:56 AM, Stephane Bortzmeyer <bortzmeyer at nic.fr> wrote:
>   
>> On Thu, Sep 04, 2008 at 08:41:55AM -0700,
>>  Erik van der Poel <erikv at google.com> wrote
>>  a message of 30 lines which said:
>>
>>     
>>> Bidi and spoofing are both *display* issues.
>>>       
>> Yes. And, therefore, both should be regarded as off-topic for the
>> IETF.
>>     
>
> No, I think it is reasonable for the IETF to consider bidi display
> issues in domain names and to try to come up with rules that can cover
> a number of RTL scripts. It seems like we could eventually settle on a
> set of rules that would avoid bidi confusion, and that it is
> reasonable for the IETF to try to avoid such confusion.
>
> My concern is that the complicated areas like bidi and ZWJ/ZWNJ are
> holding up the rest of IDNA200X and Unicode 5.1 in domain names. Many
> of the characters introduced between Unicode 3.2 and 5.1 have no
> bidi/ZW issues, and many of the IDNA changes from 2003 to 200X are
> uncontroversial.
>
> Are we going to keep discussing bidi and ZW until we have perfect
> specs for them, or can we publish the uncontroversial parts of
> Protocol and Table as Proposed Standards, with informative references
> to Bidi and ZW, which would be published as Experimental RFCs?
>
> If we are willing to live with relatively relaxed rules for Latin,
> Cyrillic, Greek and Han in IDNA200X, and to leave the visual spoofing
> issues in those scripts to zone admins and apps, why can't we live
> with relaxed rules for bidi in IDNA200X, leaving the experimentation
> to zone admins and apps?
>
> I'd also prefer not to let Rationale hold up Protocol/Table. It seems
> like we have consensus on most parts of Protocol/Table, so it doesn't
> matter that different individuals would give different rationales, as
> long as they agree on the end result.
>
> However, John seems to want to cater to people that would read
> Rationale first, therefore requiring normative definitions in that
> document. If John is the only WG member that feels this way, perhaps
> the WG consensus could be to move the normative parts of Rationale to
> Protocol and Table, and publish Rationale some time after Protocol and
> Table. Is it time for the Chair to gauge the level of consensus in
> this area?
>
> Erik
>
>   
>> On the wire, BIDI labels have zero ambiguity.
>>
>>     
>>> If we can leave spoofing out of the protocol, why can't we leave
>>> bidi out of it?
>>>       
>> Do you mean "We should regard BIDI display as off-topic and therefore
>> stop the work on draft-ietf-idnabis-bidi" (more or less my opinion) or
>> "We should forbid RTL characters from IDNAbis", as some people have
>> understood your message?
>>
>>
>>     
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>
>
>