2004/id/draft-ietf-uri-url-irp-03.txt


IETF URI Working Group                                        R. Denenberg
Internet-Draft                                                J. Kunze
draft-ietf-uri-url-irp-03.txt                                 D. Lynch
1 October 1995                                                Editors


                  Uniform Resource Locators for Z39.50


1. Status of this Document

This document is an Internet-Draft.  Internet-Drafts are working documents
of the Internet Engineering Task Force (IETF), its Areas, and its Working
Groups.  Note that other groups may also distribute working documents as
Internet-Drafts.

Internet-Drafts are working documents valid for a maximum of six months.
Internet-Drafts may be updated, replaced, or obsoleted by other documents
at any time.  It is not appropriate to use Internet-Drafts as reference
material or to cite them other than as a ``working draft' or ``work in
progress.''

To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or
munnari.oz.au.

Distribution of this document is unlimited.  Please send comments to
jak@violet.berkeley.edu, or to the discussion lists uri@bunyip.com and
z3950iw@nervm.nerdc.ufl.edu.


2. Introduction

Z39.50 is an information retrieval protocol that does not fit neatly into
a retrieval model designed primarily around the stateless fetch of data.
Instead, it models a general user inquiry as a session-oriented, multi-
step task, any step of which may be suspended temporarily while the
server requests additional parameters from the client before continuing.
Some, none, or all of these client/server interactions may require
participation of the client user, depending only on the client software
(the protocol itself makes no such requirements).


On the other hand, retrieval of "well-known" data may be performed in
a single step, that is, with a degenerate Z39.50 session consisting of
exactly one protocol search request and response.  Besides the basic
search sub-service, there are several ancillary sub-services (e.g., Scan,
Result Set Delete).  Among the functions covered by combinations of the
sub-services, two core functions emerge as appropriately handled by two
separate URL schemes:  the Session URL and the Retrieval URL.

Using two schemes instead of one makes a critical distinction between a
Z39.50 Session URL, which opens a client session initialized for
interactive use by the user, and a Z39.50 Retrieval URL, which opens and
closes a client session to retrieve a specific information item.  Making
this distinction at the scheme level allows the user interface to reflect
it on to the user, without requiring the user interface to parse otherwise
opaque parts of the URL (consistent with current practice).   


3. The Z39.50 Session URL

The Z39.50 Session URL may be informally described as providing the 
mechanism to switch the user to a Z39.50 client application. 

   -  Host is required.
   -  Port is optional, and defaults to 210.
   -  All other parameters are optional.
   -  The Z39.50 client will start a session to the specified host/port
      (alternatively, it need not explicitly start a session, but may
      instead utilize an already open session to the same host/port).
   -  A database must be included if docid is included.
   -  If docid is included, the client will perform the specified search
      (in the same manner as for the retrieval URL, specified below).
   -  If docid is not included, and other parameters (besides host/port)
      are specified, the client may use those parameters as "hints".
      Various clients may choose to treat them as requirements, or as
      preferences, or ignore them.
   -  In any case (whether a search is performed or not), the client will
      leave the Z39.50 session open for the user, to do retrievals, new
      searches, etc.  (This is the main distinction from the Retrieval URL 
      which leaves it up to the client whether or not to keep the Z39.50 
      session open)".


4. The Z39.50 Retrieval URL

The Z39.50 Retrieval URL is intended to allow a Z39.50 session to be used
as a transparent transfer mechanism to retrieve a specific information
object.
A Z39.50 client uses information in the URL to formulate a Search Request.
The server's Search Response indicates how many records match the Request.
If the number of matching records does not equal one the retrieval is
considered
unsuccessful, and the client application's behavior is not defined. If the
number of matching records equals one the server may have included the desired
record in the Search Response. If not, the client requests transmission of
the record with a Present Request. After the client has received the
specified record it may close the Z39.50 session immediately, or keep it
open for subsequent retrievals.    
   -  Host is required.
   -  Port is optional, and defaults to 210.
   -  A database is required.
   -  The meaning of a retrieval URL with no docid is undefined.
   -  The docid is placed into a type-1 query, as the single term, in
      the general format (tag 45), using the Bib-1 attribute set, with
      a Use attribute value of docid, and a structure attribute of URx.
      The docid string is server-defined and completely opaque to the client.
   -  If element set name (esn) is not specified, it is the client's choice.
      If esn is specified, it should be used either in the Search
      request for the value of small- and/or medium- set-element-set-names
      or in a Present request following a Search.  These terms and their
      use are defined within the Z39.50 Standard [2].
   -  If record syntax (rs) is not specified, it is the client's choice.  If
one
      or more record syntaxes are specified, the client should select one
      (preferably the first in the list that it supports) and use it in
      a Search or Present request as the value of PreferredRecordSyntax.


5. BNF for Z39.50 URLs

