Issue/OCLC noise tradeoff

It would be nice to include OCLC's PURL server (purl.org) in the set of active servers. OCLC has a good track record and is likely to be around for a while. Having it as a fallback should increase confidence in the system, and therefore use of it.

The implementation is easy - simply add the IP address for purl.org to the list of DNS A records for sharedname.org. Since purl.org ignores the 'Host:' header, this ends up being a simple alias (in the case that A record is used for lookup).

Well not exactly easy... our proposed synchronization method of using back-end MySQL replication with periodic PURL server cache resets would need to modified to account for the fact that OCLC's DBMS is much more than just a copy of ours. -JAR

On the other hand, unless OCLC is willing to modify its software, the cost of enabling OCLC would be extra noise in each URI, e.g. http://sharedname.org/n/uniprot/p12345 instead of http://sharedname.org/uniprot/p12345 (no "n/"). This is because it is infeasible to register every shared-names databank name as a separate purl.org top-level domain.

We could have our cake and eat it too if OCLC would deploy software (say, a future version of PURLZ) that supported a virtual hosting feature, resolving purls based not just on path but also on host name ('Host:').