home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 2000s / rfc2056.txt < prev    next >
Text File  |  1996-11-03  |  14KB  |  396 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                       R. Denenberg
  8. Request for Comments: 2056                           Library of Congress
  9. Category: Standards Track                                       J. Kunze
  10.                                  University of California, San Francisco
  11.                                                                 D. Lynch
  12.                                           SilverPlatter Information Ltd.
  13.                                                                  Editors
  14.                                                            November 1996
  15.  
  16.  
  17.                   Uniform Resource Locators for Z39.50
  18.  
  19.  
  20. Status of this Memo
  21.  
  22.    This document specifies an Internet standards track protocol for the
  23.    Internet community, and requests discussion and suggestions for
  24.    improvements.  Please refer to the current edition of the "Internet
  25.    Official Protocol Standards" (STD 1) for the standardization state
  26.    and status of this protocol.  Distribution of this memo is unlimited.
  27.  
  28. 1. Introduction
  29.  
  30.    Z39.50 is an information retrieval protocol that does not fit neatly
  31.    into a retrieval model designed primarily around the stateless fetch
  32.    of data.  Instead, it models a general user inquiry as a session-
  33.    oriented, multi-step task, any step of which may be suspended
  34.    temporarily while the server requests additional parameters from the
  35.    client before continuing.  Some, none, or all of these client/server
  36.    interactions may require participation of the client user, depending
  37.    only on the client software (the protocol itself makes no such
  38.    requirements).
  39.  
  40.    On the other hand, retrieval of "well-known" data may be performed in
  41.    a single step, that is, with a degenerate Z39.50 session consisting
  42.    of exactly one protocol search request and response.  Besides the
  43.    basic search sub-service, there are several ancillary sub-services
  44.    (e.g., Scan, Result Set Delete).  Among the functions covered by
  45.    combinations of the sub-services, two core functions emerge as
  46.    appropriately handled by two separate URL schemes:  the Session URL
  47.    and the Retrieval URL.
  48.  
  49.    Using two schemes instead of one makes a critical distinction between
  50.    a Z39.50 Session URL, which opens a client session initialized for
  51.    interactive use by the user, and a Z39.50 Retrieval URL, which opens
  52.    and closes a client session to retrieve a specific information item.
  53.    Making this distinction at the scheme level allows the user interface
  54.    to reflect it on to the user, without requiring the user interface to
  55.  
  56.  
  57.  
  58. Denenberg, et. al.          Standards Track                     [Page 1]
  59.  
  60. RFC 2056                    URLs for Z39.50                November 1996
  61.  
  62.  
  63.    parse otherwise opaque parts of the URL (consistent with current
  64.    practice).
  65.  
  66. 2. Some Basic Concepts
  67.  
  68.    This section briefly describes the usage of Z39.50-specific
  69.    terminology within the URL definitions below: specifically, the terms
  70.    database, elementset, recordsyntax, and docid.
  71.  
  72.    The Z39.50 protocol specifies various information retrieval
  73.    operations, the two most basic of which are Search and Present. In a
  74.    Search operation a client provides search criteria and indicates a
  75.    database (or several databases) on the server to search.  The
  76.    essential result of a Search operation is that a result set is
  77.    created at the server, consisting of pointers to the selected
  78.    database records.
  79.  
  80.    Z39.50 models database records, abstract database records, and
  81.    retrieval records.  A database record is a unit of information in a
  82.    database, represented in a data structure local to the server.  An
  83.    abstract database record is an abstract representation of that
  84.    information, where the client and server share a common understanding
  85.    of the representation.  This allows logical elements to be addressed
  86.    and selected for transfer, via an element set specification, or, as
  87.    used below, an "elementset".  A retrieval record is the set of
  88.    selected elements packaged in an exportable structure, by the
  89.    application of a "recordsyntax".
  90.  
  91.    Thus a Search operation results in entries pointing to database
  92.    records; via a Present operation, a client requests a retrieval
  93.    record, corresponding to a database record, corresponding to an entry
  94.    in the result set. The client indicates the composition and format of
  95.    the retrieval record by specifying an elementset and recordsyntax,
  96.    respectively.
  97.  
  98.    A special case of a Z39.50 search is a "known-item" search, when a
  99.    client intends that a search identify a single, known database
  100.    record, or "document" (for purposes of illustration, assume that a
  101.    database record corresponds to a document), and further, the client
  102.    knows an identifier for the document that can be used to effect this
  103.    known-item search.  In this case, this identifier is often referred
  104.    to as a document identifier, or "docid".
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Denenberg, et. al.          Standards Track                     [Page 2]
  115.  
  116. RFC 2056                    URLs for Z39.50                November 1996
  117.  
  118.  
  119. 3. The Z39.50 Session URL
  120.  
  121.    The Z39.50 Session URL may be informally described as providing the
  122.    mechanism to switch the user to a Z39.50 client application.
  123.  
  124.    -  Host is required.
  125.    -  Port is optional, and defaults to 210.
  126.    -  All other parameters are optional.
  127.    -  The Z39.50 client will start a session to the specified host/port
  128.       (alternatively, it need not explicitly start a session, but may
  129.       instead utilize an already open session to the same host/port).
  130.    -  A database must be included if docid is included.
  131.    -  If docid is included, the client will perform the specified search
  132.       (in the same manner as for the retrieval URL, specified below).
  133.    -  If docid is not included, and other parameters (besides host/port)
  134.       are specified, the client may use those parameters as "hints".
  135.       Various clients may choose to treat them as requirements, or as
  136.       preferences, or ignore them.
  137.    -  In any case (whether a search is performed or not), the client
  138.       will leave the Z39.50 session open for the user, to do
  139.       retrievals, new searches, etc.  (This is the main distinction
  140.       from the Retrieval URL which leaves it up to the client whether
  141.       or not to keep the Z39.50 session open.)
  142.  
  143. 4. The Z39.50 Retrieval URL
  144.  
  145.    The Z39.50 Retrieval URL is intended to allow a Z39.50 session to be
  146.    used as a transparent transfer mechanism to retrieve a specific
  147.    information object.  A Z39.50 client uses information in the URL to
  148.    formulate a Search Request.  The server's Search Response indicates
  149.    how many records match the Request.  If the number of matching
  150.    records does not equal one, the retrieval is considered unsuccessful,
  151.    and the client application's behavior is not defined.  If the number
  152.    of matching records equals one, the server may have included the
  153.    desired record in the Search Response.  If not, the client requests
  154.    transmission of the record with a Present Request.  After the client
  155.    has received the specified record it may close the Z39.50 session
  156.    immediately, or keep it open for subsequent retrievals.
  157.  
  158.    -  Host is required.
  159.    -  Port is optional, and defaults to 210.
  160.    -  A database is required.
  161.    -  The meaning of a retrieval URL with no docid is undefined.
  162.    -  The docid is placed into a type-1 query, as the single term, in
  163.       the general format (tag 45), using the Bib-1 attribute set, with
  164.       a Use attribute value of docid, and a structure attribute of URx.
  165.       The docid string is server-defined and completely opaque to the
  166.       client.
  167.  
  168.  
  169.  
  170. Denenberg, et. al.          Standards Track                     [Page 3]
  171.  
  172. RFC 2056                    URLs for Z39.50                November 1996
  173.  
  174.  
  175.    - If element set name (esn) is not specified, it is the client's
  176.       choice.  If esn is specified, it should be used either in the
  177.       Search request for the value of small- and/or medium-
  178.       set-element-set-names or in a Present request following a
  179.       Search.  These terms and their use are defined within the Z39.50
  180.       Standard [2].
  181.    -  If record syntax (rs) is not specified, it is the client's choice.
  182.       If one or more record syntaxes are specified, the client should
  183.       select one (preferably the first in the list that it supports)
  184.       and use it in a Search or Present request as the value of
  185.       PreferredRecordSyntax.
  186.  
  187. 5. BNF for Z39.50 URLs
  188.  
  189.    The Z39.50 Session and Retrieval URLs follow the Common Internet
  190.    Scheme Syntax as defined in RFC 1738, "Uniform Resource Locators
  191.    (URL)" [1].  In the definition, literals are quoted with "", optional
  192.    elements are enclosed in [brackets], "|" is used to designate
  193.    alternatives, and elements may be preceded with <n>* to designate n
  194.    or more repetitions of the following element; n defaults to 0.
  195.  
  196. z39.50url      = zscheme "://" host [":" port]
  197.                       ["/" [database *["+" database]
  198.                              ["?" docid]]
  199.                            [";esn=" elementset]
  200.                            [";rs=" recordsyntax *[ "+" recordsyntax]]]
  201.  
  202. zscheme        = "z39.50r" | "z39.50s"
  203. database       = uchar
  204. docid          = uchar
  205. elementset     = uchar
  206. recordsyntax   = uchar
  207.  
  208.    Future extensions to these URLs will be of the form of
  209.    [;keyword=value].
  210.  
  211.    The following definitions are from RFC 1738. Between the Internet
  212.    Draft version and RFC 1738 two relevant changes were made: '=' was
  213.    moved from the <extra> character class to <reserved>, and <national>
  214.    was removed from the alternatives in <unreserved>. Neither <national>
  215.    nor <punctuation> is referred to in this document nor in RFC 1738.
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Denenberg, et. al.          Standards Track                     [Page 4]
  227.  
  228. RFC 2056                    URLs for Z39.50                November 1996
  229.  
  230.  
  231. lowalpha       = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" |
  232.                  "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" |
  233.                  "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" |
  234.                  "y" | "z"
  235. hialpha        = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" |
  236.                  "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" |
  237.                  "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z"
  238.  
  239. alpha          = lowalpha | hialpha
  240. digit          = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
  241.                  "8" | "9"
  242. safe           = "$" | "-" | "_" | "." | "+"
  243. extra          = "!" | "*" | "'" | "(" | ")" | ","
  244. national       = "{" | "}" | "|" | "\" | "^" | "~" | "[" | "]" | "`"
  245. punctuation    = "<" | ">" | "#" | "%" | <">
  246.  
  247. reserved       = ";" | "/" | "?" | ":" | "@" | "&" | "="
  248. hex            = digit | "A" | "B" | "C" | "D" | "E" | "F" |
  249.                  "a" | "b" | "c" | "d" | "e" | "f"
  250. escape         = "%" hex hex
  251. unreserved     = alpha | digit | safe | extra
  252. uchar          = unreserved | escape
  253. xchar          = unreserved | reserved | escape
  254. digits         = 1*digit
  255.  
  256. 6. Security Considerations
  257.  
  258.    The two Z39.50 URL schemes are subject to the same security
  259.    implications as the general URL scheme [1], so the usual precautions
  260.    apply.  This means, for example, that a locator might no longer point
  261.    to the object that was originally intended.  It also means that it
  262.    may be possible to construct a URL so that an attempt to perform a
  263.    harmless idempotent operation such as the retrieval of an object will
  264.    in fact cause a possibly damaging remote operation to occur.
  265.  
  266. 7. Acknowledgements
  267.  
  268.    The Z39.50 Implementors Group contributed the substance of this
  269.    document.
  270.  
  271. 8. References
  272.  
  273.    [1] Berners-Lee, T., Masinter, L., McCahill, M. (editors), "Uniform
  274.        Resource Locators (URL)", RFC 1738, December 1994.
  275.        ftp://ds.internic.net/rfc/rfc1738.txt
  276.  
  277.    [2] ANSI/NISO Z39.50-1995, "ANSI Z39.50: Information Retrieval
  278.        Service and Protocol", 1995.  ftp://ftp.loc.gov/pub/z3950/
  279.  
  280.  
  281.  
  282. Denenberg, et. al.          Standards Track                     [Page 5]
  283.  
  284. RFC 2056                    URLs for Z39.50                November 1996
  285.  
  286.  
  287.    [3] ANSI/NISO Z39.50-1992, "ANSI Z39.50: Information Retrieval
  288.        Service and Protocol", 1992.
  289.        ftp://ftp.cni.org/pub/NISO/docs/Z39.50-1992/www/Z39.50.toc.html
  290.        (also available in hard copy from Omnicom Information Service,
  291.        115 Park St., SE, Vienna, VA  22180).
  292.  
  293. 9. Editors' Addresses
  294.  
  295.    Ray Denenberg
  296.    Library of Congress
  297.    Collections Services
  298.    Network Development/MSO
  299.    Washington DC 20540
  300.  
  301.  
  302.    Phone: (202) 707-5795
  303.    Fax:   (202) 707-0115
  304.    EMail: ray@rden.loc.gov
  305.  
  306.  
  307.    John A. Kunze
  308.    Center for Knowledge Management
  309.    University of California, San Francisco
  310.    530 Parnassus Ave, Box 0840
  311.    San Francisco, CA  94143-0840
  312.  
  313.    Phone: (415) 502-6660
  314.    Fax:   (415) 476-4653
  315.    EMail: jak@ckm.ucsf.edu
  316.  
  317.  
  318.    Denis Lynch
  319.    SilverPlatter Information Ltd.
  320.    10 Barely Mow Passage
  321.    Chiswick, London W4 4PH
  322.    U.K.
  323.  
  324.    Voice: +44 (0)181-995-8242
  325.    Fax:   +44 (0)181-995-5159
  326.    EMail: DenisL@SilverPlatter.com
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Denenberg, et. al.          Standards Track                     [Page 6]
  339.  
  340. RFC 2056                    URLs for Z39.50                November 1996
  341.  
  342.  
  343. Appendix. Examples of Z39.50 URLs
  344.  
  345.    A basic Z39.50 session URL that a client might use to open a
  346.    connection to the MELVYL union catalog "cat" at the University of
  347.    California is
  348.  
  349.         z39.50s://melvyl.ucop.edu/cat
  350.  
  351.    A URL that would open the MELVYL magazine database just long enough
  352.    to fetch an article from volume 30, number 19 of a hypothetical
  353.    periodical might look like
  354.  
  355.         z39.50r://melvyl.ucop.edu/mags?elecworld.v30.n19
  356.  
  357.    As a final example, here is another retrieval URL that a client could
  358.    use to request a full record (element set "f") in the MARC syntax
  359.    from a hypothetical database called TMF at CNIDR:
  360.  
  361.         z39.50r://cnidr.org:2100/tmf?bkirch_rules__a1;esn=f;rs=marc
  362.  
  363.    As in the previous example, the part of the string after the `?' is
  364.    determined by the server.  In this example, the server is running on
  365.    non-standard port 2100.
  366.  
  367.  
  368.  
  369.  
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Denenberg, et. al.          Standards Track                     [Page 7]
  395.  
  396.