RE: A new proposal (was: Re: which layer for URI processing?)

Tim Berners-Lee wrote:
>
> However, the important identity we do have is
>
>                 u1 = u2      ==>    R1  equivalent R2          (URI
> identity)
>

	This is a tricky problem. What is the definition of
"R1 equivalent R2"?

	We have already ascertained that a simple byte comparison of R1 and R2
won't suffice because the two may have an abstract equivalency. It seems
that the equivalency is a priori based on the equality of u1 and u2.

	What prevents us from defining
	"../light" = "../light" ==> R1("../light") === R2("../light") reqardless of
what R1 and R2 contain? We have already stated that the contents of the MIME
message are irrelevent.

	Again, the fact that a relative URI depends on the document base URI is not
a unique property of relative URIs.

	For example "el cid":

	"cid:contents" = "cid:contents"  (these are absolute URIs no :-?) and yet
the resources returned are dependent on the document context of the
enclosing MIME message.

	Do we ban "cid:" URIs also?

	Does this end here? What about context information send along with an HTTP
request (a.k.a. cookies). Do we define the result MIME resource only on the
basis of the URI regardless of the fact that the actual returned resource
may be dependent on the value of a cookie?

	If so, then why not just 'define' the resources returned as a result of
binding two relative uris as equivalent? Suppose I define a new scheme
"rel:". Is

	"rel:light" == "rel:light" by definition?

(answer the question and I'll tell you how the rel: protocol works :-))

Jonathan Borden

>

Received on Thursday, 25 May 2000 22:22:43 UTC