[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [doi-twg] FW: [handle-dev] New version of proxy server

To: "Hammond, Tony (ELSLON)" <T.Hammond@elsevier.com>
Subject: Re: [doi-twg] FW: [handle-dev] New version of proxy server
From: Larry Lannom <llannom@cnri.reston.va.us>
Date: Tue, 19 Nov 2002 16:54:22 -0500
Cc: "'doi-twg@doi.org'" <doi-twg@doi.org>, "'jeuler@cnri.reston.va.us'" <jeuler@cnri.reston.va.us>, "'handle-dev@cnri.reston.va.us'" <handle-dev@cnri.reston.va.us>
In-reply-to: <54A600C436EA694581B93E4BD4D4788A0565930C@elslonexc004.wins.epress.co.uk>
List-id: Handle System Developers' Mailing List <handle-dev.cnri.reston.va.us>
Sender: handle-dev-admin@cnri.reston.va.us

The OpenURL interface is coming. We'll continue to support the handle?parameters syntax, since that's been around for quite some time now,
but I hope to exercise the new OpenURL spec in this way when it is put out for trial use.

Thanks for looking at the new version. Point on needing a spec on this is well taken. All feedback appreciated.

Larry

On Tuesday, November 19, 2002, at 05:10 AM, Hammond, Tony (ELSLON) wrote:

Forwarding this to the TWG as it affects DOI as well. Lots of good news
(Tomcat server, redirect to base URL, whitespace trim, GET querystrings, etc
- see original post to hdl-dev) but some questions about querystring
implementation.

Tony

-----Original Message-----
From: Hammond, Tony (ELSLON)
Sent: 19 November 2002 10:05
To: 'Jane Euler'; handle-dev@cnri.reston.va.us
Subject: RE: [handle-dev] New version of proxy server

Is there any spec to show how parameters should be passed in GET
querystrings? Seems that one must append a querystring to the pathinfo
variable for the handle, ie something like

http://hdl.handle.net/10.1006/geno?noredirect=on

I would however have expected something more like the following (ie the GET
equivalent of the data POST) to be implemented

http://hdl.handle.net/?hdl=10.1006/geno&noredirect=on

but this does not work. (So seems there is a GET/POST asymmetry.)

Better still would have been an OpenURL (v1.0) interface, ie something like

http://hdl.handle.net/?url_ver=Z39.88-2003&rft_id=ori:hdl:10.1006/geno&srv_i
d=uri:hdl:srv/noredirect

The OpenURL is readily detected (and actioned) as such through the mandatory
version number (value of "url_ver"). The handle is given as the referent
identifier (value of "rft_id"). Service directives could be included via
"srv_id" parameters, where individual services would be identified with
their own handles.

Thanks,
Tony

-----Original Message-----
From: Jane Euler [mailto:jeuler@cnri.reston.va.us]
Sent: 18 November 2002 20:07
To: handle-dev@cnri.reston.va.us
Subject: [handle-dev] New version of proxy server

Hi All:
The Handle proxy server (hdl.handle.net/dx.doi.org) will be upgraded to a
new version tonight at approximately 11:30pm EST.
The new features are listed below.

The amount of downtime will be unnoticeable.
Please let us know if you experience any problems.

Thanks
Jane Euler
CNRI

--------------------------------------

o Now based on Apache Tomcat for better extensibility.
o Will now redirect to the URL value with the lowest index. Previously, the
proxy would redirect to an arbitrary URL in DOIs/Handles with multiple URLs.
o A new parameter "urlappend" allows an opaque character string to be
appended to the target URL.
o Whitespace is now trimmed from POST requests. This is useful for when
handles entered into the query form at hdl.handle.net or dx.doi.org have
leading or trailing spaces. Previously these spaces were interpreted as
part of the handle.
o Handle value data display now shows readable fields for binary types like
HS_ADMIN and HS_VLIST.
o Parameters passed though POST can also be passed through GET requests.
This includes parameters such as noredirect, authoritative, types, indices,
etc.

_______________________________________________
handle-dev mailing list
handle-dev@cnri.reston.va.us
http://www.cnri.reston.va.us/mailman/listinfo/handle-dev

Forwarding this to the TWG as it affects DOI as well. Lots of good news
(Tomcat server, redirect to base URL, whitespace trim, GET querystrings, etc
- see original post to hdl-dev) but some questions about querystring
implementation.

Tony

-----Original Message-----
From: Hammond, Tony (ELSLON)
Sent: 19 November 2002 10:05
To: 'Jane Euler'; handle-dev@cnri.reston.va.us
Subject: RE: [handle-dev] New version of proxy server

Is there any spec to show how parameters should be passed in GET
querystrings? Seems that one must append a querystring to the pathinfo
variable for the handle, ie something like

http://hdl.handle.net/10.1006/geno?noredirect=on

I would however have expected something more like the following (ie the GET
equivalent of the data POST) to be implemented

http://hdl.handle.net/?hdl=10.1006/geno&noredirect=on

but this does not work. (So seems there is a GET/POST asymmetry.)

Better still would have been an OpenURL (v1.0) interface, ie something like

http://hdl.handle.net/?url_ver=Z39.88-2003&rft_id=ori:hdl:10.1006/geno&srv_i

d=uri:hdl:srv/noredirect

The OpenURL is readily detected (and actioned) as such through the mandatory
version number (value of "url_ver"). The handle is given as the referent
identifier (value of "rft_id"). Service directives could be included via
"srv_id" parameters, where individual services would be identified with
their own handles.

Thanks,
Tony

-----Original Message-----
From: Jane Euler [mailto:jeuler@cnri.reston.va.us]
Sent: 18 November 2002 20:07
To: handle-dev@cnri.reston.va.us
Subject: [handle-dev] New version of proxy server

Hi All:
The Handle proxy server (hdl.handle.net/dx.doi.org) will be upgraded to a
new version tonight at approximately 11:30pm EST.
The new features are listed below.

The amount of downtime will be unnoticeable.
Please let us know if you experience any problems.

Thanks
Jane Euler
CNRI

--------------------------------------

o Now based on Apache Tomcat for better extensibility.
o Will now redirect to the URL value with the lowest index. Previously, the
proxy would redirect to an arbitrary URL in DOIs/Handles with multiple URLs.
o A new parameter "urlappend" allows an opaque character string to be
appended to the target URL.
o Whitespace is now trimmed from POST requests. This is useful for when
handles entered into the query form at hdl.handle.net or dx.doi.org have
leading or trailing spaces. Previously these spaces were interpreted as
part of the handle.
o Handle value data display now shows readable fields for binary types like
HS_ADMIN and HS_VLIST.
o Parameters passed though POST can also be passed through GET requests.
This includes parameters such as noredirect, authoritative, types, indices,
etc.

_______________________________________________
handle-dev mailing list
handle-dev@cnri.reston.va.us
http://www.cnri.reston.va.us/mailman/listinfo/handle-dev

_______________________________________________
handle-dev mailing list
handle-dev@cnri.reston.va.us
http://www.cnri.reston.va.us/mailman/listinfo/handle-dev

From handle-dev-admin@cnri.reston.va.us Thu Jan 23 20:21:39 2003
Return-Path: <handle-dev-admin@cnri.reston.va.us>
Received: from www1 by www1.cnri.reston.va.us (SMI-8.6/SMI-SVR4)
id UAA08229; Thu, 23 Jan 2003 20:19:45 -0500
Received: from cnri.reston.va.us by www1.cnri.reston.va.us (SMI-8.6/SMI-SVR4)
id UAA08201; Thu, 23 Jan 2003 20:19:38 -0500
Received: from jupiter.natlib.govt.nz (jupiter.natlib.govt.nz [210.55.131.76])
by cnri.reston.va.us (8.11.6+Sun/8.11.3) with ESMTP id h0O1JqN15029;
Thu, 23 Jan 2003 20:19:53 -0500 (EST)
Received: from jupiter.natlib.govt.nz (localhost [127.0.0.1])
by jupiter.natlib.govt.nz (8.10.1/8.10.1) with ESMTP id h0O1Jmj27708;
Fri, 24 Jan 2003 14:19:48 +1300 (NZDT)
Received: from planet.natlib.govt.nz (planet.natlib.govt.nz [192.122.171.130])
by jupiter.natlib.govt.nz (8.10.1/8.10.1) with ESMTP id h0O1Jl427698;
Fri, 24 Jan 2003 14:19:47 +1300 (NZDT)
Received: from gwia.natlib.govt.nz (kursk.natlib.govt.nz [210.55.131.57])
by planet.natlib.govt.nz (8.11.1/8.11.1) with SMTP id h0O1Jqg17830;
Fri, 24 Jan 2003 14:19:53 +1300 (NZDT)
Received: from WNDomain-Message_Server by gwia.natlib.govt.nz
with Novell_GroupWise; Fri, 24 Jan 2003 14:22:30 +1300
Message-Id: <se314c26.033@gwia.natlib.govt.nz>
X-Mailer: Novell GroupWise 5.5.4
Date: Fri, 24 Jan 2003 14:19:38 +1300
From: "Lockie Stewart" <Lockie.Stewart@natlib.govt.nz>
To: <jeuler@cnri.reston.va.us>
Cc: <handle-dev@cnri.reston.va.us>,
"Dave Thompson" <dave.thompson@natlib.govt.nz>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Subject: [handle-dev] Hi Jane,
Sender: handle-dev-admin@cnri.reston.va.us
Errors-To: handle-dev-admin@cnri.reston.va.us
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Handle System Developers' Mailing List <handle-dev.cnri.reston.va.us>
X-BeenThere: handle-dev@cnri.reston.va.us
content-length: 1910

Hi Jane,

Seeking a robust handle environment at National Library of NZ leads us to =
install handle servers on two host (tainui and fred)=20
Our dns entry handle.natlib.govt.nz resolves to tainui. (tainui CNAME =
handle.natlib.govt.nz , fred CNAME bogus.natlib.govt.nz)

If we want to change the handle server from tainui to fred we can do so by =
altering the dns entries so that the handle.natlib.govt.nz resolves to =
fred. (tainui CNAME bogus.natlib.govt.nz , fred CNAME handle.natlib.govt.n=
z)

The question therefore becomes : how do we keep the handle databases in =
sync between the two hosts ? In other words is there a file or files that =
we can ftp between servers such that the contents are the same on both of =
the hosts ?

This of course assumes that there is not a master/secondary handle server =
heirarchy reflected on the hosts, that we take it upon ourselves to ensure =
administration of handles occurs on the correct host , and that the =
replication follows.

Regards, Lockie

V V DBA
V V National Library of New Zealand =
=20
\ / Ph 0064 4 4743134 x 8720=20
< .. >___ Mobile 0064 21 648044 =20
U } Fax 0064 4 474 3140 =20
yyyy Pager dba.pager@natlib.govt.nz =20
=
--------------------------------------------------
=20
=
=20
=20

