Consensus Call Results- Tranche 4/5 (Text Issues/ IANA Considerations)

Sun Oct 12 14:13:18 CEST 2008

Consensus Call - Tranche 4/5 (Settled Text Issues and IANA  
Considerations)

ANALYSIS:

There were 9 NO votes and 6 YES votes with considerable commentary as
noted below. There were some suggestions to create another document
for implementors but I suspect there will also be views preferring to  
reduce
or maintain the current number of documents so I would suggest that we
might try to use part of Rationale for implementors or, perhaps, place
implementation observations in an appendix of, e.g., Protocol?

The range of comments below is sufficiently large that a simple  
statement
of next editing steps seems hard to summarize. Some of the comments
are sufficiently detailed that it should be possible to articulate the
issues (ie distinct alternatives) so as to allow discussion and/or  
polling
for preferences.

Plainly, there is not consensus on all of Trance 4/5, so further  
revision
and discussion is needed.

COMMENTS BELOW ARE TAKEN FROM THE POLLING RESPONSES
=====================================================

For roughly the same reasons as Mark Davis expressed yesterday (10/9).

==========================================================
In this case I concur with most of Mark Davis' comments,
so won't replicate them one by one here. Just take this
as an affirmation that most of what Mark pointed out
does (IMO) need to be addressed to reach consensus on
the document textual issues.
========================================================
(4.a) The explanation of mappings in Rationale-02 and later is
satisfactory.   (R.24)

Explanation in Rationale-03 is better, but I think this part should be
written an another document describing application implementation  
guidelines.

(4.c) The explanation of requirements on registries, the role
of registration policy, and their scope in Rationale-02 and
Protocol-05 is satisfactory (R.9, R.27, P.6).

This part also should be an another document.

(4.e) The description of detecting domain names in text and how
it interacts with the idea of alternate label separator
("dotoid") characters is adequate in Rationale-02  (R.23)

This part should be marged with application implementation guidelines.

(4.f) The description of the implications of mapping changes
between IDNA2003 and IDNA2008 is satisfactory in Rationale-02
(R.28)

This part should be marged with application implementation guidelines.

(5.a) The IANA considerations section setting up the Contextual
Rule registry (in Tables, taken from Protocol at -03) is
satisfactory.   (R.8)

Contextual rules in Protocol-03 was too restrictive.  Contextual rules
should be much simpler.  Properties of exception characters should be
defined in registries' policy.

=======================================================
COMMENTS:

In general, while good progress has been made the documents are  
nowhere near
ready to release, even putting aside the problem with mixtures of  
normative
and informative material in Rationale.

Note: it is unclear to me what the "R.xx" references are. In general,  
the
following points are quite hard to interpret, because it is very unclear
what sections of text are being referred to. In many cases, I have no  
idea
what the actual text is, even after spending a good deal of time  
looking at
it, because there are many disconnected sections that it could be  
referring
too.

For that reason, I suspect that many of the votes (*both* YES and NO)  
are
probably flawed in that it is unclear what people are voting for!

Thanks for saying this.  I tried to understand the 4/5 consensus call
better before answering, but it was too complicated to follow.  Instead
I read the documents to understand whether they are in better shape
today.  If the documents look OK, I'd say YES to everything that would
move them forward.  However, I do not see the documents specify a
technology that can be implemented reliably.  Given this, I'm saying NO
because the consensus call itself is flawed, and the documents needs
more work.

===========================================================
In general, while good progress has been made the documents are  
nowhere near ready to release, even putting aside the problem with  
mixtures of normative and informative material in Rationale.

Note: it is unclear to me what the "R.xx" references are. In general,  
the following points are quite hard to interpret, because it is very  
unclear what sections of text are being referred to. In many cases, I  
have no idea what the actual text is, even after spending a good deal  
of time looking at it, because there are many disconnected sections  
that it could be referring too.

For that reason, I suspect that many of the votes (*both* YES and NO)  
are probably flawed in that it is unclear what people are voting for!

But I tried to piece together what the following meant, and give some  
responses.

(4) Textual issues believed settled

(4.a) The explanation of mappings in Rationale-02 and later is
satisfactory.   (R.24)

