Re: now://example.org/car (was lack of consensus on httpRange-14)

>> BTW, anyone who claims that this is opportunistic revisionism
>> had better have something more than their opinion to back that up.
>
> Sure thing.  There's a Standards-Track RFC from June 1999[1] that makes
> the following claims about URLs using the http scheme, the kind which
> have been at the heart of this thread:

Thanks, I prefer a more concrete discussion.

>> 3.2.2 http URL
>>
>> The "http" scheme is used to locate network resources via the HTTP
>> protocol. This section defines the scheme-specific syntax and
>> semantics for http URLs.

Note that sentence, please.  There is a very good reason why I did not
open the HTTP specification up to this very same debate -- you can see
it from the old discussion in URI-WG.  This section decomposes the
http scheme for its purpose as a locator, as is necessary for each
of the URI schemes that are capable of direct locating.

>> http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
>>
>> If the port is empty or not given, port 80 is assumed. The semantics
>> are that the identified resource is located at the server listening
>> for TCP connections on that port of that host, and the Request-URI
>> for the resource is abs_path (section 5.1.2).
>
> I think my favorite aspect of this tidbit is "The semantics are that the
> identified resource is located at the server listening for TCP
> connections on that port of that host".  The resource may be the
> listener, not the "representation" response, but this doesn't suggest
> the use of http URIs for things other than HTTP protocol listeners.

Of course not -- it is very dangerous to talk about two orthogonal
issues in one section of an IETF spec, particularly since the
non-scheme-specific aspects of the http URI are defined by RFC 2396.
HTTP uses the general 2396 definitions for the proxied Request-URI,
Location, Referer, and Alternates header fields, not to mention the
ones defined by WebDAV.  It isn't necessary for the section on how
to use the http scheme as a locator to also define all of the
different ways that any locator can be used as an identifier.

As I've mentioned before, there was considerable disagreement among the
editors about the use of "representation" or "instance" to talk about
what comes back from a GET, so we simply refer to the message-encoded
"entity" instead.  The principles and effect of the interface are the same.
Furthermore, because the HTTP interface cannot know the nature of the
resource and the semantics are defined independently of how many
identifiers might exist for that resource, the protocol considers the
resource to have a 1:1 relationship with the URI.  That does not mean
that it requires there to be a 1:1 relationship!  It only means that
a possible N:1 relationship has no impact on the protocol semantics.

> While it is possible that this is just one of those accidental copyings
> from the Mosaic documentation, that seems extremely unlikely given the
> authorship of the document, its delivery after RFC 2396, and the care
> generally given during the RFC publication process.

Heh, actually that was a big problem in itself -- 2396 was stuck in
what was then an eight-month IESG/RFC editor review cycle when 2616
was being edited, and some of the changes were overlooked in 2616,
so there are some significant errata due to the "care" of that process.

In any case, the section above was written by me long before 2396
(see RFC 1945) and I nobody asked that it be revised afterwords.
Revising text in a proposed standard is a very painful process.

....Roy

Received on Thursday, 10 October 2002 18:50:08 UTC