_______________________________________________
handle-dev mailing list
handle-dev@cnri.reston.va.us
http://www.cnri.reston.va.us/mailman/listinfo/handle-dev

From handle-dev-admin@cnri.reston.va.us Wed Jan 29 14:59:13 2003
Return-Path: <handle-dev-admin@cnri.reston.va.us>
Received: from www1 by www1.cnri.reston.va.us (SMI-8.6/SMI-SVR4)
id OAA26794; Wed, 29 Jan 2003 14:56:59 -0500
Received: from cnri.reston.va.us by www1.cnri.reston.va.us (SMI-8.6/SMI-SVR4)
id OAA26765; Wed, 29 Jan 2003 14:56:56 -0500
Received: from abyssus.doit.wisc.edu (abyssus.doit.wisc.edu [128.104.19.201])
by cnri.reston.va.us (8.11.6+Sun/8.11.3) with ESMTP id h0TJvDN14219
for <handle-dev@cnri.reston.va.us>; Wed, 29 Jan 2003 14:57:13 -0500 (EST)
Received: from abyssus.doit.wisc.edu (msimpson@localhost)
by abyssus.doit.wisc.edu (8.11.6/8.11.6) with ESMTP id h0TJx9F32524
for <handle-dev@cnri.reston.va.us>; Wed, 29 Jan 2003 13:59:10 -0600
Message-Id: <200301291959.h0TJx9F32524@abyssus.doit.wisc.edu>
X-Mailer: exmh version 2.4 06/23/2000 with nmh-1.0.4
To: handle-dev@cnri.reston.va.us
Subject: Re: [handle-dev] Hi Jane, In-Reply-To: Your message of "Fri, 24 Jan 2003 14:19:38 +1300."
<se314c26.033@gwia.natlib.govt.nz> Reply-to: mike.simpson@doit.wisc.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 29 Jan 2003 13:59:09 -0600
From: Mike Simpson <msimpson@abyssus.doit.wisc.edu>
Sender: handle-dev-admin@cnri.reston.va.us
Errors-To: handle-dev-admin@cnri.reston.va.us
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Handle System Developers' Mailing List <handle-dev.cnri.reston.va.us>
X-BeenThere: handle-dev@cnri.reston.va.us
content-length: 5782

