Proposed Charter for the IDNAbis Working Group

[Martin Duerst]

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