Re: Determining what a URI identifies

Larry Masinter writes:
>A simpler design is:
>
>What a URI determines is defined by the scheme. The definition
>of a URI scheme must include a clear definition of what strings
>that start with that scheme identify. URIs that start with
>"http" identify resources that are accessed via the HTTP protocol,
>using the simple meaning that
>   http://host.example.org/path
>identifies the network resource that one connects to speaking
>the HTTP protocol to host "host.example.org" with path component
>"/path".

That makes an enormous amount of practical sense, and I've argued for a
long while that it corresponds both to common understandings of URIs and
common practice.    It also provides us with a safe foundation for
building caching and proxying applications which build on understandings
of http URIs more sophisticated than "retrieve that resource using the
HTTP protocol" but less open than "it identifies whatever you feel like
it identifies."

It lets developers who want to create genuinely wide-open schemes do so.
At the same time, it lets those of us who prefer to work within
explicitly constrained sets of understandings get our work done.

Unsurprisingly, that expectation is made explicit in RFC 2616:

>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.
>
>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)....

Scheme registrations are genuinely useful bits of information.


-------------
Simon St.Laurent - SSL is my TLA
http://simonstl.com may be my URI
http://monasticxml.org may be my ascetic URI
urn:oid:1.3.6.1.4.1.6320 is another possibility altogether

Received on Monday, 4 November 2002 17:28:48 UTC