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

From: Dave Crocker <[email-masked]>
Date: Sat, 27 Oct 2001 12:09:23 -0700

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 
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 
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.  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.

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   ]]]

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:

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.

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
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

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sat, 27 Oct 2001 17:10:12 -0400

Dave,

...
>    [[[  Question:  Why must we discuss writing order at all?  /Dave   ]]]
...

Because of the Colourd Books (JANET) experience, leakage, and a strong
preference for reverse ordering by large numbers of users for whom the
wee.small.mid.big.top identifier odering is as counter-intuitive as 
identifiers-in-ASCII.

Eric

---

From: Dave Crocker <[email-masked]>
Date: Sat, 27 Oct 2001 15:55:43 -0700

>wee.small.mid.big.top identifier odering is as counter-intuitive as

Hmmm.  Let me try to understand this, by starting from a really simple, 
really naive perspective:

         The registrant specifies a Domain Name that is series of 
characters. The characters are in whatever order the registrant chooses to 
put them.

         Translating them into ACE preserves the order.  The registrar and 
registry are preserve the order.  All other DNS processing modules preserve 
that order.

         The final module translates out of ACE, still preserving the order.

So it seems to me that the only job for the DNS international character set 
specifications is to make sure that the end-to-end behavior of the system 
is to preserve whatever ordering the registrant provided.

And now you, and others, can explain to me what it is that I am missing.

Encouragingly yours,

d/

----------

---

From: Martin Duerst <[email-masked]>
Date: Sun, 28 Oct 2001 11:16:39 +0900

Just a few comments:

At 12:09 01/10/27 -0700, Dave Crocker wrote:
>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.
>
>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 

Internet human users -> human Internet users

>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 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?

