Implementing 'new' schemes using HTTP and DNS

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