Proposed Charter for the IDNAbis Working Group
Martin Duerst
duerst at it.aoyama.ac.jp
Thu Mar 27 11:39:08 CET 2008
Hello Vint,
A bit more nit-picking on top of what Paul already did.
At 20:08 08/03/26, Vint Cerf wrote:
>-------------
>
>
>IDNABIS Charter
>
>Chair(s): Vinton G. Cerf
>
>Applications Area Directors:
>
>Lisa Dusseault (ldusseault at commerce.net)
>Chris Newman (Chris.Newman at sun.com)
>
>Applications Area Advisor:
>
>Lisa Dusseault (ldusseault at commerce.net)
>
>Mailing List:
>
>General Discussion: idna-update at alvestrand.no
>To Subscribe:
>http://www.alvestrand.no/mailman/listinfo/idna-update
>Archive: http://www.alvestrand.no/pipermail/idna-update/
>
>Description:
>
>The original Internationalized Domain Name (IDN) WG set the
>requirements for international characters in domain names in
>RFC3490, RFC3491 and RFC3492 in 2002 (published in 2003).
I was confused by 'requirements'. In a charter context,
I was expecting something related to a requirements document.
I suggest something more direct such as "WG defined
internationalized domain names in RFC..." or any other
rewording that avoids confusion about whether these were
requirements documents or actual specs.
>These documents depend on RFC 3454 and were tied to Unicode
>version 3.2. An update to the current version (5.x) is
>required to accommodate additional scripts. In addition,
>experience has shown a number of real or perceived defects or
>inadequacies with the protocol.
>
>This WG is chartered to untie IDNA from specific versions of
>Unicode using algorithms that define validity based on Unicode
>properties. It is recognized that some explicit exceptions may
>be necessary in any case, but attempts would be made to
>minimize these exceptions.
would -> will
>Additional goals:
>
> - Separate requirements for valid IDNs at registration time
> (insertion of names into DNS zone files), vs. at resolution
> time (looking up those names)
>
> - Review, and, as necessary revise, the algorithms and rules
> for handling right to left character sequences in an IDN
> context to allow labels based on additional scripts and
> languages and to make presentation as predictable as
> reasonably possible.
"as necessary" is thrown in the middle (sorry, don't know
the correct grammatical term), so it should have a comma at
the end, too, but then we end up with almost every word
having a comma, so I suggest
"Review, and if necessary revise, ..." or some such.
> - Permit effective use of some scripts that were
> inadvertently excluded by the original protocols.
"effective" seems totally unnecessary, please remove
> - Ensure practical stability of validity algorithms for
> IDNs.
>
>The constraints of the original IDN WG still apply to IDNABIS,
>namely to avoid disturbing the current use and operation of the
>domain name system, and for the DNS to continue to allow any
>system to resolve any domain name in a consistent way. The
>basic approach of the original IDN work will be maintained --
>substantially new protocols or mechanisms are not in scope. In
>particular, IDNs continue to use the "xn--" prefix and the same
>ASCII-compatible encoding, and the bidirectional algorithm
>follows the same basic design.
>
>The work is initially organized as four documents: overview and
>rationale, protocol, table algorithm, and changes to the
>bidirectional algorithm. These documents are to be used as the basis
>for the discussion of the general direction of the work.
>
>This working group will be providing extended public review of
>the output of a design team that has been working on the issues
>described below.
It's unclear what "issues described below" refers to.
> This review-based approach is being used in
>part because of the way the work was undertaken by the team; in
>particular, the design team has been working with IETF
>visibility and has solicited and received significant amounts
>of technical review already. If the public review provided by
>this Working Group confirms the basic method outlined in the
>input documents, it is expected that the working group will be
>able to provide any needed changes and close in a short period
>of time. If technical issues arise that indicate a
>fundamentally different approach must be taken, it is
>anticipated that this working group would close, and a new one
>with an appropriate charter would be considered.
>
>This work will address stable and unambiguous IDN identifiers.
I don't understand what this sentence is supposed to mean.
I think replacing 'address' with a different word will help.
>There are a variety of unsolvable problems, notably the problem
>of characters that are confusingly similar in appearance (often
>known as the "phishing" problem) that are not part of the scope
>of the WG.
>
>While it is referenced from the original IDNA package, the
>original Stringprep specification, RFC 3454, is not formally
>part of the IDNA package and will not be altered by this work.
The word 'IDNA Package' appears for the first time here.
I suggest introducing the term IDNA2003 at the start, where
the RFCs are listed up, and then use that familiar term here.
>The work will update or obsolete RFC 3490. It is not expected
>to continue to use Nameprep (RFC 3491). Nameprep is used by
>other specifications; determining how (or whether) to update
>those specifications and, consequently, the long-term status of
>Nameprep, are not part of this effort. The method for
>ASCII-compatible ("ACE") encoding of IDNs, "Punycode" (RFC
>3492) will not be revised by this WG.
Given this is mentioned again below, I think the last sentence
above can be removed.
>Subject to the more general constraints described above, the WG
>is permitted to consider changes that are not strictly
>backwards-compatible. For any such change that is recommended, it
>is expected to document the reasons for the change, the
>characters affected, and possible transition strategies.
>
>The assumptions outlined above are considered critical to the
>WG constituted this charter. The WG will stop, close, and
>recommend that a new charter be generated if it concludes that
>any of the following are necessary to meet its goals:
>
> (i) A change to the "punycode" algorithm or to the ACE
> approach to encoding names in the DNS.
>
> (ii) A change to the ACE prefix from "xn--"
>
> (iii) A change to the basic approach taken in the design
> team documents (Namely: a protocol that is independent of Unicode
> versions, that removes any character mapping in the
> protocol, and that has improvements to the bidi algorithm).
>
>Goals and milestones:
>
>Apr 08: WG formation
>May 08: Decision on form and structure of the WG document set
>Sep 08: WG Last Call on WG document set
>Nov 08: IETF Last Call on WG document set
>
>
>Documents:
>
>http://tools.ietf.org/html/draft-klensin-idnabis-issues
>http://tools.ietf.org/html/draft-klensin-idnabis-protocol
>http://tools.ietf.org/html/draft-faltstrom-idnabis-tables
>http://tools.ietf.org/html/draft-alvestrand-idna-bidi
Hope this helps. Regards, Martin.
#-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst at it.aoyama.ac.jp
More information about the Idna-update
mailing list