RFC2056 日本語訳

Network Working Group                                       R. Denenberg
Request for Comments: 2056                           Library of Congress
Category: Standards Track                                       J. Kunze
                                 University of California, San Francisco
                                                                D. Lynch
                                          SilverPlatter Information Ltd.
                                                                 Editors
                                                           November 1996

Denenbergがコメントのために要求するワーキンググループR.をネットワークでつないでください: 2056年の議会図書館カテゴリ: 標準化過程J.クンツェカリフォルニア大学、サンフランシスコD.リンチSilverPlatter情報株式会社エディターズ1996年11月

                  Uniform Resource Locators for Z39.50

Z39.50のためのUniform Resource Locator

Status of this Memo

このMemoの状態

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

1. Introduction

1. 序論

   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).

Z39.50は主としてデータの状態がないフェッチの周りで設計された検索モデルにきちんと収まらない情報検索プロトコルです。 代わりに、それは指向のセッション多段階タスクとして一般的なユーザ問い合せをモデル化します。サーバが続く前にクライアントから追加パラメタを要求している間、どんなそのステップも一時中断します。 これらのクライアント/サーバ相互作用のいくつか、なにも、またはすべてがクライアントユーザの参加を必要とするかもしれません、クライアントソフトウェアだけによって(プロトコル自体はどんなそのような要件も作りません)。

   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.

他方では、「よく知られる」データの検索はシングルステップで実行されるかもしれません、すなわち、堕落したZ39.50セッションがまさに1つのプロトコル検索要求と応答から成っていて。 基本的な検索サブサービス以外に、いくつかの付属のサブサービス(例えば、Scan、Result Set Delete)があります。 サブサービスの組み合わせでカバーされた機能の中では、2つのコア機能が2つの別々のURL体系によって適切に扱われるように現れます: セッションURLと検索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

1の代わりに2つの体系を使用すると、重要な区別はZ39.50 Session URLとZ39.50 Retrieval URLの間でします。それは、対話的な使用のためにユーザによって初期化されたクライアントセッションを開きます。URLは、特殊情報項目を検索するためにクライアントセッションを開いて、終えます。 ユーザーインタフェースは体系レベルでこの区別をするのにそれをユーザに反映できます、ユーザーインタフェースを必要としないで

Denenberg, et. al.          Standards Track                     [Page 1]

RFC 2056                    URLs for Z39.50                November 1996

et Denenberg、アル。 規格は1996年11月にZ39.50のためにRFC2056URLを追跡します[1ページ]。

   parse otherwise opaque parts of the URL (consistent with current
   practice).

URL(現在の習慣と一致した)のそうでなければ、不透明な部分を分析してください。

2. Some Basic Concepts

2. いくつかの基本概念

   This section briefly describes the usage of Z39.50-specific
   terminology within the URL definitions below: specifically, the terms
   database, elementset, recordsyntax, and docid.

このセクションは以下でのURL定義の中で簡潔にZ39.50特有の用語の用法を説明します: 明確に用語データベース、elementset、recordsyntax、およびdocid。

   The Z39.50 protocol specifies various information retrieval
   operations, the two most basic of which are Search and Present. In a
   Search operation a client provides search criteria and indicates a
   database (or several databases) on the server to search.  The
   essential result of a Search operation is that a result set is
   created at the server, consisting of pointers to the selected
   database records.

Z39.50プロトコルはどれが検索であるか、そして、Presentで最も基本的に様々な情報検索操作、2を指定します。 検索操作では、クライアントは、探すためにサーバで検索評価基準を提供して、データベースを示します(または、いくつかのデータベース)。 検索操作の不可欠の結果は結果セットがサーバで創設されるということです、選択されたデータベース・レコードに指針から成って。

   Z39.50 models database records, abstract database records, and
   retrieval records.  A database record is a unit of information in a
   database, represented in a data structure local to the server.  An
   abstract database record is an abstract representation of that
   information, where the client and server share a common understanding
   of the representation.  This allows logical elements to be addressed
   and selected for transfer, via an element set specification, or, as
   used below, an "elementset".  A retrieval record is the set of
   selected elements packaged in an exportable structure, by the
   application of a "recordsyntax".

Z39.50はデータベース・レコード、抽象的なデータベース・レコード、および検索記録をモデル化します。 データベース・レコードはサーバへのローカルのデータ構造で表されたデータベースの情報のユニットです。抽象的なデータベース・レコードはその情報の抽象的表現です。そこで、クライアントとサーバは表現の一般的な理解を共有します。 これは、論理要素が転送のために扱われて、選択されるのを許容します、要素セット仕様、または以下で使用されるときの"elementset"を通して。 検索レコードは輸出向きの構造で"recordsyntax"のアプリケーションでパッケージされた選択された要素のセットです。

   Thus a Search operation results in entries pointing to database
   records; via a Present operation, a client requests a retrieval
   record, corresponding to a database record, corresponding to an entry
   in the result set. The client indicates the composition and format of
   the retrieval record by specifying an elementset and recordsyntax,
   respectively.

