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:
- Encoding.
- State.
- HTTP Transport mechanism.
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:
- Z39.50-stateless
- 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:
- encapsulation of Search within Init
- and either:
- encalsulation of Present within Search, or
- piggyback Present
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:
- 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.
- 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:
- send every PDU in an HTTP request, where the corresponding HTTP response is essentially empty;
- map the Z39.50 state machine directly onto the http (hypothetical) state machine.
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:
- Z39.50 request from client followed by a trigger-resource-control request.
- Resource-control request from server specifying "no response".
- Segmentation.
- Concurent Operations.
And in addition, the Close service may be used only as follows:
- A close request may be initiated by the client, only when there is no operation in progress.
- A close request may be initiated by the server, only when there is an operation in progress. It would be issued in lieu of the operation response and would map to an HTTP response.There may be no Close response from the client.
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.