1 |
IETF URI Working Group R. Denenberg |
2 |
Internet-Draft J. Kunze |
3 |
draft-ietf-uri-url-irp-00.txt B. McLean |
4 |
22 November 1994 Editors |
5 |
Expires in six months |
6 |
|
7 |
Uniform Resource Locators for Z39.50 |
8 |
|
9 |
|
10 |
1. Status of this Document |
11 |
|
12 |
This document is an Internet-Draft. Internet-Drafts are working documents |
13 |
of the Internet Engineering Task Force (IETF), its Areas, and its Working |
14 |
Groups. Note that other groups may also distribute working documents as |
15 |
Internet-Drafts. |
16 |
|
17 |
Internet-Drafts are working documents valid for a maximum of six months. |
18 |
Internet-Drafts may be updated, replaced, or obsoleted by other documents |
19 |
at any time. It is not appropriate to use Internet-Drafts as reference |
20 |
material or to cite them other than as a ``working draft' or ``work in |
21 |
progress.'' |
22 |
|
23 |
To learn the current status of any Internet-Draft, please check the |
24 |
1id-abstracts.txt listing contained in the Internet-Drafts Shadow |
25 |
Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or |
26 |
munnari.oz.au. |
27 |
|
28 |
Distribution of this document is unlimited. Please send comments to |
29 |
jak@violet.berkeley.edu, or to the discussion lists uri@bunyip.com and |
30 |
z3950iw@nervm.nerdc.ufl.edu. |
31 |
|
32 |
|
33 |
2. Introduction |
34 |
|
35 |
Z39.50 is an information retrieval protocol that does not fit neatly into |
36 |
a retrieval model designed primarily around the stateless fetch of data. |
37 |
Instead, it models a general user inquery as a session-oriented, multi- |
38 |
step task, any step of which may be suspended temporarily while the |
39 |
server requests additional parameters from the client before continuing. |
40 |
Some, none, or all of these client/server interactions may require |
41 |
participation of the client user, depending only on the client software |
42 |
(the protocol itself make no such requirements). |
43 |
|
44 |
On the other hand, retrieval of "well-known" data may be performed in |
45 |
a single step, that is, with a degenerate Z39.50 session consisting of |
46 |
exactly one protocol search request and response. Besides the basic |
47 |
search sub-service, there are several ancillary sub-services (e.g., Scan, |
48 |
Result Set Delete). Among the functions covered by combinations of the |
49 |
sub-services, two core functions emerge as appropriately handled by two |
50 |
separate URL schemes: the Session URL and the Retrieval URL. |
51 |
|
52 |
Using two schemes instead of one makes a critical distinction between |
53 |
a Z39.50 Session URL, which opens a client session -- leaving the user |
54 |
to close it -- and a Z39.50 Retrieval URL, which opens and closes a client |
55 |
session, then displays any retrieved results. Making this distinction at |
56 |
the scheme level allows the user interface to reflect it on to the user, |
57 |
but without actually requiring the user display formatter to parse |
58 |
otherwise opaque parts of the URL (consistent with current practice). |
59 |
|
60 |
|
61 |
3. The Z39.50 Session URL |
62 |
|
63 |
The Z39.50 Session and Retrieval URLs follow the Common Internet Scheme |
64 |
Syntax as defined in RFC ???, "Uniform Resource Locators (URL)" [1]. |
65 |
The specific syntax for the Session URL is: |
66 |
|
67 |
z39.50s://host[:port] |
68 |
[/database[+database...] |
69 |
[?docid |
70 |
[&esn=elementset] |
71 |
[&rs=recordsyntax[+recordsyntax...]]]] |
72 |
|
73 |
This may be informally described as providing the mechanism to switch |
74 |
the user of the browser to a window in which a Z39.50 client is running. |
75 |
|
76 |
- Host is required. |
77 |
- Port is optional, and defaults to 210. |
78 |
- All other parameters are optional, however, if docid is present, |
79 |
then database must be present. |
80 |
- The Z39.50 client will start a session to the specified host/port |
81 |
(alternatively, it need not explicitly start a session, but may |
82 |
instead utilize an already open session to the same host/port). |
83 |
- If docid is included, the client will perform the specified search |
84 |
(in the same manner as for the retrieval URL, specified below). |
85 |
- If docid is not included, and other parameters (besides host/port) |
86 |
are specified, the client may use those parameters as "hints". |
87 |
Various clients may choose to treat them as requirements, or as |
88 |
preferences, or ignore them. |
89 |
- In any case (whether a search is performed or not), the client will |
90 |
leave the Z39.50 session open for the user, to do retrievals, new |
91 |
searches, etc. This is the main distinction from the z39.50r URL. |
92 |
|
93 |
|
94 |
4. The Z39.50 Retrieval URL |
95 |
|
96 |
The specific syntax for the Retrieval URL is: |
97 |
|
98 |
z39.50r://host[:port] |
99 |
[/database[+database...] |
100 |
[?docid |
101 |
[&esn=elementset] |
102 |
[&rs=recordsyntax[+recordsyntax...]]]] |
103 |
|
104 |
The model is designed for minimal interaction by the user with the Z39.50 |
105 |
session to be used as a transparent transfer mechanism if possible. The |
106 |
result of processing this URL should be a Result Set, which the client is |
107 |
responsible for returning to the user's browser in an appropriate form |
108 |
(e.g., HTML). |
109 |
|
110 |
- Host, database, and docid are required. |
111 |
- The docid is server-defined and otherwise opaque. |
112 |
- Port is optional, and defaults to 210. |
113 |
- If element set name (esn) is not specified, it is client's choice. |
114 |
If esn is specified, it should be used within the Search request for |
115 |
the value of small- and/or medium- set-element-set-names. These |
116 |
terms and their use are defined within the Z39.50 Standard [2]. |
117 |
- If record syntax (rs) is not specified, it is client's choice. |
118 |
If one or more record syntaxes are specified, the client should |
119 |
select one (preferably the first in the list that it supports) and |
120 |
use it within the Search request as the value of PreferredRecordSyntax. |
121 |
- The docid is placed into a type-1 query, as the single term, in |
122 |
the general format (tag 45), using the Bib-1 attribute set, with |
123 |
a Use attribute value of docid, and a structure attribute of URX. |
124 |
The docid string is completely opaque to the client. |
125 |
|
126 |
Future extensions to these URLs will be of the form of [&keyword=value]. |
127 |
|
128 |
|
129 |
5. Acknowledgements |
130 |
|
131 |
The Z39.50 Implementors Group contributed the substance of this document. |
132 |
|
133 |
|
134 |
6. References |
135 |
|
136 |
[1] Berners-Lee, T., Masinter, L., McCahill, M. (editors), "Uniform |
137 |
Resource Locators (URL)", soon to be RFC ???, October 1994. |
138 |
ftp://ds.internic.net/internet-drafts/draft-ietf-uri-url-09.txt |
139 |
|
140 |
[2] ANSI/NISO Z39.50-1992, "ANSI Z39.50: Information Retrieval Service |
141 |
and Protocol", Version 2, 1992, |
142 |
ftp://ftp.cni.org/pub/NISO/docs/Z39.50-1992/www/Z39.50.toc.html |
143 |
(also available in hard copy from Omnicom Information Service, |
144 |
115 Park St., SE, Vienna, VA 22180). |
145 |
|
146 |
7. Editors' Addresses |
147 |
|
148 |
Ray Denenberg |
149 |
Library of Congress |
150 |
Collections Services |
151 |
Network Development/MSO |
152 |
Washington DC 20540 |
153 |
ray@rden.loc.gov |
154 |
Voice: (202) 707-5795 |
155 |
Fax: (202) 707-0115 |
156 |
|
157 |
John A. Kunze |
158 |
Information Systems and Technology |
159 |
University of California at Berkeley |
160 |
293 Evans Hall |
161 |
Berkeley, CA 94720 |
162 |
jak@violet.berkeley.edu |
163 |
Voice: (510) 642-1530 |
164 |
Fax: (510) 643-5385 |
165 |
|
166 |
Bradley McLean |
167 |
Gaylord Information Systems |
168 |
7272 Morgan Rd. |
169 |
Liverpool, NY 13088 |
170 |
brad@bradpc.gaylord.com |
171 |
Voice: (315) 457-5070 |
172 |
Fax: (800) 272-3412 |