Re: Globalizing URIs

Martin J Duerst (mduerst@ifi.unizh.ch)
Mon, 7 Aug 1995 19:04:25 +0200 (MET DST)


Message-Id: <9508071704.AA14694@mocha.bunyip.com>
Subject: Re: Globalizing URIs
To: uri@bunyip.com
Date: Mon, 7 Aug 1995 19:04:25 +0200 (MET DST)
In-Reply-To: <95Aug7.092137pdt.2762@golden.parc.xerox.com> from "Larry Masinter" at Aug 7, 95 09:21:32 am
From: Martin J Duerst <mduerst@ifi.unizh.ch>

>
>I've tried to move this discussion out of HTML-WG where it doesn't
>belong; I suggest, if you want to continue, we do this on URI-WG.

Can you give me the instructions to subscribe to uri-wg?

>In brief: I disagree with many of the assertions in your 'analysis',
>and don't think your 'proposal' actually solves any of the currently
>identified problems.

I am interested in the details.

>I don't disagree that there is a problem, but the problem is that the
>Internet protocols that URLs are used to represent (FTP et al)
>primarily use ASCII to represent file names, and the
>least-common-denominator of the transport mechanisms that we expect
>for URLs (printed newspaper articles, email) force us to a limited
>representation repertoire.

FTP seems very well to be capable to do other things. I can easily access
files with ISO-8859-1 names with Fetch (an ftp implementation for the
Mac), and they even get displayed correctly on the Mac if I set an option
(sort of the same state that we have for html now).
I agree that it might be difficult to become aware of such things when
one never has the need to use it.

>And it makes absolutely no sense to have
>alternative forms for URLs (e.g., one for ASCII-only environments and
>another for 'Japanese capable newspapers') because the result would be
>that we would no longer have >UNIFORM< resource locators.

There is a lot of non-uniformity already. There are relative addresses,
the whole "BASE" stuff, and so on. There is controlled nonuniformity
wherever needed.

>You may wish to complain that it is English-centric that the
>least-common-denominiator can represent English names better than
>Swedish ones, but that is not a problem that the IETF can solve.

If it is in the form %HH%HH, with no indication of what the octets are
meaning, then Swedish or Japanese don't get represented worse than
English, they don't get represented at all!
And if it is possible to solve the problem by adding some
"controlled nonuniformity", it can very well be a task for the IETF!
Also, as the past has shown, it is better to look ahead and identify
problems and work on their solutions than putting ones head in
the sand.

Regards,	Martin.