Re: New Attempt to Close on IDNABIS Charter (v2)

["Mark Davis" <[e-mail]>]

Looks great.

On Mon, Mar 31, 2008 at 2:55 AM, Vint Cerf <[e-mail]> wrote:

> Folks,
> We have been discussing a lot about IDNs in the mailing list, a lot of the
> discussion is actually about specifics of the various draft documents
> intended to form the basis for the work of the proposed IDNABIS working
> group but a fair amount has been about the text of the charter.
>
> I have made what I hope are considered small revisions to the earlier
> proposed charter to try to take into account comments made by a number of
> you on the list.
>
> The revision which I am calling IDNABIS Charter (v2) is shown below. I
> imagine that there may still be comments about this version but I ask you to
> consider whether further amendment to the charter is as productive as
> getting to work on the documents themselves. Some concerns have been
> expressed about conditions for terminating the working group and
> re-chartering. I recognize but perhaps don't fully appreciate the hazards
> here, but have re-worded slightly these conditions. As the proposed working
> group chair, I am prepared to do the best I can to manage this process and
> to defend the work of the working group against re-chartering except under
> very significant deviation from the proposed framework in the referenced
> draft specifications.
>
> I don't quite know how to word the request but I would like to ask the AD,
> Lisa Dusseault, to submit this version to the IESG for approval no later
> than April 7, assuming that there are no further fundamental issues taken
> with the text. As to "fundamental issues", I suggest that Lisa and I be the
> arbiters of that for purposes of finalizing this charter for submission to
> the IESG.
>
> With thanks to all on the list who have participated in improving the
> charter,
>
> Vint Cerf
>
> ----------------------------------------------------------------------------------------------------
>
> IDNABIS Charter
>
>
>
> Chair(s):  Vinton G. Cerf
>
>
>
> Applications Area Directors:
>
>
>
> Lisa Dusseault ([e-mail])
>
> Chris Newman ([e-mail])
>
>
>
> Applications Area Advisor:
>
>
>
> Lisa Dusseault ([e-mail])
>
>
>
> Mailing List:
>
>
>
> General Discussion: [e-mail]
>
> 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 specified rules for
> the use of characters other than Latin A(a)-Z(z), digits 0-9 and the hyphen
> ("-") in domain names in RFC3490, RFC3491 and RFC3492 in 2002 (published in
> 2003 and often referenced collectively as "IDNA2003").
>
>
>
> 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 that significant improvements
> could be made in the protocol as presently specified.
>
>
>
> This WG is chartered to decouple 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 will be made to minimize these exceptions.
>
>
>
> 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 if 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.
>
>
>
>   - Permit use of some scripts that were inadvertently excluded by the
> original protocols.
>
>
>
>   - 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 client-based 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 specifications are initially organized as four documents: overview and
> rationale, protocol, table algorithm, and improvements 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 improvement of the IDNA
> specifications.
>
>
>
> 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 from IETF participants and from others
> including experts in the Unicode specifications and the use of scripts in
> languages.  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 respond with any needed changes and close in a
> short period of time.  If technical issues arise that indicate a
> fundamentally different approach must be taken from the one outlined above,
> it is anticipated that this working group would close, and a new one with an
> appropriate charter would be considered.
>
>
>
> This work is intended to specify an improved means to produce and use
> stable and unambiguous IDN identifiers.
>
>
>
> There are a variety of generally unsolvable problems, notably the problem
> of characters that are confusingly similar in appearance (often known as the
> "phishing" problem) that are not specifically part of the scope of the WG
> although some of the preliminary results of the design team suggest that the
> improvements contemplated in the specifications might mitigate some of the
> ways in which the current IDNA specifications can be abused for phishing
> purposes.
>
>
>
> While it is referenced from the original IDNA2003 package, the original
> Stringprep specification, RFC 3454, is not formally part of the IDNA package
> and will not be altered by this work.
>
>
>
> 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.
>
>
>
> 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 by 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: independence from Unicode version and elimination of character
> mapping in the protocol)
>
>
>
> 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
>
>
>
>
>
>
>
>
> _______________________________________________
> Idna-update mailing list
> [e-mail]
> http://www.alvestrand.no/mailman/listinfo/idna-update
>
>


-- 
Mark