Lockie et al. --

I'm in the process of trying to set up something similar for the
UW-Madison Libraries handle servers ... replication and automated failover in the case of the primary server going down. I'm trying to make sense of the documentation and what I see in the naming authority handle, and I admit I'm getting stuck. Hopefully others on this list will have already solved this problem ...

We have a primary server ("handle-1") living at IP 144.92.161.72,
ports 2641 (tcp, udp) and 2652 (http), serving the 0.NA/1711 naming
authority. I want to replicate and failover to a mirror server
("handle-2") living at IP 144.92.161.73 (same port assignments as the
primary).

From looking primarily at Section 10 ("Replication") in the
Administration Manual, and various other bits and pieces, it looks like two things have to happen:

(a) setup the mirror server and get replication authentication established. To do this, run the "Simple Setup" as detailed in the INSTALL file. Answer "n" to the "Will this be a primary server?" question, then enter the IP and port number of the primary server when prompted (i.e. for us, 144.92.161.72:2641). The setup program prompts for a server key (which we don't encrypt, since we have to do unattended restarts), skips prompting for an administrative key (only relevant for primary servers), and the prompts for a "replication authentication" key.

-> question #1: If I choose to encrypt the replication authentication key, will I need to enter the password at server startup, or otherwise periodically? I.e. is it more like the server key, or more like the administrative key?

The program finishes by telling you to email the sitebndl.zip file to CNRI. They use it to update the HS_SITE information in the 0.NA handle, I'm guessing (see below).

Then you have to modify the config.dct file in various ways. The instructions in the Admin Manual seem a little vague to me. You need to modify "server_admins" ...

-> question #2: What value do I put there? The same as in the primary, i.e. for us "300:0.NA/1711"?

and "this_server_id" ...

-> question #3: The manual says that you must modify this "if more than 1 server in HS_SITE". Does a mirror server, running on a seperate host at a seperate IP, wind up as another entry in a single HS_SITE record, or as a seperate HS_SITE record entirely?
Do I need to change this number so that it's different from the
primary?

and "replication_authentication" ...

-> question #4: What goes here? The manual doesn't say. The setup
program, for me, filled in "privatekey:300:0.NA/1711". Is this correct?

Then, the manual says you have to modify the config.dct for the primary server. These directions are even less clear to me:

-> question #5: I'm supposed to "Add the replication public key
value(`replpub.bin') to the handle specified in
replication_authentication.". My primary doesn't have any
value set for "replication_authentication". And do I need to copy "replpub.bin" over to the primary server directory?

-> question #6: Then I need to "Add that handle to the primary
server's replication_admins group in its `config.dct' file."
What handle is "that handle"?

-> question #7: There's a step that needs to be done "ONLY if mirror servers are under the same HS_SITE". Same question as #3 above; also, the proceeding line in the manual states that "The `txnsrcsv.bin' file is the `siteinfo.bin' file from the
primary server." Does that mean I have to copy the primary's
"siteinfo.bin" into place under the mirror as "txnsrcsv.bin"?

(b) Once all the above is ready, then we go to what has to happen at the 0.NA (CNRI) end. This is more or less black magic to me, but from looking at our naming authority handle (0.NA/1711) it looks like a second HS_SITE record has to be created. I.e. the existing HS_SITE record has a yes/no value for "Primary Site" for the record as a whole, although it looks like you could have multiple servers all participating as your "primary site". From the "Handle System Namespace and Service Definition", section 3.2.2, it looks like a "service site" (HS_SITE?) can be one or more server instances running on one or more hosts; the "<PrimaryMask>" field of the HS_SITE record specifies whether or not a given HS_SITE is a "primary" (as opposed to mirror?) as well as whether or not there are multiple primary sites. Here, "primary" seems to mean "able to do handle administration tasks".

-> question #8: So for a plain ol' replicated mirror of the 1711
naming authority, does CNRI wind up adding another HS_SITE record to the 0.NA/1711 handle, with the "<PrimaryMask>" field zeroed out ("this service site is not a primary, nor are there multiple
primaries under this naming authority")?

This seems to match up with what's defined in the "Handle System Protocol (ver 2.1) Specification", sections 3.1.2 and 3.1.3. I'm probably missing it, but I couldn't find anything specified for client behavior when the primary server is down, under section 3.2.3. My assumption would be that a "well-behaved" client would pull all of the HS_SITE records for a given NA, try the first one, then try the next if the primary is down, etc. Although I can't find that defined in the protocol document (but I've only scanned it so far, haven't read the whole thing as of yet).

Anyway ... anyone done this? Am I on the right track, or completely round the bend? :)

-mgs

_______________________________________________
handle-dev mailing list
handle-dev@cnri.reston.va.us
http://www.cnri.reston.va.us/mailman/listinfo/handle-dev

From handle-dev-admin@cnri.reston.va.us Wed Mar 26 07:39:06 2003
Return-Path: <handle-dev-admin@cnri.reston.va.us>
Received: from www1 by www1.cnri.reston.va.us (SMI-8.6/SMI-SVR4)
id HAA15182; Wed, 26 Mar 2003 07:33:25 -0500
Received: from ns.cnri.reston.va.us by www1.cnri.reston.va.us (SMI-8.6/SMI-SVR4)
id HAA15164; Wed, 26 Mar 2003 07:33:17 -0500
Received: from elslonexc001.epress.co.uk ([194.128.151.2])
by ns.cnri.reston.va.us with esmtp (Exim 4.12)
id 18yA6O-0002NU-00
for handle-dev@cnri.reston.va.us; Wed, 26 Mar 2003 07:33:56 -0500
Received: by elslonexc001.epress.co.uk with Internet Mail Service (5.5.2653.19)
id <HTWA1R7Z>; Wed, 26 Mar 2003 12:33:03 -0000
Message-ID: <54A600C436EA694581B93E4BD4D4788A06B7383B@elslonexc004.wins.epress.co.uk>
From: "Hammond, Tony (ELSLON)" <T.Hammond@elsevier.com>
To: "'handle-dev@cnri.reston.va.us'" <handle-dev@cnri.reston.va.us>
Date: Wed, 26 Mar 2003 12:33:07 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
charset="iso-8859-1"
Subject: [handle-dev] OpenHandle
Sender: handle-dev-admin@cnri.reston.va.us
Errors-To: handle-dev-admin@cnri.reston.va.us
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Handle System Developers' Mailing List <handle-dev.cnri.reston.va.us>
X-BeenThere: handle-dev@cnri.reston.va.us
content-length: 2218

For something different - an OpenHandle servlet:

http://hdl.handle.net/1014/open

You should be able to try any legitimate handle, eg

* for Elsevier handle service (1014)

1014/oboe
1014/yads
1014/1

* for DOI handle service (10)

10.1006/geno
10.1016/S0888-7543(03)00007-7
10.1000/240

* for Global handle service (0) - the most interesting

0.serv/10
0.na/10

(service and naming authority handles for DOI)

Tony

A few rough edges here and there but anyway. What is it?

* A simple declarative means for a user to interact with handle

* Uses the ANSI/NISO OpenURL Framework to query handle and
receive back a structured XML response. (OpenURL drafts posted
at <http://library.caltech.edu/openurl/Public_Comments.htm>)

* Alternate responses could include resolution to stored URI,
service referral, etc

* OpenURL Framework allows contextual information to be bundled along
with the query/response messaging

* An RDF schema (using OWL) is defined for the ContextObject Format
of the OpenURL Framework

* A handle is given as an OpenURL Referent Identifier - the full
handle record is then returned as Referent Private Data

* An RDF Schema is defined for a handle record - supports the
predefined handle types HS_ADMIN, HS_SITE, HS_SERV, HS_PRIMARY,
HS_ALIAS, HS_VLIST

* Service data is passsed up as ServiceType Identifiers (for service
directives - eg authoritative query, etc) or as ServiceType
Metadata (service filtering - on index/type), and is passed back
as ServiceType Private Data (service messages)

* Controversial point - handle references are given compactly in
handle URIref form - eg <hdl://0.NA/1006#index=200> indicates
the handle value at index 200 for the handle 0.NA/1006

* Handle URIref form is how a handle client would address into a
handle resource - suggest that an alternate means of filtering
handle values is to use a fragment identifier syntax, eg
<#index=2;type=url> to return values of type URL at index 2
* In sum - Resource Description Framework over OpenURL Framework

_______________________________________________
handle-dev mailing list
handle-dev@cnri.reston.va.us
http://www.cnri.reston.va.us/mailman/listinfo/handle-dev

Prev by Date: RE: [handle-dev] New version of proxy server
Next by Date: RE: [doi-twg] FW: [handle-dev] New version of proxy server
Previous by thread: [handle-dev] New version of proxy server
Next by thread: RE: [doi-twg] FW: [handle-dev] New version of proxy server
Index(es):
- Date
- Thread