したがって、検索操作はデータベース・レコードを示すエントリーをもたらします。 Present操作で、クライアントは検索記録を要求します、データベース・レコードに対応しています、結果セットでエントリーに対応しています。 クライアントは、それぞれelementsetとrecordsyntaxを指定することによって、検索記録の構成と書式を示します。

   A special case of a Z39.50 search is a "known-item" search, when a
   client intends that a search identify a single, known database
   record, or "document" (for purposes of illustration, assume that a
   database record corresponds to a document), and further, the client
   knows an identifier for the document that can be used to effect this
   known-item search.  In this case, this identifier is often referred
   to as a document identifier, or "docid".

Z39.50検索の特別なケースは「知られている項目」検索です、クライアントが、検索がシングル、知られているデータベース・レコード、または「ドキュメント」を特定することを意図して(イラストの目的には、データベース・レコードがドキュメントに対応すると仮定してください)、クライアントがさらにこの知られている項目検索に作用するのに使用できるドキュメントのための識別子を知っているとき。 この場合、この識別子はしばしばドキュメント識別子、または"docid"と呼ばれます。

Denenberg, et. al.          Standards Track                     [Page 2]

RFC 2056                    URLs for Z39.50                November 1996

et Denenberg、アル。 規格は1996年11月にZ39.50のためにRFC2056URLを追跡します[2ページ]。

3. The Z39.50 Session URL

3. Z39.50セッションURL

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

Z39.50 Session URLはZ39.50クライアントアプリケーションにユーザを切り換えるためにメカニズムを提供するとして非公式に記述されているかもしれません。

   -  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.)

- ホストが必要です。 - ポートは、任意であり、210をデフォルトとします。 - 他のすべてのパラメタが任意です。 - Z39.50クライアントは指定されたホスト/ポートにセッションを始めるでしょう。しかし、(あるいはまた、セッションが明らかに始めである必要はない、代わりに利用するかもしれない、既に公開審議、同じホスト/ポート) - docidが含まれているなら、データベースを含まなければなりません。 - docidが含まれていると、クライアントは指定された検索(以下で指定された検索URLのような同じ方法による)を実行するでしょう。 - docidが含まれていなくて、他のパラメタ(ホスト/ポート以外に)が指定されるなら、クライアントは「ヒント」としてそれらのパラメタを使用するかもしれません。 様々なクライアントは、要件として、または、好みとして彼らを扱うか、またはそれらを無視するのを選ぶかもしれません。 - どのような場合でも(検索が実行されるか否かに関係なく)、クライアントは、retrievals、新しい検索などをするためにZ39.50セッションをユーザにとって開いた状態でおくでしょう。 (これは開いて、Z39.50セッションを保ってくださいか否かに関係なく、クライアントにそれを任せるRetrieval URLからの主な区別です。)

4. The Z39.50 Retrieval URL

4. Z39.50検索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.

Z39.50 Retrieval URLが、Z39.50セッションが特殊情報オブジェクトを検索するのに見え透いたトランスファ・メカニズムとして使用されるのを許容することを意図します。 Z39.50クライアントは、検索Requestを定式化するのにURLの情報を使用します。 サーバの検索Responseは、いくつの記録がRequestに合っているかを示します。 合っている記録の数が1つと等しくないなら、検索は失敗していると考えられます、そして、クライアントアプリケーションの振舞いは定義されません。 合っている記録の数が1つと等しいなら、サーバは検索Responseにおける必要な記録を含んだかもしれません。 そうでなければ、クライアントはPresent Requestとの記録の伝達を要求します。 クライアントが指定された記録を受け取った後に、それは、すぐにZ39.50セッションを終えるか、またはその後の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.

- ホストが必要です。 - ポートは、任意であり、210をデフォルトとします。 - データベースが必要です。 - docidのない1つの検索URLの意味は未定義です。 - docidはタイプ-1質問に置かれます、ただ一つの用語として、一般形式(タグ45)で、Bib-1属性セットを使用して、docidのUse属性値、およびURxの構造属性で。 docidストリングは、サーバによって定義されていてクライアントにとって、完全に不透明です。

Denenberg, et. al.          Standards Track                     [Page 3]

