RFC1729 日本語訳
1729 Using the Z39.50 Information Retrieval Protocol. C. Lynch. December 1994. (Format: TXT=20927 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group C. Lynch Request for Comments: 1729 University of California Category: Informational Office of the President December 1994
コメントを求めるワーキンググループC.リンチ要求をネットワークでつないでください: 1729年のカリフォルニア大学カテゴリ: 社長1994年12月の情報の職務
Using the Z39.50 Information Retrieval Protocol in the Internet Environment
インターネット環境でZ39.50情報検索プロトコルを使用します。
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Summary
概要
This memo describes an approach to the implementation of the ANSI/NISO Z39.50-1992 Standard for Information Retrieval in the TCP/IP environment which is currently in wide use by the Z39.50 implementor community.
このメモは情報RetrievalのためにZ39.50作成者社会が現在広く使用中であるTCP/IP環境でANSI/NISO Z39.50-1992 Standardの実装にアプローチを説明します。
Introduction
序論
Z39.50 is a US national standard defining a protocol for computer- to-computer information retrieval that was first adopted in 1988 [1] and extensively revised in 1992 [2]. It was developed by the National Information Standards Organization (NISO), an ANSI-accredited standards development body that serves the publishing, library, and information services communities. The closely related international standard, ISO 10162 (service definition) [3] and 10163 (protocol) [4], colloquially known as Search and Retrieve or SR, reached full International Standard (IS) status in 1991. Work is ongoing within ISO Technical Committee 46 Working Group 4 Subgroup 4 to progress various extensions to SR through the international standards process. The international standard is essentially a compatible subset of the current US Z39.50-1992 standard. Z39.50 is an applications layer protocol within the OSI reference model, which assumes the presence of lower-level OSI services (in particular, the presentation layer [5]) and of the OSI Association Control Service Element (ACSE) [6] within the application layer.
Z39.50はコンピュータへの最初に、1988[1]に採用されて、1992[2]で手広く改訂されたコンピュータ情報検索のためにプロトコルを定義する米国国家規格です。 それはNational情報Standards Organization(NISO)(出版、ライブラリ、および情報サービスに共同体に役立つANSI公認の規格開発本体)によって開発されました。 検索とRetrieveかSRとして口語的に知られている密接に関係づけられた世界規格、ISO10162(サービス定義)[3]、および10163(プロトコル)[4]は1991年に完全な国際規格(ある)状態に達しました。 仕事は世界規格プロセスを通して様々な拡大をSRに進行するISO Technical Committee46作業部会4Subgroup4の中で進行中です。 世界規格は本質的には現在のUS Z39.50-1992規格のコンパチブル部分集合です。 Z39.50はOSI参照モデルの中のアプリケーション層のプロトコルです。OSI参照モデルは、低レベルOSIサービスの存在を仮定します。(特に、[5])とアプリケーションの中のOSIアソシエーション制御サービス要素(ACSE)[6]のプレゼンテーション層は層にされます。
Many institutions implementing this protocol chose, for various reasons, to layer the protocol directly over TCP/IP rather than to implement it in an OSI environment or to use the existing techniques that provide full OSI services at and above the OSI Transport layer on top of TCP connections (as defined in RFC 1006 [7] and implemented, for example, in the ISO Development Environment
このプロトコルを実装する多くの団体が、OSI環境でそれを実装するか、またはTCP接続の上で層においてOSI Transport層の上に完全なOSIサービスを供給する既存のテクニックを使用するというよりむしろTCP/IPの直接上でプロトコルを層にするのを様々な理由に選んだ、(RFC1006[7]で定義されて、例えば、ISO Development Environmentで実装されます。
Lynch [Page 1] RFC 1729 Using the Z39.50 in the Internet Environment December 1994
環境1994年12月にインターネットでZ39.50を使用するリンチ[1ページ]RFC1729
software). These reasons included concerns about the size and complexity of OSI implementations, the lack of availability of mature OSI software for the full range of computing environments in use at these institutions, and the perception of relative instability of the architectural structures within the OSI applications layer (as opposed to specific application layer protocols such as Z39.50 itself). Most importantly, some of these institutions were concerned that the complexity introduced by the OSI upper layers would outweigh the relatively meager return in functionality that they were likely to gain. Thus, for better or worse, the decision was taken to implement the Z39.50 protocol directly on top of TCP (with the understanding that this decision might be revisited at some point in the future).
ソフトウェア) これらの理由はOSIアプリケーション層(Z39.50自身などの特定の応用層プロトコルと対照的に)の中にOSI実装のサイズと複雑さ、これらの団体で使用中のコンピューティング環境の最大限の範囲のための熟しているOSIソフトウェアの有用性の不足、および建築物の相対的な不安定性の認知に関する心配を含んでいました。 最も重要に、これらの団体のいくつかがOSIの上側の層で導入された複雑さがそれらが獲得しそうだった機能性における比較的貧弱なリターンを十二分に補うことを心配していました。 したがって、のるかそるか、直接TCP(この決定が将来何らかのポイントを再訪するかもしれないという条件による)の上でZ39.50プロトコルを実装するために決定を取りました。
During 1991-1993, a group of implementing institutions agreed to participate in the Z39.50 Interoperability Testbed project (sometimes referred to by the acronym "ZIT") under the auspices of the Coalition for Networked Information (CNI). Their primary objective was to encourage the development of many interoperable Z39.50 implementations running over TCP/IP on the Internet. By mid-1993, a number of independent Z39.50 implementations were operational and able to interoperate across the Internet.
1991-1993の間、実装する団体のグループは、ネットワークでつながれた情報(CNI)のための連合の前兆でZ39.50 Interoperability Testbedプロジェクト(時々頭文字語「にきび」によって言及される)に参加するのに同意しました。 それらの主目的はインターネットでTCP/IPをひく多くの共同利用できるZ39.50実装の開発を奨励することでした。 1993年中頃までには、多くの独立しているZ39.50実装が、操作上であってインターネットの向こう側に共同利用できました。
The Library of Congress, in its role as the Z39.50 Maintenance Agency for NISO, maintains a registry of the implementors [8], which includes members of the Z39.50 interoperability testbed.
NISOのためのZ39.50 Maintenance Agencyとしての役割では、議会図書館は作成者[8]の登録を維持します。(それは、Z39.50相互運用性テストベッドの部材を含んでいます)。
This document describes implementation decisions by current implementors of Z39.50 in the Internet environment. These have been proven within the ZIT project and are being used by most of the members of the Z39.50 Implementors' Group (ZIG), an informal group that meets quarterly to discuss implementation and interoperability issues and to develop extensions to the Z39.50 protocol targeted for inclusion in future versions of the standard. Intended as a guide for other implementors who seek to develop interoperable Z39.50 implementations running over TCP/IP, this document focuses on issues related to TCP/IP, and it does not address other potential interoperability problems or agreements that have been reached among the implementors to address these problems. It does include a few notes about extensions to the existing Version 2 protocol that are being used in the implementor community which have interoperability implications. Potential implementors of Z39.50 should subscribe to the Z3950IW LISTSERV [9] to obtain information specific to the Z39.50 protocol and extensions under development as well as details of current implementations.
このドキュメントはインターネット環境でZ39.50の現在の作成者による実装決定について説明します。 これらは、ZITプロジェクトの中で立証されて、Z39.50 ImplementorsのGroup(ZIG)(実装と相互運用性問題について議論して、規格の将来のバージョンでの包含のために狙うZ39.50プロトコルに拡大を発生するように季刊誌を満たす非公式のグループ)のメンバーの大部分によって使用されています。 TCP/IPをひきながら共同利用できるZ39.50実装を開発しようとする他の作成者のためのガイドとして意図していて、このドキュメントはTCP/IPに関連する問題に焦点を合わせます、そして、それは他の潜在的相互運用性問題かこれらのその問題を訴えるために作成者の中で達した合意を扱いません。既存のバージョン2プロトコルへの相互運用性意味を持っている作成者社会で使用されている拡張子に関するいくつかの注を含んでいます。 Z39.50の潜在的作成者は、Z39.50プロトコルに特定の情報と現在の実装の詳細と同様に開発中の拡大を得るためにZ3950IW LISTSERV[9]に加入するべきです。
Lynch [Page 2] RFC 1729 Using the Z39.50 in the Internet Environment December 1994
環境1994年12月にインターネットでZ39.50を使用するリンチ[2ページ]RFC1729
Except where otherwise noted, the version of Z39.50 discussed here is ANSI/NISO Z39.50-1992, sometimes called Z39.50 Version 2 (the obsolete original version is referred to as Z39.50-1988 or Z39.50 Version 1). The approach defined should also be applicable, perhaps with some minor changes, to future versions of the Z39.50 protocol, and specifically to Version 3 which is currently under development. This document will probably be updated to address new versions of the base Z39.50 protocol as they become stable.
別の方法で述べられるところ以外の、ここで議論したZ39.50のバージョンは時々Z39.50バージョン2と呼ばれるANSI/NISO Z39.50-1992(時代遅れのオリジナルバージョンはZ39.50-1988かZ39.50バージョン1と呼ばれる)です。 また、定義されたアプローチも適切であるべきです、恐らくZ39.50プロトコルの将来のバージョンと、そして、特に現在開発中であるバージョン3へのいくつかのマイナーチェンジで。 安定するようになるときベースZ39.50プロトコルの新しいバージョンを扱うためにたぶんこのドキュメントをアップデートするでしょう。
Encoding
コード化
The Z39.50 standard specifies its application protocol data units (APDUs) in Abstract Syntax Notation One (ASN.1) [10]. These APDUs include EXTERNAL references to other ASN.1 and non-ASN.1 objects such as those defining record transfer syntaxes to be used in a given application association.
Z39.50規格は抽象的なSyntax Notation One(ASN.1)[10]でアプリケーション・プロトコルデータ単位(APDUs)を指定します。 これらのAPDUsは与えられた応用アソシエーションで使用されるために記録的な転送構文を定義するものなどの他のASN.1と非ASN.1個のオブジェクトのEXTERNAL指示するものを含んでいます。
The standard Basic Encoding Rules (BER) [11] are applied to the ASN.1 structures defined by the Z39.50 protocol to produce a byte stream that can be transmitted across a TCP/IP connection. The only restriction on the use of BER to produce this byte stream is that direct, rather than indirect, references must be used for EXTERNAL objects. This is necessary because there is no presentation context in the TCP/IP environment to support indirect reference. A Z39.50 implementation developed according to this specification and running over TCP/IP should produce a valid byte stream according to the Z39.50 standard, in the sense that the same byte stream could be passed to an OSI implementation. However, not all byte streams that can be produced by applying BER to the APDUs specified in the Z39.50 standard in an OSI environment will be legitimate under this specification for the TCP/IP environment; this specification defines a subset of the possible byte streams valid in a pure OSI environment which excludes those using indirect reference for EXTERNAL objects.
標準のBasic Encoding Rules(BER)[11]はZ39.50プロトコルによって定義された、TCP/IP接続の向こう側に伝えることができるバイト・ストリームを起こしたASN.1構造に適用されます。 間接的であるというよりむしろこのバイト・ストリームを起こすBERの使用の唯一の制限がそんなにダイレクトである、EXTERNALオブジェクトに参照を使用しなければなりません。 間接的な言及をサポートするためにTCP/IP環境にはプレゼンテーション文脈が全くないので、これが必要です。 Z39.50規格に従って、この仕様通りに開発されて、TCP/IPをひくZ39.50実装は有効なバイト・ストリームを起こすべきです、同じバイト・ストリームをOSI実装に通過できたという意味で。 しかしながら、OSI環境におけるZ39.50規格で指定されたAPDUsにBERを適用することによって起こすことができるというわけではないすべてのバイト・ストリームがTCP/IP環境のためのこの仕様に基づき正統になるでしょう。 この仕様はEXTERNALオブジェクトに関する間接的な言及を使用するものを除く純粋なOSI環境で有効な可能なバイト・ストリームの部分集合を定義します。
All other BER features should be tolerated by Z39.50 implementations running over TCP/IP, including the ability to accept indefinite length encodings, although it is preferable that implementations do not generate such encodings since they have caused problems for some ASN.1/BER parsers. It should also be noted that at least to the best of the author's knowledge, there are no implementations at present that use ASN.1/BER representations of floating point numbers; instead, integers with scaling factors have been used for these purposes. It should also be noted that Z39.50 version 2 does not really address character set encoding issues; these questions, and their interactions with ASN.1/BER support for multiple character sets, are under active discussion as part of the effort to develop Z39.50 version 3.
他のすべてのBERの特徴がTCP/IPをひくZ39.50実装によって許容されるべきです、無期長さのencodingsを受け入れる能力を含んでいて、実装がいくつかのASN.1/BERパーサのために問題を起こしたのでそのようなencodingsを生成しないのが、望ましいのですが。 また、現在のところの浮動小数点のASN.1/BER表現を使用する実装が全く少なくとも作者の知識では、ないことに注意されるべきです。 代わりに、けた移動子がある整数はこれらの目的に使用されました。 また、Z39.50バージョン2が、本当に文字集合コード化が問題であると扱わないことに注意されるべきです。 Z39.50バージョン3を開発するために、取り組みの一部としてこれらの質問、および複数の文字集合のASN.1/BERサポートとのそれらの相互作用は活発な議論であります。
Lynch [Page 3] RFC 1729 Using the Z39.50 in the Internet Environment December 1994
環境1994年12月にインターネットでZ39.50を使用するリンチ[3ページ]RFC1729
Connection
接続
In the Internet environment, TCP Port 210 has been assigned to Z39.50 by the Internet Assigned Numbers Authority [12]. To initiate a Z39.50 connection to a server in the TCP/IP environment, a client simply opens a TCP connection to port 210 on the server and then, as soon as the TCP connection is established, transmits a Z39.50 INIT APDU using the BER encoding of that INIT APDU as described above.
インターネット環境で、TCP Port210はインターネットAssigned民数記Authority[12]によってZ39.50に割り当てられました。 クライアントは、TCP/IP環境におけるサーバにZ39.50接続を開始するために、上で説明されるように210をサーバに移植するために単にTCP接続を開いて、TCP接続が確立されるとすぐに、次に、そのINIT APDUのBERコード化を使用することでZ39.50 INIT APDUを伝えます。
Implementors should be aware that there is a substantial installed base of implementations of the Wide Area Information Server (WAIS) system. The original versions of this software employed Z39.50 Version 1 with some extensions. Z39.50 Version 1 did not use BER encoding and Z39.50 Version 1 INIT APDUs look very different from the INIT APDUs of Z39.50 Version 2. Implementations of Z39.50 should at least be prepared to reject gracefully WAIS-type INIT APDUs. Some implementations recognize such INIT APDUs and revert to the Z39.50 Version 1 variant used in WAIS upon encountering them, thus providing backwards compatibility with the existing base of WAIS clients and; the usual means of checking for a WAIS, as opposed to Z39.50 Version 2, client is to see if the first byte sent on the connection is an ASCII zero, which indicates a WAIS client. (In version 1 of WAIS, bytes 0-9 of the first PDU contain an ASCII packet length; the lower case ASCII string "wais" appears starting at byte 12.) Work is currently underway to specify a WAIS profile for use with Z39.50 version 2 [13]; it is expected that this will be issued as a Z39.50 Applications Profile through the NIST OIW Library Automation Special Interest Group. This profile is expected to be compatible with the layering defined in this RFC.
作成者はWide Area情報Server(WAIS)システムの実装のかなりのインストールされたベースがあるのを意識しているべきです。 いくつかの拡大を伴うこのソフトウェア採用しているZ39.50バージョン1のオリジナルバージョン。 Z39.50バージョン1はBERコード化を使用しませんでした、そして、Z39.50バージョン1INIT APDUsはZ39.50バージョン2のINIT APDUsと非常に異なるように見えます。 Z39.50の実装は優雅にWAIS-タイプINIT APDUsを拒絶するように少なくとも準備されるべきです。 そして、彼らに遭遇するときいくつかの実装が、そのようなINIT APDUsを認識して、WAISで使用されるバージョン1異形をZ39.50に振り向けます、その結果、WAISクライアントの存立基盤との互換性を後方に提供する、。 Z39.50バージョン2と対照的にWAISがないかどうかチェックする普通の手段、クライアントは最初のバイトが、接続がASCIIゼロであることを転送したかどうかを見ることになっています。(ASCIIはWAISクライアントを示します)。 (WAISのバージョン1では、最初のPDUのバイト0-9はASCIIパケット長を含んでいます; バイト12で始まって、小文字ASCIIストリング"wais"は現れます。) 仕事は現在、Z39.50バージョン2[13]で使用のためのWAISプロフィールを指定するために進行中です。 これがZ39.50 Applications ProfileとしてNIST OIW図書館Automation特別利益団体Groupを通して発行されると予想されます。 このプロフィールはこのRFCで定義されるレイヤリングと互換性があると予想されます。
Service Mappings
サービス対応表
The Z39.50 standard maps Z39.50 services onto a variety of association control and presentation layer services. Connection establishment has already been discussed. The other two association control services that are relevant to Z39.50 are ABORT and RELEASE. The mapping of the RELEASE service to a standard TCP CLOSE is straightforward. The Z39.50 protocol itself does not, in the current version, include a Z39.50 CLOSE APDU. When the client has completed its interaction with the server, it calls the IR-RELEASE service, which is directly mapped to association control's orderly association release. In the TCP/IP environment, the client should simply initiate a TCP CLOSE. The mapping for association abort is more complex, partially because some TCP/IP implementations cannot distinguish a TCP reset from the other side of the connection from other events. To accomplish an abort (that is, a mapping of the IR-ABORT service in the Z39.50 protocol) in the TCP/IP environment, client or server need only terminate the TCP connection either via TCP ABORT or TCP CLOSE.
Z39.50規格はさまざまなアソシエーション制御とプレゼンテーション層サービスにZ39.50サービスを写像します。 既にコネクション確立について議論しました。 他の2つのZ39.50に関連しているアソシエーション制御サービスが、ABORTとRELEASEです。 標準のTCP CLOSEに対するRELEASEサービスのマッピングは簡単です。 最新版では、Z39.50プロトコル自体はZ39.50 CLOSE APDUを含んでいません。 それは、IR-RELEASEサービスをクライアントがサーバとの相互作用を終了したとき、どれが直接アソシエーション制御の規則的な協会リリースに写像されるかと呼びます。 TCP/IP環境で、クライアントは単にTCP CLOSEを開始するべきです。 協会アボートのためのマッピングは、より複雑であり、部分的に、いくつかのTCP/IPインプリメンテーションが区別できないので、接続の反対側と他のイベントとTCPリセットを区別してください。 TCP/IP環境、クライアントまたはサーバ必要だけでアボート(すなわち、Z39.50プロトコルにおけるIR-ABORTサービスのマッピング)を実行するには、TCP ABORTかTCP CLOSEを通してTCP接続を終えてください。
Lynch [Page 4] RFC 1729 Using the Z39.50 in the Internet Environment December 1994
環境1994年12月にインターネットでZ39.50を使用するリンチ[4ページ]RFC1729
Real-world implementations need to be prepared to deal with both TCP ABORT and CLOSE anyway, so this approach presents no additional problems, other than the somewhat ambiguous nature of the type of association termination.
本当の世界実装が、とにかくTCP ABORTとCLOSEの両方に対処するように準備される必要があるので、このアプローチはどんな追加問題も提示しません、協会終了のタイプのいくらかあいまいな本質を除いて。
It is expected that Z39.50 Version 3 will include a termination service which will involve an exchange of Z39.50 CLOSE APDUs, followed by an association RELEASE (which would presumably, in the Internet environment, be mapped to a TCP CLOSE). This new termination service is expected to support both graceful and abrupt termination. Of course, robust implementations will still need to be prepared to encounter TCP CLOSE or ABORT.
Z39.50バージョン3が協会RELEASE(インターネット環境でおそらく、TCP CLOSEに写像される)によって続かれたZ39.50 CLOSE APDUsの交換にかかわる終了サービスを含むと予想されます。 この新しい終了サービスが、両方が優雅で突然の終了であるとサポートすると予想されます。 もちろん、それでも、強健な実装はTCP CLOSEかABORTに遭遇するように準備される必要があるでしょう。
Service mappings for the transmission of data by client and server (to the presentation layer P-DATA service) are trivial: They are simply mapped to TCP transmit and receive operations. TCP facilities such as expedited data are not used by Z39.50 in a TCP environment.
データの伝達のためのクライアントによるサービス対応表とサーバ(プレゼンテーション層P-DATAサービスへの)は些細です: TCPに写像されて、それらは単にそうです。操作を送受信してください。 速められたデータなどのTCP施設はTCP環境でZ39.50によって使用されません。
Contexts
文脈
At the point when the TCP connection is established on TCP port 210, client and server should both assume that the application context given in Appendices A and B of the Z39.50-1992 standard are in place. These are the ASN.1 definitions of the Z39.50 APDUs and the transfer syntax defined by applying the BER to these APDUs.
TCP接続が210、クライアント、およびサーバがともに仮定するべきであるZ39.50-1992規格のAppendices AとBで与えられたアプリケーション文脈が適所にあるTCPポートの上で確立されるときのポイントで。 これらはZ39.50 APDUsの.1の定義と転送構文がこれらのAPDUsにBERを適用することによって定義したASNです。
Implementations can reasonably expect that the diagnostic set BIB-1 is supported, and, if resource control is being used, the resource report format BIB-1 is supported as well.
実装は診断セットBIB-1がサポートされて、資源管理が使用されているならまた、リソースレポート形式BIB-1がサポートされると合理的に予想できます。
In the absence of a presentation negotiation mechanism, clients and servers should be cautious about using alternative attribute sets, diagnostic record formats, resource report formats, or other objects defined by optional EXTERNALs within the Z39.50 ASN.1, such as authentication parameters, unless there is known to be prior agreement to support them. Of course, either participant in an association can reference such an object by object ID in an APDU, but there is no guarantee that the other partner in the association will be able to understand it. Robust implementations should be prepared to encounter unknown or unsupported object IDs and generate appropriate diagnostics. Over time, the default, commonly known pool of object IDs may be expanded (for example, to support authentication parameters).
プレゼンテーション交渉メカニズムがないとき、クライアントとサーバはそれらをサポートする事前同意であることが知られていて、ない場合セット、診断レコード形式、リソースレポート形式、または他のオブジェクトがZ39.50 ASN.1の中の認証パラメタなどの任意のEXTERNALsで定義した択一的属性を使用することに関して用心深いはずです。 もちろん、協会のどちらの関係者もAPDUのオブジェクトIDでそのようなオブジェクトに参照をつけることができますが、協会のもう片方のパートナーがそれを理解できるという保証が全くありません。 強健な実装は、未知の、または、サポートされないオブジェクトIDに遭遇して、適切な病気の特徴を生成するように準備されるべきです。 時間、デフォルトについてオブジェクトIDの一般的に知られているプールは広げられるかもしれません(例えばサポート認証パラメタに)。
Implementors should refer to the document [14] issued by the Z39.50 maintenance agency in June 1992 for more details on the assumed contexts and object identifiers.
作成者は1992年6月に想定された文脈とオブジェクト識別子に関するその他の詳細のためにZ39.50メインテナンス代理店によって発行されたドキュメント[14]を参照するべきです。
Lynch [Page 5] RFC 1729 Using the Z39.50 in the Internet Environment December 1994
環境1994年12月にインターネットでZ39.50を使用するリンチ[5ページ]RFC1729
Record syntaxes present a serious practical problem. In the OSI environment, the partners in a Z39.50 association are assumed to agree, either through presentation negotiation as part of association establishment, or later, dynamically, as part of the PRESENT process (through the use of the alter presentation context function at the presentation layer), on which record syntaxes the two entities commonly know. There is a preferred record syntax parameter that can be supplied by the client to guide this negotiation. A number of registered record syntaxes exist; some are based on ASN.1 and others use formats such as the MARC standard for the interchange of machine readable cataloging records which predate ASN.1, but are widely implemented. In the TCP/IP environment, if the server cannot supply the record in the preferred syntax, it has no guarantee that the client will understand any other syntax in which it might transmit the record back to the client, and has no means of negotiating such syntaxes.
記録的な構文は重大な実用的な問題を提示します。 OSI環境で、Z39.50協会のパートナーが協会設立の一部としてのプレゼンテーション交渉か後のどちらかにダイナミックに同意すると思われます、PRESENTプロセスの一部として(使用、変わる、プレゼンテーション層におけるプレゼンテーション文脈機能)、2つの実体が一般的にどの記録的な構文を知るかに関して。 クライアントがこの交渉を誘導するために提供できる都合のよい記録的な構文パラメタがあります。 多くの登録された記録的な構文が存在しています。 或るものは、ASN.1より前に起こる記録をカタログに載せながら使用がマシンの置き換えのマーク規格などのようにフォーマットするASN.1と他のものに読み込み可能な状態で基づいていますが、広く実装されます。 TCP/IP環境で、サーバが都合のよい構文による記録を提供できないなら、それはクライアントがそれが記録をクライアントに伝えて戻すかもしれなくて、そのような構文を交渉する手段を全く持っていないいかなる他の構文も理解するという保証を全く持っていません。
Several proposals have been suggested to solve this problem. One, which will likely be part of Z39.50 Version 3, is to replace the preferred record syntax parameter with a list of prioritized preferred syntaxes supplied by the client, plus a flag indicating whether the server is allowed to substitute a record syntax not on the list provided by the client. The currently proposed ASN.1 for this extension is upwards compatible with Z39.50 Version 2, although the details are still under discussion within the Z39.50 Implementor's Group. As the Version 3 ASN.1 becomes stable in this area, Z39.50 servers are encouraged to accept the extended ASN.1 for generalized preferred record syntax. The extensibility rules for Z39.50 negotiation let clients and servers negotiate the use of Z39.50 Version 2 plus the generalized preferred syntax feature from Version 3. Thus, a client could support the generalized preferred record syntax, propose its use to any server, and, if the server rejects the proposal, revert to the Version 2 preferred syntax feature.
いくつかの提案が、この問題を解決するために示されました。 もの(おそらくZ39.50バージョン3の一部になる)はクライアントによって提供される最優先する都合のよい構文のリストとサーバがリストでクライアントによって提供されなかった記録的な構文を代入できるかどうかを示す旗に都合のよい記録的な構文パラメタを置き換えることです。 この拡大のための現在提案されたASN.1は上向きにZ39.50バージョン2と互換性があります、Z39.50 ImplementorのGroupの中に詳細がまだ議論でありますが。 バージョン3として、ASN.1はこの領域で安定するようになって、Z39.50サーバが一般化された都合のよい記録的な構文のために拡張ASN.1を受け入れるよう奨励されます。 Z39.50交渉のための伸展性規則で、クライアントとサーバはZ39.50バージョン2の使用とバージョン3からの一般化された都合のよい構文機能を交渉します。 したがって、クライアントは、一般化された都合のよい記録的な構文をサポートして、どんなサーバにも使用を提案して、サーバが提案を拒絶するなら、2の都合のよい構文機能をバージョンに振り向けるかもしれません。
A second alternative (not incompatible with the Version 3 extension) would be to adopt a convention for TCP/IP implementations that the server not return a record in a syntax not on the preferred record syntax list provided by the client. Instead, it would return a diagnostic record indicating that a suitable record transfer syntax was not available. This strategy could be viewed as simply implementing a subset of the Version 3 solution, and should be considered by implementors of servers as a possible interim measure.
2番目の代替手段(バージョン3拡大と非互換でない)はサーバが都合のよい記録的な構文リストでクライアントによって提供されなかった構文による記録を返さないTCP/IPインプリメンテーションのためにコンベンションを採用するだろうことです。 代わりに、それは適当な記録的な転送構文が利用可能でなかったのを示す診断記録を返すでしょう。 この戦略は、同じくらい単にバージョン3解決の部分集合を実装しながら見ることができて、サーバの作成者によって可能な一時的な方策と考えられるべきです。
Lynch [Page 6] RFC 1729 Using the Z39.50 in the Internet Environment December 1994
環境1994年12月にインターネットでZ39.50を使用するリンチ[6ページ]RFC1729
Other Interoperability Issues
他の相互運用性問題
Version 3 will include an "other" data field in each APDU, which can be used to carry implementation-specific extensions to the protocol. A number of implementations are already employing this field, and interoperable implementations might be wise to include code which at least ignores the presence of such fields rather than considering their presence an error (in contravention of the standard).
バージョン3は各APDUの「他」のデータ・フィールドを含むでしょう。(実装特有の拡大をプロトコルまで運ぶのにAPDUを使用できます)。 多くの実装が既にこの分野を使っています、そして、共同利用できる実装は、それらの存在が誤り(規格の違反における)であると考えるよりむしろそのような分野の存在を少なくとも無視するコードを含むように賢明であるかもしれません。
References
参照
[1] National Information Standards Organization (NISO). American National Standard Z39.50, Information Retrieval Service Definition and Protocol Specifications for Library Applications (New Brunswick, NJ: Transaction Publishers; 1988).
[1] 国家の情報水準組織(NISO)。 図書館アプリケーション(ニューブランズウィック(ニュージャージー): トランザクション出版社; 1988)のための米国標準規格Z39.50、情報検索サービス定義、およびプロトコル仕様。
[2] ANSI/NISO Z39.50-1992 (version 2) Information Retrieval Service and Protocol: American National Standard, Information Retrieval Application Service Definition and Protocol Specification for Open Systems Interconnection, 1992.
[2] ANSI/NISO Z39.50-1992(バージョン2)情報検索サービスとプロトコル: 米国標準規格と情報検索アプリケーション・サービス定義とオープン・システム・インターコネクション、1992年のプロトコル仕様。
[3] ISO 10162 International Organization for Standardization (ISO). Documentation -- Search and Retrieve Service Definition, 1992.
[3] ISO10162国際標準化機構(ISO)。 ドキュメンテーション--サービス定義、1992を捜して、検索してください。
[4] ISO 10163 International Organization for Standardization (ISO). Documentation -- Search and Retrieve Protocol Definition. 1992.
[4] ISO10163国際標準化機構(ISO)。 ドキュメンテーション--プロトコル定義を捜して、検索してください。 1992.
[5] ISO 8822 - Information Processing Systems - Open Systems Interconnection - Connection Oriented Presentation Service Definition, 1988.
[5] ISO8822--情報処理システム--開放型システム間相互接続--接続はプレゼンテーション・サービス定義、1988を適応させました。
[6] ISO 8649 - Information Processing Systems - Open Systems Interconnection - Service Definition for the Association Control Service Element, 1987. See also ISO 8650 - Information Processing Systems - Open Systems Interconnection - Protocol Specification for the Association Control Service Element, 1987.
[6] ISO8649(情報処理システム--開放型システム間相互接続)はアソシエーション制御サービス要素、1987年の定義を修理します。 また、ISO8650を見てください--情報Processing Systems--オープン・システム・インターコネクション--Association Control Service Element、1987年のプロトコルSpecification。
[7] Rose, M., and D. Cass, "ISO Transport Layer Services on Top of the TCP, Version 3", STD 35, RFC 1006, Northrop Research and Technology Center, May 1987.
[7] バラ、M.、およびD.キャス、「ISOはRFC1006、ノースロップのTCP、バージョン3インチ、STD35、研究、および技術センターの上で層のサービスを輸送します、1987年5月。」
[8] Registry of Z39.50 Implementors, available from the Z39.50 Maintenance Agency (Ray Denenberg, ray@rden.loc.gov)
[8] Z39.50 Maintenance Agencyから利用可能なZ39.50 Implementorsの登録(レイDenenberg、 ray@rden.loc.gov )
Lynch [Page 7] RFC 1729 Using the Z39.50 in the Internet Environment December 1994
環境1994年12月にインターネットでZ39.50を使用するリンチ[7ページ]RFC1729
[9] To subscribe to the Z39.50 Implementor's Workshop list send the message: SUB Z3950IW yourname to: LISTSERV@NERVM.NERDC.UFL.EDU (or NERVM.BITNET). Current drafts of the Version 3 Protocol document are available through the Library of Congress GOPHER server, MARVEL.LOC.GOV.
[9] Z39.50 ImplementorのWorkshopリストに加入するには、メッセージを送ってください: 以下へのSUB Z3950IW yourname LISTSERV@NERVM.NERDC.UFL.EDU (または、NERVM.BITNET)。 MARVEL.LOC.GOV、バージョン3プロトコルドキュメントの現在の草稿は議会図書館ゴーファーサーバを通して利用可能です。
[10] ISO 8824 - Information Processing Systems - Open Systems Interconnection - Specifications for Abstract Syntax Notation One (ASN.1), 1987
抽象構文記法1(ASN.1)のための仕様、[10] ISO8824--情報処理システム--オープン・システム・インターコネクション--1987
[11] ISO 8825 Information Processing Systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1) 1987
[11] ISO8825情報処理システム--オープン・システム・インターコネクション--抽象構文記法1(ASN.1)1987年の基本的な符号化規則の仕様
[12] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994.
[12] USC/情報科学が1994年10月に設けるレイノルズ、J.、およびJ.ポステル、「規定番号」、STD2、RFC1700。
[13] WAIS Profile of Z39.50 Version 2, Revision 1.4, April 26, 1994, available from WAIS Inc.
[13] Z39.50バージョン2のWAIS Profile、1994年4月26日にWAIS Inc.から利用可能なRevision1.4
[14] Registration of Z39.50 OSI Object Identifiers (Z39.50-MA-024), available from the Z39.50 Maintenance Agency (Ray Denenberg, ray@rden.loc.gov).
[14] Z39.50 Maintenance Agency(レイDenenberg、 ray@rden.loc.gov )から利用可能なZ39.50 OSI Object Identifiers(Z39.50mA024)の登録。
Security Considerations
セキュリティ問題
This document does not discuss security considerations. However, it should be noted that the Z39.50 protocol includes mechanisms for authentication and security that implementors should review.
このドキュメントはセキュリティ問題について議論しません。 しかしながら、Z39.50プロトコルが作成者が見直すべきである認証とセキュリティのためのメカニズムを含んでいることに注意されるべきです。
Author's Address
作者のアドレス
Clifford A. Lynch University of California, Office of the President 300 Lakeside Drive, 8th Floor Oakland, CA 94612-3550
クリフォードA.リンチカリフォルニア大学、Lakeside Drive社長300のオフィス、第8Floorオークランド、カリフォルニア94612-3550
Phone: (510) 987-0522 EMail: clifford.lynch@ucop.edu
以下に電話をしてください。 (510) 987-0522 メールしてください: clifford.lynch@ucop.edu
Lynch [Page 8]
リンチ[8ページ]
一覧
スポンサーリンク