Message-Id: <9406301523.AA04566@ulua.hal.com>
To: Larry Masinter <masinter@parc.xerox.com>
Subject: Re: current status of URL document...
In-Reply-To: Your message of "Thu, 30 Jun 1994 00:51:00 PDT."
<94Jun30.005114pdt.2760@golden.parc.xerox.com>
Date: Thu, 30 Jun 1994 10:23:31 -0500
From: "Daniel W. Connolly" <connolly@hal.com>
In message <94Jun30.005114pdt.2760@golden.parc.xerox.com>, Larry Masinter write
s:
>Responses to comments from Dan Connolly (sent to this list) and Ned
>Freed (sent privately):
>
>>It seems to me that the namespace of URL schemes and the namespace of
>>MIME external-body access types are isomorphic; I suggest that they be
>>merged...
>In short, although it would be nice if there were a simple
>correspondence, there isn't. I don't see a good reason to extend MIME
>to have additional external-body types; rather, some simple extension
>that includes all URLs in one fell swoop would be more useful, e.g.,
>
>access-type="URL"; path="URL:scheme:stuff";
OK, I'll buy this. [But once again, we see that the URL: is completely
redundant and unnecessary.]
I still think my proposal is workable, if less than optimal...
>Except that what corresponds to:
> ftp://host/dir1/dir2/file
>is it:
> access-type="ftp"; site="host"; directory="dir1"; directory="dir2"; name="fi
>le"
>
>or some other syntax? I'm afraid that the two don't map all that
>easily in many cases.
For that example, I'd say
access-type="ftp"; site="host"; directory="dir1/dir2"; name="file"
I'm not suggesting that there's a general way to map an arbitrary URL
to a set of MIME external-body parameters or vice versa; rather, that
the namespace of access-type and URL scheme should be the same
namespace, so that the same name never has a different meaning in the
two syntaxes.
>> http://host/dir/file
>> access-type="http"; site="host"; path="dir/file"
>
>Except that access-type="http" isn't defined; can we actually extend
>MIME external-body types in the URL RFC??? Or will you propose this as
>a separate RFC?
That's the whole point: we get together with the MIME guys and decide
that whenever you define a URL scheme, you're defining a MIME access
type also.
>> Here's a comparison of the two namespaces:
>
>> URL scheme MIME access-type Protocol
>> file local-file Local file access
>
>There is no `file:' scheme in this draft, and it doesn't actually fit
>within the URL requirements. Perhaps this is an oversight?
I don't recommend putting file: in the URL spec, but I wouldn't mind
seeing local-file: in there.
>> Also: what's a conforming URL syntax? For example, is the following
>> a "conforming" URL or not?
>>
>> URL:x-my-scheme:x?x?t/t/#45?%%
>
>No, but only because %% is not legal. However,
Ack! So the %XX is common to all schemes, but /?#; are not? Hmmm... I
guess that's not a problem all by itself. But I think it should
somehow be made clear that the following are equivalent:
ftp://host/filen%61me
ftp://host/filename
but the these two are not:
ftp://host/file%2Fname
ftp://host/file/name
so that it is clear that gateway agents etc. cannot "escape" reserved
characters [this is in a URL->URL translation. Obviously in a
filename->URL translation reserved characters can (must!) be
escaped]. And I would argue that this should be generalized to the
case where ftp: is x-my-scheme:.
>
> URL:x-my-scheme:x?x?t/t/#45?$$
>
>would be allowed. I think, if there are those on the committee who
>want to reconsider their opinion about not reserving ?#/; in ALL
>schemes to mean `query', `fragment', `path' and `attribute' components
>respectively, they should speak up.
I'll speak up again:
The term "URL" is widely deployed in the internet community, and I'm
not talking about just the WWW application. I conjecture that 30 to
40% of the active USENET FAQ documents use URLs to cite additional
resources. There are a handful of widely circulated "beginners guide
to URLs," and countless local variations.
The internet community has a working definition of a URL that comes
from the WWW definition. That definition includes a syntax that is
common to all URLs (and URNs, and any other sort of URIs).
If this working group were to publish a URL specification that is in
conflict with that working definition, it would be a great disservice
to the community.
>> If we are strict about the "common syntax," e.g. we say that things
>> like:
>> ftp://host/file;/xxx
>> are "illegal", then we can at some future time assign a new meaning to
>> them with confidence that we will not be changing the meaning of any
>> existing URLs.
>
>Well, `;' is in fact reserved in the `ftp' scheme, so it is indeed
>illegal. Perhaps you want to choose a different example?
Yes... I think you get my meaning... I should have used the example:
x-my-scheme://host/file;/xxx
>> URLs are already widely deployed and it is of no practical use to say
>> that they begin with URL: when in practice they don't, and there are
>> no problem that arise from this practice.
>
>I believe the strongly held feeling is that there ARE problems that
>arise from this practice, and those feelings led to the introduction
>of the prefix. If the chairs of the working group were to hold a
>informal poll of the working group members to confirm the already
>established `rough consensus', it might allow us to proceed beyond
>this issue.
I have seen this argument based on "feelings" and "rough consensus" at
least a dozen times, and it continues to be without merit. I am
interested to know how the URL: prefix presents a nontrivial technical
problem.
Perhaps a sound technical argument has been made in this forum and I
missed it. In that case, the argument belongs in the URL document as
motivation for deploying this new convention.
Dan