RFC 2056                    URLs for Z39.50                November 1996

et Denenberg、アル。 規格は1996年11月にZ39.50のためにRFC2056URLを追跡します[3ページ]。

   - 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.

- 要素セット名(esn)が指定されないなら、それはクライアントの選択です。 esnが指定されるなら、検索に続いて、それは小さい、そして/または、中型のセット要素セット名の値を求める検索要求かPresent要求で使用されるべきです。 これらの用語と彼らの使用はZ39.50 Standard[2]の中で定義されます。 - 記録的な構文(rs)が指定されないなら、それはクライアントの選択です。 1つ以上の記録的な構文が指定されるなら、クライアントは、1つ(望ましくはそれがサポートするリストにおける1番目)を選択して、PreferredRecordSyntaxの値として検索かPresent要求でそれを使用するべきです。

5. BNF for Z39.50 URLs

5. Z39.50URLのためのBNF

   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.50 SessionとRetrieval URLはRFC1738(「Uniform Resource Locator(URL)」[1])で定義されるようにCommonインターネットScheme Syntaxに続きます。 定義では、リテラルが引用される、「「随意的な要素が[括弧]に同封される、」、」|「使用されて、代替手段、および要素を指定するために、<n>*で先行されていて、以下の要素のn反復を指定するかもしれないということです」。 nは0をデフォルトとします。

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

「z39.50url=は」 ://をzschemeする」というホスト[「:」 ポート][「/」[データベース*[「+」 データベース][“?" docid]]、[「;、esnが」 elementsetと等しい ]、[「;rsが」 recordsyntax*[「+」 recordsyntax]と等しい

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

zschemeは"z39.50r"と等しいです。| "z39.50s"データベース=uchar docid=uchar elementset=uchar recordsyntaxはucharと等しいです。

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

これらへのURLがフォームのものになる今後の拡大[; キーワード=価値]。

   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.

以下の定義はRFC1738から来ています。 インターネットDraftバージョンとRFC1738の間では、2つの関連変更が行われました: '='は<の付加的な>文字クラスから予約された<>まで動かされました、そして、<の国家の>は<の予約していない>で代替手段から取り外されました。 <の国家の>も<句読>もこのドキュメントとRFC1738で言及されません。

Denenberg, et. al.          Standards Track                     [Page 4]

RFC 2056                    URLs for Z39.50                November 1996

et Denenberg、アル。 規格は1996年11月にZ39.50のためにRFC2056URLを追跡します[4ページ]。

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"

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」| 「私」| 「J」| 「K」| 「L」| 「M」| 「N」| 「○」| 「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    = "<" | ">" | "#" | "%" | <">

アルファ=lowalpha| hialphaケタ=「0インチ」| "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | 「9インチ安全な=「$」」| "-" | "_" | "." | 「+」 付加的な=“!" | "*" | "'" | "(" | ")" | 「」、国家の=、「「|」」| "|" | "\" | "^" | "~" | "[" | "]" | 「'「句読は"<"と等しいです」'| ">"| "#" | "%" | <">"

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

「予約された=」;、」 | "/" | "?" | ":" | "@" | "&" | 十六進法=ケタと「等しいです」。| 「A」| 「B」| 「C」| 「D」| 「E」| 「F」| "a"| 「b」| 「c」| 「d」| 「e」| 十六進法が魔法をかける「f」エスケープ=「%」無遠慮な=アルファ| ケタ| 金庫| 付加的なuchar=無遠慮です。| 無遠慮な状態でxchar=から逃げてください。| 予約されます。| エスケープケタは1*ケタと等しいです。

6. Security Considerations

6. セキュリティ問題

   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.

2つのZ39.50 URL体系が一般的なURL体系[1]と同じセキュリティ含意を受けることがあるので、普通の注意は適用されます。 例えば、これは、ロケータがもう元々意図したオブジェクトを示さないかもしれないことを意味します。 また、それは、事実上、オブジェクトの検索などの無害なベキ等元操作を実行する試みがことによるとダメージが大きいリモート操作を起こらせるように、URLを構成するのが可能であるかもしれないことを意味します。

7. Acknowledgements

7. 承認

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

Z39.50 Implementors Groupはこのドキュメントの実体を寄付しました。

8. References

8. 参照

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

[1] バーナーズ・リー、T.、Masinter、L.、McCahill、M.(エディタ)、「Uniform Resource Locator(URL)」、RFC1738、12月1994日の ftp://ds.internic.net/rfc/rfc1738.txt

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

[2] ANSI/NISO Z39.50-1995、「ANSI Z39.50:」 1995の「情報検索サービスとプロトコル」、 ftp://ftp.loc.gov/pub/z3950/

