Re: revised "generic syntax" internet draft

[Larry Masinter <[e-mail]>]

> Well, they print something like http://WEB.SANYO.CO.JP/FOODSHOP,
> where upper case is Japanese characters. 

Actually, this is unsatisfactory. What, exactly, would they
print? Would they print "http://" too? Will Japanese users
find that familiar and comfortable? I'm afraid "something
like" isn't useful as a specification.

>                     Of course, for this we have
> to assume that DNS works with characters beyond ASCII, but that's
> a separate problem that can be solved (see draft-duerst-dns-i18n-00.txt).

I fundamentally disagree with your idea that we can
promote the solution to a problem in pieces, where the
pieces, just by themselves, don't actually solve a
problem and, in fact, introduce interoperability
difficulty. So I'm unwilling to "assume" that other
pieces of the solution will be introduced in order
to make a whole.

> This is entered as such into a browser. We assume that those users
> that are the target of the Sanyoo depaato food shop page can read
> Japanes and have equipment that allows them to input Japanese.
> I won't go into the details of entering the corresponding characters,
> it's a process the Japanese computer users are very familliar with.

No, I'm sorry, this is completely inadequate. I'm vaguely familiar
with a number of of Japanese typing methods, and I believe
that you've not been specific enough. What happens with the
codes for "http://", for example, since these are not 'Japanese
characters'? What about unusual names which seem to be printed
with furigana in Japanese newspapers?

> The browser then would convert the Japanese characters into UTF-8
> and (add %HH encoding) and pass the URL to the resolver machinery,
> where the host part would be resolved with DNS, and then the machine
> at the corresponding IP number would be contacted with HTTP.


This discussion applies only to HTTP URLs, though. You're
proposing that the recommendation be put into place for
all existing URL schemes and new versions of them, too.

> That
> machine would of course have been set up so that the correct page
> is returned.

How, please, is the machine set up? What has to be done at
the server & system administration level? What's the transition
strategy for a server that wants to serve current clients
as well as these new browsers that can deal with the proposal
you're promoting?

> I hope this explanation is detailled enough. If you don't understand
> some part of it, please tell us.

As you see, it was inadequate for the purposes of
being a stand-in for 'running code': there are 
a number of unresolved design issues in your plan,
those design issues must be resolved before interoperable
implementations can be deployed, and I'm uncertain
as to whether the results, when taken in total,
actually solve the problem you set out to solve,
or even improve the situation significantly. And
given the difficult transition strategy and lack
of interoperability with currently deployed systems,
I doubt that a proposal will actually be adopted
unless that's so.

That's why "something like" is inadequate above.
If someone had running code, they could just run it
and show us what the results were.

Regards,

Larry
--
http://www.parc.xerox.com/masinter