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