要約

  • RFC 2056は、利用者との対話を続けるz39.50sと、サーバー定義の不透明なdocidから既知項目検索を行うz39.50rを、URL方式の段階で分離した。
  • z39.50rの成功条件は検索結果がちょうど1件であることだが、その一意性は対象の真正性、書誌的正しさ、完全性、認可、安全性まで証明するものではない。
  • RFC 2056は現在もProposed Standardとして記録され、二つの方式はIANAでPermanent登録されている。ただし、文書や登録の状態は現在の配備、利用量、実装健全性、運用上の推奨を示さない。

RFC 2056が扱った問題は、Z39.50の仕事を単純な無状態取得として表せるかどうかだった。導入部では、一般的な問い合わせはセッション指向で複数段階に及び、途中でサーバーが追加パラメータを求めて処理が止まることさえあると説明される。その一方で、よく知られた項目の取得なら、一回の検索を中心とする退化した要求・応答セッションにできる。二つの操作意図を方式名に出したことで、利用者インターフェースはURLの不透明な部分を解読しなくても、これから対話型セッションへ入るのか、一件の取得を試みるのかを判別できた。

z39.50sではホストが必須で、ポートの既定値は210である。クライアントは新しいセッションを開始しても、同じホストとポートにすでに開いているセッションを再利用してもよい。docidが指定される場合はデータベースも必要になり、所定の検索が実行される。docidがなければ、その他のパラメータを要件として扱うか、選好として扱うか、あるいは無視可能なヒントと見るかはクライアントに委ねられる。処理の終点も取得型とは違い、セッションは利用者のために開いたまま残される。

z39.50rではホストとデータベースが必須で、ポートを省略すれば210となる。docidのないURLの意味は未定義だ。クライアントはSearchを構成し、ヒット数がちょうど1でなければ取得は不成功となり、その場合のアプリケーション動作はRFCでは定められていない。唯一のレコードがSearch Responseに含まれていなければPresentを発行する。レコード受領後にセッションを閉じるか保持するかはクライアントが決める。

この取得手順で使うdocidには、見た目以上の意味を与えられていない。文字列はサーバーが定義し、クライアントにとって完全に不透明である。z39.50rではそれをBib-1のUse=docid、Structure=URx、general format tag 45の単一項としてType-1 queryへ組み込む。したがって、docidが正しく保存され所定の検索に使われたことと、それが世界的に意味を持つ永続識別子であること、真正であること、内容アドレスであること、別サーバーへ移せることは別の話である。

検索結果の一意性にも同じ限界がある。Z39.50のSearch結果は、選択されたデータベースレコードへのポインタからなるサーバー側の結果集合である。RFC 2056は、ローカルなデータベースレコード、共有される抽象的なデータベースレコード、外部へ渡される取得レコードを区別する。elementsetは論理的な要素の選択を、recordsyntaxは選ばれた要素を転送用に包む方法を左右する。一件だけヒットしてレコードが届いても、それだけで意図した著作物との同一性、書誌記述の正確さ、基礎レコードの完全性が確定するわけではない。

esnが省略されればクライアントが選び、指定されていれば該当するSearchまたは後続のPresentのパラメータに入る。rsも省略時はクライアントが選択する。複数のレコード構文を示す場合でも;rs=を繰り返すのではなく、rsパラメータは一つで、その値の中で構文を+によって区切る。クライアントは自らが対応する最初の値を優先し、それをPreferredRecordSyntaxとして送るべきだとされる。RFC 1729が記録した、サーバーが希望された構文を提供できない場合の相互運用上の問題は、表現の選択と実際の提供能力が同じではないことを補足する。

BNFはRFC 1738の共通URL構文を土台とし、方式名を正確にz39.50sとz39.50rと定める。データベースは一つ以上を+で区切って指定でき、任意の?docidと;esn=、そして一つの;rs=を持てる。rsの中では一つ以上のレコード構文値を+で区切る。この構文が示すのは、どの接続先、データベース、識別子、要素集合、転送表現を要求として運べるかであって、ホストの現在の所有者や権限、ポート210で応答するサービスの意味、データベース名が指す管理範囲まで固定するものではない。

RFC 2056自身のセキュリティ節は、この境界を歴史的な仕様の内部から示している。ロケータがもはや当初意図された対象を指していない場合があり、一見無害な取得が損害を与える遠隔操作を引き起こす可能性もある、と警告する。URL方式、接続先、docid、ヒット数、要素集合、レコード構文、レコード配送はそれぞれ観測できるが、それらは対象の真正性、認証、認可、意味の完全性、安全な表現、利用者が外部で達成したかった結果とは同一ではない。受領済みのレコードも、継続的な認可やセッション連続性、その後の利用成功を遡って保証しない。

文書としての現在位置も限定して読める。RFC 2056は1996年11月にStandards Track文書として公開され、現在のRFC EditorとIETF DatatrackerはProposed Standardと表示する。DatatrackerではLegacy streamに分類され、公開されているRFCメタデータには明示的な更新・廃止関係が示されていない。IANA URI Schemesレジストリではz39.50rとz39.50sがPermanent、旧z39.50がHistoricalである。これは文書と登録の状態についての事実であり、現在どれほど配備され、通信があり、健全に実装されているかを示す測定値ではない。

近接する歴史資料も契約を混同しないほうが輪郭を明瞭にする。RFC 1625のWAISプロファイルはType-3 queryと無状態の結果処理を採用した。それに対しRFC 2056の取得URLはType-1の既知項目検索を要求し、Search ResponseにレコードがなければPresentへ進み得る。同時代の検索・取得技術という近さだけで、両者を一つの動作モデルへまとめることはできない。

参照資料