The Z39.50 Session and Retrieval URLs follow the Common Internet Scheme
Syntax as defined in RFC 1738, "Uniform Resource Locators (URL)" [1].
In the definition, literals are quoted with "", optional elements
are enclosed in [brackets], "|" is used to designate alternatives,
and elements may be preceded with <n>* to designate n or more
repetitions of the following element; n defaults to 0.  


z39.50url      = zscheme "://" host [":" port]
                      ["/" [database *["+" database]
                             ["?" docid]]
                           [";esn=" elementset]
                           [";rs=" recordsyntax *[ "+" recordsyntax]]]

zscheme        = "z39.50r" | "z39.50s"
database       = uchar
docid          = uchar
elementset     = uchar
recordsyntax   = uchar

Future extensions to these URLs will be of the form of [;keyword=value].

The following definitions are from RFC 1738. Between the Internet Draft
version and RFC 1738 two relevant changes were made: '=' was moved from
the <extra> character class to <reserved>, and <national> was removed from
the alternatives in <unreserved>. Neither <national> nor <punctuation> is
referred to in this document nor in RFC 1738.

lowalpha       = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" |
                 "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" |
                 "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" |
                 "y" | "z"
hialpha        = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" |
                 "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" |
                 "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z"

alpha          = lowalpha | hialpha
digit          = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
                 "8" | "9"
