Board)"の日本語訳である。Board)"を参照されたい。この日本語訳は参考である。公式な文書ではなく、翻訳・解釈の正確性を保証していない。Pratsam概要DAISYオンライン配信プロトコルは、サービス(Service)プロバイダからエンドユーザー(User)へのデジタルリソースの配信を容易にするWebサービス(Service)APIである。このプロトコルは、様々なダウンロードモデルを実現する設定を可能とするオペレーションのコアセットを特徴とするもので、出版されたコンテンツのオンライン配信への高まるニーズに対するフレキシブルで軽量なソリューションである。この文書のステータスこのセクションは、公開時点におけるこの文書のステータスを説明する。他の文書がこの文書を置き換える場合がある。インデックスで見つけることができる。Groupがその活動の一環として作成した。Groupの運営によって作成されたものである。本仕様の英語版が標準を定める唯一のバージョンである。はじめにこのセクションは参考情報である。DAISYオンライン配信プロトコルは、コンテンツをクライアントとユーザー(User)にタイムリーかつ費用対効果の高い方法で配信できるようにしたいというDAISY製作者のニーズから生まれた。物理的な媒体によるコンテンツの配布の課題は、これらの解決法の実装が困難になり、これらの解決法の維持が煩雑になり、環境に対して優しくないことである。Book)は、DAISY規格の主要な構成要素であるが、標準そのものが進化しており、様々なタイプのアクセシブルな媒体を配布する必要性は、DAISYコンソーシアムの多くのメンバーがすでに直面しているものである。その結果、プロバイダからリーディングシステムへのリソースの伝達を目的として、このプロトコルのためのサービス(Service)アーキテクチャを開発した。アクセシブルパブリッシングの領域を超えてコンテンツ配信メカニズムとしても有用なプロトコルにするべき設計原理に基づいている。第2の主要な開発の目的は、このプロトコルを、個人または組織の配信ニーズに合わせてカスタマイズし、調整ができるよう十分に柔軟なものにするためであった。System)を接続し、自動的に新しいコンテンツをダウンロードできるようにすることができるような、シンプルなサービス(Service)の開発を容易する。彼ら独自のコンテンツをダウンロードするような、より豊かでよりインタラクティブなモデルを可能にする。このプロトコルは、コンテンツの配信だけではなく、コンテンツの貸出を容易にするためにも設計された。期間を限定したユーザー(User)へのコンテンツ配信の手段が求められる図書館やその他の機関は、この種の配信モデルを容易にする多くの機能を見つけるだろう。明示的なデジタル著作権管理の問題が懸念事項であるため、このプロトコルではPDTB2コンテンツ保護スキームの使用も可能としている。System)とサービス(Service)との間の相互作用は、HTTPプロトコルを介したSOAPメッセージによって行われる。サービス(Service)オペーレションは規範的なWSDLドキュメントで全て定義されている。1.1に準拠している。このプロトコルのこのバージョンでは取り組むことができなかった1つの機能は、DAISYオンライン配信サービス(Service)の発見である。DAISYコンソーシアムは、後日、オンラインサービスの追跡し、位置を特定するためのシステムや仕様を開発するかもしれないが、このプロトコルと統合しうるそのような機能は、現時点では存在しない。用語このセクションは規範的である。2119]で規定されている通りに解釈されることとする。加えて、この文書を通して次の用語がこのセクションで述べられて意味で使用されている。Content)ユーザー(User)に貸与してよく(MAY)、貸与の後に返却されなければならない(MUST)コンテンツ(Content)。コンテンツ(Content)の所有権はユーザー(User)には渡されない。Content)は有料で貸与されるコンテンツ(Content)が含まれる。Provider)によって利用可能になった単数のリソースまたは複数のリソース。item)に割り当てられた一意の識別子。identifierフィールドによって公開される。item)内で使用される識別子(例えば、DAISYデジタル録音図書のメタデータ内の識別子)を一致させることは求められない。System)へのコンテンツ(Content)の転送。System)は不揮発性メモリにコンテンツ(Content)を格納する。System)の行為である。1.1]障害(Fault)。障害(Fault)は、SOAPメッセージのエラーおよび/またはステータス情報を搬送する。障害(Fault)で、このプロトコルで使用される障害(Fault)を定義している。1.1]ポートタイプ。サービス(Service)がサポートするオペレーション(Operation)のセット。item)へのアクセスを許可すること。System)は、サービス(Service)からアクセスを要求するためにissueContentオペレーションを使用する。1.1]オペレーション。サービス(Service)でサポートされているアクションである。NOT)コンテンツ(Content)。コンテンツ(Content)の所有権は、そのユーザー(User)に渡してもよいし(MAY)、渡さなくてもよい。Content)には、無料で提供されているコンテンツ(Content)が含まれている。返却の必要がない失効したDRMで保護されたコンテンツ(Content)のような、返却が要求されないコンテンツ(Content)も含まれている。System)サービス(Service)にアクセスし、ユーザー(User)のためにコンテンツ(Content)をレンダリングするハードウェアおよび/またはソフトウェアの組み合わせ。System)は、1つのデバイス上で完全に実装されてもよいし(MAY)、いくつかに分割してもよい(MAY)。適合性対象]の利用者に対応する。item)へのアクセスをやめること。item)は返却される。Content)には適用されない。サービス(Service)DAISYオンライン配信プロトコルを実装するWebサービス(Service)。適合性対象]のインスタンスに対応する。Provider)サービス(Service)を所有している人(単一または複数)または組織(単一または複数)。Provider)は、そのサービス(Service)が動作しているサーバを所有する同じエンティティであってもよいし(MAY)、同じエンティティでなくてもよい。System)とあるサービス(Service)の間の一連のオペレーション(Operation)。サービス(Service)によって定義された一意の識別子を使用する。1つのセッションが、複数のHTTPコネクションを跨いで持続してよい(MAY)。セッション(Session)識別子は、サービス(Service)の裁量において再利用してもよい(MAY)。System)に送信される。System)へのコンテンツ(Content)の転送。System)は転送されてすぐにそのコンテンツ(Content)をレンダリングし、一時的にそのコンテンツ(Content)を保存する。System)の行為である。System)を使用してサービス(Service)とやりとりし、かつ/またはそのサービス(Service)のコンテンツ(Content)にアクセスする人。基盤となる技術このセクションは規範的である。対応しなければならない(MUST)。準拠しなければならない(MUST)。2109]で規定されているHTTPセッションをサポートしなければならない(MUST)。セクション10で規定されているように)を返さなければならない(MUST)。System)は、サービス(Service)によって送信されるすべてのCookieを送受信できなければならない(MUST)。Cookieを管理できなければならない(MUST)。HTTPS交換されるデータに秘密情報を含めてもよい(MAY)ため、サービス(Service)との全てのやり取りには、HTTPSの使用が推奨される(RECOMMENDED)。System)が証明書の使用によってサービス(Service)が本物であるかどうか確認することも認めている。authority)に登録することが推奨される(RECOMMENDED)。HTTPSを介して提供されるリソースを識別する全てのURIには標準的なURIプレフィックスであるhttps:を使用しなければならない(MUST)。System)は、HTTPSをサポートしなければならない(MUST)。HTTPSへのサポートは、サービス(Service)にも推奨される(RECOMMENDED)。Basic認証スキームは、不正アクセスからコンテンツ(Content)を保護するために使用されてもよい(MAY)。Basic認証を使用する時には、サービス(Service)はURIのサーバコンポーネントフィールドにあるクレデンシャルを提供しなければならない(MUST)。userinfo@host:portである。:portという形式でなければならない(MUST)。2396]は、推奨している。サービス(Service)は、HTTPSのようなセキュアな接続を介して、このスキームを使用するのみにするべきである(SHOULD)。この方法について知られた突破口を回避できるよう開発されるべきである(SHOULD)。パスワードを保存するための現在のベストプラクティスは、データベースが危険にさらされた時に備え、それぞれのパスワードの暗号化したハッシュを格納することのみである。サービス(Service)は、userinfoフィールドで提供するために、暗号化されていない認証証明書をユーザー(User)のために取得する必要があってもよい(MAY)安全な取得方法が実装されていない限り、このスキームを使用してBasic認証を実装するサービス(Service)は、結果としてデータベースのセキュリティを損なう危険性がある。System)は、サービス(Service)によって返されたURIで提供されたBasic認証証明書のみを送信しなければならない(MUST)。コンテンツ(Content)にアクセスするために求められる証明書は、logOnオペレーションで提供される証明書と同じであることは求められない。