I’m reviewing the issue-57 discussion at the recent TAG F2F and I notice that you hammer repeatedly against the connection between meaning and service:
- I don’t think it should cost energy to mean something
- I’m concerned [about] the way you’re describing the pattern – [dependency on running web server] … if you do a GET on the string, web server must be running when you do that GET.
and so on.
These IRC comments were ignored at the time. Now I will try to answer them.
If I ever talk about meaning being determined by GET, it is only a shorthand for a more nuanced story about authorization; I don’t really mean it. I’m sorry if that’s confusing.
My understanding of this from HTTPbis is that a “representation” (or other response), over whatever protocol (including any inter-brain protocol), is authorized for an http: URI by the domain name owner. That is, it is not correct for a cache or proxy to deliver a representation for a dereference of that URI that is not so authorized. The HTTP protocol is one way to express such an authorization, and because of Expires: the authorization can last for up to a year. But it does not take any energy for a representation to *be* authorized for a URI. The domain owner’s server can shut down completely, but copies cached in disks or on the sides of buses or inside brains can continue to be authorized.
You might even be able to find out whether a representation is authorized by, say, calling the current domain owner on the phone (not sure whether HTTPbis allows this). And other URI schemes have their own ways for a representation to be authorized. For example, RFC 2397 and your duri: draft authorize representations for a whole bunch of URIs for a very long time (forever).
But regardless of the URI scheme, representation-related meaning is either cached (maybe in your brain), looked up, or calculated by an authorized formula (as in the case of data:), and while perhaps no energy is needed for meaning itself, there is no caching or lookup or calculation apparatus that does not require energy to maintain. (Of course you know this distinction, sorry if I seem to lecture.)
If there were a legitimate way to authorize an http: representation for a very long period of time, such as true domain name ownership, then maybe we wouldn’t have to worry so much about meanings in http: space changing every year. RFC 2397 seems to do a pretty good job of authorizing representations forever; but the future is inherently unpredictable, so even the meanings of data: and duri: URIs is uncertain. Perhaps their meanings will be redefined by HTML6, in order to accommodate the way deployed infrastructure understands them. … unless by “meaning” you mean duri:2011:word:meaning… oh wait…
Now I’m mostly with you on http: not necessarily being the best basis for civil discourse (which requires citations, quite separately from up-to-date links), and duri: being superior in many ways. But issue-57 is not the best place, in my opinion, to address persistence concerns, given choices that have already been made by the affected community. I think it belongs with issue-50.
(Footnote: by “authority” throughout I mean the nice kind, the kind that’s granted, not imposed.)
(Footnote: someday I’ll figure out a ZBAC way to analyze all this. Not there yet.)