Consensus Call Tranche 7 (BIDI) Summary

[Vint Cerf]

Consensus Call Tranche 7 (BiDi Model) Summary

YES - 16
NO - 0

We seem to have consensus on the BIDI document content with the  
proviso that some additional wording or explanation could be added  
per the comments below.

Harald, et al, are you able to propose additional language that might  
capture the desire for clarity? Perhaps we need a thread specific to  
the discussion about what SHOULD NOT or MUST NOT be allowed in ZONE  
data? I do not detect exact consensus on the point but wonder whether  
there IS a (reasonable?) desire to warn against (prohibit?)  
registration of strings that fail the BIDi tests?

------------------

(7) The Bidi model

(7.a) Bidi tests are not made between labels in the protocol
although warnings about possible presentation and others
difficulties should appear in the Bidi discussion.  (P.4)

(7.b) Bidi tests SHOULD be applied at lookup time (not MUST). (P.5)

COMMENTS:

I think regarding (7.b) that it MUST be done at registration time.

=======

I think all IDNA tests including BIDI tests should be applied during  
the registration.
========

The proposal seems fine.

Wrt 7.b, I believe the document should give some examples of situations
where violating the SHOULD is motivated, otherwise it will be difficult
to understand the intention behind using SHOULD instead of MUST.

For example, is it considered a valid reason to not do Bidi processing
because your platforms is resources limited (small RAM, ROM, CPU powers
etc)?

======
I would have no objection to these two points (but also no objection  
to changing them).

======

(7.b) Bidi tests SHOULD be applied at lookup time (not MUST).
(P.5)

I'm ok with this, provided that we slightly strengthen the definition
(wherever it lands).  Currently, in rationale, it's defined this way:

    The terms [sic] "lookup" is used to describe the combination of
    operations performed by this protocol and those actually performed
    by a DNS resolver.

I think this could be made more pointed by adding some remark like,
"'Resolution', as usually used in a DNS context, is part of lookup,
but a lookup involves a number of steps that are performed before any
DNS activity happens."  I'm sure someone can make that prettier.  I
realise that this does not actually add anything to the current
definition.  The point of this is to be very clear, so that we don't
get into a DNS bunfight later.

