Betr.: [WEB4LIB] Cookie-pusher for DOI resolution

[Theo van Veen]

The most ideal way of using the OpenUrl mechanism would be the following. As soon as a user finds metadata somewhere on whatever site containing OpenUrl's, he wants the OpenUrl's automatically pointing to his own preferred service component. Therefore the browser should recognize the OpenUrl's and automatically substitute the user's base-url. Such a mechanism does not exist (yet).

A mechanism that comes very close to this and is very easy to implement 
1) offers the user the ability to fill in his base-url when presenting OpenUrl's, 
2) sets the base-url in a cookie by means of  javascript and 
3) compute the OpenUrl's on the fly also by means of javascript. 
This does not require the server to interprete the cookie, it is not restricted to a set of predefined OpenUrl-servers and it does not require the server to have knowledge about the users persmissions, as the user can specify his own base-url.
  
Yes, it requires cookies and yes, it requires Javascript. As soon as browsers allow global variables (local with respect to the user but global with respect to different websites) to be used within Javascript (may this exists already) the cookie mechanism can be replaced by setting such a variable. 
What is important is that everyone uses the same mechanism to set the OpenUrl to the users base-url and I would strongly suggest the mechanism described above (unless there are more convenient mechanisms). 
See also http://www.kb.nl/persons/theo . In this example the base-url is considered to point to a personal link page but this can also be any other OpenUrl resolver. 

Theo van Veen


>>> "Thomas Dowling" <tdowling at ohiolink.edu> 03-11-01 21:00 >>>
I have received a couple of messages about my comments on the cookie-pusher
solution to appropriate copy resolution of DOIs.  Here's a fuller
articulation of my points.

I believe that the cookie pusher will prove inadequate for many users.
However, the consensus of a group of organizations who worked on this
problem over the last year was that no better solution will be available in
the foreseeable future.

The cookie pusher is a CGI script that lives at www.doi.org.  Its function
is to set a cookie within the doi.org domain and issue an HTTP Location
header sending the browser to a URL specified in its query string.  HTTP
requests received by the global DOI resolver at dx.doi.org will note the
presence of this cookie; if it's present, the resolver will redirect users
to a local DOI resolver determined from the value of the cookie.

The expected implementation is that a page on, say, www.ohiolink.edu, would
include an <img> element whose src attribute was actually the cookie pusher
script called, so as to redirect the browser to an image back on
www.ohiolink.edu.

The expected benefit of doing this is that a database vendor can create
DOI-based outbound links to citations without having to worry about where
any user's resolver might live.  Those links all go to dx.doi.org, which
determines whether to give users the global resolution service to or
redirect them to a local service.


My issues with this are:

Any user whose path to the database avoids the page(s) with the cookie
pusher image will not get the cookie set under any circumstances.  This
includes anyone following a bookmark to the database.  They will therefore
get the global resolution service rather than your carefully tailored local
service.

Sites have to choose carefully on how many pages to put the cookie pusher
image.  Too few, and you increase the number of users who won't get the
cookie set.  Too many, and the effect of continually re-running the script
might be a perception that your site is slow.

This "page from one site, image and cookie from another" trick (third-party
cookies) has been widely used by commercial traffic monitoring companies.
Because of the privacy issues involved with this, most cookie management
software--including what's built into Netscape 6.1 and IE6--disables this by
default.  This could be avoided by actually linking to the cookie pusher
rather than insinuating it into an img, but IMO this exacerbates the problem
of deciding where users should see that link.

The image-based cookie will not be set under any circumstances if:

  The browser is not set to show images.
  The browser is set to disallow all cookies.
  The browser is set to allow cookies only from a set of servers that
    does not include www.doi.org.
  The browser, or cookie management software, or firewall is set to
    disallow third party cookies.
  OR the browser does not go to a cookie-pushing page before
    going to services with DOI-based links to dx.doi.org.


But again, there's no better solution right now to identify your users to
the global DOI resolver.  That's why we will increasingly tell vendors that
straight DOI links are a very minimal level of service (just one step better
than hard-wired links to publisher sites).  The preferred solution for
licensed services will be to include an OpenURL resolver's base URL in the
customer profile information.

Thomas Dowling
Ohio Library and Information Network
tdowling at ohiolink.edu