safe           = "$" | "-" | "_" | "." | "+"
extra          = "!" | "*" | "'" | "(" | ")" | ","
national       = "{" | "}" | "|" | "\" | "^" | "~" | "[" | "]" | "`"
punctuation    = "<" | ">" | "#" | "%" | <">

reserved       = ";" | "/" | "?" | ":" | "@" | "&" | "="
hex            = digit | "A" | "B" | "C" | "D" | "E" | "F" |
                 "a" | "b" | "c" | "d" | "e" | "f"
escape         = "%" hex hex
unreserved     = alpha | digit | safe | extra
uchar          = unreserved | escape
xchar          = unreserved | reserved | escape
digits         = 1*digit

6. Security Considerations

The two Z39.50 URL schemes are subject to the same security implications
as the general URL scheme [1], so the usual precautions apply.  This means,
for example, that a locator might no longer point to the object that was
originally intended.  It also means that it may be possible to construct
a URL so that an attempt to perform a harmless idempotent operation such
as the retrieval of an object will in fact cause a possibly damaging
remote operation to occur.


7. Acknowledgements

The Z39.50 Implementors Group contributed the substance of this document.


8. References

   [1] Berners-Lee, T., Masinter, L., McCahill, M. (editors), "Uniform
       Resource Locators (URL)", RFC 1738, December 1994.
       ftp://ds.internic.net/rfc/rfc1738.txt

   [2] ANSI/NISO Z39.50-1994, "ANSI Z39.50:  Information Retrieval Service
       and Protocol", 1994.  ftp://ftp.loc.gov/pub/z3950/

   [3] ANSI/NISO Z39.50-1992, "ANSI Z39.50:  Information Retrieval Service
       and Protocol", 1992.
       ftp://ftp.cni.org/pub/NISO/docs/Z39.50-1992/www/Z39.50.toc.html
       (also available in hard copy from Omnicom Information Service,
       115 Park St., SE, Vienna, VA  22180).


7. Editors' Addresses

Ray Denenberg
Library of Congress
Collections Services
Network Development/MSO
Washington DC 20540
ray@rden.loc.gov
Voice: (202) 707-5795
Fax:   (202) 707-0115


John A. Kunze
Information Systems and Technology
University of California at Berkeley
293 Evans Hall
Berkeley, CA  94720
jak@violet.berkeley.edu
Voice: (510) 642-1530
Fax:   (510) 643-5385

Denis Lynch
TRW Business Intelligence Systems
1329 Moffet Park Drive
Sunnyvale, CA 94089
dml@bis.trw.com
Voice: (408) 541-6418
Fax:   (408) 541-6401
1
2	IETF URI Working Group R. Denenberg
3	Internet-Draft J. Kunze
4	draft-ietf-uri-url-irp-03.txt D. Lynch
5	1 October 1995 Editors
6
7
8	Uniform Resource Locators for Z39.50
9
10
11	1. Status of this Document
12
13	This document is an Internet-Draft. Internet-Drafts are working documents
14	of the Internet Engineering Task Force (IETF), its Areas, and its Working
15	Groups. Note that other groups may also distribute working documents as
16	Internet-Drafts.
17
18	Internet-Drafts are working documents valid for a maximum of six months.
19	Internet-Drafts may be updated, replaced, or obsoleted by other documents
20	at any time. It is not appropriate to use Internet-Drafts as reference
21	material or to cite them other than as a ``working draft' or ``work in
22	progress.''
23
24	To learn the current status of any Internet-Draft, please check the
25	1id-abstracts.txt listing contained in the Internet-Drafts Shadow
26	Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or
27	munnari.oz.au.
28
29	Distribution of this document is unlimited. Please send comments to
30	jak@violet.berkeley.edu, or to the discussion lists uri@bunyip.com and
31	z3950iw@nervm.nerdc.ufl.edu.
32
33
34	2. Introduction
35
36	Z39.50 is an information retrieval protocol that does not fit neatly into
37	a retrieval model designed primarily around the stateless fetch of data.
38	Instead, it models a general user inquiry as a session-oriented, multi-
39	step task, any step of which may be suspended temporarily while the
40	server requests additional parameters from the client before continuing.
41	Some, none, or all of these client/server interactions may require
42	participation of the client user, depending only on the client software
43	(the protocol itself makes no such requirements).
44
45
46	On the other hand, retrieval of "well-known" data may be performed in
47	a single step, that is, with a degenerate Z39.50 session consisting of
48	exactly one protocol search request and response. Besides the basic
49	search sub-service, there are several ancillary sub-services (e.g., Scan,
50	Result Set Delete). Among the functions covered by combinations of the
51	sub-services, two core functions emerge as appropriately handled by two
52	separate URL schemes: the Session URL and the Retrieval URL.
53
54	Using two schemes instead of one makes a critical distinction between a
55	Z39.50 Session URL, which opens a client session initialized for
56	interactive use by the user, and a Z39.50 Retrieval URL, which opens and
57	closes a client session to retrieve a specific information item. Making
58	this distinction at the scheme level allows the user interface to reflect
59	it on to the user, without requiring the user interface to parse otherwise
60	opaque parts of the URL (consistent with current practice).
61
62
63	3. The Z39.50 Session URL
64
65	The Z39.50 Session URL may be informally described as providing the
66	mechanism to switch the user to a Z39.50 client application.
67
68	- Host is required.
69	- Port is optional, and defaults to 210.
70	- All other parameters are optional.
71	- The Z39.50 client will start a session to the specified host/port
72	(alternatively, it need not explicitly start a session, but may
73	instead utilize an already open session to the same host/port).
74	- A database must be included if docid is included.
75	- If docid is included, the client will perform the specified search
76	(in the same manner as for the retrieval URL, specified below).
77	- If docid is not included, and other parameters (besides host/port)
78	are specified, the client may use those parameters as "hints".
79	Various clients may choose to treat them as requirements, or as
80	preferences, or ignore them.
81	- In any case (whether a search is performed or not), the client will
82	leave the Z39.50 session open for the user, to do retrievals, new
83	searches, etc. (This is the main distinction from the Retrieval URL
84	which leaves it up to the client whether or not to keep the Z39.50
85	session open)".
86
87
88
89
90	4. The Z39.50 Retrieval URL
91
92	The Z39.50 Retrieval URL is intended to allow a Z39.50 session to be used
93	as a transparent transfer mechanism to retrieve a specific information
94	object.
95	A Z39.50 client uses information in the URL to formulate a Search Request.
96	The server's Search Response indicates how many records match the Request.
97	If the number of matching records does not equal one the retrieval is
98	considered
99	unsuccessful, and the client application's behavior is not defined. If the
100	number of matching records equals one the server may have included the desired
101	record in the Search Response. If not, the client requests transmission of
102	the record with a Present Request. After the client has received the
103	specified record it may close the Z39.50 session immediately, or keep it
104	open for subsequent retrievals.
105	- Host is required.
106	- Port is optional, and defaults to 210.
107	- A database is required.
108	- The meaning of a retrieval URL with no docid is undefined.
109	- The docid is placed into a type-1 query, as the single term, in
110	the general format (tag 45), using the Bib-1 attribute set, with
111	a Use attribute value of docid, and a structure attribute of URx.
112	The docid string is server-defined and completely opaque to the client.
113	- If element set name (esn) is not specified, it is the client's choice.
114	If esn is specified, it should be used either in the Search
115	request for the value of small- and/or medium- set-element-set-names
116	or in a Present request following a Search. These terms and their
117	use are defined within the Z39.50 Standard [2].
118	- If record syntax (rs) is not specified, it is the client's choice. If
119	one
120	or more record syntaxes are specified, the client should select one
121	(preferably the first in the list that it supports) and use it in
122	a Search or Present request as the value of PreferredRecordSyntax.
123
124
125	5. BNF for Z39.50 URLs
126
127	The Z39.50 Session and Retrieval URLs follow the Common Internet Scheme
128	Syntax as defined in RFC 1738, "Uniform Resource Locators (URL)" [1].
129	In the definition, literals are quoted with "", optional elements
130	are enclosed in [brackets], "\|" is used to designate alternatives,
131	and elements may be preceded with <n>* to designate n or more
132	repetitions of the following element; n defaults to 0.
133
134
135
136	z39.50url = zscheme "://" host [":" port]
137	["/" [database *["+" database]
138	["?" docid]]
139	[";esn=" elementset]
140	[";rs=" recordsyntax *[ "+" recordsyntax]]]
141
142	zscheme = "z39.50r" \| "z39.50s"
143	database = uchar
144	docid = uchar
145	elementset = uchar
146	recordsyntax = uchar
147
148	Future extensions to these URLs will be of the form of [;keyword=value].
149
150	The following definitions are from RFC 1738. Between the Internet Draft
151	version and RFC 1738 two relevant changes were made: '=' was moved from
152	the <extra> character class to <reserved>, and <national> was removed from
153	the alternatives in <unreserved>. Neither <national> nor <punctuation> is
154	referred to in this document nor in RFC 1738.
155
156	lowalpha = "a" \| "b" \| "c" \| "d" \| "e" \| "f" \| "g" \| "h" \|
157	"i" \| "j" \| "k" \| "l" \| "m" \| "n" \| "o" \| "p" \|
158	"q" \| "r" \| "s" \| "t" \| "u" \| "v" \| "w" \| "x" \|
159	"y" \| "z"
160	hialpha = "A" \| "B" \| "C" \| "D" \| "E" \| "F" \| "G" \| "H" \| "I" \|
161	"J" \| "K" \| "L" \| "M" \| "N" \| "O" \| "P" \| "Q" \| "R" \|
162	"S" \| "T" \| "U" \| "V" \| "W" \| "X" \| "Y" \| "Z"
163
164	alpha = lowalpha \| hialpha
165	digit = "0" \| "1" \| "2" \| "3" \| "4" \| "5" \| "6" \| "7" \|
166	"8" \| "9"
167	safe = "$" \| "-" \| "_" \| "." \| "+"
168	extra = "!" \| "*" \| "'" \| "(" \| ")" \| ","
169	national = "{" \| "}" \| "\|" \| "\" \| "^" \| "~" \| "[" \| "]" \| "`"
170	punctuation = "<" \| ">" \| "#" \| "%" \| <">
171
172	reserved = ";" \| "/" \| "?" \| ":" \| "@" \| "&" \| "="
173	hex = digit \| "A" \| "B" \| "C" \| "D" \| "E" \| "F" \|
174	"a" \| "b" \| "c" \| "d" \| "e" \| "f"
175	escape = "%" hex hex
176	unreserved = alpha \| digit \| safe \| extra
177	uchar = unreserved \| escape
178	xchar = unreserved \| reserved \| escape
179	digits = 1*digit
180
181	6. Security Considerations
182
183	The two Z39.50 URL schemes are subject to the same security implications
184	as the general URL scheme [1], so the usual precautions apply. This means,
185	for example, that a locator might no longer point to the object that was
186	originally intended. It also means that it may be possible to construct
187	a URL so that an attempt to perform a harmless idempotent operation such
188	as the retrieval of an object will in fact cause a possibly damaging
189	remote operation to occur.
190
191
192	7. Acknowledgements
193
194	The Z39.50 Implementors Group contributed the substance of this document.
195
196
197	8. References
198
199	[1] Berners-Lee, T., Masinter, L., McCahill, M. (editors), "Uniform
200	Resource Locators (URL)", RFC 1738, December 1994.
201	ftp://ds.internic.net/rfc/rfc1738.txt
202
203	[2] ANSI/NISO Z39.50-1994, "ANSI Z39.50: Information Retrieval Service
204	and Protocol", 1994. ftp://ftp.loc.gov/pub/z3950/
205
206	[3] ANSI/NISO Z39.50-1992, "ANSI Z39.50: Information Retrieval Service
207	and Protocol", 1992.
208	ftp://ftp.cni.org/pub/NISO/docs/Z39.50-1992/www/Z39.50.toc.html
209	(also available in hard copy from Omnicom Information Service,
210	115 Park St., SE, Vienna, VA 22180).
211
212
213	7. Editors' Addresses
214
215	Ray Denenberg
216	Library of Congress
217	Collections Services
218	Network Development/MSO
219	Washington DC 20540
220	ray@rden.loc.gov
221	Voice: (202) 707-5795
222	Fax: (202) 707-0115
223
224
225	John A. Kunze
226	Information Systems and Technology
227	University of California at Berkeley
228	293 Evans Hall
229	Berkeley, CA 94720
230	jak@violet.berkeley.edu
231	Voice: (510) 642-1530
232	Fax: (510) 643-5385
233
234	Denis Lynch
235	TRW Business Intelligence Systems
236	1329 Moffet Park Drive
237	Sunnyvale, CA 94089
238	dml@bis.trw.com
239	Voice: (408) 541-6418
240	Fax: (408) 541-6401