- From: Henry S. Thompson <ht@inf.ed.ac.uk>
- Date: Wed, 27 Apr 2005 14:31:08 +0100
- To: www-tag <www-tag@w3.org>
During the TAG's consideration of the XRI proposals [1] a thread on the TAG's private mailing list which started on an administrative topic strayed into technical discussion. In order to include a public reference to this discussion in our feedback to the XRI TC, which is now ready to be sent, this message reproduces the relevant parts of the discussion. Responses are welcome, but because the deadline for sending the feedback is this Friday, probably won't be able to be considered for it. When replying to this message _please_ don't copy the entire thing, just the Part you are actually replying to! ht [1] http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xri =============== Part 1 ============== > >My position is: since > >you can do this with http://dns naming, you should; using xri: names > >might seem a little easier in the small, but it costs *everybody* else > >that you want to communicate with. And it doesn't really solve > >anything; the levels of indirection are already available with > >http://dns. If somebody can't manage http://DNS names, then they > >won't be able to manage xri: names either. > > DNS is still the key component in this, without DNS XRIs would not work. > This is simply an abstraction layer on top. The one thing you cannot do > with DNS that you can do with an XRI is to both maintain a direct > pointer to a resource as well as a abstract pointer. Oh really? Witness: This version: http://www.w3.org/TR/2004/REC-webarch-20041215/ Latest version: http://www.w3.org/TR/webarch/ Previous version: http://www.w3.org/TR/2004/PR-webarch-20041105/ and various identifiers for software packages... =============== Part 2 ============== Ok, then maybe what we should do is to suggest a change in syntax. After about 30 seconds work on my test system I can get the exact same results with; http://mycomputer.com/xri=referance It takes three dns resolutions instead of two, but it solves the same purpose. This could actually be more flexible in that it would allow local systems to have their own authority and thus avoid the registration issues; http://xriauthority.example.com/xri=myprinter/current_driver or allow centralized authorities; http://xri.google.com/xri=myprinter/current_driver Either way, this would allow them to solve the same business issue without the introduction of a new URI prefix. =============== Part 3 ============== Just to amplify a bit [on Part 1] | To illustrate; | | http://myserver/myprinter/mydriver/version1 | | will be replaced over time with; | | http://NEWSERVER/myprinter/mydriver/version2 You can't replace the URI. http://myserver/myprinter/mydriver/version1 exists now and will forever exist. I imagine you mean one of two things: 1. The resource in question is "the most recent version of the thing" and the URI http://myserver/myprinter/mydriver/version1 used to identify it. But now the thing has been updated and the identifier for the most recent version of the thing has become http://NEWSERVER/myprinter/mydriver/version2 Don't do that. The resource hasn't changed, version2 is "the most recent version of the thing" so continue to use http://myserver/myprinter/mydriver/version1 to point to it. If you also need a way to point to "version1 of the thing", that's a different resource and you should give it a URI. 2. The resource in question is "version1 of the thing" and the URI http://myserver/myprinter/mydriver/version1 identifies it. But now the thing has been updated and there's a version2 of the thing and its identifier is http://NEWSERVER/myprinter/mydriver/version2 But what you really want is for your customers to be able to find "the most recent version of the thing". So give it a URI. You want a URI for a currently unidentified resource, "the most recent version of the thing", so give it one. Say http://myserver/myprinter/mydriver/current and use that. | However, the xri pointer | | xri://myserver/myprinter/mydriver/current | | Will always point to the most current driver. No more or less reliably than http://myserver/myprinter/mydriver/current (Well, less reliably actually, since there's no deployed infrastructure to support xri: yet ;-) I think part of the problem here is one of user education. One of my long standing arguments against using http: URIs as names was that users *think of them as addresses* and while it's perfectly possible to use them as names, it's counter-intuitive to a lot of people. | Note: drivers in particular usually keep the last few versions available | incase you need them for some reason and so you would likely want both | options. Just as the W3C keeps *all* of the public drafts of Recommendation track documents available and yet provides a stable URI for "the most recent version". =============== Part 4 ============== > | Ok, then maybe what we should do is to suggest a change in syntax. > | After about 30 seconds work on my test system I can get the exact same > | results with; > | > | http://mycomputer.com/xri=referance Exactly. > | Would this address your concern? Yes, quite. I'd like for the TAG to say to the XRI folks Yes, persistence is important; thanks for investing it it. But please implement your persistence idioms inside http://DNS rather than asking the world to tool up on xri: You're welcome to compete inside http://DNS like the rest of us, but as to another concentration of power in another namespace root, no thanks. . . . I don't mind if the XRI folks educate users about how to use http://DNS names well, or even if the XRI folks provide services that do it for people that aren't comfortable doing it for themselves. =============== Part 5 ============== The XRI discussion did suggest one other interesting question: to what extent does http redirection meet the needs for the sorts of aliasing that are being discussed under the XRI banner? I've begun to suspect that there are at least two cases of interest: 1) the redirection is to a stable URI intended for public use 2) redirection is being used for load leveling or other transient purposes -- the redirection is to a URI that is unsuitable for bookmarking or other long-term reference. As an example of the latter, if you enter the following URI into the Firefox address bar: http://www.ibm.com/developerworks the page you get is labeled: http://www-130.ibm.com/developerworks/ Of course, I hope that my employer follows the recommended practice that cool URI's don't change, but I'm guessing that the former is a better long term bookmark than the latter. Redirection can become visible to users in ways that are at best confusing, and at worst inappropriate. I'm sure this has been discussed before, but it's the one aspect of recommending http that leaves me a bit uncomfortable. =============== Part 6 ============== > 1) the redirection is to a stable URI intended for public use 2) > redirection is being used for load leveling or other transient > purposes -- the redirection is to a URI that is unsuitable for > bookmarking or other long-term reference. Yes, that's what the HTTP WG decided too: "10.3.2 301 Moved Permanently The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs." -- http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.2 "10.3.3 302 Found The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. " -- http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.3 The browsers treat them the same, I think. As I recall, the justification was security (transparency). I kinda think it's a bug, but I haven't really finished thinking it thru. =============== Part 7 ============== > The browsers treat them the same, I think. As I recall, the > justification was security (transparency). I kinda think it's a bug Seems so to me too. Still, I think that redirection for either reason necessarily puts you in the business of having what users would think of as two names for the same resource, and that's a complexity that's likely to leak through at times even if the user agents are improved. > I kinda think it's a bug, Me too. > but I haven't really finished thinking it thru. Me either. Perhaps we should at the very least find a way to suggest that user agents do better in carefully handling both 301's and 302's (or maybe it's that servers should be configured to more carefully report the reason for the redirection)? There are many cases in which my browser appears to do the wrong thing, but I haven't taken the time to figure out which end of the connection is "at fault". -- Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh Half-time member of W3C Team 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail really from me _always_ has this .sig -- mail without it is forged spam]
Received on Wednesday, 27 April 2005 13:31:18 UTC