- From: Larry Masinter <masinter@adobe.com>
- Date: Mon, 28 Sep 2009 15:03:47 -0700
- To: Jonathan Rees <jar@creativecommons.org>, Dan Connolly <connolly@w3.org>
- CC: "www-tag@w3.org" <www-tag@w3.org>
A URI (or URL or IRI or whatever) is a communication from a URI producer to a URI consumer, which identifies a resource the URI producer wants the URI consumer to identifier. If the URI consumer wants to understand the communication, the URI consumer needs to understand what the URI producer intended. " does it leave open the possibility of conforming agents using mechanisms that give answers at variance with what the Web would give?" Consumers of URIs that use mechanisms other than the one indicated by the URI itself must somehow be using additional information that isn't contained within the URI itself. I don't think it should be part of the "Web canon" to forbid the use of additional out-of-band information, but certainly such use is "non-conforming" within the domain of applicability. One additional piece of information which is often necessary but not part of the URI is the timeframe in which access is expected. So 100 years from now, if an interpreter of a 100-year-old document comes across "http://www.netscape.com", the interpreter (a URI consumer) may well use some out of band information to understand and interpret what was likely meant by the producer of that URI. Other examples of out-of-band information come from local configuration information (intranet users allowing WINS resolution of domain names) and "transparent proxies", where organizations intercept HTTP traffic and try to redirect requests to local caches as a way of reducing net bandwidth use and improving latency. There is no simple way to normatively ALLOW or DISALLOW a URI consumer from using out-of-band information to pick a different resolution method, but this doesn't change the fact that the URI producer's *meaning* is the one indicated by the URI scheme itself, even if the producer is aware of and takes into consideration the consumer's likely additional behavior. I think the discussion of "meaning" without being clear about "to whom" and "when" is very difficult and leads to incorrect conclusions and contradictions; be careful to use "meaning" as verb (someone means something at some point in time) rather than an attribute (X has meaning Y). Sometimes within a given document you don't need to qualify all those things, if the document itself is clear (alas, not the case for most of the documents we're discussing.) Larry -- http://larry.masinter.net -----Original Message----- From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] On Behalf Of Jonathan Rees Sent: Monday, September 28, 2009 2:29 PM To: Dan Connolly Cc: www-tag@w3.org Subject: Re: Alternative dereference behavior On Mon, Sep 28, 2009 at 4:04 PM, Dan Connolly <connolly@w3.org> wrote: > On Mon, 2009-09-28 at 13:00 -0400, Jonathan Rees wrote: >> This message is pursuant to ACTION-312 which I took on at the F2F. >> >> Roughly speaking, the question is: Does the canon say that the Web is >> the authority for http: URI "dereference" (GET), or does it leave open the >> possibility of conforming agents using mechanisms that give answers >> at variance with what the Web would give? > > [...] >> Summary: > [...] >> . General advice (AWWW, IAB TC) is that if you "split the web" by making URIs >> non-global you are doing something really tragic. A change >> in the rules for dereference would theoretically be OK, as long as everyone >> made the change in step (ha!). > > Exactly. That seems like a "yes" answer to the question above, > inasmuch as an authority is something that helps you avoid something > really tragic. > > I don't see any contradiction with my reading of webarch; > maybe the description of the action should change or something? > > "Find a path thru the specs that I think contradicts Dan's reading of > webarch" > -- http://www.w3.org/2001/tag/group/track/users/38732 I will not be able to complete this action, because you were right and I was wrong. So I think the action does need to be changed or dismissed. Jonathan
Received on Monday, 28 September 2009 22:05:01 UTC