- From: Martijn Koster <mak@victor.nexor.co.uk>
- Date: Tue, 15 Aug 1995 10:11:21 BST
- To: Keith Moore <moore@cs.utk.edu>
- Cc: Martin J Duerst <mduerst@ifi.unizh.ch>, uri@bunyip.com
In message <199508142110.RAA19670@wilma.cs.utk.edu>, Keith Moore writes: > But you completely left out the hardest problems to solve: > > 5) Everybody knows how to type the ASCII letters and digits (some > better than others), but otherwise, most people do not know how to > type characters that aren't used by some language that they're > familiar with. > > 6) URLs expressed in character sets besides ASCII are more vulnerable > to translation to other character sets (say ISO 8859/1 to ISO 636-XX) > which make the URL invalid. This translation WILL occur as the result > of URLs being mailed around, copied from one application to another, > or being printed on paper in one environment and typed in again in a > different environment that uses a different charset. Let me just add my support to that. IMHO these problems outweigh any possible advantages, even if you could convince browser writers to all implement something like Martin Duerst proposes. > But at least part of the "stale URL" problem is more subtle: we don't > give URLs names that are meaningful to outsiders as much as we give > them names that are meaningful to their maintainers. They reflect the > structure of the file systems on which they reside. These structures > (and therefore the URLs) get changed every so often as file servers > get re-organized, even though neither the files themselves, nor the > meanings of the files, changed. I was just about to make that point, in reply to the many "telephone- numbers rule!" messages. If as a server admin I had better mechanisms to associate meaningful-full non-filesystem-dependent (and with a bit of luck non-machine dependent) ASCII names to my resources a lot of my hassles would disappear. -- Martijn __________ Internet: m.koster@nexor.co.uk X-400: C=GB; A= ; P=Nexor; O=Nexor; S=koster; I=M WWW: http://web.nexor.co.uk/mak/mak.html
Received on Tuesday, 15 August 1995 05:13:08 UTC