W3C home > Mailing lists > Public > www-webdav-dasl@w3.org > July to September 1999

Z39.50 over HTTP

From: Jim Whitehead <ejw@ics.uci.edu>
Date: Mon, 5 Jul 1999 12:59:56 -0700
To: www-webdav-dasl@w3.org
Message-ID: <NDBBIKLAGLCOPGKGADOJGENPCAAA.ejw@ics.uci.edu>
At http://lcweb.loc.gov/z3950/agency/zhttp.html there is a document titled,
"Profile for Z39.50 over HTTP" (Second Draft, April 7, 1999).

Since Z39.50 is a stateful protocol, the hardest issues discussed in this
draft are how to map the stateful protocol onto stateless HTTP.  The draft
discusses two approaches, using Z39.50 in a stateless mode, and using Z39.50
statefully, running over stateless HTTP (passing a session identifier with
each request/response).

Z39.50 uses ASN.1 encoded using the Basic Encoding Rules (BER).  This
proposal suggests continuing to use ASN.1, instead using XML Encoding Rules
(XER) <http://asf.gils.net/xer/index.html>.

The proposal suggests using the DASL SEARCH method, which sounds good to me.
This does raise a tiny, yet solvable issue in the current DASL spec.  Right
now, using DASL, it's possible to submit a search request using any search
syntax.  However, in the current DASL protocol spec., no matter which search
syntax you use, the response must come back using the PROPFIND response
format.  Since this Z39.50 proposal suggests returning the results in
XER-encoded ASN.1, this violates the "return results using PROPFIND format"
rule.

But, it makes sense to me that a different query grammar might very well
return a response using a different response format than PROPFIND. That is,
if you have good reason to change the query request, you may very well have
good reasons to change the response format as well.  As a result, I
recommend we tweak the PROPFIND response requirement, replacing it with:

Query responses are STRONGLY RECOMMENDED to use the PROPFIND response
format, but MAY use other response formats.  A specific query grammar MUST
always use the same response format, whether PROPFIND or other.

This would replace text at the beginning of Section 2.4.  There are a couple
of extensibility options available here (new status code, use of a new MIME
type for XER responses, etc.) -- some thought will need to go into just how
to phrase this.

- Jim
Received on Monday, 5 July 1999 16:18:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 22 March 2009 03:38:04 GMT