Latest docs
Mark Davis
mark at macchiato.com
Sat Dec 20 20:08:37 CET 2008
Latest feedback.
Many notable improvements in the docs. I haven't checked them completely
against my list, but in general, very nice work. Some remaining issues.
Defs.
====
To help prevent confusion between characters that are visually
similar, it is suggested that implementations provide visual
indications where a domain name contains multiple scripts (or what
are considered multiple scripts in a local environment in which some
mixed-script use is normal).
The scripts are still recognized as separate scripts, so the parenthesized
clause doesn't make apply. It should instead be something that makes it very
clear what the issue is, and provides an example. Suggested:
"... where a domain name contains multiple scripts with characters that are
visually confusable, such as an omicron in Greek mixed in with Latin text."
> allowing UNASSIGNED in lookup is *"(something that is now recognized as a
considerable source of risk)"*. (Defs)
This needs some justification, at least in Rationale if not here. What is a
scenario that illustrates that it is a risk?
1. If a lookup is against a registry is conformant to IDNA2008, it is no
risk at all: the UNASSIGNED character will be valid or invalid according to
the registry's version of Unicode.
2. If the registry is not conformant, then we already permit lookup to
proceed without full validation of U-Labels or any validation of A-Labels.
So allowing lookup of UNASSIGNED is the least of our problems!!
====
subject to the constraints about permitted characters that are
specified in the Protocol and Tables documents as well as the
symmetry constraint described.
Need to specify the section in Protocol that specifies U-Label. There are
many constraints in those documents; you need to point to the place that
sums up what makes a U-Label. (For example, satisfying just the lookup
constaints does not a U-Label make.)
... the symmetry constraint described [add "below"].
====
Rationale
some because they are
actively dangerous in URI, IRI, or similar contexts and others
because there is no evidence that they are important enough to
=>
some because they are
visually confusable in URI, IRI, or similar contexts and others
because there is no evidence that they are important enough to
[*dangerous* is too vague. If the issue is visually confusable, say so. If
it is some other problem, say what that is.]
====
>"characters are permanently excluded".
1. As per John Klensin: *"People have complained about statements that
appear to predict what the IETF will do in the future or to commit it to
future actions and those statements have been removed or
corrected as they
have been identified."*
So this needs to at least be qualified to say that the *intent* is for them
to be permanently excluded.
====
Security Considerations (Defs/BIDI) still needs to:
1. document how the compatibility problems between 2003 and 2008 can
cause security problems (See
http://docs.google.com/Doc?id=dfqr8rd5_361dwv9cff8 ). Some of this is in
Rationale, but needs to be added or referenced, while other parts are
missing. I can supply some suggested text if desired.
2. document the security issues that can arise in BIDI where Label
Uniqueness and Character Grouping are not maintained. (These goals cannot be
guaranteed because of intra-label issues and variance among bidi
implementations).
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20081220/51f8927e/attachment.htm
More information about the Idna-update
mailing list