To: uri@bunyip.com
Subject: Re: current status of URL document...
From: Larry Masinter <masinter@parc.xerox.com>
Message-Id: <94Jun30.005114pdt.2760@golden.parc.xerox.com>
Date: Thu, 30 Jun 1994 00:51:00 PDT
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, so that the following are explicitly equivalent:
> ftp://host/dir/file
> access-type="ftp"; site="host"; directory="dir"; name="file"
Except that what corresponds to:
ftp://host/dir1/dir2/file
is it:
access-type="ftp"; site="host"; directory="dir1"; directory="dir2"; name="file"
or some other syntax? I'm afraid that the two don't map all that
easily in many cases.
> 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?
> 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?
> afs Andrew File System
There was BNF for afsaddress in the previous draft, but not
description. I felt uneasy making up a description all on my own so I
dropped it from the BNF. (Also, afs: isn't widely deployed or used as
a URL.)
> ftp ftp File Transfer protocol
> anon-ftp File Transfer protocol
See above. The semantics don't quite match.
> mailto mail-server Electronic mail address
The `mailto:' URL and the `mail-server' external-body types are
actually quite different. `mail-server' external-body types include a
body that you send to the remote server to retrieve some data.
mailto: URLs specify a mailbox, without any presumption that any
automated processing will happen when mail is sent to that address,
and with no content presupplied.
I think in fact that the mailboxes that you might see in a `mailto:'
URL and those you would see in a MIME external-body are more or less
disjoint.
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";
> 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,
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.
> 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?
> I still think this is silly and unnecessarily prescriptive, but I see
> here that it is not mandatory.
> 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.
> By the way... that draft listed TimBL as the editor... shouldn't
> Mr. Masinter's name be on there too?
> Dan
I'm uneasy about my standing in this matter. I originally intended to
make only small edits, but one thing led to another. I have had no
direct correspondence with TimBL about editing this document, the
process by which we had agreed to move forward on it, my intentions to
proceed, or, since I sent a draft privately, any of the edits made.
If the changes had been minor, leaving my name only in the
Acknowledgements section would be appropriate. However, given how
extensive they are, I don't think I should continue without some kind
of confirmation from Tim, at least as to his feelings about the status
of authorship. One the one hand, it isn't reasonable to leave
someone's name on a document which they do not approve of or agree
with, on the other hand, it isn't reasonable to take someone's name
off a document for which they rightly deserve credit. I
================================================================
In addition, Ned Freed sent several comments, most of which are fairly
straightforward (renumbering sections, allowing the RFC editor to add
the appropriate boilerplate and submitting this as an internet draft)
The main substantive issue was dealing with the fact that `http' and
`gopher' are not RFCs or standards, and that there are often
objections to forward-references to other standards that do not exist.
I think the way to deal with the issue is to say that this memo only
establishes the SYNTAX of URLs for those protocols, and that any
standard document for those protocols would have to establish how the
URL is to be interpreted. This might mean cutting down the GOPHER
section, and instead moving that to the Gopher protocol RFC as it
makes its way through the standard process.
If anyone has any additional comments, I'd appreciate them sooner,
rather than later. I'm off-net next week; if I don't get done by
Friday, I'll work on this offline.