Date: Thu, 24 Mar 1994 21:11:09 +0100
Message-Id: <9403242011.AA29139@dxmint.cern.ch>
From: hallam@alws.cern.ch
Subject: Re: how to make progress on the URL document
>1.) It is silly to impose the same syntax on all URLs, and there is no
> functional requirement for this. URLs have a functional requirement
> to specify an access method and an opaque parameter package for
> use by that access method. Period. There is general agreement
> on this.
It is absolutely vital that we do this. The more uniform URLs are the more
clients can get out of the protocols other than HTTP. Otherwise clients
with interesting and powerful features making use of particular features of
the URL design will only provide those functions for the compliant protocols
and not for the non compliant ones. Or worse clients will break.
Since a URL refers to a RESOURCE and not a file there is no reason why the
two systems cannot be combined. A search term on a resource specifies some
subset which is itself a resource. In the same way we can consider any
program to be a relationship between a set of initial and final values
(cf Z.). The fact that it is usefull to consider one abstraction in one
context does not preclude another being usefull in a separate context.
I did not read Tim's post as saying that the ? should be mandated for all
searches. Just that if an item is searchable it should always be an option
on how to search.
>> 2. In a URL, if a "/" does not imply a hierarchy, it
>> should be escaped. (This just affects gopher servers
>> whose files contain "/" but aren't directory
>> delimiters, like Mac servers). If you want the
>> string to be 100% opaque, just specify that
>> "/" is escaped.
>>
>
>Once again, a URL consists of an access method and an opaque parameter
>package for use by that access method. To know how to interpret the
>opaque parameter package, the client writer needs to read the
>section of the URL document that tells them how. If the access method
>says that there is no heirarchy to be assumed, and you ignore this, then
>you do so at your own risk.
This means that clients have to know about the URL in order to calculate
relative URLS.
In a well structured client the transport section should be entirely separate
from the user interface. It may even be a remote section. For example a
person working on the end of a slow line is likely to want to use a gateway
and the client will thus have no code whatsoever to handle the internals
of URLS. This is how it should be.
Of course we can specify a URL spec where the clients will work as expected
for everything except gopher. Apart from persuading people that its time to give
up on gopher I can't think of any positive benefit in doing this.
>We shouldn't have to transpose everything into EBCIDIC and then triple DES
>encrypt it to protect against people that can't read an RFC before writing
>their client. If the spec. says that something is opaque, it should be
>treated that way.
Nobody was suggesting using SGML.
The point is not what the spec says but what the spec should say. The point of
the spec is to provide the maximum possible functionality. Reserving the slash
for a hierarchical delimiter across all possible access methods is a good
idea. It means we can minimize the complexity of the clients.