>    [[[  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.

>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:"

>includes case folding, map outs, and prohibited characters.

may includes -> may include

>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        DNS Character set enhancement specification submitted

Regards,  Martin.

---

From: Dave Crocker <[email-masked]>
Date: Sat, 27 Oct 2001 20:28:32 -0700

>(e.g. we just encoded 'FOO' as ace? We can't.

actually, I think we can.  the software doing the searching might not be a 
human, but it's place in the overall DNS system is the same place as human 
users.  That is, in the user agent, not the DNS infrastructure.

>Unicode internally.

I think you are confusing what goes on inside a random user program with 
what goes on inside the DNS.

>one. The sequence of labels is something anyone can get used to.

If the DNS software CREATED strings, then making sure characters were in 
the correct order would make sense.

However the strings are created outside of DNS.  The only thing the DNS 
system must do is PRESERVE that order.

>"The Action Item(s) for the Working Group are:"

Fewer characters...

>name would be better, I guess.

Glad to use other language.  Please suggest a term.  I simply used what was 
already in the previous draft.

d/

----------

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sun, 28 Oct 2001 04:28:19 -0500

Martin,

Thanks for catching bidi. I'm sorry I didn't notice you'd made a change from
your draft with Larry. We should discuss your #3 (numbers), using a different
subject line.

Eric

---

From: Martin Duerst <[email-masked]>
Date: Sun, 28 Oct 2001 14:42:32 +0900

At 20:28 01/10/27 -0700, Dave Crocker wrote:
>>>involves only end-user software.  In particular software that needs to 
>>>be changed is restricted to:  Human DNS input and output modules.
>>

User agent is a wide term, and may be okay. Human input/output
is quite different, and inappropriate. As a human being I don't
like to be thrown into the same pot as some software. So can
we please change that to 'DNS input and output modules'?

>what goes on inside the DNS.

No, I don't. I just wanted to make sure that the charter doesn't
give the impression that all software has to use ACE throughout
because conversion happens on 'Human input/output'.

>system must do is PRESERVE that order.

DNS names appear on paper and displays. If we are not sure that
the same internal string of characters will lead to the same display
and vice versa, then all our work on idn will just lead to a lot of
confusion. It may look as if just extending the set of characters
won't change anything here, but at least for Arabic and Hebrew,
that's not the case.

>>"The Action Item(s) for the Working Group are:"

I was asking something different, sorry. Why are there
two subtitles in your charter listing action items for
the WG, one of them with two action items, and one with
four?

>Glad to use other language.  Please suggest a term.  I simply used what 
>was already in the previous draft.

Why not just call it 'DNS internationalization architecture specification'?

Regards,   Martin.

---

From: "Eric A. Hall" <[email-masked]>
Date: Sun, 28 Oct 2001 16:20:34 -0600

>          3.  Specify dates for deliverable that are very near-term.

These are fine goals, but the specific objective items you cite are not
satisfactory to the weight of the task at hand. Instead, they raise more
artificial barriers.

> researching or otherwise having broad discussions.

Some of the proposals are at odds with such an objective, and so the
adoption of this objective would only serve to narrow the work items. For
example, UDNS requires a coordinated release for at least two purposes: so
that name lengths can be synchronized, and so that delegation entities can
coordinate delegations they make as UTF-8 and ACE encoded representations
of the same UCS string. Adopting your work items would mean that those
considerations would not be incorporated (unless you added them to ACE
while I wasn't looking), and would therefore result in alternatives being
non-conformant with the WG output.

Additional beauracracy does not result in better science. Let's let the
technology compete on its own merits, okay?

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Dave Crocker <[email-masked]>
Date: Sun, 28 Oct 2001 15:05:10 -0800

At 04:20 PM 10/28/2001 -0600, Eric A. Hall wrote:
>  Instead, they raise more artificial barriers.

The purpose of a charter is to make clear what IS to be done and what IS 
NOT to be done.  As such, raising barriers is one of the requirements for a 
good charter, if the working group is ever to be productive.

Let us be clear about the term "productive".  Discussion, debate and 
learning are all interesting and worthy activities.  However, none of them 
is the goal of an IETF working group.

The goal of an IETF working group is to produce a specification that gets 
used.  Hence it must solve a real problem, solve it in a manner that others 
find useful, and solve it in a timely manner.

Protracted debate ensures that none of these criteria is satisfied.

For example, this group has gone at least one extra year longer than it 
should have, given the urgency of the problem it is trying to solve.  As 
such, there is some potential that independent, proprietary (ie, closed) 
solutions will render the IETF work irrelevant.

>Some of the proposals are at odds with such an objective

How very strange.  Some of the proposals do not want a single technical 
specification, or they do not want to stop researching?

In any event, that is the problem.  Failing to converge on a single 
specification often kills working group utility.

>, and so the
>adoption of this objective would only serve to narrow the work items.

Excellent!  That is exactly what the proposed working is intended to 
accomplish.  Unless the work items are narrowed, no work gets done.

>For example, UDNS requires a coordinated release for at least two 
>purposes: so that name lengths can be synchronized, and so that delegation 
>entities can
>of the same UCS string.

uDNS a) is not a complete specification, and b) imposes operational 
requirements that are not viable in the existing DNS infrastructure.

It also does not have much practical support.

>technology compete on its own merits, okay?

We are doing engineering, not science.  Perhaps that disparity of view is 
the source of some difficulties among participants.

d/

----------

---

From: Dave Crocker <[email-masked]>
Date: Sun, 28 Oct 2001 15:08:41 -0800

At 02:42 PM 10/28/2001 +0900, Martin Duerst wrote:
>>   the software doing the searching might not be a human, but it's place 
>> in the overall DNS system is the same place as human users.  That is, in 
>> the user agent, not the DNS infrastructure.
>

I am not thrilled with the term "human i/o" either.  The difficulty is in 
using a term that clearly marks the DNS end-points (including DNS server 
administration, since that is where names are first entered.)

In the world of email and perhaps directories, the term "user agent" is 
pretty clear.  In the world of the DNS, it is not.

"DNS input/output modules" could as easily refer to communication between 
DNS servers, hence it is not sufficiently specific.

In case it is not obvious, I am at a bit of a loss, so the best I can do is 
suggest that we keep seeking suggestions for a term that will 
work.  (Frankly I would be delighted if we could find a way to re-apply the 
UA/MTA model, the way the x.500 directory people did.)

And that prompts me to ask whether simply saying:

         DNS Client

would satisfy people???

>I just wanted to make sure that the charter doesn't

Does "DNS client" satisfy this concern?

>won't change anything here, but at least for Arabic and Hebrew,

I fear that my point is being missed:

1.  The registrant decides what order to write the characters.
2.  That is how they are put into the DNS and returned from the DNS and 
displayed by DNS client software.

As long as the system preserves whatever order the registrant specified, 
then how does the DNS have to know whether it is arabic, hebrew, kanji, or 
greek?

In other words, I believe the DNS is, and must be, entirely opaque with 
respect to character ordering.

With respect to strings on paper or displays, again, the point is that it 
must be shown in whatever order the registrant specified, it.

>>>What's the difference between "Working Group action items are:" and "The 
>>>Action Item(s) for the Working Group are:"
>...
>I was asking something different, sorry. Why are there two subtitles in 
>your charter listing action items for the WG, one of them with two action 
>items, and one with four?

My turn to apologize.  I had not noticed that there were two sections with 
essentially the same labels.  Yes they should be changed, possibly 
eliminating one altogether.  I'll do something about that for the next 
version of the text.

>Why not just call it 'DNS internationalization architecture specification'?

Your suggestion is for a term that is clean and impressive.  However I 
believe it also is too broad.

There are, perhaps, other issues in internationalization of the DNS that we 
are NOT working on.  Hence we need a term that excludes, as well as includes.

d/
----------

---

From: "Eric A. Hall" <[email-masked]>
Date: Sun, 28 Oct 2001 17:18:41 -0600

Dave Crocker wrote:

> We are doing engineering, not science.  Perhaps that disparity of view
> is the source of some difficulties among participants.

It is certainly clear that scientific analysis is being sacrificed in
favor of agenda manipulation and beauracracy, yes.

> requirements that are not viable in the existing DNS infrastructure.

IPv6 is different from IPv4, OSPF was different from RIP, IMAP is
different from POP, why is anybody surprised that a UTF-8 DNS which
provides a top-to-bottom internationalized DNS is going to be different
from a hostname-restricted IDNA?

Of course, last time this was brought up for discussion, the beauracracy
called technical analysis off-topic. No surprise you want to formalize
such a position through agenda reconstruction. Color me unimpressed.

> specification, or they do not want to stop researching?

What's so wrong with multiple complementary specifications? Why are you
committed to a single specification which only serves a single objective
of legacy compatibility and which does so at the expense of every protocol
and application yet to be written?

---

From: Dave Crocker <[email-masked]>
Date: Sun, 28 Oct 2001 15:32:24 -0800

>favor of agenda manipulation and beauracracy, yes.

Ahh.  I see.  You have a complaint about working group process.

The procedures for redressing such grievances are well documented.  Please 
feel free to pursue them.  Note that a small amount of complaining on the 
working group mailing list is a legitimate part of that process, as a way 
of assessing support for your complaint.  However I suspect that you are 
already long beyond that part.

>from a hostname-restricted IDNA?

No one is surprised that "UTF-8 DNS", whatever that means, might be 
different from the existing DNS.  However surprise or not is irrelevant to 
the current discussion.

The key point is that, after two years of debate, it is time to declare 
that changes to the core DNS protocols, including changes to official 
character representation by that core, is no longer the technical path 
being pursued for near-term support of internationalized characters.  The 
approach to be taken is  to have end-system encapsulation, in the style of ACE.

>What's so wrong with multiple complementary specifications?

What is wrong with that approach is that it does not work.

Please review the last 11 years of IETF history, in particular the results 
of its trying to support multiple "complementary" (but actually competing) 
specifications, versus the results of choosing a single specification.  By 
contrast, review the stellar history of the equivalent OSI protocols, since 
they very much attempted to provide support of multiple alternatives, as 
you desire.

>Why are you committed to a single specification which only serves a single 
>objective of legacy compatibility and which does so at the expense of 
>every protocol and application yet to be written?

It serves both legacy compatibility AND the primary objective of 
internationalized characters.

Your assessment that it does so at some sort of unspecified cost to some 
set of unspecified protocols, that will be created at some unspecified 
times and for some unspecified set of functions, is quite seriously 
irrelevant to the current  requirements.

d/

----------

---

From: "Eric A. Hall" <[email-masked]>
Date: Sun, 28 Oct 2001 17:49:13 -0600

> Ahh.  I see.  You have a complaint about working group process.

No, I have an issue with agenda railroading. I feel no need to run for
mommy's skirts when things don't go my way, however.

> being pursued for near-term support of internationalized characters.

Perhaps this can be represented through some measure other than an
unsolicited agenda reconstruction.

> Please review the last 11 years of IETF history, in particular the
> results of its trying to support multiple "complementary" (but actually
> competing) specifications, versus the results of choosing a single
> specification.

SMTP, IMAP, NNTP are complementary. RIP, OSPF and BGP work well together
when needed. HTTP and FTP aren't burning each other down. Golly, it almost
seems like complementary is the norm.

> irrelevant to the current  requirements.

Protocols which comply with BCP18 will use UTF-8 for all protocol data
_except_ domain names, where they will require ACE. Going with ACE-only
directly equates to two mandatory encodings. This is an incredibly high
cost to lay on the Internet for the sole purpose of backwards
compatibility, particularly given the fact that there is no reason to
limit the Internet to just one choice. Other costs were itemized in the
last thread, but we can go through it again if you are up to completing
the discussion.

---

From: Dave Crocker <[email-masked]>
Date: Sun, 28 Oct 2001 19:27:22 -0800

>mommy's skirts when things don't go my way, however.

Perhaps you see something constructive in plaintive and inflammatory 
language on an engineering discussion list.  However it is not, especially 
absent any specific, constructive engineering content.

>seems like complementary is the norm.

Hmmm.  Yes.  Whereas ACE and Raw UTF-8 DNS are most certainly NOT 
complementary.  They are competitive.  They both try to solve the same 
problem, albeit differently.

>_except_ domain names, where they will require ACE.

Yes.  As with pretty much all existing protocols.  You need to distinguish 
between starting a new protocol, versus making changes to an existing one.

>  Going with ACE-only directly equates to two mandatory encodings. This is 
> an incredibly high
>cost to lay on the Internet

Thank you for that economic assessment.  As has been pointed out, however, 
it is not valid.

Please refer to the many earlier discussions about the relative cost -- or 
rather lack of it -- for ACE, particularly given the remarkably short 
string length for Domain Names.

However, it is nice to see that you agree that UTF-8 is also an 
encoding.  As such, the relative difference in cost, between an ACE and 
UTF-8, is negligible.

>  for the sole purpose of backwards compatibility

Indeed.  Very shallow thinking.  Why would anyone want to spend effort 
being compatible with an installed base of many millions of systems?  Can't 
imagine...

Unfortunately, Eric, this has now devolved into a tutorial on first 
principals of Internet protocol engineering.  It is unfortunate because an 
IETF working group is primarily for doing engineering, rather than 
instructing participants on the basics.  No doubt other venues are more 
appropriate for extended, basic pedagogy.

d/

----------

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 29 Oct 2001 03:17:08 -0600

Dave Crocker wrote:

> >  Going with ACE-only directly equates to two mandatory encodings.
> > This is an incredibly high cost to lay on the Internet
> 
> Thank you for that economic assessment.  As has been pointed out,
> however, it is not valid.

This is an outrageous assertion. It is not possible for two encodings to
be as efficient for the community as a single shared encoding. Using the
same encoding for DNS as is used for the protocol, the document formats,
the application I/O and the underlying operating system is the maximum
possible efficiency for the Internet commmunity as a whole. Conversely,
introducing an entirely separate mandatory encoding that has no tools, no
history, no experience and no users, is the antithesis of operational
efficiency. Claiming as much is unbelievable. I'm astounded by this.

> encoding.  As such, the relative difference in cost, between an ACE and

Negligible? Does the phrase "you are right, ACE costs more to implement"
stick in your throat or something?

I have said several times quite clearly that ACE is necessary as a
backwards compatibility mode for legacy applications. Where we part is
that you also believe that this second mandatory untested encoding that is
jammed into a transliteration layer for every existing and future
application is the ultimate in practical design. Just admit that it has
problems which can be addressed by an optimized form with a different set
of priorities. Come on, just say it!

---

From: Dave Crocker <[email-masked]>
Date: Mon, 29 Oct 2001 07:56:24 -0800

At 03:17 AM 10/29/2001 -0600, Eric A. Hall wrote:
>It is not possible for two encodings to
>be as efficient for the community as a single shared encoding.

Please attend to the difference between "incredibly high cost" and "not as 
efficient".  There is nothing contradictory in having the former be NOT 
true at the same time as the latter IS true.

One of the problems with your use of injudicious language is that it lacks 
precision.  A cost can exist, but be small.

>backwards compatibility mode for legacy applications.

Doing one specific piece of work, now, and deferring pursuit of an 
additional specification, for additional changes to the DNS, is standard 
IETF practise.

Since you are (correctly) declaring that we do need to do an ACE approach, 
there is no debate.

So let's move on.

d/

ps.  this line of debate is now closed, since I will not be responding 
further and it takes two to have a debate.

----------

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 29 Oct 2001 11:09:24 -0600

I knew you couldn't say it.

---

From: "Kenny Huang" <[email-masked]>
Date: Sat, 27 Oct 2001 20:55:59 +0800

I support UTF-8 based advanced DNS infrastructure, and support ACE 
since many people like to embrace legacy systems. DNS definitely 
is capable to take care more than one encoding scheme. The Internet
is composed by both legacy system and advanced system all the time.
Let the market decide whice one can survive.

Kenny Huang

---

From: Dave Crocker <[email-masked]>
Date: Mon, 29 Oct 2001 17:31:15 -0800

>I support UTF-8 based advanced DNS infrastructure, and support ACE

Kenny,

Thank you.  However support for a concept, such as "UTF-8", is not really a 
factor in this topic.  We are trying to make progress of concrete 
specifications.

The concerns now are:

         -  what is feasible for transition with the existing DNS installed 
base,

         -  what specifications are essentially complete, and

         -  what specifications have demonstrated good working group rough 
consensus.

d/

----------

---

From: "xiaodong lee" <[email-masked]>
Date: Tue, 30 Oct 2001 11:34:09 +0800

Dear Dave:
I think UTF-8 is a good solution too.  Though it is not a feasible plan yet now.
In the future, we should not alaways use complex alogrithm to support IDN.
Xiaodong Lee

---

From: David Hopwood <[email-masked]>
Date: Tue, 30 Oct 2001 05:36:57 +0000

-----BEGIN PGP SIGNED MESSAGE-----

Dave Crocker wrote:
> Eric A. Hall wrote:

You're assuming that a hybrid design will have completely independent
ACE and non-ACE components, and that deploying IDNA first will not cause
any problems for such a design. On the contrary, I think it is pretty
clear that this would cramp the possible design space of the non-ACE
component quite significantly.

- -- 
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip

---

From: Dave Crocker <[email-masked]>
Date: Mon, 29 Oct 2001 21:53:01 -0800

At 05:36 AM 10/30/2001 +0000, David Hopwood wrote:
>any problems for such a design.

Two years for this working group.  No complete specification for a "hybrid" 
solution.

12 years of IETF work.  Every effort at "hybrid" solutions, particularly 
when they are done simultaneously, has gone badly.

The math is compelling.

>On the contrary, I think it is pretty clear that this would cramp the 
>possible design space of the non-ACE component quite significantly.

By extension you are arguing that we should never make any decisions now, 
because we might close off choices for some future (or separate) work?

We appear to be stuck on a theme of confusing engineering with science.

d/

----------