Denenberg, et. al.          Standards Track                     [Page 5]

RFC 2056                    URLs for Z39.50                November 1996

et Denenberg、アル。 規格は1996年11月にZ39.50のためにRFC2056URLを追跡します[5ページ]。

   [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).

[3] ANSI/NISO Z39.50-1992、「ANSI Z39.50:」 「情報Retrieval Serviceとプロトコル」、1992 ftp://ftp.cni.org/pub/NISO/docs/Z39.50-1992/www/Z39.50.toc.html (SE、ウィーン、ヴァージニア Omnicom情報Service、115Park通り、22180からハードコピーで利用可能なも)。

9. Editors' Addresses

9. エディタのアドレス

   Ray Denenberg
   Library of Congress
   Collections Services
   Network Development/MSO
   Washington DC 20540

レイのDenenberg議会図書館の収集サービスは開発/MSOワシントンD.C.20540をネットワークでつなぎます。

   Phone: (202) 707-5795
   Fax:   (202) 707-0115
   EMail: ray@rden.loc.gov

以下に電話をしてください。 (202) 707-5795 Fax: (202) 707-0115 メールしてください: ray@rden.loc.gov

   John A. Kunze
   Center for Knowledge Management
   University of California, San Francisco
   530 Parnassus Ave, Box 0840
   San Francisco, CA  94143-0840

ナレッジ・マネジメントカリフォルニア大学のためのジョンA.クンツェセンター、530パルナッソス山Ave、サンフランシスコBox0840サンフランシスコ、カリフォルニア94143-0840

   Phone: (415) 502-6660
   Fax:   (415) 476-4653
   EMail: jak@ckm.ucsf.edu

以下に電話をしてください。 (415) 502-6660 Fax: (415) 476-4653 メールしてください: jak@ckm.ucsf.edu

   Denis Lynch
   SilverPlatter Information Ltd.
   10 Barely Mow Passage
   Chiswick, London W4 4PH
   U.K.

デニスリンチSilverPlatter情報Ltd.10はほとんどPassageチズウィック、ロンドンW4 4PHイギリスを芝刈りしません。

   Voice: +44 (0)181-995-8242
   Fax:   +44 (0)181-995-5159
   EMail: DenisL@SilverPlatter.com

声: +44 (0) 181-995-8242Fax: +44 (0) 181-995-5159 メールしてください: DenisL@SilverPlatter.com

Denenberg, et. al.          Standards Track                     [Page 6]

RFC 2056                    URLs for Z39.50                November 1996

et Denenberg、アル。 規格は1996年11月にZ39.50のためにRFC2056URLを追跡します[6ページ]。

Appendix. Examples of Z39.50 URLs

付録。 Z39.50URLに関する例

   A basic Z39.50 session URL that a client might use to open a
   connection to the MELVYL union catalog "cat" at the University of
   California is

クライアントがカリフォルニア大学でMELVYL総合目録「猫」に接続を開くのに使用するかもしれない基本的なZ39.50セッションURLはそうです。

        z39.50s://melvyl.ucop.edu/cat

z39.50s://melvyl.ucop.edu/猫

   A URL that would open the MELVYL magazine database just long enough
   to fetch an article from volume 30, number 19 of a hypothetical
   periodical might look like

ちょうど第30巻、仮定している定期刊行物のNo.19からの記事をとって来ることができるくらい長いMELVYL雑誌データベースを開くURLに似るかもしれません。

        z39.50r://melvyl.ucop.edu/mags?elecworld.v30.n19

z39.50r://melvyl.ucop.edu/雑誌?elecworld.v30.n19

   As a final example, here is another retrieval URL that a client could
   use to request a full record (element set "f") in the MARC syntax
   from a hypothetical database called TMF at CNIDR:

最終的な例として、ここに、クライアントがCNIDRでTMFと呼ばれる仮定しているデータベースからマーク構文による完全な記録(要素セット「f」)を要求するのに使用できた別の検索URLはあります:

        z39.50r://cnidr.org:2100/tmf?bkirch_rules__a1;esn=f;rs=marc

z39.50r://cnidr.org: __a1; esn=f; 2100/tmf?bkirch_規則rsはしぼりかすと等しいです。

   As in the previous example, the part of the string after the `?' is
   determined by the server.  In this example, the server is running on
   non-standard port 2100.

前の例のように、'?'の後のストリングの一部がサーバで決定しています。この例では、サーバは標準的でないポート2100で走っています。

Denenberg, et. al.          Standards Track                     [Page 7]

et Denenberg、アル。 標準化過程[7ページ]