Message-Id: <199408062213.PAA19520@nic.cerf.net>
Date: Sat, 06 Aug 1994 15:07:36 -0700
To: uri@bunyip.com
From: miked@CERF.NET (Michael A. Dolan)
Subject: URL Comments
Gentlemen (and ladies ?)-
Follows are some comments/questions on the Aug 4, 1994 draft IETF URL
document. Some comments are probably just my lack of understanding, to
which I hope to be enlightened.
In the chance that I might have raised valid issues, I'd be happy to
help work to resolve/define them.
Regards,
Mike
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1. (2.2) This section seems to catagorize charFrom uri-request@mocha.bunyip.com Mon Aug 8 22:15:22 1994
Received: from mocha.bunyip.com (mocha.bunyip.com [192.77.49.150]) by mail.cs.tu-berlin.de (8.6.9/8.6.9) with SMTP id VAA01206 for <bene@cs.tu-berlin.de>; Mon, 8 Aug 1994 21:54:38 +0200
Received: by mocha.bunyip.com (5.65a/IDA-1.4.2b/CC-Guru-2b)
id AA08697 on Mon, 8 Aug 94 12:38:44 -0400
Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
id AA08693 (mail destined for /usr/lib/sendmail -odq -oi -furi-request uri-out) on Mon, 8 Aug 94 12:38:35 -0400
Received: from golden.parc.xerox.com ([13.1.100.139]) by alpha.xerox.com with SMTP id <14479(9)>; Mon, 8 Aug 1994 09:37:52 PDT
Received: by golden.parc.xerox.com id <2760>; Mon, 8 Aug 1994 09:37:46 -0700
To: bert@let.rug.nl
Cc: uri@bunyip.com
In-Reply-To: Bert Bos's message of Mon, 8 Aug 1994 03:59:59 -0700 <199408081050.AA060573055@freya.let.rug.nl>
Subject: Re: FYI, revised draft URL document
From: Larry Masinter <masinter@parc.xerox.com>
Sender: Larry Masinter <masinter@parc.xerox.com>
Fake-Sender: masinter@parc.xerox.com
Message-Id: <94Aug8.093746pdt.2760@golden.parc.xerox.com>
Date: Mon, 8 Aug 1994 09:37:35 PDT
thanks for your comments.
> On the whole, the proposed RFC seems a sound piece of work. Although
> the underlying principles (usable in hard-copy, simplicity of syntax)
> aren't stated explicitly, they are applied consistently and
> intuitively, except for the Gopher URLs (see below).
The underlying principles are included in a separate document.
> The explanations are short, but sufficient, except that in two or
> three places a sentence seems to be missing and one whole section
> seems to be lost.
> Ad 2) To start with that last omission: section 2 states that there will be
> a section on what I assume are `partial URLs'. The section will presumably
> contain the rules for abbreviating and expanding URLs in the context
> of a `base URL'. However, no such section exists.
I removed the last paragraph of section 2. We intentionally removed
(for consideration independently) the description of `relative URLs'
from this document, but the introduction remained.
> Ad 3.2.1) In the last sentence of 3.2.1, an example is given with an
> empty path segment. The example seems to suggest that the non-empty
> path segment (`etc') that is present as well will be ignored.
I've searched for this example, but I don't see it. Could you quote
it?
> Ad 3.3) The last sentence of 3.3 mentions that HTTP URLs have a
> `hierarchical structure'. It isn't explained what this entails.
I agree, it doesn't explain. Our current plan is to explain `relative
URLs' in a separate document. I wonder if we can leave this as is, or
if it's important to add some introductory note that the hierarchical
structure of URL space is used in conjunction with `relative URLs',
but then not to explain those.
> Ad 3.4) The Gopher URLs are the only part of the document that seems a
> little messy. The meaning of a URL seems to depend on subtle things,
> such as the presence of a `7' at the start. Moreover, the semantic
> differences are not reflected in the grammar in section 5. Gopher URLs
> are also the only URLs where an escape (%09) functions as a delimiter.
> I think that is contrary to the concept of escapes, which is that they
> *remove* any special meaning.
I agree it is a little messy, but it is mainly in contrast with the
other sections, since the gopher URL section is much longer. The
particular design choices for Gopher+ URLs were made after
consideration of those issues. I don't think using %09 as a delimiter
is inconsistent, because the character encoded (tab) is not allowed in
any other circumstance.
> Another thing that I missed in the document is the explanation of `#'
> to refer to an anchor inside a document. I think there are arguments
> in favour of including the `#'. For one, most people would say that a
> URL with a `#' in it is still a URL. Secondly, the same principles of
> readability and printability apply to the anchor as to the rest of the
> URL. Thirdly, it is very likely that the anchor will one day have to
> be transferred over a network (the same happened to the hostname and
> port, after the introduction of proxies.)
> Currently, the `#' is only used to refer to parts of (or points in)
> HTML documents, but this RFC could pave the way for a more general
> application.
There is not general agreement on what the form of an anchor might
mean for other than HTML documents, although there's lots of
conjectures for how one might refer to images, etc. I agree that
people might say that a URL with a # is still a URL, and that the
principles still apply, and that anchors are transferred over a
network. However, none of those are particularly strong arguments for
including more about anchors than currently appears here, are they?