Re: [idn] RE: An idn protocolfor consideration in making the requirements

[ned.freed@innosoft.com]

> I will cheerfully be open-minded to any proposal that
> "works" *both* in Ned's sense ("no protocol mishaps"?)
> *and* my sense:

> 	User sees only (ever): human selected fallback
> 	domain names or internationalised domain names in
> 	a commonly accepted and globally viable plain text
> 	encoding (which are: UTF-8, UTF-16). Plus, of
> 	course, fulfillment of Ned's sense of "works" too.

Suppose for such a moment that we develop a proposal defining such a solution
which is viable and deals with all the issues John Klensin raised, plus many
others that haven't even been mentioned yet. And further suppose that
deployment of new DNS software is a requirement of that solution, of course
along with fallback facilities and such for various application services.

This last point means that you cannot simply upgrade your local software to the
new crop of applications that support this stuff and start using these names
willy-nilly. You have to wait for infrastructure upgrades to the DNS that are
in some, and perhaps even many, cases beyond your control.

Now suppose we ask the DNS operations folks how long it will reasonably take
for the necessary software to deploy to any significant degree, keeping in mind
that we're dealing with a critical infrastructure component provided by folks
who have a lot on their plate besides internationalization. I'm not a DNS
operations person, but I would not be totally amazed if the answer that comes
back is most conveniently expressed in units of decades. 

So the bottom line is how do you feel about a solution that is purer and nicer
and has some real attractiveness long term, but which you won't see significant
benefit from for many, many years? What is your choice then?

Now, I only said "suppose" here. But I don't think it is totally unrealistic to
think that such a downside will manifest from the sort of scheme you're
insisting on.

And this is why I think it is critical to make and keep a distinction between
issues we *must* address (like making sure we have a viable transition stragegy
for applications and which at least minimizes leakage) and issues we'd sure
*like* to address (like not ending up with a bunch of encoded goo in the DNS
that we have to tolerate forever).

> Maybe that is a 'strong' statement, but without such a
> goal we may very likely get a 'solution' that will lead
> to problems that a) there is no end to, and b) some think
> aren't problems no matter how problematic they are.

Having it as a goal is fine. But having it as a requirement all proposals
must meet is not.

> The no-too-positive experience with using application
> specific encodings that are reencodings into ASCII,
> i.e., QP and BASE64 for text, must be taken into account.

Fine, as long as the totally negative experience with "just-send-8" that
preceeded the development of QP and base64 is also taken into account. (I have
a very long memory.)

> I'm not sure if your last paragraph refers to me
> walking away (who cares ;-) or me scaring others off.
> But neither of those was my intent.  My intent is to
> try to speak for the end users (as best I can) and to
> promote the generation of solutions that end users will
> not consider to be strange or problematic.

I also speak for end users -- users who have shown that they are able to
tolerate an occasional glitch in decoding of noncritical elements but who won't
accept total untraceable data loss, and who may or may not be willing to wait
for a very long time for the perfect solution to emerge.

				Ned