Thanks to Stephane for pointing out the short fuse on this. I personally believe that a longer discussion and a cc to working groups like EAI and DNSEXT would have gotten more adequate review. Comments on the text below. At 9:57 AM -0800 2/26/08, The IESG 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@xxxxxxxx) 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@xxxxxxxxxxxx) >Chris Newman (Chris.Newman@xxxxxxx) > >Applications Area Advisor: > >Lisa Dusseault (ldusseault@xxxxxxxxxxxx) > >Mailing List: > >General Discussion: idna-update@xxxxxxxxxxxxx >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. > First, the two paragraphs above repeat each other a bit (naming specific versions in one and using characteristics in another). Second, this going pretty far into solution space, without a discussion of where the community agreed that this is the solution. Note that I am not saying I disagree with using Unicode properties here, but pointers to both the discussion docs and how Unicode is managing this property seem necessary to give this adequate review. It may be the input docs given below are the only discussion, but I hope that at least some pointers to Unicode consortium documents can be made here. There is no liaison information given; is the WG expected to maintain a liaison to the Unicode Consortium or is the IETF liaison expected to take on any new work as a result of this? (Obviously, there is a serious difference between work we can do based on already published or otherwise agreed specifications and work which requires coordination). >Additional goals: > >- Separate requirements for valid IDNs at registration time, >vs. at resolution time I think you need to define what "resolution time" means here. For better or worse, IDNs now appear in authority sections of URIs and not all of those are resolved at all. If what you mean is "Separate requirements for valid IDNs in registration contexts, in identifiers, and in relation to the wire format of DNS", then I think you need three categories. >- 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 Can you unpack this? >- 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). This is ambiguous. If this is meant to say that the WG can decide after starting its work that it must abandon the character properties design direction and go to inclusion/exclusion lists, then the statement above giving design direction needs to be changed. If this is meant to say "backwards compatibility with X" what X is is not clear here. >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: These milestones are either completely impractical or indicate strong confidence on the part of the IESG that very minimal work will be needed to transform the input documents into output. If it is the latter, why is a WG being formed at all, rather than using independent submission? Ted Hardie >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@xxxxxxxx >http://www.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf