- From: Gavin Nicol <gtn@ebt.com>
- Date: Thu, 3 Aug 1995 14:20:43 -0400
- To: ietf-lists@proper.com
- Cc: html-wg@oclc.org, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>I disagree. The person in charge of www.jacme.co.jp is in charge of >creating the object-name part of the URLs. They can make up unambiguous >names. End users don't make up URLs, or if they do, they shouldn't assume >anything about how the server will respond to their requests. This is not always true. The [EUC] part could specify one of a myriad different coded character sets and encodings, with the following octect string being different for each as well. I think it unreasonable to expect the administrator to maintain a database of all possible alias. In addition, I really do think there needs to be a standard way of specifying this kind of data. An example of *why* is spiders: they walk all over the net indexing pages, and some of online indexes display URL's as part of the textual data. Without a standard way of specifying the coded character set and encoding, the URL's would always have to be displayed in thier raw form. >However, it should not be a change to the current URL RFC at this >very late date. Feel free to create a seperate draft that describes >this as an optional naming convention. Well, I can sympathise with this position. The change I recommend is backward compatible, and will be part of the upcoming I18N RFC.
Received on Thursday, 3 August 1995 11:22:45 UTC