Re: [idn] iDNS re-chartering proposal, take 2

[Martin Duerst <duerst@w3.org>]

Just a few comments:

At 12:09 01/10/27 -0700, Dave Crocker wrote:
>Folks,
>
>Perhaps the most important goals in re-chartering this effort are to:
>
>         1.  Narrow the scope of work
>
>         2.  Specify deliverables very precisely
>
>         3.  Specify dates for deliverable that are very near-term.
>
>This should make it easier to distinguish what is in-scope and what is 
>not, as well as help the group focus on tasks that must be done soon.
>
>Note the reference to near-term.  This eliminates discussion about work to 
>be done in the future.  The issue is not that the work is not important, 
>but that discussion about future work  gets in the way of discussion about 
>current work, for producing something useful NOW.  When the working group 
>has satisfied near-term requirements, it will be free to consider 
>re-chartering for longer-term goals.
>
>With these factors in mind, I offer some modifications to the proposed new 
>charter.  The modifications are intended to:
>
>1.  Make the opening paragraph comprehensive, so that it is useful by 
>itself.  The first paragraph of a working group charter is distributed as 
>an "abstract" of the charter.  That means it should summarize the problem, 
>summarize the nature of the work to be done, summarize the technical 
>approach, and possibly summarize the resulting benefit from the work.
>
>2.  Focus on the production of a single technical specification to be 
>offered as a standard.  Hence the working group is no longer exploring, 
>researching or otherwise having broad discussions.
>
>3.  Ensure the quickest possible milestones for delivering a specification 
>that is immediately useful and will produce DNS changes that also are 
>immediately useful.  This will reflect the past two years of discussion.
>
>4.  Modify terminology a little bit, to reflect our better understanding 
>of the task that is to be done.  This should help people avoid discussing 
>issues that are not really helpful to the working group task.  It also 
>should help people understand that we are specifying character codes, 
>rather than anything as broad and amorphous as "access".
>
>
>So, here is the proposed, modified re-chartering text:
>
>
>Domain Names are Internet identifiers. They are used both for machine and 
>human processing, so the form of a Domain Name must be convenient for both 
>processing venues.  The current set of valid Domain Name characters is 
>limited to common Internet ASCII, which is inadequate for the broad range 
>of Internet human users.  This working group will produce a standards-track

Internet human users -> human Internet users


>specification for extending the range of characters that can be used in 
>Domain Names, by humans.  The enhancement will be designed to minimize 
>changes to existing Domain Name software and operations.  In particular, 
>changes to the DNS infrastructure of storage and exchange mechanisms will 
>be avoided.
>
>The technical approach for the current specification effort shall be to 
>permit use of international character sets, as recommended by the IAB, and

character sets -> characters
(or even better, international character sets -> non-ASCII characters)

Character set is a very ambiguous term, and in some of its meanings,
may give the wrong impression.


>then encode the characters, to permit their transmission and storage 
>within existing DNS mechanisms.  Hence this enhancement to the DNS 
>involves only end-user software.  In particular software that needs to be 
>changed is restricted to:  Human DNS input and output modules.

Please be careful here. Assume somebody has software that allows to
find all domain names with the string 'FOO' in it, where 'FOO' isn't
necessarily a full label. Now assume this software should work with
idns, too. Can we do that by just changing the input module
(e.g. we just encoded 'FOO' as ace? We can't.

Also, assume that a protocol specifies that domain names be in
UTF-8 (or something else), or that a program decides to use
Unicode internally. Then the term 'Human DNS input and output'
seems to be rather inappropriate.


>No other modules will need to be changed.
>
>Language information is not encoded in these identifiers.  That is, 
>"names" from different languages are defined in a single namespace.
>
>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 will identify consequences to the current deployed DNS 
>infrastructure, the protocols and the applications as well as transition 
>scenarios, where applicable.
>
>The working group will actively ensure communication with interested 
>groups who are studying the same, or related, topics.

This is a good point. Has this been done up to now (actively)?
Or is this new? What would these groups be?


>Working Group action items are:
>
>1. An Informational RFC documenting considerations for supporting 
>International character sets in domain names. The document will discuss 
>factors used to develop solutions to this problem, taking localized (e.g. 
>writing order) and related operational issues into consideration.
>
>    [[[  Question:  Why must we discuss writing order at all?  /Dave   ]]]

The problem Eric has mentioned is one problem, but actually the easier
one. The sequence of labels is something anyone can get used to.

The more serious problem is bidirectionality (Arabic, Hebrew).
For some more details of the problem and one possible solution, see e.g.
http://www.ietf.org/internet-drafts/draft-duerst-iri-bidi-00.txt.

After an informal 'bof' in Sept. at the Unicode Conference in San
Jose, Paul also set up a mailing list for discussion.

It's quite important that we solve this problem here, because:
- Many people who understand (part of) this problem have a serious
   hunch that there is some connection between this and nameprep.
- If we don't clearly say how this works, we will get various
   different solutions, with a complete chaos (i.e. no defined
   mapping) between what people see/write down and what is stored.


>2. A standards track specification for internationalized domain name 
>strings, to be used by humans, including specifying any transition issues.
>
>
>The Action Item(s) for the Working Group are:

What's the difference between

"Working Group action items are:" and
"The Action Item(s) for the Working Group are:"


>1.  An Informational RFC specifying the requirements for providing 
>International character sets in domain names. The document should provide 
>guidance for developing solutions to this problem, taking localized (e.g. 
>writing order) and related operational issues into consideration.
>
>2.  A standard track specification on permitting international characters 
>in domain names, including specifying any transition issues.
>
>3.  A standard track specification on an ASCII Compatible Encoding (ACE), 
>to be used in the standard track specification on permitting international 
>characters in domain names.
>
>4.  A standard track specification on normalization of domain name 
>identifiers for the purpose of string comparisons. This document may 
>includes case folding, map outs, and prohibited characters.

may includes -> may include



>Goal & Milestone:
>
>Nov 2001        Draft of architecture relating input methods, namepreps
>                 and zonefiles
>Nov 2001        Draft of ACE specification
>Nov 2001        Draft of DNS identifier normalization specification
>Nov 2001        Draft of DNS character set enhancement specification

'Character set enhancement' is a very weird term. This is the
IDNA spec, isn't it? Using the word 'architecture' in a generic
name would be better, I guess.


>Jan 2002        Architecture draft submitted for informational publication
>Jan 2002        ACE specification submitted for standardization
>Jan 2002        DNS identifier normalization specification submitted
>                 for standardization
>Jan 2002        DNS Character set enhancement specification submitted
>                 for standardization

Regards,  Martin.