Subject: Re: Access from publisher?
GullifB@utrc.utc.com
Date: Mon, 30 Aug 1999 12:50:03 -0400
From: GullifB@utrc.utc.com Message-Id: <D241ECCF8B34D21185C700805FA72468015E7FED@EXPRESS7> To: arl-ejournal@arl.org Subject: Re: Access from publisher? Date: Mon, 30 Aug 1999 12:50:03 -0400
On Mon, 30 Aug 1999, Anke de Looper <anke.delooper@benjamins.nl> wrote:
>
> John Benjamins is a small commercial scholarly publisher with an
> extensive list in linguistics and related topics. At this moment
> we publish 27 journals and yearbooks. We intend to make our journals
> available electronically starting in 2000.
>
> We are working on the technical infrastructure at our side, which should
> --ideally-- match the client's side.
>
> I would very much appreciate some feedback on the following (direct
> replies or pointers to relevant literature):
>
> 1) Libraries seem to favor IP-controlled access over passwords. Is that
> so, and why? I thought passwords would allow greater flexibility in
> offering access to patrons even if they are off-site. Also, IP
> authentications is problematic (see ARL-EJOURNAL messages in
> February about JANET cache).
>
> 2) Do libraries (prefer to) download an issue of an electronic journal
> once, to offer access to patrons from a local server, or is the
> issue/document downloaded from the publisher's server by each
> patron in turn? Does this depend on what the publisher allows?
>
> Any comments, suggestions or pointers are appreciated.
Our corporation is spread over many countries and locations, each a
petty computer baronetcy of its own, so we have no hope of consolidating
our end users under one domain name or IP address.
We do provide our list of possible IP addresses to vendors (publishers)
who must authenticate that way, but as soon as one of the local DP shops
adds a new firewall without telling anyone, we have to find out about
it from suddenly disenfranchised users, find out the new IP, and notify
all the vendors we connect with in that way.
It is for that reason that we prefer password access. Having users
remember and enter passwords is impractical because users forget and
have to call the library or systems office to have the passwords reset,
so we embed the userid and password into the URL for the journal link.
Despite that seemingly loose security the arrangement has worked well
for all parties concerned. In the years we have done this we have
discovered maybe one or two clever users who deciphered the password
and took it home or to their next workplace. We consider this an
adequate tradeoff. We make it very clear to publishers how we're going
to make access to their products available, emphasizing that we do have
a secure intranet (keeping out users from outside our corporation), and
they have all agreed to our arrangement. Just like with copyright
permissions, I tell the publisher what we want to do and as long as
they say OK, we proceed according to our word.
Publishers can always re-evaluate the contract at renewal time. We
have even had an occasional case of a publisher calling us mid-year,
saying the usage statistics are so high or so low that they want to
revise the contract immediately. We are not the regular,
every-user-and-location-accounted-for institution publishers say they
expect, so giving them this way out puts them at ease.
We decided, upon conversion of our library operation to a "virtual"
service making most information available electronically, to access
all electronic materials remotely instead of loading tapes onto our
own disk drives. As a result, we suffer from reliability problems
and our licensing agreements are a little bit different from a
traditional library's, but we choose to concentrate our resources on
access and on-time delivery. We support a business, not a scholarly
community. We do not have to deal with caching servers (well,
actually, I think a computer fiefdom in one of our divisions just
installed one, to improve performance). This seems to matter to
publishers when we negotiate agreements.
On the other hand, I think Boeing Co. takes the opposite approach and
loads data locally. It makes life easier in some ways.
United Technologies Corp. would not be typical of John Benjamins
clientele, but I offer our perspective in hopes of being informative
to the discussion in general.
Brad Gulliford
Project Manager, I-Net Team
United Technologies Information Network
East Hartford, Connecticut USA
860 610-7902
<gullifb@utrc.utc.com>
This archive was generated by hypermail 2a16 : Mon Dec 20 1999 - 18:02:16 EST