...
The resolver has one lookup table with an entry for each known prefix. That lookup table specifies one of 2 behaviors for that prefix, which in our case we anticipate to We anticipate that a prefix will normally correspond to a collection (, but it could be used for distinct services redirecting to the same collection – the resolver wouldn't care).
That lookup table specifies one of a finite set of behaviors for that prefix.
Strict behavior
The resolver would have a 2nd lookup table specific to that prefix (never mind for now how this would be efficiently implemented). If an entry matching the entire identifier part as an indivisible string is found, the resolver redirects to that entry. Otherwise the resolver returns an error. Any of the 6 distinct URI forms above would fail unless the resolver had been provided a redirection location uniquely matching the incoming URI (Note that the redirection locations need not be unique).
Pass through behavior
The resolver would never return an error, but instead pass the entire identifier string along to a single redirection address (e.g., http://arxiv.org
). This allows the collection to treat the different forms of the URI however it needs to.
Other possibilities
It would be possible for a collection to use more than one prefix to allow different behaviors for different circumstances. There could also be additional behaviors , such as checking for example a behavior involving authentication and/or authorization before redirecting.
...
Jon: This might be a way for a collection to continue its own branding when publishing otherwise meaningless persistent identifiers, as for example registering the domain name handle.ecommons.cornell.edu and directing it to http://hdl.handle.net, so that a URL in the form http://handle.ecommons.cornell.edu/1813/734 could be published instead of http://hdl.handle.net/1813/734; both would resolve to http://ecommons.cornell.edu/handle/1813/734