RE: Proposed AWWW erratum on "information resources" [was Re: Fwd: Splitting vs. Interpreting]

Hi Larry,

On Wed, 2009-08-05 at 12:46 -0700, Larry Masinter wrote:
> > Compare this with a corresponding http URI such as
> > http://filbert.example/nadia/woosel/yes
> > In this case, the chain of authority looks like:
> >   1. AWWW delegates to RFC3986 (because the whole thing is a URI)
> >   2. RFC3986 delegates authority for http:* URIs to the owner of the
> > http scheme
> 
> OK so far
> 
>   3. Owner of http scheme delegates authority for
> http://filbert.example/* URIs to the owner of filbert.example.
> 
> No. The "Owner" of the http scheme is the IETF. The http
> URI scheme is defined in a Draft Standard for HTTP, following
> IETF process. The current definition doesn't delegate the
> "authority" for http://filbert.example/* URIs to the
> "owner" of filbert.example, it only allows for the HTTP
> protocol to be used to connect the HTTP server being run
> at the computer with the DNS entry for filbert.example.

Yes, I realize that the HTTP spec doesn't say that.  That could either
be viewed as a gap that should be corrected or one could view it as
unnecessary for the HTTP spec to make that explicit delegation, since
the layering of extension semantics on top of http URIs is
non-destructive (monotonic).

It is not correct to say that the HTTP spec 'only allows for the HTTP
protocol to be used'.  The HTTP spec only *defines* the use of that
protocol with the http scheme, but it does not prevent other protocols
from being used as well.

Section 3.1 of the AWWW addresses this explicitly:
http://www.w3.org/TR/webarch/#dereference-uri
[[
Although many URI schemes (§2.4) are named after protocols, this does
not imply that use of such a URI will necessarily result in access to
the resource via the named protocol. Even when an agent uses a URI to
retrieve a representation, that access might be through gateways,
proxies, caches, and name resolution services that are independent of
the protocol associated with the scheme name.

Many URI schemes define a default interaction protocol for attempting
access to the identified resource. That interaction protocol is often
the basis for allocating identifiers within that scheme, just as "http"
URIs are defined in terms of TCP-based HTTP servers. However, this does
not imply that all interaction with such resources is limited to the
default interaction protocol. For example, information retrieval systems
often make use of proxies to interact with a multitude of URI schemes,
such as HTTP proxies being used to access "ftp" and "wais" resources.
Proxies can also to provide enhanced services, such as annotation
proxies that combine normal information retrieval with additional
metadata retrieval to provide a seamless, multidimensional view of
resources using the same protocols and user agents as the non-annotated
Web. Likewise, future protocols may be defined that encompass our
current systems, using entirely different interaction mechanisms,
without changing the existing identifier schemes. See also, principle of
orthogonal specifications (§5.1).
]]


> 
> >   4. The owner of filbert.example delegates authority for
>   http://filbert.example/* URIs to the Filbert specification.
> 
> I'm not sure who you think the "owner" of "filbert.example"
> is. HTTP doesn't know anything about "owners". 

The AWWW defines the notion of URI owner:
http://www.w3.org/TR/webarch/#uri-ownership


> There are
> protocols, domain names, operators, and an infrastructure
> of DNS. The system doesn't allow delegation to a new 
> "specification". What the operator of the service at
> filbert.example has as operational policy is, and should
> be, opaque to the agent interpreting 
> "http://filbert.example/*"

You seem to be ignoring the point of layered semantics.



> 
> 
> 
> > There is one extra level of indirection in the http case, but the net
> > effect is nearly identical.
> 
> Only in some hypothetical world.
> 
> 
> > For simplicity, but without loss of generality, I have made the syntax
> > of these two URIs look very similar. 
> 
> You're building up an imaginary system which cannot be
> put into practice. 

Huh?  This isn't imaginary.  It's the way semantic extensibility works
*now*.  

> I could imagine a hypothetical world
> in which you could make the associations you're providing,
> but I don't think it's possible given the organizations
> involved, nor do I think that the hypothetical world
> you postulate is a better one than the one in which
> http URIs are used for the HTTP protocol, and if you don't
> want the HTTP protocol, you use a different URI scheme.

You're missing the point.  It's not about *not* wanting the HTTP
protocol.  An http URI still has its semantics as an http URI, which
means that it is still legitimate for someone to try to dereference an
http URI, and they might even get useful information back as a result.
The additional Filbert semantics are in *addition* to the http
semantics: they *further* license the use of that URI as a Filbert URI.
That's what layered semantics is all about.  

This is no different in principle from the use of URIs for accessing
weather forecasts.  As owner of the weather.example domain I could
decree that all URIs minted in the URI subspace of
http://weather.example/zipcode/* are for accessing weather forecasts by
zip code, such as http://weather.example/zipcode/02144 .  I could
publish this information to the world, and allow people to access
weather forecasts for any zip code this way.  Furthermore, if I chose to
do so, I could define a new WEATHER protocol that is specifically used
for accessing weather reports by zip code, and declare to the world that
any URI in the URI subspace http://weather.example/zipcode/* may be
accessed using the WEATHER protocol.

TimBL has written about this layering in one of his "Design Issues"
documents:
http://www.w3.org/DesignIssues/Stack


David Booth

> 
> I could respond to the rest, but it's mainly repetitive.
> 
> Larry
> 
> 
> 
> 
-- 
David Booth, Ph.D.
Cleveland Clinic (contractor)

Opinions expressed herein are those of the author and do not necessarily
reflect those of Cleveland Clinic.

Received on Thursday, 6 August 2009 03:07:14 UTC