[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] Update Charter revision 2
I think the intention is this:
The discussion to do reordering is within scope. The table for
reordering in my view is a frequency analysis sorting and that maybe
within scope. If reordering creates any codepoints tables, then that
table is not.
The discussion of whether to do TC-SC equivalent matching, and if so,
where and how is also within scope. The tables of TC-SC is not.
-James Seng
----- Original Message -----
From: "Kenny Huang" <huangk@alum.sinica.edu>
To: "James Seng/Personal" <jseng@pobox.org.sg>; <idn@ops.ietf.org>
Sent: Wednesday, October 24, 2001 12:12 PM
Subject: RE: [idn] Update Charter revision 2
> If the goal of the working group is changed, then many of our
discussion will
> become useless. The original description of WG is attached.
> Are we exploring an evolving goal with evolving activities ? If that
is the case, then
> we can discuss re-ordering or TC/SC issues right here.
>
> Kenny Huang
> ---------------------------------------------------------------------
>
> 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.
>
> 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 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. An Informational RFC or RFC's documenting the various proposals and
Implementations of Internationalization (i18n) of Domain Names. The
document(s) should also provide a technical evaluation of the proposals
by the Working Group.
>
> 3. A standards track specification on access to internationalized
domain names including specifying any transition issues.
> ---------------------------------------------------------------------
>
> > -----Original Message-----
> > From: owner-idn@ops.ietf.org [mailto:owner-idn@ops.ietf.org]On
> > Behalf Of James Seng/Personal
> > Sent: Wednesday, October 24, 2001 10:59 AM
> > To: idn@ops.ietf.org
> > Subject: [idn] Update Charter revision 2
> >
> >
> > 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
> >
> >
>