Proposed Work Item:

Profile for Z39.50 over HTTP

Discussion Paper

Second Draft
April 7, 1999

This is a second draft of a discussion paper aimed towards a profile for Z39.50 over HTTP. Comments are solicited, in particular, see "Comments solicited" in the "Ed. note"s.

The following architectural issues are addressed:

1. Encoding

For the proposed profile, Z39.50 APDUs will continue to be described in ASN.1 (using the abstract syntax defined in the Z39.50 standard) though not encoded in BER, but rather in XML, via XER.

2. State

There will be requirements for both stateful as well as stateless Z39.50 applications over the web. Two levels of "stateness" are defined:
  1. Z39.50-stateless
  2. Z39.50-stateful/HTTP-stateless
Ed. note: discussion from the previous draft of "HTTP stateful" mode is removed from this draft, based on comment from the earlier draft.

2.1 Z39.50 Stateless Mode

For Z39.50-stateless mode, a single HTTP request/response sequence will comprise an entire Z-association. A Z39.50 request maps to an HTTP request and a Z39.50 response maps to an HTTP response. (A Z39.50 request or response with encapsulated requests or responses is considered a single Z39.50 request or response for purposes of this mapping.)

Z39.50 stateless mode requires encapsulation. At minimum, the following must be supported:

Ed. Note: Consideration should also be given to whether there should be a requirement to support encapsulation of Close. If the client includes an encapsulated Close, then the server may infer stateless mode. If the client does not include Close, it is not clear how to otherwise convey stateless mode (one alternative, proposed below, is by absence of a session id). Comments solicited on this question.

2.2 Z39.50 Stateful/HTTP-stateless Mode

For Z39.50-stateful/HTTP-stateless mode, a Z-association may be maintained across multiple (serial) TCP connections. A "session-id" definition will be developed to support this.

The session-id might be used to convey stateful mode. Thus if the client does not include a session-id with an Init, stateless mode would be inferred (and therefore the requirement to encapsulate Close in stateless mode would not be necessary).

2.3 Mapping Requests and Responses

For mapping of Z39.50 requests and responses to HTTP requests and responses, two approaches are possible:
  1. Z39.50 request from client maps to http request and the respective Z39.50 response maps to the respective http response. Z39.50 requests from server, Z39.50 responses from client, and any instance where the Z39.50 state machine allows a client or server to send two consecutive messages (without an intervening message from the other), are all dissallowed.
  2. Map client messages to requests and server messages to responses (regardless or whether they are cast as requests or responses in Z39.50), profiling out the troublesome cases (listed below).
Ed. note: the following approaches, discussed in the earlier draft, have been discarded:
Approach 1 is assumed for the Z39.50 stateless mode, and either approach 1 or 2 could be used for Z39.50 stateful mode. For approach 2, the client sends, for example, a Search Request in an HTTP request and the server might send an AccessControl Request in the HTTP response. The client send an AccessControl Response in an HTTP request and the server sends a Search response in an HTTP response.
Ed. note: though this has been substantially streamlined since the earlier draft, is it still suceptible to the perception that it attempts to support asynchronous operation? This was one of the complaints from the earlier draft. This does not attempt to support asynchronous operation, however, if this approach is still going to cause confusion, I suggest we should streamline this further and simply dissallow access control and resource control. Comments solicited on this question.

The following (where the Z39.50 state machine allows a client or server to send two consecutive messages without an intervening message from the other) would be excluded by the profile:

And in addition, the Close service may be used only as follows: In addition, if request/response mapping-approach 1 is used, then Access Control and Resource control will be excluded, and Close may be initiated by the client only (and only when there is no operation in progress).

3. Transport Mechanism

It is anticipated that Z39.50 PDUs will be encapsulated within HTTP protocol messages using the "Search" method (as does DASL).
Ed. Note: Comments solicited on the proposal to use the "Search" method, as opposed to some other HTTP method, for instance "Post".
The mappings are yet to be worked-out.