日米両国におけるドキュメント・デリバリー・サービスの改善に … · 平成11年2月に行われた「日米両国におけるドキュメント・デリバリー・サービ

日米両国におけるドキュメント・デリバリー・サービスの

改善に関するプロジェクト

2000 年度報告

2001 年 3 月

国立情報学研究所

日米両国におけるドキュメント・デリバリー・サービスの改善に関するプロジェクト 2000 年度報告書

目次

挨拶････････････････････････････････････････････････････････宮澤彰

1 日米両国におけるドキュメント・デリバリー・サービスの改善に関する

プロジェクト概要

1.1 設置経緯....................................................... 1

1.2 メンバー一覧 ................................................... 1

1.3 活動内容....................................................... 2

1.4 今後の課題 ..................................................... 8

2 日米両国におけるドキュメント・デリバリー・サービスの改善に関する

ワーキンググループ活動報告

2.1 設置経緯...................................................... 11

2.2 メンバー一覧 .................................................. 11

2.3 活動内容...................................................... 12

2.4 総括 .......................................................... 15

資料

*日米ドキュメント・デリバリー・サービス試行実験について............... 17

*日米両国の ILL 改善のための試行実験プロジェクト両国による評価と提言 .. 20

ISO プロトコルサービス一覧 ........................................... 23

ISO プロトコル APDU 一覧 .............................................. 24

ISO プロトコル状態一覧 ............................................... 25

APDU 送信・受信毎の NACSIS-ILL システム ISO ILL プロトコル

対応機能の動作....................................................... 26

NACSIS-ILL Profile for the ISO ILL Protocol .......................... 35

* 印の資料は国立大学図書館協議会作成

挨拶

国立情報学研究所では、オンライン共同目録方式の目録所在情報サービス

NACSIS-CAT によって、全国の大学図書館の総合目録を維持し、また、このデータベー

スを利用した図書館相互貸借のメッセージシステム NACSIS-ILL によって、学術情報の

流通に寄与してきた。とくに、総合目録データベースは NACSIS-Webcat サービスによ

って、インターネットを介して全世界に無料で公開され、海外にも多くのユーザを持

っている。これらの発展の結果、米国の図書館から、日本の大学図書館の所蔵する資

料が容易に探せるようになり、それらの資料にアクセスしたいという要求が出てくる

ようになってきた。これらの点から、図書館の間で、国際的なドキュメントデリバリ

ーの必要性が問題になってきており、国立情報学研究所としても、これらの動きに対

応した施策をとる必要性が出てきた。

一方、国立大学図書館協議会は、北米の日本関係図書館団体である NCC（North

American Coordinating Council on Japanese Library Resources）と協議を行い、そ

の中で、両国の書誌ユティリティ機関に対し、ドキュメントデリバリーの改善を助け

るため、ISO ILL プロトコルによる ILL メッセージの国際的交換を可能にしてほしい

との要望が出された。ISO ILL プロトコルは、各国ごとの閉じたネットワークの中で

の ILL メッセージ交換でなく、国際的なメッセージ交換を可能にするためのプロトコ

ルで、最近北米、ヨーロッパはもとより、韓国などでも実装例が多くなり、真に国際

的プロトコルになりつつある。このプロトコルに対応することは、こういった国際的

動向からしても国立情報学研究所に求められているものであり、今回本プロジェクト

によってその実現を図ることになった。

本プロジェクトの最終成果であるプロトコルの実装は、本報告書にあるとおり設計

を終えて、開発ならびにテストの段階であるが、一方この実装を実際のサービスにつ

なげるための米国の書誌ユーティリティOCLCならびに、RLGとの話し合いも始まった。

これらの成果が、真に国際的な学術情報の流通基盤進展に寄与することを願うもので

ある。

国立情報学研究所実証研究センター長

日米両国におけるドキュメント・デリバリー・サービスの

改善に関するプロジェクト主査

宮澤彰

1

1 日米両国におけるドキュメント・デリバリー・サービスの改善に関するプロジェクト概要

1.1 設置経緯

平成 11 年 2 月に行われた「日米両国におけるドキュメント・デリバリー・サービ

スの改善に関するラウンドテーブル」において、国立大学図書館協議会と全米日本研

究資料調整委員会（NCC）との間で「日米両国の ILL 改善のための試行実験プロジェク

ト」が合意された。この合意事項の中で、両国の書誌ユティリティに対し、ISO の ILL

プロトコルの実装が要請されており、両国間の ILL システムの試行実験が平成 11 年 7

月から平成 12 年 3 月まで行われ、平成 12 年 6 月まで延長され、さらに平成 12 年 12

月まで延長され終了した。

また、RLG（Research Libraries Group)からは、共同プロジェクトの提案が昨年に

あり、平成 11 年 4 月にはより具体的な提案が送られてきている。

さらに、米国を代表する書誌ユティリティである OCLC との間においても、ILL プロ

トコルによる接続に向けての検討が開始されている。

本プロジェクトは、これらを考慮し、学術情報センターと RLG 及び OCLC との協力

内容を検討することにより、日米間の学術情報流通をより一層促進するため、国際事

業調整部会の下に平成 12 年 3 月までの期間で設置された。

本プロジェクト及び本プロジェクトの下に設置された「日米両国におけるドキュメ

ント・デリバリー・サービスの改善に関するワーキンググループ」において検討及び

作業を行い、学術情報センター図書館間相互貸借システム（NACSIS-ILL）においては、

BLDSC の ILL プロトコル採用に対応して、ILL プロトコルの申込側機能の開発を既に行

っており、提供側機能の開発についても作業を進めている。

本プロジェクトは平成 12 年 3 月で終了したが、平成 12 年 3 月 14 日に開催された

日米両国におけるドキュメント・デリバリー・サービスの改善に関するプロジェクト

第 2回会議において、RLG や OCLC 対応の ILL システム仕様作成、Z39.50 対応といった

課題が残されていることから、今後も検討を継続する必要性が確認されており、今後

の検討課題を検討するために国際事業委員会の下に設置が継続された。

1.2 メンバー一覧

本プロジェクトは前述のとおり大学図書館関係者等との密接な連係のもとに進める

ことが必要であることから、関連の外部構成員の参加も考慮した。

構成は以下のとおりである。

2

富山大学附属図書館笹川郁夫事務部長

群馬大学附属図書館星野雅英情報管理課長

東京大学附属図書館木下伸二情報管理課長

北海道大学附属図書館諏訪田義美情報システム課長

国立情報学研究所根岸正光研究主幹

宮澤彰実証研究センター長（主査）

神門典子助教授

孫媛助教授

江口浩二助手

高野茂開発・事業部次長

秋山和男広報調査課長

京藤貫コンテンツ課長

酒井清彦コンテンツ課補佐

鵜澤和往計量情報係長

事務局船渡川清広報調査課課長補佐

櫻井美智雄国際事業係長

佐藤大明国際事業係員

また、第 3回会議においては、オブザーバとして以下の参加があった。

富山大学附属図書館四津忠一情報サービス課参考調査係長

群馬大学附属図書館高林桂子情報サービス課資料運用係長

東京大学附属図書館栃谷泰文総務課図書館専門員

東京大学附属図書館関川雅彦総務課企画渉外掛長

北海道大学附属図書館中村陽情報システム課システム管理係員

1.3 活動内容

1.3.1 第 1 回

日時：平成 12 年 10 月 30 日（月）15 時～18 時

場所：学術総合センター12 階会議室

出席者：国立大学図書館協議会

笹川、諏訪田、木下


根岸、宮澤、神門、江口、高野、秋山、京藤、酒井、鵜澤

（事務局：船渡川、櫻井、佐藤）

3

資料

（１）平成 11 年度「日米両国におけるドキュメント・デリバリー・サービスの改善

に関するプロジェクト第 2回会議」議事要旨（案）

（２）日米 DDS のアクションプランの評価に向けて

（３）日米両国におけるドキュメント・デリバリー・サービスの改善に関する検討

事項について（案）

（４）海外との料金決済の具体的方法について

（５）OCLC IFM サービスの概要について（参考資料）

（６）平成 12年度日米両国におけるドキュメント・デリバリー・サービスの改善

に関するワーキンググループの検討事項について（案）

参考資料『日米両国におけるドキュメント・デリバリー・サービスの改善に関する

プロジェクト 1999 年度報告』

議事

議事に先立ち、秋山課長から、平成 12年度のメンバー紹介及び配布資料の確認が

あった。

宮澤実証研究センター長を主査として、議事を進行した。

船渡川課長補佐から資料 1に基づき、平成 11 年度「日米両国におけるドキュメン

ト･デリバリー･サービスの改善に関するプロジェクト第 2回会議」議事要旨（案）

について説明があり、承認された。

（１）日米両国におけるドキュメント・デリバリー・サービスの改善に関する活動

の現状について

酒井課長補佐から参考資料『日米両国におけるドキュメント・デリバリー・

サービスの改善に関するプロジェクト 1999 年度報告』に基づき、平成 11 年度

の活動状況及び平成 12 年度に予定しているシステム開発等の状況について説

明があった。

平成 12 年度にプロトタイプシステムを開発し、ILL システムの ISO 対応と連

携した接続システムの 1手段としてシステム開発を進める、OCLC との接続テス

トについてはこれからスケジュールやテスト項目を調整するとの補足説明があ

った。

木下課長から資料 2に基づき、日米ドキュメント・デリバリー・サービス試

行実験の状況について説明があった。試行実験を平成 12年 12 月まで延長し、

参加機関に変動があったこと、日米双方で第 3者評価と当事者評価を行い、平

成 13 年 1 月 31 日～2 月 1 日に開催される「日米 DDS 試行実験総括会議『日米

両国における学術情報アクセスの改善のための情報担当者会議 Conference on

4

improvement of academic information access between U.S. and Japan』」に

提出するとの補足説明があった。

また、この総括会議において日米文化教育交流会議（CULCON）への報告をま

とめる必要があるとの説明があった。

（２）日米両国におけるドキュメント・デリバリー・サービスの改善のための課題

について

京藤課長から資料 3 に基づき、平成 12 年度に検討すべき事項について説明

があった。笹川部長から資料 4に基づき、海外との料金決済の方法について説

明があり、この方法については国立大学図書館協議会国際情報アクセス特別委

員会 WG のたたき台としての案であるとの補足説明があった。

酒井課長補佐から資料 5 に基づき、OCLC IFM サービス及び OCLC IFM サービ

スを導入した場合の問題点等について説明があった。

料金決済について種々意見交換を行い、以下の意見等が出された。

• 将来の独立行政法人化を踏まえた案が必要である。

• 国公私間の料金決済を包括した仕組みが望ましい。

（３）今後の進め方について

鵜澤係長から資料 6に基づき、システム開発に関するワーキンググループの

設置、検討事項、作業分担、スケジュール等について説明があり、了承された。

料金決済については、次回のプロジェクト会議で検討することとし、国立大

学図書館協議会から案を提示することとなった。

（４）その他

次回のプロジェクト会議を、12 月中旬に開催することを確認し、日程等につ

いては後で調整することとした。

1.3.2 第 2 回

日時平成 12 年 12 月 15 日（金）14 時～16 時

場所学術総合センター12 階会議室

出席者国立大学図書館協議会

笹川、諏訪田、木下


根岸、宮澤、神門、孫、江口、高野、秋山、京藤、酒井、鵜澤


5

資料



（２）国際 ILL における文献複写料金の決済モデル案について

（３）［国立大学図書館協議会準備資料］

（参考資料）ISO プロトコルによるシステム間リンクの開発状況

議事

（１）前回議事要旨（案）の確認

船渡川課長補佐から資料 1 に基づき、平成 12 年度「日米両国におけるドキ

ュメント・デリバリー・サービスの改善に関するプロジェクト第 1回会議」議

事要旨（案）について説明があり、承認された。

（２）日米 DDS 試行実験について

笹川部長から資料 3に基づき、日米文化教育交流会議（CULCON）及び日米 DDS

試行実験の経緯について説明があり、日米 DDS 試行実験は平成 12年 12 月で終

了することになっているが、平成 13 年 1 月 31 日～2 月 1 日に開催される「日

米 DDS 試行実験総括会議『日米両国における学術情報アクセスの改善のための

情報担当者会議 Conference on improvement of academic information access

between U.S. and Japan』」までは実験を終了せず、文献複写の申込があれば受

け付けるとの補足説明があった。また、高橋事務部長（東京大学附属図書館）

の私案「日米 DDS 実験に関する評価と今後の日本側の対応（案）」と土屋館長（千

葉大学附属図書館）の意見に関して説明があり、まだ国立大学図書館協議会と

してオーソライズされたものではないとの補足説明があった。

国立大学図書館協議会としては、日米間のドキュメント・デリバリー・サー

ビスが本格的に運用できるようになるまでの間をプレ運用段階とし、いくつか

のパイロット館がOCLCのIFMサービスに加入するなどの方策を検討していると

の説明があった。

これについて、宮澤主査及び NII 側委員から、これら私案・意見では、米国

側からの依頼が少ない原因を一方的に日本側システムに問題があるとしている

こと、しかもその原因が推測に基づいており根拠が不明であること、プレ運用

で OCLC を利用するという譲歩案を提示する前に米国側に提案すべき案が少な

くとも 2案はあること、日本側としては相手館（国）の特定システムに依存す

るようなシステム開発は避けるべきこと、ドキュメント・デリバリー・サービ

スについては、必ず相互性を確保することが重要であることを米国側にも主張

する必要がある、以上の点からこの私案・意見は非常に問題が多いとの指摘が

6

あった。

木下課長から国立大学図書館協議会側で用意したその他の資料について説

明があり、統計等については前回のプロジェクト会議で報告しているとの補足

説明があった。

以上の議論を踏まえ、どのような形でまとめるかについて、国立大学図書館

協議会で再度案を練り直すこととなった。

（３）国際 ILL における文献複写料金の決済モデル案について

京藤課長から資料 2に基づき、国立情報学研究所側で用意した国際 ILL にお

ける文献複写料金の 4つの決済モデル案について概要説明があり、酒井課長補

佐からモデル案ごとの具体的な説明があった。

意見交換を行い、以下の意見等が出された。

• 海外の図書館も NACSIS-ILL に参加するよう国立大学図書館協議会として

要請してはどうか。

• 公立・私立・海外を含めた統一的な料金処理が可能な、国際 ILL 業務にお

ける料金決済に文献複写料金決済機構を設立する方向（案 3）で検討するこ

とが望ましい。

（４）その他

酒井課長補佐から、参考資料「ISO プロトコルによるシステム間リンクの開

発状況」に基づき、開発スケジュール等について説明があり、OCLC との接続に

ついては 2001 年 10 月を目標としているとの説明があった。

