- From: John A. Kunze <jak@violet.berkeley.edu>
- Date: Mon, 13 Mar 1995 19:36:27 -0800
- To: uri@bunyip.com, z3950iw@nervm.nerdc.ufl.edu
I've made a new draft of the Z39.50 URL document available from the usual
sources (directions below). The main changes are in response to feedback
(from the last live URI group meeting) that '&' is somewhat problematic
in URL schemes due to current SGML parser limitations, and that the
references needed clarification. I've also added a security section.
Larry, I'd like to spend 15 minutes on this document at the URI meeting in
Boston next month. Enclosed at the end are the Unix file "diffs" showing
all the changes. Here are directions for getting the actual document:
Internet-Drafts are available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-ietf-uri-url-irp-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-uri-url-irp-01.txt
-John
======================== file diffs =====================================
*** zurl.00 Mon Nov 28 13:49:37 1994
--- zurl.01 Mon Mar 13 19:12:17 1995
***************
*** 1,7 ****
IETF URI Working Group R. Denenberg
Internet-Draft J. Kunze
! draft-ietf-uri-url-irp-00.txt B. McLean
! 22 November 1994 Editors
Uniform Resource Locators for Z39.50
--- 1,7 ----
IETF URI Working Group R. Denenberg
Internet-Draft J. Kunze
! draft-ietf-uri-url-irp-01.txt B. McLean
! 6 March 1995 Editors
Uniform Resource Locators for Z39.50
***************
*** 39,45 ****
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 make 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
--- 39,45 ----
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
***************
*** 61,74 ****
3. The Z39.50 Session URL
The Z39.50 Session and Retrieval URLs follow the Common Internet Scheme
! Syntax as defined in RFC ???, "Uniform Resource Locators (URL)" [1].
The specific syntax for the Session URL is:
z39.50s://host[:port]
[/database[+database...]
[?docid
! [&esn=elementset]
! [&rs=recordsyntax[+recordsyntax...]]]]
This may be informally described as providing the mechanism to switch
the user of the browser to a window in which a Z39.50 client is running.
--- 61,74 ----
3. The Z39.50 Session URL
The Z39.50 Session and Retrieval URLs follow the Common Internet Scheme
! Syntax as defined in RFC 1738, "Uniform Resource Locators (URL)" [1].
The specific syntax for the Session URL is:
z39.50s://host[:port]
[/database[+database...]
[?docid
! [;esn=elementset]
! [;rs=recordsyntax[+recordsyntax...]]]]
This may be informally described as providing the mechanism to switch
the user of the browser to a window in which a Z39.50 client is running.
***************
*** 98,105 ****
z39.50r://host[:port]
[/database[+database...]
[?docid
! [&esn=elementset]
! [&rs=recordsyntax[+recordsyntax...]]]]
The model is designed for minimal interaction by the user with the Z39.50
session to be used as a transparent transfer mechanism if possible. The
--- 98,105 ----
z39.50r://host[:port]
[/database[+database...]
[?docid
! [;esn=elementset]
! [;rs=recordsyntax[+recordsyntax...]]]]
The model is designed for minimal interaction by the user with the Z39.50
session to be used as a transparent transfer mechanism if possible. The
***************
*** 107,113 ****
responsible for returning to the user's browser in an appropriate form
(e.g., HTML).
! - Host, database, and docid are required.
- The docid is server-defined and otherwise opaque.
- Port is optional, and defaults to 210.
- If element set name (esn) is not specified, it is client's choice.
--- 107,113 ----
responsible for returning to the user's browser in an appropriate form
(e.g., HTML).
! - Host, database, and docid are all required.
- The docid is server-defined and otherwise opaque.
- Port is optional, and defaults to 210.
- If element set name (esn) is not specified, it is client's choice.
***************
*** 123,144 ****
a Use attribute value of docid, and a structure attribute of URX.
The docid string is completely opaque to the client.
! Future extensions to these URLs will be of the form of [&keyword=value].
! 5. Acknowledgements
The Z39.50 Implementors Group contributed the substance of this document.
! 6. References
[1] Berners-Lee, T., Masinter, L., McCahill, M. (editors), "Uniform
! Resource Locators (URL)", soon to be RFC ???, October 1994.
! ftp://ds.internic.net/internet-drafts/draft-ietf-uri-url-09.txt
! [2] ANSI/NISO Z39.50-1992, "ANSI Z39.50: Information Retrieval Service
! and Protocol", Version 2, 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).
--- 123,158 ----
a Use attribute value of docid, and a structure attribute of URX.
The docid string is completely opaque to the client.
! Future extensions to these URLs will be of the form of [;keyword=value].
! 5. 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.
+
+
+ 6. Acknowledgements
+
The Z39.50 Implementors Group contributed the substance of this document.
! 7. References
[1] Berners-Lee, T., Masinter, L., McCahill, M. (editors), "Uniform
! Resource Locators (URL)", soon to be RFC 1738, October 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).
Received on Monday, 13 March 1995 22:36:36 UTC