I note, also, that the consensus call did not discuss the current
protocol restriction on registration, which is this:

    Additional special tests for right-to-left strings are applied (See
    [IDNA2008-BIDI].  Strings that contain right to left characters that
    do not conform to the rule(s) identified there MUST NOT be inserted
    as labels in zone files.

I remain pretty uncomfortable with any part of this specification
making new requirements on what may be put into DNS zone data.  I
predict that the above restriction is going to be rejected out of hand
by some registry operators.  If you really want this paragraph to
stand, you will for sure be updating the DNS specifications and the
document will run the risk of getting handed to dnsext for review of
this provision.  Is this provision really necessary?

=========
7a seems a long-winded way of avoiding the obvious, the semantics of  
"." in the DNS is not a sentence terminator, and the algorithm that  
is used works for the latter case, and not for the former.

7b I'm going to just ditto XXXX's comments all the way down to "is  
this provision really necessary".
======

I'm happy with saying "Registries that want to claim conformance to
IDNA2008 ...

I see two problems.

First, applicants that have spent six to seven figures to obtain and
operate a registry under contract with ICANN have a very different risk
model compared to registries which operate without contract. Some ccTLD
NIC may ignore as non-binding any MUST or MUST NOT language, while it
would be somewhat risk insensitive for a gTLD NIC to ignore language
that appears in, or is referenced by, the contract that allows them to
operate a registry. IANAL, etc.

[comment by another WG member:
and wearing the foot in the other mouth.... ICANN is very concerned
about making strings available whose most distinguishing feature is that
they are useful in attempts to confuse, mislead and defraud, while it
does not want to stand in the way of the use of any string that has
another useful purpose.

So ICANN's likely to require conformance in contract to *some* set of
standards, IDNA200X being one. It's unlikely that ICANN would attempt to
require conformance to RFC 2549 (IP over Avian Carriers).]


Second, is IDNA200{3,X} as capable of conformance, let alone as
important to conform (for insert your favorite motivation here,
"security and stability" is one frequently used, I'm sort of partial to
coherence and correctness, but YMMV) as 882/883 et seq?

[Comment by another WG member:
If it's not possible to conform to IDNA200X, this WG has failed.

(Conformance to 882 would be extremely unwise. That document was
obsoleted ten years ago. ]

[Comment by another WG member:
1. ccTLD registries aren't contractually obligated to ICANN. That was
the intent of my first comment, which you appear to have missed  
completely.]

[Reply comment:
I didn't miss it, I ignored it, because I wanted to make the point that
ICANN wants to require conformance to this spec for the new gTLDs (and
other gTLDs), and that's a reasonable desire.]

[comment by another WG member:
Some do have contracts, some have MOU's, some have other agreements.
But yes, there is no "one contract fits all" for ccTLD ICANN
relationships so it is hard force things to ccTLDs.  See for some
of the details http://www.icann.org/en/cctlds/agreements.html.]


Personally, I don't think so, but "conformance to IETF protocols ..."
fails to distinguish degrees of mandatory to actually take serious.
=======
how else can we formulate "don't do this"?

First, I am not convinced, even a little bit, that the specification
ought to be saying any MUSTs about contents of zone files.  But what
about this:

     Zone operators SHOULD have a policy that forbids accepting as
     U-labels strings that fail the BIDI criterion.  Zone operators
     SHOULD NOT generate A-labels from a putative U-label that fails
     the BIDI criterion, and SHOULD NOT insert such A-labels in zone
     data.

Alternatively,

     Zone operators conforming to this specification MUST have a policy
     that forbids accepting as U-labels strings that fail the BIDI
     criterion.  Zone operators conforming to this specification MUST
     NOT generate A-labels from a Putative U-label that fails the BIDI
     criterion, and MUST NOT insert such A-labels in zone data.

if you really want to use the MUST. In my opinion, the second form is
actually weaker, since the first imposes an implied restriction on
zone operations (which is not a matter for DNSEXT, I'm delighted to
say, althought DNSOP might have something to say about it) whereas the
second only imposes a restriction on those claiming to conform to the
specification.

But I want to think that this is implicit in "conformance to IETF
protocols is voluntary" and "IDNA2008 is a different specification from
the DNS". Otherwise, modularization suffers.

I agree, which is why I'm picking at this nit.
========

I have tried to understand exactly what the points of this consensus
call are, but I have not been able to do so. I could dig deeper in
related material, but my guess is that others may have similar
questions. So here they go:

1. Are these questions about the Bidi document, or the Protocol
    document. What I find at P.4 at
    http://www.alvestrand.no/pipermail/idna-update/2008-August/ 
002537.html
    seems to strongly suggest that this is only about what's in
    Protocol, i.e. essentially references to Bidi and usage of
    the Bidi constraints in the Protocol.

[comment by chair:
I think the intent is to seek consensus on BiDi practices, whether in  
the
BiDi document or referenced in Protocol.]


2. Is the idea of checking bidi constraints across label boundaries
    essentially dead? P.4 seems to suggest so, but

3. P.5 is just about lookup time. Judging from Patrick's contribution,
    it's completely unclear to what extent this tranche includes
    registration.

[comment by chair:
I believe the intent was to dispose of cross-label checking as a  
requirement
or recommendation regardless of whether at registration or look up  
time.]

[Comment by editor:
I very much favour cross-label checking at registration time - for the
"natural hierarchy".

No matter what else the protocol says, there's entirely no benefit in
recommending that both "<aleph>.3.com" and "3.<aleph>.com" be
permitted at registration time. They display the same, and registering
both can have no goal but confusion.]
======



NOTE NEW BUSINESS ADDRESS AND PHONE
Vint Cerf
Google
1818 Library Street, Suite 400
Reston, VA 20190
202-370-5637
vint at google.com




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20081021/117b1113/attachment-0001.htm