Re: [idn] Update Charter revision 2

Martin Duerst <duerst@w3.org> Wed, 24 October 2001 04:21 UTC

Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00285 for <idn-archive@lists.ietf.org>; Wed, 24 Oct 2001 00:21:09 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.33 #1) id 15wFLH-000AIh-00 for idn-data@psg.com; Tue, 23 Oct 2001 21:08:35 -0700
Received: from toro.w3.mag.keio.ac.jp ([133.27.228.201]) by psg.com with esmtp (Exim 3.33 #1) id 15wFLG-000AIb-00 for idn@ops.ietf.org; Tue, 23 Oct 2001 21:08:34 -0700
Received: from enoshima (toro.w3.mag.keio.ac.jp [133.27.228.201]) by toro.w3.mag.keio.ac.jp (Postfix) with ESMTP id 312187F414; Wed, 24 Oct 2001 13:08:04 +0900 (JST)
Message-Id: <4.2.0.58.J.20011024123116.06271690@localhost>
X-Sender: duerst@localhost
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J
Date: Wed, 24 Oct 2001 12:32:49 +0900
To: James Seng/Personal <jseng@pobox.org.sg>, idn@ops.ietf.org
From: Martin Duerst <duerst@w3.org>
Subject: Re: [idn] Update Charter revision 2
In-Reply-To: <030701c15c37$e463d8b0$1401000a@jamessonyvaio>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Sender: owner-idn@ops.ietf.org
Precedence: bulk

This looked good to me, except that it would seem more
natural to have the architecture doc out before the specs
nailing down the details, and that i'm not sure how
stringprep fits into this picture (it's not listed below,
but we depend on it).

Regards,   Martin.

At 10:59 01/10/24 +0800, James Seng/Personal wrote:
>Comments please.
>
>-James Seng
>
>--- CUT HERE ---
>Description of Working Group:
>
>The goal of the group is to specify the requirements for
>internationalized access to domain names and to specify a standards
>track protocol based on the requirements.
>
>Domain names and host names are forms of identifier. Language
>information is not encoded in these identifiers; that is, "names" from
>different languages are defined in a single namespace.
>
>The scope of the group is to investigate the possible means of doing
>this and what methods are feasible given the technical impact they will
>have on the use of such names by humans as well as application programs,
>as well as the impact on other users and administrators of the domain
>name system.
>
>A fundamental requirement in this work is to not disturb the current use
>and operation of the domain name system, and for the DNS to continue to
>allow any system anywhere to resolve any domain name.
>
>The WG work may modify the DNS protocol and other related work
>undertaken by the DNSEXT WG. But such changes must be co-ordinated with
>the DNSEXT WG.
>
>The WG will reference work from ISO/IEC, the Unicode Consortium as much
>as possible. The consideration are the policy and principle adopted by
>the I18N group on the stability of published codepoints and future
>addition
>of codepoints. The discussion of new codepoints, codepoints properties
>and
>mappings between codepoints are out-of-scope for the working group and
>should be done in other relevant expert group.
>
>The group will not address the question of what, if any, body should
>administer or control usage of names that use this functionality.
>
>The group must identify consequences to the current deployed DNS
>infrastructure, the protocols and the applications as well as transition
>scenarios, where applicable.
>
>The WG will actively ensure good communication with interested groups
>who are studying the problem of internationalized access to domain
>names.
>
>The Action Item(s) for the Working Group are
>
>1. An Informational RFC specifying the requirements for providing
>    Internationalized access to domain names. The document should
>    provide guidance for development solutions to this problem,
>    taking localized (e.g. writing order) and related operational
>    issues into consideration.
>
>2. A standard track specification on access to internationalized
>    domain names including specifying any transition issues.
>
>3. A standard track specification on an ASCII Compatible Encoding
>    (ACE). This may or may not be used in the standard track
>    specification on access to internationalized domain names.
>
>4. A standard track specification on normalization of identifiers
>    for the purpuse of comparisons. This document may includes case
>    folding, map outs, and prohibited characters.
>
>Goal & Milestone:
>
>Nov 2001    Nameprep RFC wg last call
>Dec 2001    Nameprep RFC send to IESG for advancement
>Nov 2001    First draft of architecture draft specifying the
>             relationship between input methods, namepreps and zonefile
>Dec 2001    Protocol RFC wg last call
>Dec 2001    Second draft of architecture draft
>Jan 2002    Protocol RFC send to IESG for advancement
>Feb 2002    Architecture draft last call
>Mar 2002    Architecture draft send to IESG for advancement
>