Hi all, couldn't resist jumping in on this one:

> But appears that the handle system is quite a bit more fleshed out than a simple purl server, it's a distributed protocol-independent network.   The protocol-independent part may or may not be useful, but it certainly seems like it could be, it doens't hurt to provide for it in advance. The distributed part seems pretty cool to me.
> So if it's no harder to set up, maintain, and use a handle server than a Purl server (this is a big 'if', I'm not sure if that's the case), and handle can do everything purl can do and quite a bit more (I'm pretty sure that is the case)... why NOT use handle instead of purl? It seems like handle is a more fleshed out, robust, full-featured thing than purl.

I think it's also worth adding that handles (and DOIs) can also be used to create PURLs, eg. (which isn't a real link) -- in fact, there's no reason why you couldn't use a PURL server as a local handle resolver, aside from the fact that it wouldn't be participating in the handle network.  See, for example: <>

One thing PURL has going for it is that it has defined meanings for HTTP response codes; these are similar to REST responses though I don't know if they're the same; the most recent documentation mentions that PURL servers are RESTful but I suspect this is part of the recent re-tooling of PURL.

The only potential advantage of PURLs that I can see is the ability to do partial redirects, eg. --> http://some.server/long.path/xxxxx -- though one could make the case that this might be useful for directing handle requests to the appropriate servers, eg. --> http://handleserver1/xxxxxx and --> http://doiserver2/xxxxxx ...

Overall, I tend to agree that handles seem more flexible -- or at least, less tied to URL and HTTP -- than PURLs.  Not having to rely on a specific server for resolution is a fairly major bonus (think DNS-style round-robin resolver querying for handles; not possible with PURLs).


PS.  At the risk of reposting potentially old news:  <>