No. The paragraph "Highly Localized Preprocessing." is dangerous and  
should be modified drastically. Condition (i) ["(i) only U-labels and  
A-labels are used in interchange with systems outside the local  
environment"] is wishful thinking, not borne out by reality; we've  
seen time and time again that people copy what works in a browser  
into an href or email.

And conditions like "Preprocessing MUST NOT map a character that is  
valid in a label (i.e., one that is PROTOCOL-VALID or permitted in  
any context) into another character." are insufficient. They permit,  
for example, uppercase A-ring to be mapped to "aa" on one system and  
"a" on another.

Having this section be so weak represents a major interoperability  
problem.

(4.b) The explanation of the symbol prohibition in Rationale-02
and later is satisfactory.   (R.25)

No. The explanation is specious, and should be removed.

(4.c) The explanation of requirements on registries, the role
of registration policy, and their scope in Rationale-02 and
Protocol-05 is satisfactory (R.9, R.27, P.6).

No. The requirements should be in one place

(4.d) The description of the Bidi changes between IDNA2003 and
IDNA2008 in Rationale-02 is satisfactory.   (R.15)

Yes

(4.e) The description of detecting domain names in text and how
it interacts with the idea of alternate label separator
("dotoid") characters is adequate in Rationale-02  (R.23)

No. Example: the following is still incorrect. Take the code or  
regular expression used to find domain names, and change [.] to  
include the other alternatives. Not rocket science.

"When using Unicode, this gets even more difficult if treatment
of certain special characters (like the dot that separates labels in
a domain name) depends on context (e.g., prior knowledge of whether
the string represents a domain name or not). That knowledge is not
available if the primary heuristic for identifying the presence of
domain names in strings depends on the presence of dots separating
groups of characters with no intervening spaces."

(4.f) The description of the implications of mapping changes
between IDNA2003 and IDNA2008 is satisfactory in Rationale-02
(R.28)

(4.g) The discussion of user agent security issues should be
retained in Section 6.3 of Rationale.  (R.6, R.19)

No. There should be one unified section with security issues.

(4.h) The description of why we are using Unicode is
satisfactory in Rationale-02.   (R.13)

Don't know where this is.

(4.i) With the new note warning that, while the lookup and
registration steps in Protocol are similar, they are not
identical, the structure of the description of those steps is
satisfactory. (P.10, P.15)

No. The text should state precisely what the differences are.

(4.j)  The text about A-label dislay that now appears in Rationale-02
is satisfactory.  (R.20)

No. It discourages input of A-Labels and display of A-Labels, without  
mentioning the widespread use of A-label display to indicate  
suspicious sites. While I agree that there are better mechanisms,  
this is a place that requires discussion, not ignoring the practice.

(5) IANA Considerations and table changes.

(5.a) The IANA considerations section setting up the Contextual
Rule registry (in Tables, taken from Protocol at -03) is
satisfactory.   (R.8)

Very unclear. The contextual rules were supposed to be moved to  
tables, but aren't there yet. The various sections on IANA  
considerations just bounce around between one another now

http://tools.ietf.org/html/draft-ietf-idnabis-tables-02#section-5
http://tools.ietf.org/html/draft-ietf-idnabis-rationale-03#section-13
http://tools.ietf.org/html/draft-ietf-idnabis-protocol-05#section-8

There is completely insufficient information as to what the  
considerations are, and precisely the process that IANA is to use to  
manage any changes, and exactly what the formats are.

(5.b) We are agreed that changes to the table-defining rules,
and especially to lists of contextual rules and exception
characters, require IETF consensus and publication of a new
RFC.   (R.12)

Yes. However, statements like "Characters that are placed in the  
"PROTOCOL-VALID" category are never removed from it unless the code  
points themselves are removed from Unicode" are completely specious,  
and need to be removed or changed to add "unless this document is  
obsoleted". IETF can at any time change the rules; after all, we are  
doing that with this very document, removing thousands of characters  
from being valid in IDNs.

(5.c) The IANA registry for contextual rules should be
maintained with a "last updated" date.   (P.16)

Another case where I can't find the text. The reference doesn't give  
a document and "last updated" is not found in either protocol or  
rationale.

(5.d) The contextual rules themselves should be specified and
maintained as procedural steps, as discussed in Dublin. (P.2,
P.3)

Yes
  ===============================================

Rationale-03 Section 8 "Front-end and User Interface Processing" is
satisfactory, but the section should be moved to protocol document and

please recommend "General Preprocessing" for backword compatibility
with IDNA2003 (if implementors want compatilibity)
in protocol-05 Section 5.3.

(4.b) The explanation of the symbol prohibition in Rationale-02
and later is satisfactory.   (R.25)

Protocol-05 section 4.3.2.3 "Contextual Rules" are too complicated to
implement.

==============================================
(4.a) The explanation of mappings in Rationale-02 and later is
satisfactory.   (R.24)

I still don't think I understand it, I can't tell whether it's
normative (whatever that would mean in this context), and I'm still
bothered by the nagging feeling that it allows just about anything to
be considered a "label" in some contexts.  I appreciate that I've been
a laggard in responding to this issue, but since there's a deadline of
10 Oct and since we have to agree to everything or nothing, I have to
say "no".

===============================================

(4.b) The explanation of the symbol prohibition in Rationale-02
and later is satisfactory.   (R.25)

Not at all. Unless you consider FUD like talking about "dangerous
characters" (9.2.1.1) as an explanation.

(4.c) The explanation of requirements on registries, the role
of registration policy, and their scope in Rationale-02 and
Protocol-05 is satisfactory (R.9, R.27, P.6).

No (5.2). A lot of handwaving ("it is generally believed that labels
containing characters from more than one script are a bad practice")
but no explanation.

(4.d) The description of the Bidi changes between IDNA2003 and
IDNA2008 in Rationale-02 is satisfactory.   (R.15)

No. 6.1 says "it is likely that some strong suggestions should be made
about display order as well" without demonstrating it, except by a
reference to a quite different problem (the Janet order).
=================================================
R.9, R.27, P.6 I think this is what Patrik asked me to think about at  
Dublin. I can't say its at "yes", yet. From just that I have to  
answer "no" to the fourth set.

So "No".
==================================================

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/20081012/7055e90a/attachment-0001.htm 