笹川部長から、国際 ILL における文献複写料金の決済方法について、国立大

学図書館協議会と国立情報学研究所で文部省と協議してはどうかとの提案があ

り、日程を調整することとした。

笹川部長から、平成 13 年 1 月 31 日～2 月 1 日に開催される「日米 DDS 試行

実験総括会議『日米両国における学術情報アクセスの改善のための情報担当者

会議 Conference on improvement of academic information access between U.S.

and Japan』」の概要について、紹介があった。

1.3.3 第 3 回

日時平成 13 年 3 月 12 日（月）10 時～12 時

場所学術総合センター12 階会議室

出席者国立大学図書館協議会

笹川、諏訪田、星野、四津、中村、高林、栃谷、関川

7


宮澤、高野、秋山、京藤、酒井、鵜澤


資料



（２）日米両国における学術情報アクセス改善のための情報担当者会議

Conference on Improvement of Academic Information Access between U.S.

and Japan

（３）日米両国におけるドキュメント･デリバリー・サービスの改善に関するワーキ

ンググループ活動報告

（４）ISO ILL プロトコルを用いた、OCLC 及び RLG とのシステム間リンクの運用に

ついて（米国出張関連資料）

議事

資料４の一部差し換え及び追加があったため、資料の確認を行った。

（１）日米 DDS 試行実験総括会議「日米両国における学術情報アクセス改善のため

の情報担当者会議」の報告

笹川部長から資料 2に基づき、日米 DDS 試行実験総括会議「日米両国におけ

る学術情報アクセス改善のための情報担当者会議」について報告があった。

笹川部長から、文献複写料金に関わる料金決済の制度については文部科学省

で検討がなされているほか、ILL システムについては国立情報学研究所でシス

テム開発が行われており、国立大学図書館協議会では参加館への呼びかけを行

う等の広報・協力を行うとの説明があった。

また、笹川部長から、グローバル ILL/ドキュメントデリバリーの検討に向け

て、土屋千葉大学附属図書館長をコーディネータとし、実務を笹川富山大学附

属図書館事務部長、星野群馬大学附属図書館情報管理課長、早瀬東北大学附属

図書館情報サービス課長、国立大学図書館協議会事務局のチームで担当するこ

とになったとの報告があった。

（２）日米両国におけるドキュメント･デリバリー・サービスの改善に関するワー

キンググループの報告

鵜澤係長から資料 3に基づき、日米両国におけるドキュメント・デリバリー・

サービスの改善に関するワーキンググループの活動報告があった。

鵜澤係長から、検討事項となっている平成 13 年度システム開発事項の検討、

OCLC とのテスト、電子的配送アドレス（OEDA）フィールドの使い方の検討（記

8

述方法）の検討は大筋で終了した、テストについても問題はないとの説明があ

った。

（４）米国出張

京藤課長から、資料 4に基づき、ISO ILL プロトコルを用いた、OCLC 及び RLG

とのシステム間リンクの運用について説明があった。また、3月16日にRLGと、

3 月 19 日に OCLC とシステム間リンクの打ち合わせを行うこととしており、国

立情報学研究所としてこの資料の方針で臨みたいとの説明があった。

3 月 27 日（火）の午後に OCLC が国立情報学研究所を訪問することになって

おり、文部科学省も参加する予定であるとの説明があった。これに対して、国

立大学図書館協議会事務局からも参加することとなった。

本プロジェクトの平成 13 年度以降の取り扱いや OCLC との交渉、平成 13 年

10 月のシステム間リンク実現に向けて、今後は、プロジェクト会議という形を

とる必要はないと考えられるが、引き続き国立情報学研究所と国立大学図書館

協議会との連絡の場を設けることが必要であるとの意見があり、検討すること

とした。

1.4 今後の課題

1.4.1 これまでの検討経緯

日米両国間のドキュメント・デリバリー・サービスが円滑に実施できるよう、米国

の書誌ユーティリティである RLG 及び OCLC の各 ILL システムと NACSIS-ILL とを、ISO

の ILL プロトコルを用いてシステム間の相互利用を実現することを目標として検討し

てきた。

この検討のためにワーキンググループを設置し、技術的な事項を中心に 3回の会合

を行い、NACSIS-ILL システム側の開発作業を進めてきた。

また、国際 ILL における文献複写料金の決済方法について検討を行い、ドキュメン

ト・デリバリー・サービスの実施に向けて、文部科学省及び国立大学図書館協議会と

協議を行っている。

1.4.2 今後の課題

(1) RLG 及び OCLC 等協力機関との ILL システムの接続テスト

ISO の ILL プロトコルに対応した NACSIS-ILL システムと、各協力機関とのシステ

ムの相互接続を行うためのテストを実施している。NII 側のテスト環境を作成し、

引き続きテストを行う必要がある。

9

(2) Z39.50 への対応

ILL システムの相互接続を行うに当たっては、双方の協力機関に属する大学等図

書館の資料所蔵状況が的確な方法で判ることが重要であり、そのためにお互いの目

録所在情報データベースを参照できるよう、Z39.50 への対応について検討を行って

いる。このためのシステム開発を行う必要がある。

(3) 文献複写料金の決済方法の確立

日米両国間のドキュメント・デリバリー・サービスが円滑に実施できるためには、

国際 ILL における文献複写料金の決済方法を確立させる必要がある。

10

11

2 日米両国におけるドキュメント・デリバリー・サービスの改善に関するワーキンググループ活動報告

2.1 設置経緯

平成 12 年 10 月 30 日に開催された「日米両国におけるドキュメント・デリバリー・

サービスの改善に関するプロジェクト」第 1回会議において、以下の事項を検討する

ことを目的として、本ワーキンググループは設置された。

(1) 平成 13 年度システム開発事項の検討

− 貸借依頼・受付

− RLG との依頼・受付

− Z39.50 への対応

(2) OCLC とのテスト

− NII 側でのテスト環境の設定

− OCLC とのスケジュール調整

− テスト項目（チェック項目）の検討及び調整

− テスト作業

− レビュー

(3) 電子的配送アドレス（OEDA）フィールドの使い方の検討（記述方法）

2.2 メンバー一覧

氏名所属

栃谷泰文東京大学附属図書館総務課図書館専門員

関川雅彦東京大学附属図書館総務課企画渉外掛長

大原寿人東京工業大学附属図書館情報サービス課電子情報掛長

（以上、国立大学図書館協議会）

宮澤彰国立情報学研究所実証研究センター長

江口浩二国立情報学研究所研究系助手

酒井清彦国立情報学研究所開発・事業部コンテンツ課課長補佐

鵜澤和往国立情報学研究所開発・事業部コンテンツ課計量情報係長

（以上、国立情報学研究所）

12

2.3 活動内容

平成 12 年 12 月 18 日から平成 13 年 2 月 28 日の間、3回の会合を開催した。

第 1 回：平成 12 年 12 月 18 日（月） 13 時 30 分～17 時

第 2 回：平成 13 年 2 月 7 日（水） 10 時 00 分～17 時

第 3 回：平成 13 年 2 月 28 日（水） 10 時 00 分～17 時

各会合の議事内容は、以下のとおり。

第 1回

出席者：

栃谷、関川、大原、宮澤、江口、酒井、鵜澤、岡本

議事

(1) 平成 12 年度検討事項、スケジュール、作業分担について

鵜澤係長から資料 2に基づき、本ワーキンググループの平成 12 年度におけ

る検討事項、スケジュール、作業分担について説明があり、検討の結果了承

された。

(2) 貸借業務の依頼・受付機能の ISO プロトコル対応について

資料5等に基づき、宮澤主査からISO ILLプロトコル及びRLGのILL Manager

等各機関の実装について説明があった。具体的な検討は、次回に集中して行

うことになった。

(3) OCLC との接続テスト事項について

送信データのエンコードは、正常に行われていることが確認できているこ

と、また受信データについては、NII のネットワークの設定（ファイアウォー

ル）の問題で未確認であるとの報告があった。

第 2回

出席者：


議事

(1) 鵜澤係長から、「貸借業務の依頼･受付機能の ISO プロトコル対応につい

て」の「1. 概要」に基づき、開発の原則的な考えについて説明があった。

この説明に対し、以下の指摘があった。

－ (2)「標準的な仕様に準拠する」とあるが、「準拠」はあいまいな表現

なので、「適合」「整合」に改めるべきである。

13

－ (4)については、将来的な含みを持たせた表現に代えるべきである。

