WG Review: Internationalized Domain Name (idn)

[Mark Davis]

The text looks good. I'd suggest just one change, to the following:

> - Revise bi-directional algorithms to produce a deterministic
> answer whether a label is allowed or not
> - Determine whether bi-directional algorithm should allow
> additional mnemonics labels

The above wording is a bit misleading, since it suggests that IDNA2003
wasn't deterministic in what it specified about BIDI labels. IDNA2003 was
deterministic in what it specified; it just was not optimal in that it
didn't prevent visual ambiguity due to ordering. Also, the Unicode BIDI
algorithm itself is not being modified; just the restrictions on label
contents based on that algorithm. And the comment about mnemonics is a bit
mysterious to me.

So my suggestion would be to replace the above two bullets with:

- Revise the restrictions on labels to provide for better visual
disambiguation in the cases where characters would be subject to
bidirectional reordering.

Mark

On Tue, Feb 26, 2008 at 9:57 AM, The IESG <iesg at ietf.org> wrote:

> A new IETF working group has been proposed in the Applications Area.  The
> IESG has not made any determination as yet.  The following draft charter
> was submitted, and is provided for informational purposes only.  Please
> send your comments to the IESG mailing list (iesg at ietf.org) by March 4,
> 2008.
>
> Internationalized Domain Name (idn)
> =============================
> Last modified: 2008-02-18
>
> Current Status: Proposed Working Group
>
> Chair(s):
>
> TBD
>
> 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
> RFC 3454, RFC3490, RFC3491 and RFC3492 in 2002. These documents
> were tied to Unicode version 3.2 and 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. Some of them are
> described in an IAB review (RFC4690), which also provides a good
> introduction to the subject matter.
>
> IDNA is currently tied to an obsolete version of Unicode. 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.
>
> Additional goals:
>
> - Separate requirements for valid IDNs at registration time,
> vs. at resolution time
> - Revise bi-directional algorithms to produce a deterministic
> answer whether a label is allowed or not
> - Determine whether bi-directional algorithm should allow
> additional mnemonics labels
> - Permit effective use of some scripts that were
> inadvertently excluded by the original protocols.
>
> The constraints of the original IDN WG still apply, 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. 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 WG will work to ensure practical stability of the validity
> algorithms for IDNs (whether based on character properties or
> inclusion/exclusion lists).
>
> The work is currently organized into four deliverables, all
> Standards Track. The WG will verify that it has consensus
> to adopt the proposed documents as a starting point. The
> Overview document with explanation and rationale is intended
> for Standards Track status because it has definitions and
> other normative text required by the other documents. The
> protocol specification explains how to map non-ASCII
> characters into ASCII DNS labels. It relies normatively on
> two other documents that are separate for readability: the
> bidirectional algorithm specification and the character
> validity tables. The validity of characters in IDNs is
> almost exclusively based on Unicode properties but is
> organized as tables and categories for readability.
>
> Goals and milestones:
>
> Mar 08: WG Last Call for Overview/Rationale document
> Apr 08: Revised Overview/Rationale document
> Apr 08: WG Last Call for Protocol, Bidi and Tables documents
> May 08: Revised Protocol, Bidi and Tables documents
> May 08: Review Overview document again if needed
> Jul 08: Request for publication for all documents
>
> 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
>
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce at ietf.org
> http://www.ietf.org/mailman/listinfo/ietf-announce
>



-- 
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20080227/30eebf3b/attachment-0001.html