Consensus Call Tranche 4/5 (Settled Textual Issues and IANA Considerations

[Mark Davis]

On Mon, Oct 6, 2008 at 11:00 PM, Vint Cerf <vint at google.com> wrote:

> DUE DATE: OCTOBER 10, 2008 (ET)
>

NO


>
> 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!

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


>
>
> NOTE NEW BUSINESS ADDRESS AND PHONE
> Vint Cerf
> Google
> 1818 Library Street, Suite 400
> Reston, VA 20190
> 202-370-5637
> vint at google.com
>
>
>
>
>
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20081009/81e71915/attachment-0001.htm