(2) 「2. ISO プロトコルサービス」（別紙 1）、[3. ISO プロトコル APDU」（別

紙 2）、「4. ISO プロトコル状態」（別紙 3）に基づき、実装対象としている

サービス等の説明があり、サービス毎に実装の方向性について検討を行った。

－ "CANCEL"APDU の送信について

－ "CANCEL-REPLY"APDU の受信について

－ "RECALL"APDU の受信について

－ "LOST"APDU の送信・受信について

－ "DAMAGED"APDU の送信・受信について

－ "MESSAGE"APDU の送信・受信について

－ "STATUS-QUERY"APDU の送信機能について

－ "EXPIRY"APDU の送信・受信機能について

(3) 「5. APDU 送信・受信ごとの NACSIS-ILL システムの動作、ISO ILL プロ

トコル・NACSIS-ILL 状態遷移図」（別紙 4）に基づいて、APDU の送受信をキー

としたシステムの動作について説明があった。

システムについて、以下の点の確認・検討を行った。

◎ 貸借依頼業務（NACSIS-ILL が依頼業務を行う）

－ ISO プロトコル対応機能は、NACSIS-ILL システムのコマンドの実行

とは、非同期に動作する（連動していない）。

－依頼先が ISO 対応機関かどうかは、OMLID の値で判断している。ISO

対応機関は、プログラムの外部にテーブルを持つよう仕様に明記し、

ISO 対応機関の変更に対応可能なような仕組みを備えるべき。

－ "ILL-Answer"APDU の受信について

－ "Conditional-Reply"APDU の送信について

－「到着処理中」状態の扱いについて

－ "NOT RCVD/OVERDUE"APDU の受信について

－ "RECALL"APDU の受信について

－ "OVERDUE"APDU 受信について

－ "CHECKED-IN"APDU 受信について

－ "Message"APDU の送信・受信について

－ "Renew"APDU、”Renew-Answer”APDU の送信・受信について

14

－ "LOST"APDU の送信・受信について

－クレーム以外のメッセージの送受信は、本システム外部のメール機

能等を使用する。

◎ 貸借受付業務（NACSIS-ILL が受付業務を行う）

－ "ILL-Answer"APDU の送信について

－ "Conditional-Reply"APDU の受信について

－ "Cancel"APDU の受信について

－ "Renew-Answer"APDU の送信について

－ "Lost"APDU 送信・受信について

－ "Expired"APDU の送信について

－ "Message"APDU の送信・受信について

◎ 今後の作業内容として、以下の点が確認された。

－実装方法について、開発メーカとの検討、及び海外の ISO ILL プロ

トコル対応機関の技術者への確認をする。

－基本仕様から詳細仕様への展開

－状態遷移表作成

－ APDU 詳細表を作成し、問題のあるところを検討する。これをもとに、

Profile を作成する。

－ PICS の作成

－ OCLC と RLG の PICS の比較 → 実装項目の差は、結構大きい。しか

し、システム開発に大きく影響するような問題は出ないような気がす

るので、それほどの時間を費やさなくても良いだろう。

第 3回

出席者：


議事：

資料の状態遷移表に基づいて、以下の点について検討を行った。

◎ 貸借依頼機能

－ "LOST"APDU の扱いについて

－ "CANCEL"APDU の扱いについて

－「CLAIM」コマンドの扱いについて

15

◎ 貸借受付機能

－ "ILL-Answer"APDU 内のメッセージの取扱について

－ "RECALL"APDU を受信した場合の対応について

－ "LOST"APDU の送信機能について

－貸借業務における「到着処理中」状態の扱いについて

－ DDATE の扱いについて

－「RENEW」コマンドの取扱について

－ "MESSAGE"APDU の扱いについて

－電子的配送アドレス（OEDA）フィールドの実際の使われ方の検討

2.4 総括

本年度の本ワーキンググループにおける活動は、3 点の検討事項のうち、「平成 13

年度システム開発事項の検討」の特に、貸借依頼・受付機能の仕様の検討を中心に検

討を進めてきた。

この 3回の会合での検討結果に基づき、NACSIS-ILL システムの ISO ILL プロトコル

用 Profile を作成する。これは、今後の接続テスト実現のための基礎資料となるもの

で、訪米時に OCLC、RLG にて提示する予定である。

16

17

日米ドキュメント・デリバリー・サービス試行実験について日米ドキュメント・デリバリー・サービス試行実験について日米ドキュメント・デリバリー・サービス試行実験について日米ドキュメント・デリバリー・サービス試行実験について

木下木下木下木下伸二伸二伸二伸二

東京大学附属図書館東京大学附属図書館東京大学附属図書館東京大学附属図書館

2001200120012001年年年年 1111月月月月 31313131日日日日１．経緯１．経緯１．経緯１．経緯

1997.5 第 18回 CULCON合同会議で、日本側から「7項目の行動指針」を披瀝。このひとつが、「ドキュメント・デリバリー・サービス原報についての海外からの需要に対して、日米両国の図書館、情報サービス機関のドキュメント・デリバリー・サー

ビス（原報提供サービス）を改善すること。」である。 1998.3 上記の提案の実行について、文部省から国公私立大学図書館協力委員会に検討依頼があり、その後、国公私立大学図書館協力委員会で協議した結果、国立大学図書館

協議会に具体的対応策の骨子検討を委ねることとなった。これを受けて６月に国立大

学図書館協議会に「国際情報アクセス特別委員会」を設置し対応することとなった。 1998.6.10-11 第 2回 CULCON「情報アクセスWG」合同会議

第 18回 CULCON合同会議(1997)で披露された「７項目の行動指針」について、協議したが、特に、「ドキュメント・デリバリー・サービス」の改善については、日

本側から以下の提案をし、了承された。 ① 日本国内からの米国への学術情報に関するニーズ調査を行う。 ② 文献画像伝送システムの実験を行う。 ③ 小規模なラウンドテーブルを開催する。

1999.2.8-10 「日米両国におけるドキュメント・デリバリー・サービスの改善に関するラウンド・テーブル」（国立大学図書館協議会・国公私立大学図書館協力委員会、

North American Coordinating Council on Japanese Library Resources）本ラウンド・テーブルにおいて、「日米両国の ILL（図書館間相互貸借）改善のための試行実験プロジェクト」（以下「日米 DDS 試行実験」という。）について合意し,実施することとなった。

1999.2.18-19 第 19回 CULCON合同会議（沖縄）において、上記「ラウンド・テーブル」における審議内容を報告した。

1999.11 日米ドキュメント・デリバリー・サービス実験を開始。（参加機関：日本側 7機関、米国側 10大学）

18

2000.3.6-７ North American Coordinating Council on Japanese Library Resourcesの会議「Year 2000 Conference」（米国・サンディエゴ）に日本側から土屋千葉大学館長他が出席・協議した結果、次の点に合意した。 ① 実験期間を当初予定の 2000年 3月末を 2000年６月まで延長 ② 実験の総括・評価本実験について、日米双方で評価を行う。 ③ 文献複写について本格運用開始の検討 ④ 現物貸借のテストを実施の検討

2000.6 実験期間を 2000年 12月末まで延長。米国側新参加 7大学（終了 1大学）。 2001.1.31-2.1 DDS試行実験総括会議「日米両国における学術情報アクセスの改善のため

の情報担当者会議 Conference on improvement of academic information access between U.S. and Japan」を東京にて開催。

2001.5 第 20回 CULCON合同会議（於・ロスアンジェルス）において、実験結果を報告する予定。

２．日米２．日米２．日米２．日米 DDSDDSDDSDDS試行実験計画の概要試行実験計画の概要試行実験計画の概要試行実験計画の概要（１）目的

① 日米両国間の情報アクセスの改善を図る。 ② 日米両国間の現状の相互利用の促進し、諸問題の解決を図る。

（２）実施機関 ① 日本：国立大学図書館協議会・国公私立大学図書館協力委員会 ② 米国：North American Coordinating Council on Japanese Library Resources

（３）実験期間 ① 当初予定期間 1999年 7月 1日～2000年 3月 31日（実験は、準備期間のため、1999年 11月から開始となった。）

② 期間延長 2000年 3月のサンディエゴの会議で 2000年 6月 30日まで延長した。

③ 再延長 5月に再延長を米国側に申し入れ2000年12月31日まで再延長した。（7月から米国側参加機関が増加した。）

（４）ドキュメント・デリバリーの対象と伝送方法 ① 対象：文献複写（コピー） ② 伝送方式：インターネットを経由する電子的文献画像伝送システムを使用する。

（５）実験経費双方が負担する。文献の提供は無償とする。

19

（６）参加機関

＊：2000年 7月から参加

＊＊：2000年 6月まで参加

日本側米国側北海道大学千葉大学東京大学東京工業大学京都大学国立情報学研究所慶應義塾大学

University of California – Berkeley *University of California － Santa

Barbara University of Chicago Columbia University *Cornell University Duke University. **Harvard University *University of Iowa *University of Kansas *University of Massachusetts North Carolina State University * Ohio State University University of Oregon University of Pittsburgh University of Texas * University of Toronto University of Washington, Seattle

３．試行実験の状況３．試行実験の状況３．試行実験の状況３．試行実験の状況実験状況（2000年 11月末現在） ① 日本から米国への依頼 586件 ② 米国から日本への依頼 59件

20

日米両国のILL改善のための試行実験プロジェクト

両国による評価と提言

2001年2月1日

「日米両国における学術情報アクセスの改善のための情報担当者会議」が、2001 年１月

31日及び 2月１日の 2日間、東京において開催された。同会議参加者一同は、「日米両国のILL改善のための試行実験プロジェクト」（以下「実験プロジェクト」という。）が成功裡に終了したことを CULCON に報告できることを大変うれしく思う。この実験プロジェクトは、日本の国立大学図書館協議会及び米国の AAU/ARL/NCC の Japan Journal Access Projectが共同して実施したものである。

両国の参加者は、実験プロジェクトの多大な成果を高く評価し、今後、グローバルな相互

貸借・ドキュメントデリバリ（ILL/DD）サービスの完全な実現に向けてあらゆる努力を傾注すべきであると提言する。実験プロジェクトによって、参加者すべてが貴重な経験をつむことができた。特に、日米

両国において、人文科学、社会科学、自然科学及び工学のあらゆる学問分野に広範な文献

需要のあることが確認された。また、電子的伝送技術がドキュメントデリバリの手段とし

て実用可能であることを証明した。さらに、日米両国の ILL 実務担当者の間に将来における協力の礎となる強い信頼感を伴った人間関係が形成された。

さらに以下の課題を確認した。

○ 目録関連の問題・ NACSIS‐CAT及び OCLC、RLIN、その他の目録間のリンクの形成・日本側における目録の遡及入力の促進・日本側における目録のローマ字化

○ ILLの依頼を他の図書館に伝達する方式 ○ 料金決済方式の確立 ○ 著作権問題 ○ 広報・教育・コミュニケーションの問題

・ Ariel伝送モードの適切な使用についての教育・利用者及び ILL担当者に対するサービスの周知

実験プロジェクトが成功裡に終了したことで、今や ILL/DDサービスは、全面的なグローバル化の段階に移行しつつある。この移行期間において、平常の ILL/DD 業務の中で、現

21

行のサービスを中断することなく日米 ILL/DD 業務を行いつつ、グローバル ILL/DD サービスの完全な導入に向けて準備を進めることとする。

国立情報学研究所（NII）及び OCLC、RLINなどの ISO ILLプロトコルによるシステム間リンクの開発が、明確なスケジュールによって進められている。その結果、グローバル

ILL/DDの実現が目に見える形で考えられるようになった。グローバル ILL/DDへ向けたシステム間リンクの構築の円滑な進展を図るため、日本においては NII、米国においてはOCLC、RLINなどと密接に協力することが必須である。NIIが 2001年 10月まで運用開始を予定している OCLC とのシステム間リンクを実現するために、米国側がこれを支援することが喫緊である。

今後、日米双方は、このサービスに関して、研究者、図書館職員及び関係者への広報、教

育、コミュニケーションを続けること、及び参加館の拡大に努力することが重要である。そのために、グローバル ILL/DDの目標の完全な実現に携わる担当を日米双方に設けた。これら両国の担当者は、協力して活動を継続する。

22

23

別紙 1

ISO プロトコルサービス一覧

ISOプロトコルで定義されているサービス一覧を表 1に示す。 NACSIS-ILLシステムの ISOプロトコル対応で実装の対象とするサービスには「○」を、実装の対象外のサービスには「－」を記している。表 1：ISOプロトコルサービス一覧 No.No.No.No. サービス名サービス名サービス名サービス名特性特性特性特性送信送信送信送信((((依頼依頼依頼依頼)))) 受信受信受信受信((((受付受付受付受付))))

1 ILL-REQUEST ILL依頼 ○ ○

2 FORWARD 依頼転送－－

3 FORWARD-NOTIFICATION 転送通知－－

4 SHIPPED 送付 ○ ○

5 ILL-ANSWER ILL回答 ○ ○

6 CONDITIONAL-REPLY 条件付き回答 ○ ○

7 CANCEL 取消し－ ○

8 CANCEL-REPLY 取消し回答 ○ －

9 RECEIVED 受取り ○ ○

10 RECALL 返却請求 ○ ○

11 RETURNED 返送 ○ ○

12 CHECKED-IN 到着 ○ ○

13 OVERDUE 督促 ○ ○

14 RENEW 更新 ○ ○

15 RENEW-ANSWER 更新回答 ○ ○

16 LOST 紛失通知 ○ ○

17 DAMAGED 汚損通知－－

18 MESSAGE メッセージ ○ ○

19 STATUS-QUERY 状態照会 ○ ○

20 STATUS-OR-ERROR-REPORT 状態/失敗報告 ○ ○

21 EXPIRY 終了 ○ ○

凡例

○：実装対象

－：実装対象外

※1 “FORWARD”、”FORWARD-NOTIFICATION”は、IPIG の Profile で転送処理の実装は行なわないよう規定されているため、実装対象外とする。

24

別紙 2 ISO プロトコル APDU 一覧

表 2：ISOプロトコル APDU一覧

No.No.No.No. APDUAPDUAPDUAPDU名名名名備考備考備考備考対応する対応する対応する対応する

サービスサービスサービスサービス

1 ILL-REQUEST 依頼機関が、貸借、所在、資料の複写、図書館からのサー

ビスの見積りを要求するために使用。

ILL-REQUEST

2 FORWARD-

NOTIFICATION

サービス提供館が依頼機関にリクエストの転送と転送先を

通知するために使用。

FORWARD-

NOTIFICATION

3 SHIPPED 受付機関が資料が発送された旨を通知するために使用。 SHIPPED

4 ILL-ANSWER 受付機関が依頼機関に回答を送るために使用。

（可能な回答：CONDITIONAL, RETRY, UNFILLED,

LOCATIONS-PROVIDED, WILL-SUPPLY,

HOLD PLACED, ESTIMATE）

ILL-ANSWER

5 CONDITIONAL-

REPLY

依頼機関がCONDITIONALであるILL-ANSWERに回答する

ために使用。可能な回答はYES（条件を受け入れる）とNO

（条件は受け入れられない）。

CONDITIONAL-

REPLY

6 CANCEL ILL処理のキャンセルを示唆するために依頼機関が使用。 CANCEL

7 CANCEL-REPLY CANCELリクエストに回答するために受付機関が使用。 CANCEL-REPLY

8 RECEIVED 資料を受けとった旨を通知するために依頼機関が使用。 RECEIVED

9 RECALL 資料を直に返却するよう依頼するために受付機関が使用。 RECALL

10 RETURNED 貸借資料を返送したことを通知するために依頼機関が使用 RETURNED

11 CHECKED-IN 貸借資料の返却を確認するために受付機関が使用。 CHECKED-IN

12 OVERDUE 資料が期限切れであることを依頼機関に通知するために受

付機関が使用。

OVERDUE

13 RENEW 貸借資料の更新を依頼するために依頼機関が使用。 RENEW

14 RENEW-ANSWER RENEWリクエストに回答するために受付機関が使用。 RENEW-ANSWER

15 LOST 相手に対して、資料が紛失した旨伝えるために依頼機関、

受付機関どちらも使用。

LOST

16 DAMEGED 相手に対して、資料が汚損した旨伝えるために依頼機関、

受付機関どちらも使用。

DAMAGED

17 MESSAGE ILLの処理状態に影響を及ぼすことなく互いに連絡をとりあう

ために依頼機関、受付機関の双方が使用。

MESSAGE

18 STATUS-QUERY REMOTE SITEのILL処理状態について問合せを行なうため

に依頼機関、受付機関の双方が使用する

STATUS-QUERY

19 STATUS-OR-

ERROR-REPORT

ILL処理の現在の状況、および他の関連する情報やエラー

の状況を伝えるため依頼機関、受付機関の双方が使用。

STATUS-OR-

ERROR-REPORT

20 EXPIRED ILL処理の失効を依頼機関に伝えるために受付機関のシス

テムが使用する。このAPDUの送信は、サービス利用館では

なく、ILLサービス提供館により起動される。

EXPIRY

※1 網掛けは、実装対象外の APDUを示す。

25

別紙 3 ISO プロトコル状態一覧

表 3：ISO プロトコル状態（依頼機関）

状態状態状態状態説明説明説明説明

IDLE ILL 処理は，開始されていない。

PENDING リクエストは作成され，資料が受付機関（RESPONDER）に期待されている，もしく

は，資料が供給されるか保留中であるというメッセージを受けた。もしくはそのリク

エストは，もう一つの組織に転送された。

NOT-SUPPLIED その ILL 処理は，そのリクエストが受付機関（RESPONDER）によって満たされるこ

とができない状態にある。

CONDITIONAL その ILL 処理は，依頼機関（REQUESTER）が指定された条件に合うことに同意す

るならばそのリクエストが満たされることができる状態にある。

CANCEL-PENDING 依頼機関（REQUESTER ）は ILL 処理のキャンセルをしたが，受付機関

（RESPONDER）からは応答はない。

CANCELLED ILL 処理は，受付機関（RESPONDER）によってキャンセルされた。

SHIPPED 資料は，依頼機関（REQUESTER）に送られた。

RECEIVED 資料は，受付機関（RESPONDER）から受け取られた。

○ RENEW/PENDING 資料更新のためのリクエストが作成された。

○ RENEW/OVERDUE 期限が切れている資料のためのリクエストが作成された。

○ OVERDUE 依頼機関（REQUESTER）は，資料が期限が切れていると通知された。

○ NOT RECEIVED/

OVERDUE

まだ受け取られなかった資料のために受付機関（RESPONDER）は，OVERDUE 通

知を送り出した。

RECALL 受付機関（RESPONDER）が資料を督促した。

○ RETURNED 資料は，受付機関（RESPONDER）送り返された。

LOST(*) 資料は，紛失した。

表 4：ISO プロトコル状態（受付機関）

状態状態状態状態説明説明説明説明

IDLE 受付機関（RESPONDER）は，リクエストを受け取っていない。

IN-PROCESS リクエストは，受け取られて，受付機関（RESPONDER）によって処理中である。資

料はまだ送られていない。

FORWARD リクエストは，もう一つの組織に転送された。

NOT-SUPPLIED 受付機関（RESPONDER）は，リクエストに ILL ANSWER で次の回答をした：

RETRY, UNFILLED, LOCATIONS-PROVIDED, ESTIMATE。

もしくはその ILL 処理は，失効した。

CONDITIONAL 依頼機関（REQUESTER）が指定された条件に合うことに同意した時のみ，そのリク

エストは満たされる。

CANCEL-PENDING 依頼機関（REQUESTER）はその ILL 処理のキャンセルをしたが，受付機関

（RESPONDER）からはまだ，応答がされていない

CANCELLED ILL 処理が受付機関（RESPONDER）によってキャンセルされた。

SHIPPED 資料は，依頼機関（REQUESTER）に送付された。

○ RENEW/PENDING 資料更新のためのリクエストが作成された。

○ RENEW/OVERDUE 期限が切れている資料のためのリクエストが作成された。

○ OVERDUE 受付機関（RESPONDER ）は，資料の期限が切れていることを依頼機関

（REQUESTER）に知らせた。

RECALL 資料は，受付機関（RESPONDER）によって督促された。

○ CHECKED-IN 依頼機関（REQUESTER）から返却された資料を受け取った。

LOST(*) 資料は，紛失した。

※1 表 3、表 4において、網掛けは開発対象外の状態を示す。

26

別紙 4

APDU 送信・受信毎の NACSIS-ILL システム ISO ILL プロトコル対応機能の動作

1 貸借依頼業務

前提条件：

− OMLIDに ISO対応機関（例：OCLC，RLGなど）が指定されていること。 − ISO ILLプロトコル対応機能では，次候補館への自動転送は，行わない。 1.1 ILL-Request 送信 [ISO対応外部依頼システム]

「未処理」＋"（なし）"→APDU送信→「処理中」+"PENDING"，及び「回答待」＋"IDLE"→APDU送信→「処理中」+"PENDING" 転送エラー（データチェックエラー）時は、「処理中」+"PENDING"→「新着照会」+"IDLE"に遷移する。利用者は「新着照会」のレコードに対して，「照会」→「回答待」の状態に遷移させる。

1.2 Forward-Notification 受信

実装対象外。 1.3 Shipped 受信 [ISO対応外部依頼システム]

「処理中」+"PENDING"→「発送」+"SHIPPED" 「処理中」+"RECEIVED"→「クレーム回答待」+"RECEIVED" 注）“CANCEL”APDU の送信は，実装しない。 “SHIPPED”APDUの受信は，必須とする。

1.4 ILL-Answer(CONDITIONAL) 受信 [ISO対応外部依頼システム]

「処理中」+"PENDING"→「新着照会」+"CONDITIONAL"にする。上記以外の ISO状態での受信は受信エラーとして，Status-Or-Error-Reportを送信する。 ○ コメント情報のセット方法，日本語化について，要検討。

1.5 ILL-Answer (UNFILLED) 受信 [ISO対応外部依頼システム]

「処理中」+"PENDING"→「新着照会」+"NOT-SUPPLIED"にする。上記以外の ISO状態での受信は受信エラーとして，Status-Or-Error-Reportを送信する。 ○ コメントに理由・メッセージ内容等をセットする。

1.6 ILL-Aanswer (ESTIMATE) 受信

ILL-ANSWER(UNFILLED)と同じ

27

1.7 ILL-Aanswer (RETRY) 受信

ILL-ANSWER(UNFILLED)と同じ 1.8 ILL-Answer (LOCATIONS-PROVIDED) 受信

ILL-ANSWER(UNFILLED)と同じ 1.9 ILL-Answer (WILL-SUPPLY) 受信 [ISO対応外部依頼システム]

「処理中」 +"PENDING" 以外の ISO 状態での受信は受信エラーとして，

Status-Or-Error-Reportを送信する。状態遷移無し。 ○ コメントに理由・メッセージ内容等をセットする。

1.10 ILL-Answer (HOLD PLACED) 受信

ILL-ANSWER(WILL-SUPPLY)と同じ 1.11 Conditional-Reply (YES) 送信 [ISO対応外部依頼システム]

「回答待」+"CONDITIONAL"→APDU送信→「処理中」+"PENDING" メッセージの転送は，想定していないため，転送エラー対象外。 SENDCMNT（コメント欄）にデータが入っていた場合，データを転送する。コメントに記録する情報は，例文集・コード等を用意する。

1.12 Conditional-Reply (NO) 送信 [ISO対応外部依頼システム]

「CANCEL」+"CONDITIONAL"→APDU送信→「CANCEL」+"（なし）" メッセージの転送は，想定していないため，転送エラー対象外。 SENDCMNT（コメント欄）にデータが入っていた場合は，データを転送しない。

1.13 Cancel 送信

実装対象外。 1.14 Cancel-Reply (YES) 受信 [ISO対応外部依頼システム]

あらゆる状態での受信は，受信エラーとして，Status-Or-Error-Reportを送信する。 1.15 Cancel-Reply (NO) 受信

Cancel-Reply (YES)と同じ 1.16 Received 送信 [ISO対応外部依頼システム]

28

「借用中」＋"SHIPPED"→APDU送信→「借用中」＋"RECEIVED" 「更新請求」＋"SHIPPED"→APDU送信→「更新請求」＋"RECEIVED" 「到着処理中」＋" NOT RCVD/OVERDUE "→APDU送信→「到着処理中」＋"OVERDUE" 「返送」＋"SHIPPED"→APDU送信→「返送」＋"RETURNED" （”Returned”APDUも同時に送信？）転送エラー対象外。 SENDCMNT（コメント欄）にデータが入っていた場合は，データを転送しない。 "SHIPPED"APDU未着で、現物が到着した場合は、以下の方法で対応。 ISO 対応機能としては、エラー扱いとし、依頼館からの連絡により、管理者が受付機関に成り代わって、"SHIPPED"APDUを送信する。

1.17 Recall 受信

要検討。――「発送」以降を対象。DDATEを更新。 1.18 Returned 送信 [ISO対応外部依頼システム]

「返送」＋”RECEIVED”→ APDU送信→「返却処理中」＋"RETURNED" 「返送」＋” OVERDUE”→ APDU送信→「返却処理中」＋"RETURNED" 転送エラー対象外。 SENDCMNT（コメント欄）にデータが入っていた場合は，データを転送しない。

1.19 CHECKED-IN 受信 [ISO対応外部依頼システム]

「返却処理中」＋"RETURNED"→「返却確認」＋"RETURNED" 「“CHECKED-IN”APDU は，追跡段階（貸借で依頼機関が現物を受領してから，返却するまでの段階）で ILLトランザクションに関する問題が起ったときにトランザクションを強制的に最終状態にするためにも使用される。このサービスで ILLトランザクションを強制的に最終状態にさせる場合は，貸出資料を考慮したほうが良いが，必ずしも受付機関側へ戻って

いる必要は無い。このサービスによって，ILL トランザクションは受付機関にとって最終状態になる。」（JIS X0808より）。

1.20 Overdue 受信 [ISO対応外部依頼システム]

「処理中」＋“PENDING”→「処理中」＋“NOT RCVD/OVERDUE” 「発送」＋“SHIPPED”→「発送」＋“NOT RCVD/OVERDUE” 「借用中」＋“RECEIVED”→ 「借用中」＋“OVERDUE” 「借用中」＋“RENEW/OVERDUE” → 「借用中」＋“OVERDUE” "Overdue"は、"PENDING"から可能となっている。 ILL 参加館から"到着処理中"つまり"Received"の送信前に受信する場合があり、その場合は"NOT RCVD/OVERDUE"となる。この"NOT RCVD/OVERDUE"の状態から行なえる事は"SHIPPED"と同様であるが、"NOT RCVD/OVERDUE"から"Received"を送信すると、ISO状態"RECEIVED"でなく"OVERDUE"となる。

29

NACSIS-ILL状態の変化はない。 DDATEの値の更新。

1.21 Renew 送信

「更新請求」＋"RECEIVED"→APDU送信→「返却処理中」＋"RENEW/PENDING" 「更新請求」＋"OVERDUE"→APDU送信→「返却処理中」＋"RENEW/OVERDUE" 転送エラー対象とする

1.22 Renew-Answer (YES) 受信

「返却処理中」＋"RENEW/PENDING"→ 「返却クレーム未処理」＋"RECEIVED"＋コメントに"RENEW-ANSWER-YES"をセット「返却処理中」＋"RENEW/OVERDUE"→「返却クレーム未処理」＋"RECEIVED" ＋コメントに"RENEW-ANSWER-YES"をセット，DDATEを更新

1.23 Renew-Answer (NO) 受信

「返却処理中」＋"RENEW/PENDING"→ 「返却クレーム未処理」＋"RECEIVED"＋コメントに"RENEW-ANSWER-NO"をセット「返却処理中」＋"RENEW/OVERDUE"→「返却クレーム未処理」＋"OVERDUE" ＋コメントに"RENEW-ANSWER-NO"をセット，DDATEは更新無し

1.24 Lost 送信

システム外部に送信機能を実装。 1.25 Lost 受信

“SHIPPED”→“LOST” “NOT RCVD/OVERDUE”→“LOST” “RECEIVED”→“LOST” “OVERDUE”→“LOST” “RENEW/OVERDUE”→“LOST” “RENEW/PENDING”→“LOST” “RETURNED”→“LOST” “RECALL”→“LOST” “PENDING”→“LOST”

1.26 Damaged 送信

実装対象外。 1.27 Damaged 受信

実装対象外。 1.28 Expired 受信

実装対象外。

30

2 貸借受付業務

前提条件：

− AMLIDに ISO対応機関（例：OCLC，RLGなど）が指定されていること。 − ISO ILLプロトコル対応機能では，次候補館への自動転送は，行わない。

2.1 ILL-Request 受信「未処理」＋”IN-PROCESS”の新規レコードを生成する。但し，transaction-id.transactin-group-qualifier、transaction-id.transactin-qualifier が同一の ILLレコードが既に作成されている場合，更新はしない。エラーにしない

2.2 Forward 送信

実装対象外 2.3 Shipped 送信 [ISO対応外部依頼システム]

「発送」+"IN-PROCESS"→APDU送信→「発送」+"SHIPPED" 転送エラー（データチェック）対象外。

2.4 ILL-Answer (CONDITIONAL) 送信 [ISO対応外部依頼システム]

「新着照会」+"IN-PROCESS"→APDU送信→「新着照会」+"CONDITIONAL" 転送エラー時：「新着照会」+"IN-PROCESS"→「回答待」＋”IN-PROCESS” コメントは，”responder-note”に記録

2.5 ILL-Answer (UNFILLED) 送信 [ISO対応外部依頼システム]

「新着照会」+"IN-PROCESS"→APDU送信→「CANCEL」+"NOT-SUPPLIED" コメント("PARDON"or"UNFILLED")をシステムセット。転送エラー対象外。

2.6 ILL-Answer (ESTIMATE) 送信

実装対象外。 2.7 ILL-Answer (RETRY) 送信

実装対象外。 2.8 ILL-Answer (LOCATIONS-PROVIDED) 送信

実装対象外。 2.9 ILL-Answer (WILL-SUPPLY) 送信

31

実装対象外。 2.10 ILL-Answer (HOLD PLACED) 送信

実装対象外。 2.11 Conditional-Reply (YES) 受信 [ISO対応外部依頼システム]

「照会」+"CONDITIONAL"→「回答待」+"IN-PROCESS"。 (CONDITIONAL-REPLY(YES)を履歴で残す) 「CANCEL」+"NOT-SUPPLIED"のレコードに対して、APDU を受信しても何もしない。また，該当レコードへの更新はしない。

2.12 Conditional-Reply (NO) 受信 [ISO対応外部依頼システム]

「照会」+"CONDITIONAL"→「CANCEL」+"NOT-SUPPLIED" 「CANCEL」+"NOT-SUPPLIED"のレコードに対して、APDU を受信しても何もしない。また，該当レコードへの更新はしない。

2.13 Cancel 受信 [ISO対応外部依頼システム]

「未処理」+" IN-PROCESS "→「CANCEL」+"CANCEL PENDING" 上記以外の状態での"Cancel"APDU受信は、”Cancel-Reply (NO) “APDU送信転送エラー対象外。 2.13，2．14，2.14’については，APDU 返送のタイミング（バッチ処理か、その場ですぐに

返送するのか）を検討する必要あり。 2.14 Cancel-Reply (YES) 送信 [ISO対応外部依頼システム]

「CANCEL」+"CANCEL PENDING"→APDU送信→「CANCEL」+"CANCELLED" 転送エラー対象外。

2.14’ Cancel-Reply (NO) 送信 [ISO対応外部依頼システム]

「未処理」+" IN-PROCESS "以外の状態で，”Cancel”APDUを受信した場合，ISOSTATは，変更せずに APDU送信のみを行う。転送エラー対象外。

2.15 Received 受信 [ISO対応外部依頼システム]

「発送」+"SHIPPED"→「到着処理中」+"SHIPPED" 「発送」+"OVERDUE"→「到着処理中」+"OVERDUE" 上記以外の状態での受信は、エラーとして、"STATUS-OR-ERROR-REPORT"APDUを送信

32

する。

？NACSIS-ILLの状態遷移は，「到着処理中」で適当か？（”DAMAGED”APDU ＝ CLAIMコマンドの受信に備えて，「クレーム未処理」などへ状態遷移可能な「到着処理中」に遷移する仕様にしている。しかし，”DAMAGED”APDUをサポートしないのなら，”RECEIVED”APDU受信時に「借用中」に状態遷移する方が適切か？ただし，複写では，「到着処理中」に状態遷移をする実装となっている。）

2.16 Recall 送信

実装しない 2.17 Returned 受信 [ISO対応外部依頼システム]

「発送」＋”SHIPPED”→「返送」＋”SHIPPED” 「到着処理中」＋”SHIPPED”→「返送」＋”SHIPPED” 「借用中」＋”SHIPPED”→「返送」＋”SHIPPED”

2.18 CHECKED-IN 送信 [ISO対応外部依頼システム]

「返却確認」＋”SHIPPED” →APDU送信→「返却確認」+"CHECKED-IN" 「返却確認」＋” RENEW/PENDING” →APDU送信→「返却確認」+"CHECKED-IN" 「返却確認」＋” RENEW/OVERDUE” →APDU送信→「返却確認」+"CHECKED-IN" 「返却確認」＋” OVERDUE” →APDU送信→「返却確認」+"CHECKED-IN"

ISO状態"CHECKED-IN"以降の APDUは認めないようにする。受信した場合は、エラーとし，Status-Or-Error-Reportを送信する。 "RECEIVED"APDU, "RETURNED"APDUが到着しない状態で、資料が返却され、「返却確認」にしたい場合は、利用者からの連絡により，管理者が強制的に ISO状態、NACSIS-ILL状態を変更する。

2.19 Overdue 送信 [ISO対応外部依頼システム]

DDATEを判断基準として、システムが"OVERDUE"APDUを送信する。「発送」＋”SHIPPED” →APDU送信→「発送」＋"OVERDUE" 「発送」＋” RENEW/OVERDUE” →APDU送信→「発送」＋"OVERDUE" 「到着処理中」＋”SHIPPED” →APDU送信→「到着処理中」＋"OVERDUE" 「到着処理中」＋” RENEW/OVERDUE” →APDU送信→「到着処理中」＋"OVERDUE" 「借用中」＋”SHIPPED” →APDU送信→「借用中」＋"OVERDUE" 「借用中」」＋” RENEW/OVERDUE” →APDU送信→「借用中」＋"OVERDUE" 「更新請求」＋”SHIPPED” →APDU送信→「更新請求」＋"OVERDUE" 「更新請求」＋” RENEW/OVERDUE” →APDU送信→「更新請求」＋"OVERDUE" 「返却クレーム未処理」」＋”SHIPPED” →APDU送信

33

→「返却クレーム未処理」＋"OVERDUE" 「返却クレーム未処理」」＋” RENEW/OVERDUE” →APDU送信

→「返却クレーム未処理」＋"OVERDUE" 2.20 Renew 受信 [ISO対応外部依頼システム]

「発送」＋”SHIPPED”→ 「更新請求」+" RENEW/PENDING" 「到着処理中」＋”SHIPPED””→ 「更新請求」+" RENEW/PENDING" 「借用中」＋”SHIPPED””→ 「更新請求」+" RENEW/PENDING" 「発送」＋”OVERDUE” → 「更新請求」+" RENEW/OVERDUE" 「到着処理中」＋”OVERDUE” → 「更新請求」+" RENEW/OVERDUE" 「借用中」＋”OVERDUE” → 「更新請求」+" RENEW/OVERDUE"

上記以外の状態で受信した場合は，受信エラーとし，Status-Or-Error-Reportを送信する。 2.21 Renew-Answer (YES) 送信 [ISO対応外部依頼システム]

「返却クレーム未処理」+"RENEW/PENDING"→APDU送信→「借用中」＋"SHIPPED" 「返却クレーム未処理」+"RENEW/OVERDUE"→APDU送信→「借用中」＋"SHIPPED"

APDU送信と同時に，DDATEの修正を行う。 2.22 Renew-Answer (NO) 送信 [ISO対応外部依頼システム]

「返却クレーム未処理」+"RENEW/PENDING"→APDU送信→「借用中」＋"SHIPPED" 「返却クレーム未処理」+"RENEW/OVERDUE"→APDU送信→「借用中」＋"SHIPPED"

DDATEは，変更無し。 2.23 Lost 送信

「発送」＋”SHIPPED”→「CALLBACK」コマンド→「処理中」＋”SHIPPED”→「PARDON」コマンド→「新着照会」＋”SHIPPED”

[ISO対応外部依頼システム] 「新着照会」＋”SHIPPED”→APDU送信→「照会」＋”NOT-SUPPLIED”

定期的に、最終状態（確認・返却確認）へ状態遷移 2.24 Lost 受信 [ISO対応外部依頼システム]

あらゆる状態で→APDU受信→「更新請求」＋”LOST” “Lost”APDU受信後，利用者は，レコードを「DISPLAY/RECEIVE」して，「OK」コマンドで，「返却確認」に遷移させる。 2.25 Damaged 送信

実装対象外。

34

2.26 Damaged 受信実装対象外。

2.27 Expired 送信

ISO ILLプロトコル接続機能の外部にて実装する。「設定日付」「状態」「ISO対応機関」を条件として，該当する ILLレコードのリストをファイルに出力（編集可能な形式）して、このファイルを入力ファイルとして"Expired"APDUを送信する。

2.27 Expired 受信実装対象外。

2.28 Message 送信 "Message"APDUの送信は、CLAIMコマンドを使って実装する。「返却クレーム未処理」に遷移したら、「CALLBACK」コマンドで元の状態に戻す。

2.29 Message受信

"Message"APDUの受信は、実装する。メッセージが到着したら ILLレコードのコメントに追加する。状態は、ISO、NACSIS-ILLともに変更しない。

35

NACSIS-ILL

Profile for the ISO ILL Protocol

Version 0.1

12 March 2001

36

Annex A. IPIG Profile Conformance Statement

Requirements List

(Normative)

This Annex forms an integral part of the IPIG Profile for the ISO Protocol. It provides a series of tables indicating the requirements, parameter by parameter, for compliance with the IPIG Profile for the ISO ILL Protocol. Implementors wishing to assert conformance to this Profile SHALLSHALLSHALLSHALL:

- Complete a copy of this Annex, the IPIG Profile Conformance Statement Requirements List, indicating the capabilities supported by their implementations, as a statement of static conformance to this Profile;

- Make a completed Requirements List network-accessible via a URL;

- Inform the ILL ASMA of the URL for listing in the central registry of completed Conformance Statement Requirements Lists.

The ILL ASMA maintains a central registry of completed Conformance Statement Requirements Lists.

A.1. Notations Used in the IPIG Profile Conformance Statement Requirements List

A.1.1. Notation for Column Headings

IPIGIPIGIPIGIPIG Defined in the IPIG Profile. This column indicates the level of support required for conformance to this Profile.

ImplImplImplImpl Implementation Indicator. This column is to be completed by the implementor to indicate the level at which the implementation supports each service or parameter.

37

A.1.2. Notation used in the IPIG Column

MMMM Mandatory: Mandatory support of an ILL service implies that the implementation SHALLSHALLSHALLSHALL be capable of invoking the specified service, including the initiation and receipt of the APDU(s) associated with the service, as appropriate to the user role (Requester, Responder, or Intermediary).

Mandatory support of a parameter implies that an implementation SHALLSHALLSHALLSHALL be capable of transmitting data values for that parameter in APDUs according to the protocol specifications in ISO 10161-1:1997. If data are available, having been explicitly supplied or able to be generated by a user application, that data SHALLSHALLSHALLSHALL be carried in the APDU.

Mandatory support of a data type within a parameter implies that an implementation SHALLSHALLSHALLSHALL be capable of transmitting values for that specific data type if the parent parameter is transmitted. For example, if the optional maximummaximummaximummaximum----costcostcostcost parameter is supported, it is mandatory that values for currencycurrencycurrencycurrency----code code code code and monetary monetary monetary monetary----valuvaluvaluvalueeee data types are included.

OOOO Optional: Optional support of an ILL service or parameter implies that it is permitted but not mandatory for the IPIG Profile. However, if this feature is implemented, it SHALLSHALLSHALLSHALL conform to the specifications and restrictions contained in the IPIG Profile.

CCCC Conditional: Support of this ILL service or parameter depends on certain conditions identified for the feature in the Reference, Usage or Range of ValuesReference, Usage or Range of ValuesReference, Usage or Range of ValuesReference, Usage or Range of Values column, or elsewhere in this IPIG Profile.

XXXX Out-of-scope: Support of this ILL service or parameter is not addressed in the IPIG Profile.

-- Not applicable.

38

A.1.3. Notation used in the Impl Column

This notation is to be supplied by the implementor when stating the conformance of an ILL implementation to the IPIG Profile.

YYYY Yes, this ILL service or parameter has been implemented.

NNNN No, this ILL service or parameter has not been implemented.

Non-support of a service implies that an implementation does not have the capability to transmit the APDUs associated with the service, and has no support for the service beyond the capability to receive the associated APDUs without failure.

A.1.4. Numbering

In the tables of Annex A, each row that requires implementation details to be supplied is numbered at the left-hand edge of the row. This numbering is included as a means of uniquely identifying all possible implementation details within the Requirements List.

A.1.5. Completion by the Implementor

The implementor, when stating conformance with the IPIG Profile for the ISO ILL Protocol, SHALLSHALLSHALLSHALL complete all "[ ]"marked entries in the ImplImplImplImpl column of the IPIG Profile Conformance Statement Requirements List and all other appropriate sections in the IPIG Profile. Implementors may remove the contents of the "References, Usage or Range of Values" column and add details specific to their implementation. However, they should not make any other changes to this established proforma when preparing a Conformance Statement. Where the response exceeds the space available, references may be made to additional annexes where complete descriptions are provided.

39

A.2. Implementation Details

A.2.1. Date of Statement

Date of Statement (YYYY-MM-DD) 2001-03-12

A.2.2. Identification of the Implementation

1 Implementation Supplier (i.e., Company name)

NII National Institute of Informatics, Japan

2 Implementation Name NACSIS-ILL

3 Implementation Version Number 1

4 Implementation Contact Information

Contents Division

Contents Assessment Section

2-1-2 Hitotsubashi Chiyoda-ku Tokyo Japan

101-8430

A.2.3. Statement of Conformance

Ref. Impl Comments

1 All mandatory features of version 1.0 of the IPIG Profile for the ISO ILL Protocol have been implemented.

[ N ]

1.1 All static constraints identified in Clause 6 of version 1.0 of the IPIG Profile for the ISO ILL Protocol have been implemented.

[ N ]

1.2 The implementation exhibits behaviour consistent with dynamic constraints as specified in Clause 7 of version 1.0 of the IPIG Profile for the ISO ILL Protocol.

[ N ]

A.3. General Details

A.3.1. ISO 10161 Details

1 Protocol Version Number 2

2 Other Version Number(s) supported

3 Defect Report Number(s) implemented

4 Amendment(s) implemented 1

A.3.2. Roles Supported

See Clause 6.1 for details on the dynamic constraints imposed by the IPIG Profile concerning support of the ILL-Service-User roles.

Ref. IPIG Impl

1 Requester O [ Y ]

40

2 Responder O [ Y ]

3 Intermediary O [ N ]

A.3.3. Transaction Types Supported

See Clause 6.2 for details on the static constraints imposed by the IPIG Profile concerning support of Transaction Types.

Requester Responder Intermediary Ref. Transaction Type

IPIG Impl IPIG Impl IPIG Impl

1 Simple M [ Y ] M [ Y ] -- [ ]

2 Chained O [ N ] O [ N ] C [ N ]

3 Partitioned O [ N ] O [ N ] C [ N ]

A.3.4. ILL Service Types Supported

See 7.4 for details on the dynamic constraints imposed by the IPIG Profile concerning support for ILLILLILLILL----REQUEST.iLLREQUEST.iLLREQUEST.iLLREQUEST.iLL----serviceserviceserviceservice----typetypetypetype.

Requester Responder Intermediary Ref. Service Type


1 Loan O [ N ] O [ N ] O [ N ]

2 Copy/Non-returnable O [ Y ] O [ Y ] O [ N ]

3 Locations O [ N ] O [ N ] O [ N ]

4 Estimate O [ N ] O [ N ] O [ N ]

5 Responder-specific O [ N ] O [ N ] O [ N ]

A.3.5. Maximum Field Lengths: System-Id and Transaction-Id

See 6.5 for details on the static constraints imposed by the IPIG Profile on the maximum lengths of specific data parameters.

Ref No. Parameter IPIG Impl 1 System-Id Total of 175 characters

1.2 - person-or-institution-symbol 25 characters

1.3 - name-of-person-or-institution 150 characters

2 Transaction-Id Total of 250 characters

2.1 - initial-requester-id 175 characters

2.1.1 - - person-or-institution-symbol 25 characters

2.1.2 - - name-of-person-or-institution 150 characters

2.2 - transaction-group-qualifier 25 characters

2.3 - transaction-qualifier 25 characters

2.4 - sub-transaction-qualifier 25 characters

41

A.3.6. Transfer Syntax

See 6.10.1 Transfer Syntax for a more detailed discussion of the Transfer Syntax requirements for implementations conforming to the IPIG Profile.

Ref. IPIG Impl

1 ASN.1BER M [ Y ]

2 EDIFACT X --

A.3.7. Transport Services

See 6.10.2 Communication Services, 6.10.3 Using Internet Mail, and 6.10.4 Using Direct Transfer over TCP for more detailed discussions of the Transport Services requirements for implementations conforming to the IPIG Profile.

Ref. IPIG Impl

1 Internet mail M [ N ]

1.1 - MIME encoding M [ N ]

2 Direct Transfer over TCP O [ Y ]

2.1 - Listen on port 1611 M [ Y ]

2.2 - Connect to port 1611 M [ Y ]

2.3 - Listen on port 499 O [ N ]

2.4 - Connect to port 499 O [ N ]

A.3.8. Character Sets Support

See 6.11 Character Sets for a more detailed discussion of the requirements for the handling of character sets by implementations conforming to the IPIG Profile.

Ref. IPIG Impl

1 Supports ISO Latin-1 M [ Y ]

2 Recognizes escape sequences for other sets

M [ Y ]

3 Supports Unicode UTF-8 O [ Y ]

4 Supports additional character sets, as specified

O [ N ]

4.1 - character set 1 O [ ]

4.2 - character set 2 O [ ]

4.3 - etc. O [ ]

42

Note to implementors: Add additional rows in 4 as required to specify the character set escape sequences supported.

A.4. Syntaxes This section identifies requirements for support of the various possible syntaxes associated with the ILL Protocol. Support of a particular syntax implies that an implementation can generate and receive information defined by that syntax.

Indicate in the table below the implementation's degree of support for each abstract syntax listed.

The tables of A.7 indicate the degree of support of specific data parameters defined for use in the external objects associated with each abstract syntax listed below.

The tables of A.6 specify which external objects are defined for use in specific parameters within each APDU.

Ref. Object Class Abstract Syntax Name OID IPIG Impl 1 system-no (6) IPIG-System-Number 1 0 10161 6 1 O [ Y ]

2 supplemental-item-description (7)

SICI 1 0 10161 7 1 O [ N ]


Item-Language-Translation

1 0 10161 7 2 O [ N ]


[all MARC record syntaxes registered by Z39.50 MA]

1 2 840 10003 5 + O [ N ]

5 e-delivery-mode (9) Internet Delivery Service

1 0 10161 9 1 O [ N ]

6 e-delivery-mode (9) - SMTP 1 0 10161 9 1 1 O [ N ]

6.1 e-delivery-mode (9) - FTP 1 0 10161 9 1 2 O [ N]

6.2 e-delivery-mode (9) Fax Delivery Service 1 0 10161 9 2 O [ Y ]

7 e-delivery-parameters JEDDS ILL Electronic Delivery Parameters

1 0 10161 10 1000 7 1 O [ N ]

8 extension (13) OCLC ILL Request Extension

1 0 10161 13 2 O [ N ]

9 extension (13) APDU-Delivery-Info 1 0 10161 13 3 M [ Y ]

10 extension (13) ILL-Supplemental-Client-Info

1 0 10161 13 4 O [ N ]

11 extension (13) IPIG-Additional-User-Error Information

1 0 10161 13 6 M [ N]

43

12 extension (13) Internal-Reference-Number

1 0 10161 13 7 O [ N ]

13 Access Control Format (Z39.50)

Prompt-1 1 2 840 10003 8 1 M [ Y ]

Note to implementors: Note to implementors: Note to implementors: Note to implementors: The abstract syntax specification (ASN.1) for each external object listed in the above table is available in the online Register of the Maintenance Agency responsible for it.

OIDs beginning with the number sequence "1 0 10161" describe objects registered by the Interlibrary Loan Application Standards Maintenance Agency. Copies of the specifications are accessible through the Register for the ILL Application Standards (ISO 10160 and ISO 10161-1).

If an OID contains "1000" within the number sequence (such as {1 0 10161 10 1000 7 1} JEDDS ILL Electronic Delivery JEDDS ILL Electronic Delivery JEDDS ILL Electronic Delivery JEDDS ILL Electronic Delivery ParametersParametersParametersParameters), it is a "local" object, listed in the Register of Local Object Identifiers <URL: http://www.nlc-bnc.ca/iso/ill/regiloid.htm >.

All other OID beginning with "1 0 10161" represent "public" objects, listed in the Register of Public Object Identifiers <URL: http://www.nlc-bnc.ca/iso/ill/regipoid.htm >.

OIDs beginning with the number sequence "1 2 840" describe objects registered by the Z39.50 Maintenance Agency. Copies of the specifications are accessible through the Registry of Z39.50 Object Identifiers <URL: http://lcweb.loc.gov/z3950/agency/defns/oids.html >.

A.5. Interlibrary Loan Application Services This section describes ILL services rather than APDUs. Invocation of an ILL application service requires the transmission of the APDUs associated with the service.

Indicate in the table below the implementation's degree of support for each ILL Service listed.

44

Use the tables of A.6 to indicate the degree of support of specific data parameters defined for use in the APDUs associated with each service.

A.5.1. Support of Services

Requester Responder Intermediary Ref.


References, Usage or Range of Values

1 ILL-REQUEST M [ Y ] M [ Y ] M [ N ]

2 FORWARD -- -- X [ N ] X [ N ] Service out-of-scope for the IPIG Profile.

3 FORWARD-NOTIFICATION

X [ N ] X [ N ] X [ N ] Service out-of-scope for the IPIG Profile.

4 SHIPPED M [ Y ] M [ Y ] M [ N ]

5 ILL-ANSWER M [ Y ] M [ Y ] M [ N ]

6 CONDITIONAL-REPLY

M [ Y ] C [ Y ] M [ N ] Responder implementations supporting transaction-results with the value "conditional" SHALL also support the CONDITIONAL-REPLY service; otherwise it is not applicable.

7 CANCEL O [ N ] M [ Y ] M [ N ]

8 CANCEL-REPLY

C [ Y ] M [ Y ] M [ N ] Requester implementations supporting the CANCEL service SHALL also support the CANCEL-REPLY service; otherwise it is not applicable.

9 RECEIVED M [ Y ] M [ Y ] M [ N ]

10 RECALL C [ N ] C [ N ] C [ N ] Implementations supporting the "loan" service type SHALL also support the RECALL service; otherwise it is not applicable.

11 RETURNED C [ N ] C [ N ] C [ N ] Implementations supporting the "loan" service type SHALL also support the RETURNED service; otherwise it is not applicable.

12 CHECKED-IN C [ N ] C [ N ] C [ N ] Implementations supporting the "loan" service type SHALL also support the CHECKED-IN service; otherwise it is not applicable.

13 OVERDUE C [ N ] C [ N ] C [ N ] Implementations supporting the "loan" service type SHALL also support the OVERDUE service; otherwise it is not applicable.

14 RENEW O [ N ] C [ N ] C [ N ] This service is applicable only for implementations that also support the "loan" service type.

Implementations functioning as Responder or Intermediary SHALL support the RENEW service.

45

Requester Responder Intermediary Ref.


References, Usage or Range of Values

However, if functioning only as a Requester, it is optional to support the RENEW service.

15 RENEW-ANSWER

C [ N ] C [ N ] C [ N ] This service is applicable only for implementations that support the "loan" service type.

Implementations, functioning as Responder and Intermediary, SHALL support the RENEW-ANSWER service.

Requester implementations that support the RENEW service SHALL also support the RENEW-ANSWER service.

16 LOST M [ N ] M [ N ] M [ N ]

17 DAMAGED O [ N ] O [ N ] M [ N ]

18 MESSAGE O [ N ] O [ N ] M [ N ]

19 STATUS-QUERY O [ Y ] O [ Y ] M [ N ]

20 STATUS-OR-ERROR-REPORT

M [ Y ] M [ Y ] M [ N ]

21 EXPIRY M [ N ] M [ N ] M [ N ] Requester and Intermediary implementations SHALL have the capability to accept an EXPIRY APDU.

Responder and Intermediary implementations SHALL maintain an expiry-timer.

A.6. Support of APDU Parameters In ISO 10161-1:1997, an implementation capable of receiving an APDU SHALLSHALLSHALLSHALL be capable of accepting data for all parameters defined for the APDU. This section is used to identify the capability of an IPIG implementation conforming to the IPIG Profile to transmit specific data parameters within each APDU.

Indicate in the tables below the degree of support of the data parameters defined in clause 9 of ISO 10161-1:1997. If the implementation supports different values (or has different constraints) for different roles, this SHALLSHALLSHALLSHALL be indicated.

Use the table in A.5 to indicate the degree of support for associated ILL Services.

46

NOTE:NOTE:NOTE:NOTE: In the tables following in A.6., ., ., ., the first occurrence of a data parameter is expanded to include its component data types. In all subsequent instances where identical expansions of data types occur, table and row number references point back to these expansions.

A.6.1. ILL-Request APDU

Ref. no.

Parameter IPIG Impl References, Usage or Range of Values

1 protocol-version-num M [ Y ] Implementations conforming to IPIG Profile SHALL support the value "2".

See 6.6 for a discussion of the requirements for this data parameter.

2 transaction-id M [ Y ]

2.1 - initial-requester-id M [ Y ] See 6.4.2 for a discussion on the maximum length set for this data parameter.

2.1.1 - - person-or-institution-symbol

O [ Y ] Maximum length: 25 characters.

See 6.5.2 and 6.5.3 for a discussion on the maximum length set for this data parameter.

Format: <identifier of name authority>:<symbol>

Examples: NLC-BNC:UK0013 OCLC:BRI RLG:UKBW

For details on formatting this parameter, see 7.1.

2.1.1.1 - - - person-symbol O [ N ]

2.1.1.2 - - - institution-symbol O [ N ]

2.1.2 - - name-of-person-or-institution

O [ Y ] Maximum length: 150 characters.

See 6.5.2 and 6.5.3 for a discussion on the maximum length set for this data parameter.

2.1.2.1 - - - name-of-person O [ N ]

2.1.2.2 - - - name-of-institution O [ N ]

2.2 - transaction-group-qualifier M [ Y ] Maximum length: 25 characters.

See 6.5.3 for a discussion on the maximum length set for this data parameter.

2.3 - transaction-qualifier M [ Y ] Maximum length: 25 characters.


2.4 - sub-transaction-qualifier C [ N ] Maximum length: 25 characters.


Intermediaries SHALL have the ability to provide values for the sub-transaction-qualifier.

3 service-date-time M [ Y ]

47

Ref. no.


3.1 - date-time-of-this-service M [ Y ]

3.1.1 - - date M [ Y ]

3.1.2 - - time M [ Y ] Implementations conforming to the IPIG Profile SHALL express time values as UTC, rather than as local time.

For details on formatting this parameter, see 6.7.1.

3.2 - date-time-of original-service

O [ N ]

3.2.1 - - date M [ N ]

3.2.2 - - time M [ N ] See A.6.1, Ref. 3.1.2.

4 requester-id M [ Y ] See 6.4.1 for a discussion of the requirements for requester-id and responder-id.

At least one element SHALL be present.

4.1 - person-or-institution-symbol O [ Y ] See A.6.1, Ref. 2.1.1.


4.2 - name-of-person-or-institution

O [ N ] See A.6.1, Ref. 2.1.2.

5 responder-id M [ Y ] See 6.4.1 for a discussion of the requirements for requester-id and responder-id.

At least one element SHALL be present. 5.1 - person-or-institution-symbol O [ Y ] See A.6.1, Ref. 2.1.1.



O [ N ] See A.6.1, Ref. 2.1.2.

6 transaction-type C [ Y ] ISO 10161-1:1997 specifies the default value for the transaction-type parameter as (1) "simple". Implementations that support chaining or partitioning SHALL support values (2) "chained" and (3) "partitioned" for this parameter.

DEFAULT: simple (1) 7 delivery-address O [ Y ]

7.1 - postal-address O [ Y ]


O [ Y ] See A.6.1, Ref. 2.1.2.

7.1.2 - - extended-postal-delivery-address

O [ N ]

7.1.3 - - street-and-number O [ Y ]

7.1.4 - - post-office-box O [ N ]

7.1.5 - - city O [ N ]

7.1.6 - - region O [ N ]

7.1.7 - - country O [ Y ]

7.1.8 - - postal-code O [ Y ]

7.2 - electronic-address O [ N ] To specify a System-Address for electronic delivery, use of Delivery-Service.e-delivery-address electronic-delivery.e-delivery-details is

48

Ref. no.


required. If iLL-Request.delivery-address.electronic-address is also present in an APDU, it SHALL be ignored. See also A.6.1, Ref. 8.2.4.1. For details on formatting this parameter, see 7.2.

See also 7.3 for a discussion of the data parameters to be used for electronic delivery addresses.

7.2.1 - - telecom-service-identifier O [ N ] For details on formatting this parameter, see 7.2.1.

7.2.2 - - telecom-service-address O [ N ] For details on formatting this parameter, see 7.2.2.

8 delivery-service O [ Y ] See 7.3 for a discussion of the data parameters to be used for electronic delivery addresses.

8.1 - physical-delivery O [ Y ]

8.2 - electronic-delivery O [ N ]

8.2.1 - - e-delivery-service O [ N ]

8.2.1.1 - - - e-delivery-mode O O

[ N ] [ N ]

For details on the use of this parameter, see 6.9.3.

The following external objects have been defined for use in this parameter:

{1 0 10161 9 1} Internet Delivery Service {1 0 10161 9 2} Fax Delivery Service

8.2.1.2 - - - e-delivery-parameters

O

[ N ]

For details on the use of this parameter, see 6.9.3.

The following external object has been defined for use in this parameter:

{1 0 10161 10 1000 7 1} JEDDS ILL Electronic Delivery Parameters

8.2.2 - - document-type O [ N ]

8.2.2.1 - - - document-type-id O

[ N ]

The following external object has been defined for use in this parameter:

{1 0 10161 11 1} IANA Media Type See 2.1.2.4 for URL for IANA's directory of Media Types assignments.

8.2.2.2 - - - document-type-parameters

[ N ] If the object identifier of document-type-id is {1 0 10161 11 1} IANA Media Type, the content of this parameter is a SEQUENCE OF Visible-String.

8.2.3 - - e-delivery-description O [ N ]

8.2.4 - - e-delivery-details O [ Y ]

8.2.4.1 - - - e-delivery-address O [ Y ] Use this parameter to provide a System-Address for electronic delivery, If this parameter is present in an ILL-REQUEST, then Implementations SHALL ignore the presence of delivery-address.electronic-address (See A.6.1, Ref. 7.2) in the same transaction.


See also 7.3 for a more detailed discussion of the data parameters to be used for electronic delivery addresses.

49

Ref. no.


8.2.4.2 - - - e-delivery-id O [ N ] See A.6.1, Ref. 2.1.1 and 2.1.2 for the expansion of component data types for System-Id and details on its use.

See A.6.1, Ref. 7.1

8.2.5 - - name-or-code O [ N ]

8.2.6 - - delivery-time O [ N ] See A.6.1, Ref. 3.1.2.

9 bill ing-address O [ Y ]

9.1 - postal-address O [ Y ]


O [ Y ] See A.6.1, Ref. 2.1.2.

9.1.2 - - extended-postal-delivery-address

O [ N ]

9.1.3 - - street-and-number O [ N ]

9.1.4 - - post-office-box O [ Y ]

9.1.5 - - city O [ N ]

9.1.6 - - region O [ N ]

9.1.7 - - country O [ Y ]

9.1.8 - - postal-code O [ Y ]

9.2 - electronic-address O [ N ] See A.6.1, Ref. 7.2.

9.2.1 - - telecom-service-identifier O [ N ] For details on formatting this parameter, see 7.2.1.

9.2.2 - - telecom-service-address O [ N ] For details on formatting this parameter, see 7.2.2.

10 iLL-service-type M [ Y ] See 7.4 for details on the use of this data parameter.

Use the table at A.3.4 to specify the use of iLL-service-type parameter in more detail.

11 responder-specific-service O [ N ] No OIDs are registered for this external object.

12 requester-optional-messages M [ Y ] See 7.5 and IPIG Guidelines 8 for discussion of treatment of optional APDUs.

12.1 - can-send-RECEIVED M [ Y ]

12.2 - can-send-RETURNED M [ Y ]

12.3 - requester-SHIPPED M [ Y ]

12.4 - requester-CHECKED-IN M [ Y ]

13 search-type O [ Y ]

13.1 - level-of-service O [ N ] See 7.6 for a discussion of abstract levels of service defined for use by IPIG implementors.

13.2 - need-before-date O [ N ]

13.3 - expiry-flag O [ N ] DEFAULT: "no-expiry" (3)

13.4 - expiry-date O [ Y ]

14 supply-medium-info-type O [ Y ]

14.1 - supply-medium-type M [ Y ]

14.2 - medium-characteristics O [ N ]

50

Ref. no.


15 place-on-hold O [ N ] DEFAULT: "according-to-responder-policy" (3)

16 client-id O [ Y ]

16.1 - client-name O [ Y ]

16.2 - client-status O [ Y ]

16.3 - client-identifier O [ N ]

17 item-id M [ Y ] Although all parameters within the item-id are optional, the item-id SHALL contain sufficient information to identify the requested item. This need be no more than a system number that the responder application can use to identify the item in its database. The ILL-REQUEST may also carry a Supplemental-Item-Description that might contain additional information, e.g., a bibliographic record.

17.1 - item-type O [ N ]

17.2 - held-medium-type O [ N ]

17.3 - call number O [ Y ]

17.4 - author O [ Y ]

17.5 - title O [ Y ]

17.6 - sub-title O [ N ]

17.7 - sponsoring-body O [ N ]

17.8 - place-of-publication O [ N ]

17.9 - publisher O [ N ]

17.10 - series-title-number O [ Y ]

17.11 - volume-issue O [ Y ]

17.12 - edition O [ N ]

17.13 - publication-date O [ Y ]

17.14 - publication-date-of-component

O [ N ]

17.15 - author-of-article O [ Y ]

17.16 - title-of-article O [ Y ]

17.17 - pagination O [ Y ]

17.18 - national-bibliography-no O [ Y ] Use IPIG-System-Number {1 0 10161 6 1}.

Several commonly used system numbers are defined within the data structure of the external object, IPIG-System-Number {1 0 10161 6 1}. If a national bibliography number is not enumerated in this object, use the "other" data type and enter the database identification database-ID and number as ILL-Strings.

17.19 - iSBN O [ Y ]

17.20 - iSSN O [ Y ]

17.21 - system-no O [ N ] Use IPIG-System-Number {1 0 10161 6 1}.

Several commonly used system numbers are defined within the data structure of the external object, IPIG-System-Number {1 0 10161 6 1}. If a

51

Ref. no.


system number is not enumerated in this object, use the "other" data type and enter the database identification database-ID and number as ILL-Strings.

17.22 - additional-no-letters O [ N ]

17.23 - verification-reference-source

O [ Y ]

18 supplemental-item-description

O

O

O O O O

[ N ]

[ N ]

[ N ] [ N ] [ N ] [ N ]


{1 0 10161 7 1} SICI {1 0 10161 7 2} Item-Language-Translation

In addition, the Record Syntax for MARC record formats as registered with Z39.50 Maintenance Agency (values 1-99) may be used in this parameter. For example:

{1 2 840 10003 5 10} USMARC {1 2 840 10003 5 11} UK MARC {1 2 840 10003 5 10} CANMARC {1 2 840 10003 5 20} AUSMARC

See 2.2.2.2 for URL of Registry of Z39.50 Object Identifiers.

19 cost-info-type O [ N ] See IPIG Guidelines 6.2.4 for "Scenarios for Handling Cost-Info-Type."

19.1 - account-number O [ N ]

19.2 - maximum-cost O [ N ]

19.2.1 - - currency-code M [ N ] See 6.4.3 for a discussion of the requirements for this data parameter.

19.2.2 - - monetary-value M [ N ]

19.3 - reciprocal-agreement O [ N ] DEFAULT: "false"

19.4 - will-pay-fee O [ N ] DEFAULT: "false"

19.5 - payment-provided O [ N ] DEFAULT: "false"

20 copyright-compliance C [ Y ] Because copyright compliance information is country-specific, implementations conforming to the IPIG Profile SHALL support the copyright compliance types of those countries in which their systems are used, or as appropriate for the institutions to which requests are sent.


See IPIG Guidelines 6.2.1 for a discussion of the use of the copyright-compliance parameter.

21 third-party-info-type C [ N ] Implementations that permit or support chaining or partitioning SHALL have the ability to transmit values for the third-party-info-type parameter.

See IPIG Guidelines 6.2.10 for a discussion of the various third-party-info-type permissions.

21.1 - permission-to-forward X -- DEFAULT: "false"

NOTE: The Forward Service is out of scope for the IPIG Profile.

21.2 - permission-to-chain O [ N ] DEFAULT: "false"

21.3 - permission-to-partition O [ N ] DEFAULT: "false"

52

Ref. no.


21.4 - permission-to-change-send-to-list

O [ N ] DEFAULT: "false"

21.5 - initial-requester-address C [ N ] Intermediaries that support partitioning SHALL have the ability to transmit values for the initial-requester-address parameter.

21.5.1 - -telecom-service-identifier O [ N ] For details on formatting this parameter, see 7.2.1.

21.5.2 - -telecom-service-address O [ N ] For details on formatting this parameter, see 7.2.2.

21.6 - preference O [ N ] DEFAULT: "unordered" (2)

21.7 - send-to-list O [ N ] ILL-REQUESTs generated by implementations conforming to the IPIG Profile SHALL contain no more than 5 entries in the send-to-list. Individual entries in the send-to-list SHALL NOT be truncated.

21.7.1 - - system-id M [ N ]

21.7.1.1

- - - person-or-institution-symbol

O [ N ] See A.6.1, Ref. 2.1.1. For details on formatting this parameter, see 7.1.

21.7.1.2

- - - name-of-person-or-institution

O [ N ] See A.6.1, Ref. 2.1.2.

21.7.2 - - account-number O [ N ]

21.7.3 - - system-address O [ N ]

21.7.3.1

- - - telecom-service-identifier

O [ N ] For details on formatting this parameter, see 7.2.1.

21.7.3.2

- - - telecom-service-address O [ N ] For details on formatting this parameter, see 7.2.2.

21.8 - already-tried-list C [ N ] Intermediaries SHALL be able to transmit values for the already-tried-list.

ILL-REQUESTs generated by implementations conforming to the IPIG Profile SHALL contain no more than 25 entries in the already-tried-list. Individual entries in the already-tried-list SHALL NOT be truncated.

21.8.1 - - person-or-institution-symbol

O [ N ] See A.6.1, Ref. 2.1.1. For details on formatting this parameter, see 7.1.


O [ N ] See A.6.1, Ref. 2.1.2.

22 retry-flag O [ Y ] DEFAULT: "false"

23 forward-flag X -- DEFAULT: "false"

NOTE: The Forward Service is out of scope for the IPIG Profile.

24 requester-note O [ Y ]

25 forward-note X -- NOTE: The Forward Service is out of scope for the IPIG Profile.

53

Ref. no.


26 iLL-request-extensions O M O O C

[ N ] [ Y ] [ N ] [ N ] [ Y ]


{1 0 10161 13 2} OCLC-ILL-Request-Extension {1 0 10161 13 3} APDU-Delivery-Info {1 0 10161 13 4} ILL-Supplemental-Client-Info {1 0 10161 13 7} Internal-Reference-Number {1 2 840 10003 8 1} Prompt-1

Mandatory if user authentication is required by the recipient of the APDU.

26.1 - identifier M [ Y ] Implementations conforming to the IPIG Profile SHALL support the value "1", as defined in ISO 10161-1:1997 AM 1.

26.2 - critical O [ Y ] DEFAULT: "false"

26.3 - item M [ N ]

A.6.2. Forward-Notification APDU

Service not supported by IPIG Profile.

A.6.3. Shipped APDU

Ref. no.



2 transaction-id M [ Y ] See A.6.1, Ref. 2.

3 service-date-time M [ Y ] See A.6.1, Ref. 3.

4 requester-id M [ Y ] See A.6.1, Ref. 4.

5 responder-id M [ Y ] See A.6.1, Ref. 5.

6 responder-address C [ N ] See A.6.1, Ref. 7.2.

Implementation supporting partitioning or chaining SHALL be able to supply the responder-address, intermediary-id, and transaction-type parameters.

6.1 - telecom-service-identifier O [ N ] For details on formatting this parameter, see 7.2.1.

6.2 - telecom-service-address O [ N ] For details on formatting this parameter, see 7.2.2.

7 intermediary-id C [ N ] Implementation supporting partitioning or chaining SHALL be able to supply the responder-address, intermediary-id, and transaction-type parameters.

7.1 - person-or-institution-symbol O [ N ] See A.6.1, Ref. 2.1.1.



O [ N ] See A.6.1, Ref. 2.1.2.

8 supplier-id C [ N ] If an implementation permits the supplier of the it t b diff t f th fi l d

54

Ref. no.


item to be different from the final responder, that is, if an implementation supports acting as the agent for other, possibly non-automated, suppliers, then the supplier-id parameter SHALL be transmitted.

8.1 - person-or-institution-symbol O [ N ] See A.6.1, Ref. 2.1.1. For details on formatting this parameter, see 7.1.


O [ N ] See A.6.1, Ref. 2.1.2.

9 client-id C [ Y ] If client-id data were supplied on the initial ILL-REQUEST, implementations conforming to the IPIG Profile SHALL transmit data for this parameter in the SHIPPED APDU. Otherwise, it is optional. See ISO 10160:1997 Clause 7.3.4.1.

See A.6.1, Ref. 16 for the exapnsion of component data types for client-id.

10 transaction-type C [ Y ] DEFAULT: "simple" (1)

Implementations supporting partitioning or chaining SHALL be able to supply the responder-address, intermediary-id, and transaction-type parameters.


O [ N ] See A.6.1, Ref. 18.

12 shipped-service-type M [ Y ] Values for this parameter (a subset of ILL-service-type) are limited to (1) "loan" and (2) "copy/non-returnable".

See 7.4.2 for guidelines on the use of this parameter.

13 responder-optional-messages

M [ Y ] See 7.5 and IPIG Guidelines 8 for discussion of the treatment of Optional APDUs.

13.1 - can-send-SHIPPED M [ Y ]

13.2 - can-send-CHECKED-IN M [ Y ]

13.3 - responder-RECEIVED M [ Y ]

13.4 - responder-RETURNED M [ Y ]

14 supply-details M [ Y ] At least one of the component types of supply-details SHALL be present.

14.1 - date-shipped O [ Y ]

14.2 - date-due C [ N ] If the "loan" service type is supported, then the implementation must be able to transmit values for the date-due parameter.

14.2.1 - - date-due-field O [ N ]

14.2.2 - - renewable O [ N ] DEFAULT: "true"

14.3 - chargeable units O [ Y ]

14.4 - cost O [ Y ]

14.4.1 - - currency-code M [ Y ] See 6.4.3 for a discussion of the requirements for this data parameter.

14.4.2 - - monetary-value M [ Y ]

14.5 - shipped-conditions O [ N ]

55

Ref. no.


14.6 - shipped-via O [ N ]

14.6.1 - - physical-delivery O [ N ]

14.6.2 - - electronic-delivery O [ N ] See A.6.1, Ref. 8.2.

14.7 - insured-for O [ N ]

14.7.1 - - currency-code M [ N ] See 6.4.3 for a discussion on the requirements for this data parameter.


14.8 - return-insurance-required O [ N ]

14.8.1 - - currency-code M [ N ] See 6.4.3 for a discussion on the requirements for this data parameter.


14.9 - no-of-units-per-medium O [ N ]

14.9.1 - - medium M [ N ]

14.9.2 - - no-of-units M [ N ]

15 return-to-address O [ N ]


O [ N ] See A.6.1, Ref. 2.1.2.

15.2 - extended-postal-delivery-address

O [ N ]

15.3 - street-and-number O [ N ]

15.4 - post-office-box O [ N ]

15.5 - city O [ N ]

15.6 - region O [ N ]

15.7 - country O [ N ]

15.8 - postal-code O [ N ]

16 responder-note O [ Y ]

17 shipped-extensions M O O C

[ Y ] [ N ] [ N ] [ Y ]

See A.6.1, Ref. 26 for data types included in any "extensions" parameter.


{1 0 10161 13 3} APDU-Delivery-Info {1 0 10161 13 4} ILL-Supplemental-Client-Info {1 0 10161 13 7} Internal-Reference-Number {1 2 840 10003 8 1} Prompt-1


56

A.6.4. ILL-Answer APDU

Ref. no. Parameter IPIG Impl References, Usage or Range of Values 1 protocol-version-num M [ Y ] Implementations conforming to IPIG Profile

SHALL support the value "2".





6 transaction-results M [ Y ] See 7.4.3 for a discussion on the use of this parameter.

7 results-explanation C [ Y ] If the value of transaction-results is "conditional", "locations-provided", or "estimate", the results-explanation parameter SHALL be present.

7.1 - conditional-results C [ Y ] Mandatory if the value of transaction-results is "conditional".

See IPIG Guidelines 6.5.1 for recommendations on handling multiple conditions.

7.1.1 - - conditions M [ Y ]

7.1.2 - - date-for-reply O [ N ]

7.1.3 - - locations O [ N ]

7.1.3.1 - - - location-id M [ N ]

7.1.3.1.1

- - - - person-or-institution-symbol

O [ N ] See A.6.1, Ref. 2.1.1.


7.1.3.1.2

- - - - name-of-person-or-institution

O [ N ] See A.6.1, Ref. 2.1.2.

7.1.3.2 - - - location-address O [ N ] See A.6.1, Ref. 7.2.

7.1.3.3 - - - location-note O [ N ]

7.1.4 - - proposed-delivery-service

O [ N ] See A.6.1, Ref. 8.

7.2 - retry-results O [ N ] See IPIG Guidelines 6.2.8 for an example of the use of retry.

7.2.1 - - reason-not-available O [ N ]

7.2.2 - - retry-date O [ N ]

7.2.3 - - locations O [ N ] See A.6.4, Ref. 7.1.3.

7.3 - unfilled-results O [ N ] See 6.8 for a discussion of the use of this results-explanation if an unrecognized or unsupported critical extension occurs in an ILL-REQUEST APDU.

7.3.1 - - reason-unfilled M [ N ]


7.4 - locations-results C [ N ] Mandatory if the value of transaction-results is "locations-provided".

7.4.1 - - reason-locs-provided O [ N ]

7.4.2 - - locations M [ N ] See A.6.4, Ref. 7.1.3.

57

Ref. no. Parameter IPIG Impl References, Usage or Range of Values 7.5 - will-supply-results O [ N ]

7.5.1 - - reason-will-supply M [ N ]

7.5.2 - - supply-date O [ N ]

7.5.3 - - return-to-address O [ N ] See A.6.1, Ref. 7.1 for the expansion of component data types for postal-address.


7.5.5 - - electronic-delivery-service

O [ N ] See A.6.1, Ref. 8.2.

7.6 - hold-placed-results O [ N ]

7.6.1 - - estimated-date-available

M [ N ]

7.6.2 - - hold-placed-medium-type

O [ N ]


7.7 - estimate-results C [ N ] Mandatory if the value of transaction-results is "estimate".

7.7.1 - - cost-estimate M [ N ]


8 responder-specific-results O [ N ] No OIDs are registered for this external object.


O [ N ] See A.6.1, Ref. 18.

10 send-to-list O [ N ] See A.6.1, Ref. 21.7.

11 already-tried-list O [ N ] See A.6.1, Ref. 21.8.

12 responder-optional-messages

M [ Y ] See A.6.3, Ref. 13.

See 7.5 and IPIG Guidelines 8 for discussion of treatment of optional APDUs.


14 iLL-answer-extensions M O C

[ Y ] [ N ] [ Y ]



{1 0 10161 13 3} APDU-Delivery-Info {1 0 10161 13 7} Internal-Reference-Number {1 2 840 10003 8 1} Prompt-1


A.6.5. Conditional-Reply APDU

Ref. no.






58

Ref. no.



6 answer M [ Y ]


8 conditional-reply-extensions M O C

[ Y ] [ N ] [ Y ]





A.6.6. Cancel APDU

Ref. no.







6 requester-note O [ N ]

7 cancel-extensions M O C

[ Y ] [ N ] [ Y ]





A.6.7. Cancel-Reply APDU

Ref. no.







6 answer M [ Y ]

59

Ref. no.



8 cancel-reply-extensions M O C

[ Y ] [ ] [ ]





A.6.8. Received APDU

Ref. no.







6 supplier-id C [ N ] Support of this parameter is required only when a responder is acting as an agent for the actual supplier of the item (and so the supplier-id will differ from the responder-id), or if a value for the system-id has been transmitted as a parameter in the SHIPPED APDU.


O [ N ] See A.6.1, Ref. 18.

8 date-received M [ Y ]

9 shipped-service-type M [ Y ] Values for this parameter (a subset of ILL-service-type) are limited to (1) "loan" and (2) "copy/non-returnable".


11 received-extensions M O C

[ Y ] [ N ] [ Y ]





60

A.6.9. Recall APDU

Ref. no.


1 protocol-version-num M [ N ] Implementations conforming to IPIG Profile SHALL support the value "2".

2 transaction-id M [ N ] See A.6.1, Ref. 2.

3 service-date-time M [ N ] See A.6.1, Ref. 3.

4 requester-id M [ N ] See A.6.1, Ref. 4.

5 responder-id M [ N ] See A.6.1, Ref. 5.

6 responder-note O [ N ]

7 recall-extensions M O C

[ N ] [ N ] [ N ]





A.6.10. Returned APDU

Ref. no.








O [ N ] See A.6.1, Ref. 18.

7 date-returned M [ N ]

8 returned-via O [ N ]

9 insured-for O [ N ]

9.1 - currency-code M [ N ] See 6.4.3 for a discussion of the requirements for this data parameter.

9.2 - monetary-value M [ N ]


11 returned-extensions M O C

[ N ] [ N ] [ N ]




61

Ref. no.



A.6.11. Checked-in APDU

Ref. no.







6 date-checked-in M [ N ]


8 checked-in-extensions M O C

[ N ] [ N ] [ N ]





A.6.12. Overdue APDU

Ref. no.







6 date-due M [ N ] See A.6.3, Ref. 14.2 for an expansion of the component data types of date-due.


8 overdue-extensions M O C

[ N ] [ N ] [ N ]




Mandatory if user authentication is required by the recipient of the

62

Ref. no.


APDU.

A.6.13. Renew APDU

Ref. no.







6 desired-due-date O [ N ]


8 renew-extensions M O C

[ N ] [ N ] [ N ]





A.6.14. Renew-Answer APDU

Ref. no.







6 answer M [ N ]

7 date-due C [ N ] If the value of the answer parameter is "true", then a new value for the date-due parameter SHALL be sent as part of this APDU.

See A.6.3, Ref. 14.2 for an expansion of the component data types of date-due.


9 renew-answer-extensions M O

[ N ] [ N ]



{1 0 10161 13 3} APDU-Delivery-Info {1 0 10161 13 7} Internal-Reference-Number

63

Ref. no.


C

[ N ]

{1 2 840 10003 8 1} Prompt-1 Mandatory if user authentication is required by the recipient of the APDU.

A.6.15. Lost APDU

Ref. no.







6 note O [ N ]

7 lost-extensions M O C

[ N ] [ N ] [ N ]





A.6.16. Damaged APDU

Ref. no.







6 damaged-details O [ N ]

6.1 - document-type-id O

[ N ]

The following external object has been defined for use in this parameter: {1 0 10161 11 1} IANA Document Type

6.2 - damaged-portion M [ N ]

7 note O [ N ]

8 damaged-extensions M O

[ N ] [ N ]



{1 0 10161 13 3} APDU-Delivery-Info {1 0 10161 13 7} Internal-Reference-

64

Ref. no.


C

[ N ]

Number {1 2 840 10003 8 1} Prompt-1


A.6.17. Message APDU

Ref. no.







6 note M [ N ]

7 message-extensions M O C

[ N ] [ N ] [ N ]





A.6.18. Status-Query APDU

Ref. no.







6 note O [ Y ]

7 status-query-extensions M O C

[ Y] [ N ] [ Y ]





65

A.6.19. Status-or-Error-Report APDU

Ref. no.







6 reason-no-report C [ N ] Responders capable of sending an APDU in which neither the status-report nor the error-report parameter is present SHALL support this parameter; otherwise it is not applicable.

The circumstances in which no report might be sent are not specified either in the base standard or in the IPIG Profile.

7 status-report O [ Y ]

7.1 - user-status-report M [ Y ]

7.1.1 - - date-requested O [ Y ]

7.1.2 - - author O [ N ]

7.1.3 - - title O [ Y ]

7.1.4 - - author-of-article O [ N ]

7.1.5 - - title-of-article O [ Y ]

7.1.6 - - date-of-last-transition M [ N ]

7.1.7 - - most-recent-service M [ N ] Implementations SHALL be capable of sending all values consistent with the INTERLIBRARY LOAN APPLICATION SERVICES (see A.5) and ILL-service-types (see A.3.4) supported.

7.1.8 - - date-of-most-recent-service

M [ N ]

7.1.9 - - initiator-of-most-recent-service

M [ N ]

7.1.9.1 - - - person-or-institution-symbol

M [ N ] For details on formatting this parameter, see 7.1.

7.1.9.2 - - - name-of-person-or-institution

O [ N ] See A.6.1, Ref. 2.1.2.

7.1.10 - - shipped-service-type C [ N ] If this information has been transmitted in an earlier SHIPPED or RECEIVED APDU, then an implementation conforming to the IPIG Profile SHALL supply the most current information as a value for this parameter. See A.3.4.

7.1.11 - - transaction-results C [ N ] If this information has been transmitted in an ILL-ANSWER APDU, then an implementation conforming to the IPIG Profile SHALL supply it as a value for this parameter.

7.1.12 - - most-recent-service-note C [ N ] If a note has been supplied in the most recent service APDU received or the most recent service request invoked, then an implementation conforming to the IPIG Profile

66

Ref. no.


SHALL supply it as a value for this parameter.

7.2 - provider-status-report M [ Y ] Implementations SHALL be capable of sending all values consistent with the INTERLIBRARY LOAN APPLICATION SERVICES (see A.5) and ILL-service-types (see A.3.4) supported.

8 error-report O [ Y ]

8.1 - correlation-information M [ Y ] This parameter includes Information that permits correlation of the error-report with the ILL service to which it applies.

8.2 - report-source M [ Y ]

8.3 - user-error-report C [ Y ] If the value of report-source is "user", then the user-error-report parameter SHALL be present. Otherwise it is not applicable.

8.3.1 - - already-forwarded X -- The Forward Service is out of scope for the IPIG Profile.

8.3.1.1 - - - responder-id M [ Y ] See A.6.1, Ref. 5.

8.3.1.2 - - - responder-address O [ N ] See A.6.3, Ref. 6.

8.3.2 - - intermediary-problem O [ N ]

8.3.3 - - security-problem O [ N ]

8.3.4 - - unable-to-perform O [ N ]

8.4 - provider-error-report C [ Y ] If the value of report-source is "provider", then the provider-error-report parameter SHALL be present. Otherwise it is not applicable.

8.4.1 - - general-problem O [ N ]

8.4.2 - - transaction-id-problem O [ N ]

8.4.3 - - state-transition-prohibited O [ N ]

8.4.3.1 - - - aPDU-type M [ N ] For a list of possible values, see A.5.

8.4.3.2 - - - current-state M [ N ]

9 note O [ Y ]

10 status-or-error-report-extensions

M C O C

[ Y ] [ N ] [ N ] [ Y ]



{1 0 10161 13 3} APDU-Delivery-Info {1 0 10161 13 6} IPIG Additional User Error Information

Mandatory if an implementation supports truncation of data.

{1 0 10161 13 7} Internal-Reference-Number {1 2 840 10003 8 1} Prompt-1


A.6.20. Expired APDU

Ref. no.


1 protocol-version-num M [ N ] Implementations conforming to IPIG Profile SHALL t th l "2"

67

Ref. no.


SHALL support the value "2".





6 expired-extensions

M O C

[ N ] [ N ] [ N ]





A.7. External Objects The table in A.4 indicates the degree of support for the associated abstract syntaxes for which these external objects have been defined.

The tables in A.6 specify which external objects are defined for use in specific parameters within each APDU.

Indicate in the tables below the degree of support of the data parameters defined for use in the external objects to be used by implementations conforming to the IPIG Profile. If the implementation supports different values (or has different constraints) for different roles, this SHALLSHALLSHALLSHALL be indicated.

Note to implementors: Note to implementors: Note to implementors: Note to implementors: The abstract syntax specification (ASN.1) for each external object listed in the above table is available in the online Register of the Maintenance Agency responsible for it.

See the Note to implementors following A.4 for guidance on how to identify the Maintenance Agency with which each of the following external objects is registered.

68

system-no (6)

A.7.1. {1 0 10161 6 1} IPIG-System-Number

Ref. no.


1 type M [ N ]

1.1 - well-known-system O [ N ]

1.2 - system-id O [ N ]

2 database-ID O [ N ]

3 number M [ N ]

supplementary-item-description (7)

A.7.2. {1 0 10161 7 1} SICI

Ref. no.


1 SICI M [ N ]

A.7.3. {1 0 10161 7 2} Item-Language-Translation

Ref. no.


1 Item-Language-Requirement M [ N ]

1.1 - translation-option M [ N ]

1.2 - language-code O [ N ] Values defined in ISO 639-2:1998

A.7.4. {1 2 840 10003 5} Record Syntaxes,

The official and complete Z39.50 MA register of record syntaxes is available online at <http://lcweb.loc.gov/z3950/agency/defns/oids.html#5>

Note to Implementors: This list of record syntaxes provides only a selection of formats registered by the Z39.50 Maintenance Agency. Add additional rows as required to the table below to specify additional MARC record syntax from the list in the Z39.50 register, which are supported by the implementation.

Ref. no.

OID Record Syntax IPIG Impl References, Usage or Range of Values

1 1.2.840.10003.5.1 Unimarc O [ N ]

2 1.2.840.10003.5.10 Usmarc O [ N ]

3 1.2.840.10003.5.11 Ukmarc O [ N ]

4 1.2.840.10003.5.17 Canmarc O [ N ]

5 1.2.840.10003.5.20 Ausmarc O [ N ]

69

Ref. no.

OID Record Syntax IPIG Impl References, Usage or Range of Values

6 1.2.840.10003.5.24 JPmarc O [ N ]

7 1.2.840.10003.5.25 SWEMarc O [ N ]

other (please specify)

e-delivery-mode (9) & e-delivery-parameters (10)

A.7.5. Internet and Fax Delivery Services

The use of eeee----delivery parametersdelivery parametersdelivery parametersdelivery parameters is contingent on specifications in the external objects defined for e e e e----deliverydeliverydeliverydelivery----modemodemodemode. The external objects currently defined for eeee----delivery modedelivery modedelivery modedelivery mode (Internet Delivery Services (SMTP and FTP) and Fax Delivery Service) require that any eany eany eany e----deliverydeliverydeliverydelivery----parametersparametersparametersparameters are also external objects.

Ref. no.

OID Object Subclass IPIG Impl References, Usage or Range of Values

1 1.0.10161.9.1 Internet Delivery Service

O [ N ]

1.1 1.0.10161.9.1.1 - SMTP O [ N ]

1.1.1 1 0 10161 10 1000 7 1 - - JEDDS-ILL-Edelivery-Parameters

O [ N ] Values include "GEDI" and "Ariel MIME".

1.2 1.0.10161.9.1.2 - FTP O [ N ]

1.2.1 1 0 10161 10 1000 7 1 - - JEDDS-ILL-Edelivery-Parameters

O [ N ] Values include "GEDI" and "Ariel FTP".

2 1.0.10161.9.2 Fax Delivery Service O [ N ]

2.1 1 0 10161 10 1000 7 1 - JEDDS-ILL-Edelivery-Parameters

O [ N ] Defined value: "FAX".

extension

A.7.6. {1 0 10161 13 2} OCLC ILL Request Extension

Ref. no.


1 client-department O [ N ]

2 payment-method O [ N ]

3 uniform-title O [ N ]

4 dissertation O [ N ]

5 issue-number O [ N ]

6 volume O [ N ]

7 affil iations O [ N ]

8 source O [ N ]

70

A.7.7. {1 0 10161 13 3} APDU-Delivery-Info

Ref. no.


1 sender-info M [ Y ]

1.1 - encoding M [ Y ] Implementations conforming to the IPIG Profile SHALL support the following values:

(2) "bER-In-MIME" (3) "bER"

1.2 - transport M [ Y ]

1.3 - aliases O [ N ]

2 recipient-info M [ Y ] See A7.7, Ref. 1

3 transponder-info O [ N ] See A7.7, Ref. 1

A.7.8. {1 0 10161 13 4} ILL-Supplemental-Client-Info

Ref. no.


1 Client-Info-Type M [ N ]

1.1 - standard O [ N ]

1.2 - local O [ N ]

2 Client-Info-Content M [ N ]

2.1 - string-content O [ N ]

2.2 - postal-address O [ N ]

2.3 - name-or-id O [ N ]

2.4 - status-code O [ N ]

2.5 - defined-number O [ N ]

2.6 - nested O [ N ]

2.7 - amount O [ N ]

A.7.9. {1 0 10161 13 6} IPIG-Additional-User-Error-Information

Ref. no.


1 element-truncated O [ N ]

1.1 - element M [ N ]

1.2 - truncated-value M [ N ]

2 missing-required-element O [ N ]

3 unsupported-field-length O [ N ]


3.2 - min-length O [ N ]

3.3 - max-length O [ N ]

4. unrecognized-data O [ N ]


4.2 - data O [ N ]

4.3 - expected-format O [ N ]

71

Ref. no.


4.4 - supported-values O [ N ]

5 inconsistent-data O [ N ]

6 other O [ N ]

A.7.10. {1 0 10161 13 7} Internal-Reference-Number

Ref. no.


1 requester-internal-reference O [ N ] Implementors SHALL supply either one of requester-internal-reference and/or responder-internal-reference when using this object.

1.1 - reference-authority M [ N ]

1.2 - internal-reference M [ N ]

2 responder-internal-reference O [ N ] Implementors SHALL supply either requester-internal-reference and/or responder-internal-reference when using this object.

2.1 - reference-authority M [ N ]

2.2 - internal-reference M [ N ]

Access Control

A.7.11. {1 2 840 10003 8 1} Prompt-1

This object is registered as an Access Control Format in the Registry of Z39.50 Object Identifiers, available online at http://lcweb.loc.gov/z39.50/agency/defns/oids.html#8

The full ASN.1 definition of the Access Control Format Prompt-1 is found in ANSI/NISO Z39.50-1995. Annex 7.

Ref. no.


1 challenge X --

2 response M [ Y ]

2.1 - prompt-id M [ Y ]

2.1.1 - - enummerated-prompt M [ Y ]

2.1.1.1 - - - type M [ Y ] Support required for (0) "group-id", (1) "user-id" and (2) "password".

Support for other defined values is optional.

2.1.1.2 - - - suggested-string O [ ]

2.1.2 - - non-enumerated-prompt X --

2.2 - prompt-response M [ Y ] [1] "String" is the only choice relevant for IPIG implementations.

72

日米両国におけるドキュメント・デリバリー・サービスの改善に関するプロジェクト

2000年度報告

2001年 3月 31日印刷発行発行国立情報学研究所〒101-8430 東京都千代田区一ツ橋 2-1-2 電話 (03) 4212 - 2000 印刷日本印刷株式会社〒101-0021 東京都千代田区外神田 6-3-3 電話 (03) 3833 - 6971

ISBN 4-924600-91-1

ISBN 4-924600-91-1

Documents

日米両国におけるドキュメント・デリバリー・サービスの 改善に … · 平成11年2月に行われた「日米両国におけるドキュメント・デリバリー・サービ

日米両国におけるドキュメント・デリバリー・サービスの改善に … · 平成11年2月に行われた「日米両国におけるドキュメント・デリバリー・サービ