ネットワークワーキンググループ J. Veizades Request for Comments: 2165 @Home Network 分類: スタンダードトラック E. Guttman C. Perkins Sun Microsystems S. Kaplan 1997年6月 サービス・ロケーション・プロトコル (Service Location Protocol) このメモの位置付け この文書は、インターネット・コミュニティに対してインターネット・スタ ンダードトラックのプロトコルを規定するとともに、それを改良するための 議論や提言を求めるものである。このプロトコルの標準化状態、およびステ ータスについては、"Internet Official Protocol Standards"(STD 1)の最 新版を参照すること。このメモの配布に制限はない。 要旨 サービス・ロケーション・プロトコルはネットワークサービスの発見と選択 のための枠組みを提供する。このプロトコルを使用することにより、インタ ーネットを利用しているコンピュータでは、ネットワークに基づくアプリケ ーションにネットワークサービスの多くの静的な構成が必要なくなる。コン ピュータがよりポータブルになり、ユーザが寛容でなくなり、ネットワーク 管理の要求を実現するために、このことは特に重要となる。 目次 1. はじめに 3 2. 専門用語 3 2.1. 表記法の定義 . . . . . . . . . . . . . . . . . . . . . . 5 2.2. サービス情報と述部表現 . . . . . . . . . . . . . . . . . 5 2.3. 言語仕様 . . . . . . . . . . . . . . . . . . . . . . . . 6 3. プロトコル概要 6 3.1. プロトコル処理 . . . . . . . . . . . . . . . . . . . . . 7 3.2. スキーム . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.1. URLスキーム "service:" . . . . . . . . . . . . . 9 3.3. 標準属性定義 . . . . . . . . . . . . . . . . . . . . . . 9 3.4. 命名局 . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.5. サービス・ロケーション応答の解釈 . . . . . . . . . . . . 10 3.6. サービス・ロケーションでのTCP, UDP, マルチキャストの利用 10 3.6.1. マルチキャスト対ブロードキャスト . . . . . . . . 11 3.6.2. サービス指定マルチキャストアドレス . . . . . . . 11 3.7. サービス・ロケーション・スケーリングと マルチキャスト操作モード . . . . . . . . . . . . 12 Veizades, et. al. Standards Track [Page 1] RFC 2165 Service Location Protocol June 1997 4. サービス・ロケーション・ゼネラル・メッセージフォーマット 14 4.1. トランザクションIDの利用 (XIDs) . . . . . . . . . . . . . 15 4.2. URLエントリ . . . . . . . . . . . . . . . . . . . . . . . 16 4.3. 認証ブロック . . . . . . . . . . . . . . . . . . . . . . 17 4.4. URLエントリの寿命 . . . . . . . . . . . . . . . . . . . 19 5. サービス要求メッセージフォーマット 19 5.1. サービス要求の使用法 . . . . . . . . . . . . . . . . . . 22 5.2. ディレクトリ・エージェント・ディスカバリー要求 . . . . . 23 5.3. 述部文法の用語説明 . . . . . . . . . . . . . . . . . . . 24 5.4. サービス要求述部文法 . . . . . . . . . . . . . . . . . . 26 5.5. 要求の文字列マッチング . . . . . . . . . . . . . . . . . 27 6. サービス応答メッセージフォーマット 28 7. サービスタイプ要求メッセージフォーマット 29 8. サービスタイプ応答メッセージフォーマット 31 9. サービス登録メッセージフォーマット 32 10. サービス認証メッセージフォーマット 35 11. サービス登録取消メッセージフォーマット 37 12. 属性要求メッセージフォーマット 38 13. 属性応答メッセージフォーマット 40 14. ディレクトリ・エージェント広告メッセージフォーマット 42 15. ディレクトリ・エージェント 43 15.1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . 43 15.2. ディレクトリ・エージェントの発見 . . . . . . . . . . . . 43 16. スコープの発見と使用 45 16.1. 保護スコープ . . . . . . . . . . . . . . . . . . . . . . 46 17. 言語と文字エンコードの問題 47 17.1. 文字エンコードと文字列の問題 . . . . . . . . . . . . . . 48 17.1.1. 文字エスケープシーケンスの代用 . . . . . . . . . 49 17.2. 言語依存文字列 . . . . . . . . . . . . . . . . . . . . . 49 18. サービス・ロケーション処理 50 18.1. サービス・ロケーション接続 . . . . . . . . . . . . . . . 50 18.2. 非同期仮定 . . . . . . . . . . . . . . . . . . . . . . . 51 18.3. 同一効果 . . . . . . . . . . . . . . . . . . . . . . . . 51 19. セキュリティの考察 51 20. サービス・ロケーション・メッセージを使用した文字列形式 52 20.1. 前の応答者のアドレス指定 . . . . . . . . . . . . . . . . 53 20.2. "service:"スキームの正式な記述 . . . . . . . . . . . . . 53 20.2.1. サービスタイプ文字列 . . . . . . . . . . . . . . 54 20.3. 属性情報 . . . . . . . . . . . . . . . . . . . . . . . . 54 20.4. サービス・ロケーションでのアドレス指定 . . . . . . . . . 55 20.5. 属性値のエンコード規則 . . . . . . . . . . . . . . . . . 55 21. プロトコル要求事項 56 21.1. ユーザ・エージェント要求事項 . . . . . . . . . . . . . . 56 21.2. サービス・エージェント要求事項 . . . . . . . . . . . . . 58 21.3. ディレクトリ・エージェント要求事項 . . . . . . . . . . . 59 22. 設定の変更が可能なパラメータとデフォルト値 61 22.1. サービス・エージェント: 定義済みディレクトリ・エージェントの利用 . . . . 62 22.2. タイムアウト間隔 . . . . . . . . . . . . . . . . . . . . 63 Veizades, et. al. Standards Track [Page 2] RFC 2165 Service Location Protocol June 1997 23. 設定の変更が不可能なパラメータ 63 24. 謝辞 64 A. 付録: ISO 639より:1988 (E/F): "Code for the representation of names of languages" 65 B. SLP証明書 66 C. MD5とRSAを使用したSLPセキュリティ配置例 68 D. 可動ノードによるSLP証明書の使用例 68 E. 付録: これ以外の記事 69 1. はじめに 一般にユーザーは、ネットワークアドレスのエイリアスであるネットワーク ホスト名(人が読み取り可能なテキスト文字列)を使ってサービスを見つける。 サービス・ロケーション・プロトコルはユーザに、ネットワークホストがサ ポートしているサービス名を知っておく必要を無くす。むしろ、ユーザがサ ービスを指定し、サービスを表す属性セットを与える。サービス・ロケーシ ョン・プロトコルは、ユーザがサービスのネットワークアドレスにこの記述 をバインドすること許す。 サービス・ロケーションはローカル・エリア・ネットワーク内のアプリケー ションに動的な構成メカニズムを提供する。それはインターネット全体に対 してグローバルな決定方式ではなく、むしろサービスを共有する企業ネット ワークに役立つことを意図している。アプリケーションは、時には遠隔地の 企業ネットワークに接続されたサービスを発見する必要があるクライアント として作成される。 多くの異なるクライアントや利用可能なサービスがある場合、プロトコルは 広告されたサービスのために、集中化されたリポジトリを提供する直ぐ近く のディレクトリ・エージェントが使われるようにする。 2. 専門用語 ユーザ・エージェント (User Agent, UA) サービス属性と構成を取得するためにユーザの定義に基づき 動作しているプロセス。ユーザ・エージェントはサービス・ エージェント、あるいはディレクトリ・エージェントからサ ービス情報を取り出す。 サービス・エージェント (Service Agent, SA) サービス属性と構成を広告するために1つ以上のサービスの定 義に基づき動作しているプロセス。 サービス情報 (Service Information) 単一サービスと結合した属性の集合や構成情報。サービス・ エージェントはサービス自体の集合のために、サービス情報 を広告する。 Veizades, et. al. Standards Track [Page 3] RFC 2165 Service Location Protocol June 1997 サービス (Service) サービスは、ネットワークに機能を提供するプロセス、また はシステムである。サービス自身は、サービス・ロケーショ ン・プロトコルに対して外部の通信メカニズムを使ってアク セスされる。 ディレクトリ・エージェント (Directory Agent, DA) 効率的なアクセスをするために、ユーザー・エージェントに より、情報を集中化したサービス情報の単一リポジトリを提 供するサービスエージェントからの情報を収集するプロセス。 与えられたホスト毎にただ1つのDAがある。 サービスタイプ (Service Type) 個々のサービスタイプはユニークなサービスタイプ文字列を 持つ。サービスタイプは、予期される属性、値、及びプロト コルの振る舞いを含む"サービススキーム"と呼ばれるテンプ レートを定義する。 命名局 (Naming Authority) サービスタイプや属性により与えられたカタログの仲介やグ ループ。デフォルトの命名局はIANA(Internet Assigned Numbers Authority)である。 キーワード (Keyword) サービスの特徴を説明している文字列。 属性 (Attribute) サービスの特徴を説明している文字列の組(クラス、値のリ スト)。もし値の文字列が特定の形式を取るなら、ブーリア ン、整数、あるいは不明な値と解釈される(20.5参照)。 述部 (Predicate) 属性、関係、及び論理演算子のブーリアン表現。述部は、特 定の要求を満たすサービスを見つけるために用いられる。 5.3を参照。 英数字 (Alphanumeric) 'a'から'z'と、'A'から'Z'の範囲の文字。 範囲 (Scope) 論理的なグループを作るサービスの集合。3.7と16を参照。 Veizades, et. al. Standards Track [Page 4] RFC 2165 Service Location Protocol June 1997 サイト・ネットワーク (Site Network) サイト内の全ホストに到達するための充当する値を持たない エージェントのマルチキャスト範囲内において、アクセス可 能な全ホスト(22章を参照)。サイトがマルチキャストをサポ ートしていない場合、エージェントのサイトネットワークは 単一サブネットに限定される。 URL ユニバーサル・リソース・ロケーター - [6]を参照。 アドレス定義 (Address Specification) エージェントを指定するためのネットワーク層プロトコル依 存メカニズム。インターネットシステムのためのURLの一部。 2.1. 表記法の定義 CAPS 全て大文字で表現する文字列は厳密なプロトコル定数である。こ の場合、全文字列の比較は無意味である(5.5参照)。幾つかの文 字列は本ドキュメント内で、定義通りに使用されるように値が付 けられている。''(アポストロフィ)内の1文字は定数として使用 される。 <> この記号で設定する値は20章で詳しく記述されている。一般にメ ッセージ内の項目の全定義は20章で記述されているか、これ以降 で最初に使用される際に説明されている。 | | \ \ この表記法のメッセージレイアウトは可変長のフィールドを示 | | す。 2.2. サービス情報と述部表現 サービス情報はテキスト形式で表現される。目標は人が読み取り可能な形式 で電子メールで伝達することである。ネットワーク・サービスの位置は、人 が読み取り可能な形式のユニバーサル・リソース・ロケーター(URL)として エンコードされる。データグラム・ヘッダのみが、人が読み取り不可能な形 式でエンコードされる。サービス・ロケーション・プロトコルで使用される 文字列はNULLターミネートではない。 5.4にあるように、述部はキーワード、属性、論理的な接続語を使用し、簡 単なブーリアン表記法で表現される。 論理的な接続語と副表現は、最初に接続語がきて、次にそれを操作する表現 がくるようにプレフィックス・オーダーで表現される。 Veizades, et. al. Standards Track [Page 5] RFC 2165 Service Location Protocol June 1997 2.3. 言語仕様 本ドキュメントでは、特定の要求事項を意味する幾つかの単語を使用する [8]。これらの単語は大文字で書かれる。 MUST この単語、もしくは"要求される"という形容詞は、定義が仕 様上無条件で必要であることを意味する。 MUST NOT この表現は定義が使用上禁止であることを意味する。 SHOULD この単語、もしくは"する必要がある"という形容詞は、幾つ かの状況において、この項目を無視する有効な理由が存在す るかもしれないということを意味するが、完全な実装は理解 されなければならなく、異なる方法を選択する前に慎重に検 討する必要がある。さもなければ、不意の結果を招く。 MAY この単語、もしくは"選択できる"という形容詞は、この項目 が選択肢の中で許された組の1つであることを意味する。こ のオプションを含まない実装は、オプションを含む他の実装 を使用して相互運用しなければならない。 silently discard 実装はデータグラムを処理せずに、また送信側にエラーを返 さずにデータグラムを捨てる。実装は捨てられたデータグラ ムの内容を含むエラーロギング機能を提供し、カウンタを使 用してイベントを記録すべきである。 3. プロトコル概要 サービス・ロケーションでの基本操作は、クライアントがサービスの位置を 発見することを試みることである。小規模な設備では、個々のサービスは、 個々のクライアントに個別に応答する構成になる。大規模な設備では、サー ビスが1つ以上のディレクトリ・エージェントを使用してそのサービスを登 録し、クライアントはサービス・ロケーション情報の要求を満たすために、 ディレクトリ・エージェントとコンタクトを取る。クライアントは前の構成、 DHCP[2,11]、ディレクトリ・エージェント・ディスカバリのマルチキャスト アドレスへのクエリーの発行によって、ディレクトリ・エージェントの所在 を発見することができる。 Veizades, et. al. Standards Track [Page 6] RFC 2165 Service Location Protocol June 1997 3.1. プロトコル処理 下図は、下記に示された内容の関係を示す。 +----------------+ この情報が欲しい: +-----------+ |アプリケーション| - - - - - - - - - - - -> | サービス | +----------------+ +-----------+ /|\ | | | +------------+ | | | | \|/ \|/ \|/ +---------------+ +------------+ +----------------+ | ユーザ |<-------->| サービス | | UA要求に | | エージェント | |エージェント| | 答えない | +---------------+ +------------+ | サービス | | | | エージェント | | \|/ +----------------+ | +--------------+ | +---------------->| ディレクトリ |<----------+ | エージェント | +--------------+ ___________ /|\ / 多くの他の\ +---------->| SA | \___________/ 下記に、サイトのネットワーク上でサービスを見つけるために、ユーザ・エ ージェントが利用する操作を示す。ユーザ・エージェントはネットワーク接 続を開始する際に配置する必要ない。ユーザ・エージェントは、ユーザのニ ーズに合ったサービスを説明する述部を構成する情報を取得することができ る。ユーザ・エージェントはサービス情報が広告されているサービス・エー ジェントを見つけるために、早期にネットワーク要求で受け取った情報を構 築することができる。 ユーザ・エージェントは2つの方法で操作する: ユーザ・エージェントが既 にディレクトリ・エージェントの位置を取得している場合、ユーザ・エージ ェントは特定のリクエストを解決するためにリクエストとしてユニキャスト を行う。ディレクトリ・エージェントはユーザ・エージェントへの応答をユ ニキャストする。ユーザ・エージェントは応答が得られるまで、ディレクト リ・エージェントに対してリクエストをリトライする。従って、ディレクト リ・エージェントがリクエスト(情報を持たないと言っている)をサービスで きない場合は、エラーコードを設定することが可能であれば、値が0の戻り 値を返さなければならない。 ユーザ・エージェントがディレクトリ・エージェントの情報を持たない、あ るいはサイトネットワークで利用可能なディレクトリ・エージェントが存在 しない場合は、2つ目の発見の方法が取られる。ユーザ・エージェントは、 応答からサービスの位置を突き止めるために、サービス指定マルチキャスト アドレスにリクエストとしてマルチキャストを行う。このマルチキャストア ドレスを聞いている全サービス・エージェントが、ユーザ・エージェントの 要求を満たすように応答され、かつ供給される。 Veizades, et. al. Standards Track [Page 7] RFC 2165 Service Location Protocol June 1997 同様のメカニズムがディレクトリ・エージェントディスカバリーで使用され ている; 5.2を参照。ユーザ・エージェントのための情報を持たないサービ ス・エージェントは応答してはいけない。 ユーザ・エージェントがクエリーを満たす全サービスの一覧取得を望む際は、 再送/収束アルゴリズムが使用される。ユーザ・エージェントは前応答者の リストと一緒にリクエストを再送する。リストに存在しないサービス・エー ジェントのみが応答する。リクエストに対する新しいレスポンスが存在しな い場合、レスポンスの蓄積は完全だと考えられる。リクエスト長に依存し、 単一データグラム内に約60の前の応答者をリストすることができる。もしこ れより多い応答者が存在するなら、3.7に記述のあるスケーリングメカニズ ムを使用する。 一方、規則というより例外的に、サービスを発見するための(ディレクトリ ・エージェントのような)マルチキャスト/収束モデルは重要であるかもしれ ない。一旦ユーザ・エージェントがディレクトリ・エージェントの位置を知 ると、ユニキャスト要求/応答処理が使用される。 サービス・エージェントはサービス指定マルチキャストアドレス上のマルチ キャスト要求のため聞いておくべきであり、利用可能なディレクトリ・エー ジェントを登録しなければならない。このディレクトリ・エージェントは TCP、あるいはUDPを使用してユニキャストされたユーザ・エージェントから の要求を解決する。これはディレクトリ・エージェントが最初にDHCP、DAデ ィスカバリー・マルチキャストアドレス、上記のマルチキャストメカニズム、 あるいはマニュアル構成を使用して発見されなければいけないことを意味す る。5.2を参照。 マルチキャスト要求に応答しないサービス・エージェントは、ディレクトリ ・エージェントが無いため有用ではない。特に軽量の実装が必要ならば、幾 つかのサービス・エージェントはこの機能を含まないかもしれない。 サービスが利用不可能になった場合、ディレクトリ・エージェントによりサ ービスの登録を取り消すべきである。ディレクトリ・エージェントは、登録、 あるいは登録取消のどちらも認証をもって応じる。サービス登録は寿命と満 了期間を含む。サービス登録は寿命が来る前に、サービス・エージェントに よりリフレッシュする必要がある。必要ならば、サービス・エージェントは サービスを供給するための権限を証明するために署名したURLを広告するこ とができる。 3.2. スキーム ネットワーク上でリソースにアクセスするためのクライアントとして設計さ れたサービス・ロケーション・プロトコルは、ユニバーサル・リソース・ロ ケーター(URL)の自然なアプリケーションである。URL指定を再利用すること と、ワールド・ワイド・ウェブ(WWW)技術により、クライアントとサーバが より柔軟になり、既存のコードを使用できることを意図する。 Veizades, et. al. Standards Track [Page 8] RFC 2165 Service Location Protocol June 1997 更に、クライアントが様々な環境に依存したサービスのためのリクエストを 動的に組み立てることができるように、ブラウザはロケーター形式の類似点 を利用して記述されることを望む。 3.2.1. URLスキーム "service:" サービスURLスキームはサービス・ロケーションにより利用される。これは サービス・ロケーションを指定するために使用される。多くのサービスタイ プは"service:"スキーム名の後に、スキーム名を含んだ形で命名される。サ ービスタイプは、DAがサービスを登録/登録取消するためSAにより使用され る。また、サービスの応答をUAに戻すためにSAとDAで使用される。"service:" URLスキームの形式は20.2に記述がある。"service:"スキームに続く情報の 形式は、後続のURL構造と、IETF標準化プロセスで正式になったセマンティ クスと密接であるべきである。 良く知られているサービスタイプはIANAにより登録されており、テンプレー トとしてRFCが利用可能である。プライベートなサービスタイプもサポート される。 3.3. 標準属性定義 サービス・ロケーション・プロトコルで使用されているサービスタイプは以 下のように記述しなければならない。 サービスのサービスタイプ文字列 属性とキーワード 属性定義と説明 IANAで登録されなかったサービスタイプは、独自の命名局文字列を使用する。 新しいサービスタイプの登録過程を[13]に記述する。 特定のサービスタイプを広告するサービスは、標準化された属性の完全な集 合をサポートしなければならない。それらは標準セットの範囲を超えて、追 加の属性をサポートできる。認識できない属性はユーザ・エージェントによ り無視されなければならない。 "x-"で始まるサービスタイプ名は、幾つかの公式に登録されたサービスタイ プ名と矛盾しないことが保証される。試験的に、あるいはプライベートなサ ービスタイプ名をこのプレフィックスに使用することを提案する。同様に、 "x-"で始まる属性名は幾つかの公式に登録された属性名として使用されない ことが保証される。 与えられたサービスタイプのサービスは、暗黙定義されたネットワーク化プ ロトコルに適応すべきである。サービスタイプがマルチプロトコルに適応し ている場合、構成情報がサービスタイプ属性情報の中に含まれるべきである。 Veizades, et. al. Standards Track [Page 9] RFC 2165 Service Location Protocol June 1997 この構成情報は、サービスと直接接続するサービス要求と属性要求の結果を 使用するアプリケーションを作成可能にする。 サービス・ロケーション・プロトコルで使用されているサービスタイプ文字 列のフォーマットについては20.2.1を参照のこと。 3.4. 命名局 サービスの命名局は、サービス・ロケーションにより登録、規定されたサー ビスタイプの意味と属性を定義する。命名局自体は組織をユニークに識別す る文字列である。IANAで提供されている文字列が無い場合はそれがデフォル トとなる。IANAはInternet Assigned Numbers Authorityを意味する。 命名局は試験的な、所有権のある、あるいは私的利用するサービスタイプを 定義することができる。利用手順は'ユニークな'命名局文字列を生成し、上 記の標準属性定義を明示することである。この命名局は、5章と9章で記述さ れているように登録とクエリーを伴う。 3.5. サービス・ロケーション応答の解釈 応答は配送時間において有効であると考えるべきである。しかし、サービス は、応答時間とアプリケーションがサービスを利用するために捜し求める瞬 間との間に、失敗、あるいは変化するかもしれない。サービス・ロケーショ ンを使用するアプリケーションは、提供されたサービス情報が新鮮ではない、 あるいは不完全であるという可能性があるため、心構えをしておく必要があ る。この場合、提供されたサービス情報は、ユーザ・エージェントが望んだ サービスに接続することを許可せず、サービス要求、あるいは属性要求は再 送されるかもしれない。 サービス特有の構成情報(使用されるプロトコルなど)はサービス・レジスト レーション内の属性情報として含まれるべきである。これらの構成属性は、 サービス・ロケーションの応答を解釈するアプリケーションに使用される。 3.6. サービス・ロケーションでのTCP, UDP, マルチキャストの利用 サービス・ロケーション・プロトコルは、伝送プロトコルにUDP(コネクショ ンレス)、あるいはTCP(コネクションあり)での実装を要求する。後者は大き な転送において、必要な時にのみ使用される。接続は応答中のディレクトリ ・エージェントではなく、常にエージェント要求、あるいは登録により開始 される。サービス・エージェントとユーザ・エージェントは、転送している 情報にサービス・ロケーションポート427のように短命なポートを使用する。 Veizades, et. al. Standards Track [Page 10] RFC 2165 Service Location Protocol June 1997 一般的に、サービス・ロケーションディスカバリーメカニズムは、利用可能 なサービスと接続する必要のある多くの企業ネットワークにメッセージをマ ルチキャストする。プロトコルは3.6.1に詳述した制限で、ブロードキャス ト環境で動作する。 3.6.1. マルチキャスト対ブロードキャスト サービス・ロケーション・プロトコルは、DHCPが利用可能な、あるいはネッ トワーク層でマルチキャストがサポートされたネットワークで利用されるよ うに設計されている。ネットワーク層でブロードキャストがサポートされて いる場合に、このプロトコルをサポートするには以下の手順に従う。 3.6.1.1. 単一サブネット ネットワークが他のネットワークと接続していない場合、シンプルなネット ワーク層ブロードキャストはマルチキャストの代わりに動作する。 サービス・ロケーションポートにブロードキャストされたサービス・ロケー ションの要求メッセージを、サービス・エージェントは聞くべきであり、デ ィレクトリ・エージェントは聞かなければならない。このことは、単一サブ ネット上でサービス・ロケーションを使用するマルチキャスト機能が欠如し たUAを許可する。 3.6.1.2. 多重サブネット ディレクトリ・エージェントは、ユーザ・エージェントに中心となる情報の クリアリングハウスを提供する。ディレクトリ・エージェントのアドレスが、 個々のユーザ・エージェントとサービス・エージェントにより静的に構成す るようにネットワークが構成されている場合、ディレクトリ・エージェント は、異なるサブネットに属する情報のためにブリッジとして動作する。ディ レクトリ・エージェントのアドレスは、DHCPを使用しているエージェントに より動的に構成することができる。また、そのアドレスは静的な構成により 決定することもできる。 多重サブネットを使用したブロードキャスト環境では、動的な発見は実現不 可能であり、また手動構成は困難であるため、多重サブネットを企業に供給 する配置済みDAは、多重ホップを使用したマルチキャストディスカバリーの 使用を必要とする(つまり、IPヘッダ内でTTL > 1)。 3.6.2. サービス指定マルチキャストアドレス このメカニズムは、ある1つのサービスエージェントが受け取るデータグラ ム数を最小にするために利用される。サービス・ロケーション・ゼネラル・ マルチキャスト・アドレスは、幾つかのサービスをクエリーするために使用 されるが、サービス指定マルチキャストアドレスが存在するなら、これを使 用すべきである。 サイトネットワークがマルチキャストをサポートしていない場合、クエリー はサービス・ロケーションポートに対してブロードキャストを行うべきであ る。一方、土台となるハードウェアが必要なマルチキャストアドレス数をサ ポートしない場合。サービス・ロケーション・ゼネラル・マルチキャスト・ アドレスが使用される。 Veizades, et. al. Standards Track [Page 11] RFC 2165 Service Location Protocol June 1997 サービス・エージェントは、サービスタイプのためのサービス指定マルチキ ャストアドレスを広告するだけでなく、このマルチキャストを聞かなければ ならない。 サービス指定マルチキャスト・アドレスは、サービスタイプ文字列上の文字 列ハッシュを算出することにより計算される。サービスタイプ文字列は、ど のような文字セットからでもASCII文字列に最初に変換されなければならな いため、ハッシュは明確な解を持つ。 文字列ハッシュ機能は、Chris Torek作のコードの一部により修正される。 /* * SLPhashは指定された長さのシングルバイト文字列を、 * 0-1023の範囲のハッシュ値で返す。 */ unsigned long SLPhash (const char *pc, unsigned int length) unsigned long h = 0; while (length-- != 0) { h *= 33; h += *pc++; } return (0x3FF & h); /* 0-1023の範囲に丸める */ } この値は、IANAより割り当てられるように、サービス指定ディスカバリー・ アドレスに基づく範囲に付加される。これらは1024に隣接したマルチキャス トアドレスである。 3.7. サービス・ロケーション・スケーリングとマルチキャスト操作モード ほとんどノードの無い非常に小規模なネットワークでは、DAは必要ない。ユ ーザエージェントはマルチキャスト要求によりサービスを直接見つけること ができる。サービス・エージェントはこの時ユーザ・エージェントに応答を 返す。更に、ユーザ要求に応答するサービス・エージェントは、サービス情 報を入手可能にするために使用されなければならない。これは、多くのホス トとサービスを持つ環境には合わない。 仲介するサービス・ロケーションシステムがネットワークを分割すると、主 要なリポジトリ(ディレクトリ・エージェント)は、ネットワーク基盤に送ら れるサービス・ロケーションメッセージ数を減らすことができる。主要なリ ポジトリは全てのサービスと属性要求に応答できるため、わずかなサービス と属性応答が必要である。このような理由から、ディレクトリ・エージェン トを区別するという必要性は無い。 サイトもそのようなサイズになるかもしれないので、1つの主なサービス情 報のリポジトリだけで運営することは不可能である。 Veizades, et. al. Standards Track [Page 12] RFC 2165 Service Location Protocol June 1997 この場合はより多くのディレクトリ・エージェントが必要である。幾つかの ディレクトリ・エージェントにより広告されたサービス(とサービスエージ ェント)は、"スコープ"と呼ばれる論理的なグループに一緒にまとめられる。 スコープを持つ全てのサービス登録は、既にあるか、後で発見されるスコー プの全ての(適切なマルチキャストの範囲内の)DAを使用して登録されなけれ ばならない。スコープを持たないサービス登録はスコープ外のDAにのみ登録 される。ユーザ・エージェントは、スコープで使用するために配置されたDA のリクエストを作る。 たとえ特定のスコープ、あるいはスコープの組を持つDAを使用して、サービ ス・エージェントを明確に登録するために配置されていても、サービス・エ ージェントはスコープ外のDAを使用して登録されなければならない。たとえ 特定のスコープを持つDAを使用するために配置されていても、ユーザ・エー ジェントはスコープ無しでDAに問い合わせるかもしれない。これは、スコー プを持たないどのようなDAでも、利用可能な全てのサービス情報を持つとい うことである。 スコープ内のユーザエージェントは、スコープ外のDAの代わりが可能であれ ば、配置されたスコープをサポートするDAを常に使用するべきである。これ により、スコープ外のDAは乱用することができず、スケーリングの問題が発 生する。 特定のDAセットにのみ登録する特別なサービス・エージェントを配置するこ とは可能である(22.1を参照)。この場合、サービスは全ディレクトリ・エー ジェントを経由してユーザ・エージェントを利用可能でないが、何人かのネ ットワーク管理者はこの使用法を考えるかもしれない。 従って、3つの明確な動作モードがある。1つ目は管理の介在を必要としない もの。2つ目はDAが実行されることだけを必要とするもの。そして最後は、 スコープを持つ配置された全てのDAと、以下に示すサービスへ割り当てらて いるスコープの首尾一貫した戦略を必要とするものである。ユーザはこれら を使用するに当たり、適切なスコープを指示しなければならない。この管理 の作用は、ユーザとアプリケーションに、補助無しでサービスを動的に発見 することを許す。 1番目のモード(DAがない)はLANのために意図されている。2番目のモード(1 つ以上のDAを使用するがスコープを使用しない)は、ホスト数に制限のある 相互接続されたLANのグループによく当てはまる。3番目のモード(DAとスコ ープを使用する)は、SLPプロトコルがインターネットに接続された構内環境 で使用されることを許可する。 スコープ内のDAが使用される場合、それらはスコープ外の登録やリクエスト を受け付けない。スコープ外のリクエストを発行するUAは、スコープ外のサ ービスのみを発見する。可能ならば、それらはリクエストでスコープを使用 すべきであり、スコープ外のDAの好みに応じて、スコープ内でDAを使用すべ きである。大規模な構内環境では、スコープ外のDAを持つことは悪い考えで ある。それらは全ての登録を引き寄せ、結局スケーリングの問題を呈する。 Veizades, et. al. Standards Track [Page 13] RFC 2165 Service Location Protocol June 1997 これ以降のプロトコル文書は、グローバルなインターネットでサービスディ スカバリープロトコルをサポートするメカニズムを記述する。 4. サービス・ロケーション・ゼネラル・メッセージフォーマット 以下に示すヘッダは全メッセージ記述で使用され、利用されている機能に続 く"サービス・ロケーション・ヘッダ"を使用して略記される。 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Function | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |O|M|U|A|F| rsvd| Dialect | Language Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Char Encoding | XID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version(バージョン) 本プロトコルドキュメントではサービス・ロケーションプロト コルのバージョンは1である。 Function(機能) サービス・ロケーションデータグラムは、機能フィールドによ りオペレーションを識別することができる。以下に定義されて いるオペレーションを示す。 メッセージタイプ 略語 Function値 サービス要求 SrvReq 1 サービス応答 SrvRply 2 サービス登録 SrvReg 3 サービス登録取消 SrvDereg 4 サービス承認 SrvAck 5 属性要求 AttrRqst 6 属性応答 AttrRply 7 DA広告 DAAdvert 8 サービスタイプ要求 SrvTypeRqst 9 サービスタイプ応答 SrvTypeRply 10 Length(長さ) サービス・ロケーション・ヘッダを含んだメッセージのバイト 数。 O 'オーバーフロー'用のビット。このフィールドの使用法は18章 を参照のこと。 Veizades, et. al. Standards Track [Page 14] RFC 2165 Service Location Protocol June 1997 M '言語'用のビット。このビットが設定された要求は、ユーザ・ エージェントがサービス、あるいは属性要求により示された言 語(17章を参照)でのみレスポンスに応じることを示す。 U 'URL証明提出'用のビット。このフィールドの使用法は、4.2、 4.3、9章、11章を参照のこと。 A '属性証明提出'用のビット。このフィールドの使用法は、4.2、 4.3、13章を参照のこと。 F サービス承認に'F'ビットが設定されいた場合、ディレクトリ ・エージェントは、エントリを更新するのではなく、新しいエ ントリとしてサービスを登録している。 rsvd 0でなければならない。 Dialect(通用語) Dialectタグは、使用される表現形式の変形を示すため、サー ビス・ロケーション・プロトコルの将来のバージョンで使用さ れる。このフィールドは予備で、サービス・ロケーション・プ ロトコルの将来のバージョンのために0が設定されていなけれ ばならない。 Language Code(言語コード) これ以降のメッセージの残りの文字列は、このフィールドで符 号化された(17章、及び付録 Aを参照)言語で解釈される必要が ある。 Character Encoding(文字エンコーディング) メッセージの残りの部分の文字列は、幾つかの標準化されたエ ンコーディングで符号化される(17.1を参照)。 Transaction Identifier(XID:処理識別子) XID(トランザクションID)フィールドは、要求側が個々の要求 と応答をマッチさせるために使用する(4.1を参照)。 属性認証ブロックがあれば、URL認証ブロックもあるというこ とに注意する必要がある。従って、'A'ビットが設定されてい るのに'U'ビットが設定されていない場合はエラーとなる。 4.1. トランザクションIDの利用 (XIDs) 再送はサービス・ロケーション・プロトコルで、確実なトランザクションを 保証するために使用される。ユーザ・エージェント、あるいはサービス・エ ージェントがメッセージを送信し、予期するレスポンスの受信に失敗する場 合、メッセージは再送される。同一サービス・ロケーションデータグラムの 再送は、更新されたXIDを含むはずがない。 Veizades, et. al. Standards Track [Page 15] RFC 2165 Service Location Protocol June 1997 オリジナルの要求を、DA、あるいはSAに届けるのは可能だが、応答を要求側 に届けるのには失敗する。同一XIDの使用は、DA、あるいはSAにオリジナル の要求の応答をキャッシュすることを許し、二重に要求が届くことになる。 このキャッシュされた情報は、非常に簡潔に保持されているだけである (CONFIG_INTERVAL_0)。クライアントに返された情報は常に有効となるため、 ディレクトリ・エージェントでの登録/登録取消、あるいはSAでのサービス 情報変更の際は、キャッシュをフラッシュするべきである。 要求側は内部的にランダムにXIDを生成し、要求毎にそれをインクリメント する。最終的には、XIDは0となり、そこからインクリメントし続ける。 ディレクトリ・エージェントは状態を示すために、DA広告のXIDの値を使用 する(15.2を参照)。 4.2. URLエントリ URLが登録されている場合、寿命と長さも持ち、認証される。これらの値は 登録期間としてURLと関連している。この関連は"URLエントリ"として知られ ており、以下に示す形式である。 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | Length of URL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ URL \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (if present) URL Authentication Block ..... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Lifetime(寿命) 後の登録/登録取消が無い時に、登録が有効な時間長。 Length of URL(URL長) 32769バイト以内のURLの長さ。 URL Authentication Block(URL認証ブロック) (必要ならば)タイムスタンプのある証明書(4.3を参照)。 Veizades, et. al. Standards Track [Page 16] RFC 2165 Service Location Protocol June 1997 URLはRFC1738[6]に従う。メッセージヘッダに'U'ビットが設定されている場 合、URLにはURL認証ブロックが続く。URLで使用されているスキームが標準 化された表現ではない場合の最小の要求を次に示す。 service::// "service"はサービス登録とサービス応答を含む全サービス・ロケーション 情報のURLスキームである。個々のURLエントリは service:スキー ム名を含む。これは、サービスタイプ要求に対する応答の場合を除き、 を含む。 4.3. 認証ブロック 認証ブロックは認証サービスを登録/登録取消するために使用する。URLは、 URLエントリを含まれたサービス応答を受信するユーザ・エージェントが、 次に使用するURLエントリに認証情報を保持するため、URL認証ブロックと共 に登録される。サービス属性は属性認証ブロックと共に登録される。両認証 ブロックは下記に記述する形式である。 サービス登録がDAにより認証された証明を伴っている場合、DAは権限の無い エントリが登録されたサービスを無効にできないように、後のいかなるサー ビス登録取消を確認しなければならない。同様に、サービス登録がDAにより 認証された属性認証ブロックを伴っている場合、DAは権限の無いエントリが、 登録された属性を無効にできないように、後のいかなる属性登録を確認しな ければならない。 前もって認証された登録取消を使用した再送攻撃を避けるために、登録取消、 あるいは属性登録メッセージは、DAにより使用されるタイムスタンプを含ま なければならない。有効な登録取消を無効にするために、前もって認証され た登録を使用した再送攻撃を避けるために、登録もタイムスタンプを含まな ければならない。 Veizades, et. al. Standards Track [Page 17] RFC 2165 Service Location Protocol June 1997 認証ブロックは以下のフォーマットである。 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Timestamp + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Block Structure Descriptor | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Structured Authenticator ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Timestamp(タイムスタンプ) ネットワーク・タイム・プロトコル(NTP)で指定された64ビッ ト値[16]。 Block Structure Descriptor(BSD:ブロック構造記述子) 認証者の組織の記述。オブジェクト識別子として、現在定義さ れている値は1のみ。 Length(長さ) Authenticator(認証者)の長さ。 Structured Authenticator(構造化した認証者) アルゴリズムの仕様と、そのアルゴリズムにより作られた認証 データ。 構造化した認証者は、認証情報のデジタル署名を含む。このデジタル署名は アルゴリズムを決定するのに十分な情報と、デジタル署名を検証するために 選択されたキーを含んでいる。 デジタル署名は、以下に示す規則正しいデータストリームにより計算される。 CHARACTER ENCODING OF URL (ネットワークバイトオーダーで2バイト) LIFETIME (ネットワークバイトオーダーで2バイト) LENGTH OF URL (ネットワークバイトオーダーで2バイト) URL (nバイト) TIMESTAMP (SNTP形式で8バイト[16]) Veizades, et. al. Standards Track [Page 18] RFC 2165 Service Location Protocol June 1997 URL認証ブロックを生成する際に、構造化された認証者に確認されたアルゴ リズムから生成された認証データは、以下に示すデータストリームとして計 算される。 ATTRIBUTE CHARACTER ENCODING (ネットワークバイトオーダーで2バイト) LENGTH OF ATTRIBUTES (ネットワークバイトオーダーで2バイト) ATTRIBUTES (nバイト) TIMESTAMP (SNTP形式で8バイト[16]) 保護スコープで使用されるために構成された、全てのサービス・ロケーショ ン・プロトコル自体(ユーザ・エージェント、サービス・エージェント、デ ィレクトリ・エージェント)は、"md5WithRSAEncryption"[4]の実装と、BSD 値を1にすることによりこの暗号を関連付けることができるようにすべきで ある。 BSD値が1で、OIDとして"RSA暗号法を使用したmd5"が選択される場合、その バイト値を持つ"RSA暗号法を使用したmd5"のために、構造化した認証者は、 ASN.1 卓越した符号化(DER)[9]で始まる(16進数で最初のMSB)。 "30 0d 06 09 2a 86 48 86 f7 0d 01 01 04 05 00" これは直ちに、上記フィールド上で計算されたMD5[22]メッセージダイジェ ストにより連結される"MD5"のためのOIDから成るビット列の(スコープの秘 密鍵を使用した)RSA暗号化の("ビット列"として)ASN.1 卓越した符号化に より続けられる。MD5 OIDとダイジェストの正確な構成はRFC1423[4]に記述 されている。 4.4. URLエントリの寿命 Lifetimeフィールドに応答の秒数が設定されると、どのようなエージェント にでもキャッシュさせることが可能となる。値が0ということは、情報をキ ャッシュしてはいけないことを意味する。ユーザ・エージェントはサービス 情報をキャッシュするかもしれないが、この様な場合エージェントはアプリ ケーションに、キャッシュされた情報をフラッシュし、ネットワーク上に直 接要求を発行するための方法を提供しなければならない。 サービスはLifetimeを持つDAによって登録されるべきで、CONFIG_INTERVAL_1 が提案されている。サービスはこの間隔が経過する前、あるいはサービス広 告が利用できなくなる前に再登録されなければならない。従って、最終的に は、消滅した、あるいは登録取消に失敗したサービスは、自動的に登録取消 となる。 5. サービス要求メッセージフォーマット サービス要求は、ディレクトリ・エージェントやサービス・エージェントか らURLを取得するために使用される。 Veizades, et. al. Standards Track [Page 19] RFC 2165 Service Location Protocol June 1997 サービス要求のフォーマットを以下に示す。 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Location header (function = SrvReq) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |length of prev resp list string|| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of predicate string | Service Request | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ Service Request , contd. \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UAが巨大な応答を結果として返すような要求を発行する場合、SA、あるいは DAは'オーバーフロー'ビットを設定し短縮された応答(サイトのMTUのデータ グラムサイズ)を返す。UAはTCPを使用して要求を再度発行しなければならな い。 は7章と20.1に記述がある。 ユーザ・エージェントがリスタート後(システムリブート後、ネットワーク カーネルのロード後をいう)、サービス要求は、1秒間隔以内の設定された遅 延値(デフォルトはCONFIG_INTERVAL_4)で均一に分布したあるランダム時間 遅延すべきである。 サービス要求はユーザ・エージェントに、サービスのサービスタイプを指定 することと、特定言語で述部を指定することを許す。サービス要求の一般的 なフォームを以下に示す。 [.]/[]/[]/ 省略されたフィールドにも区切りが必要である。 - はサービスタイプを参照する。利用可能なサービスの個々の 型で、ユニークなサービスタイプ名文字列。20.2.1を参照のこと。 Veizades, et. al. Standards Track [Page 20] RFC 2165 Service Location Protocol June 1997 - は命名局である。この文字列は、サービス要求の内の属性 情報の意味解釈を決定する。 - はクエリーの範囲を限定するために使用される文字列である。 スコープは与えられたサイトで管理上決定される。これは必ずしもネッ トワークトポロジーと関係するわけではない(16章参照)。このフィール ドを省略すると、スコープ外のサービス広告にのみ満足したリクエスト であるということを意味する。 - 文字列は要求の場所を示す。これはユーザ・エージェントが興 味のあるサービス例の選択を許すクエリーを含む。要求は属性、ブー リアン演算子、関係を含む(5.3を参照)。 マルチキャストサービス要求の場合は、前の応答者のリストが送られる。こ のリストは応答リスト内にある要求を防止するが、他のソースからの応答は かき消されない。要求は新しい応答が無い、あるいは一定の時間 (CONFIG_INTERVAL_3)が経過するまで、繰り返し(CONFIG_INTERVAL_2間隔待 つことを推奨)マルチキャストする。値は別々のタイミングでディレクトリ ・エージェント・ディスカバリーを使用してサービス要求に適用される。 5.2を参照。 リクエストがマッチしている登録された情報に成功するには、以下の条件が 満たされているに違いない。 1. 結果は要求の時と同じサービスタイプを持たなければならない。 2. 結果は同じ命名局を持たなければならない。 3. 結果は同じスコープを持たなければならない。(要求のスコープが省略 された場合、要求はスコープ無しで登録されているサービスとマッチす るだけである。スコープされた要求は、全てのスコープ無しのサービス とマッチすることに注意すること。) 4. で指定された条件は、サービスに登録された属性、及びキーワ ードとマッチしなければならない。 Veizades, et. al. Standards Track [Page 21] RFC 2165 Service Location Protocol June 1997 5.1. サービス要求の使用法 ユーザ・エージェントは、前に形成されたサービスタイプの属性の情報を使 用しサービス要求を形成する。ユーザ・エージェントは、サービス要求を発 行する前に、サービスタイプの属性値を取得するために属性要求も発行する (13章を参照)。属性要求から特定のサービスの種類を記述した属性を得るこ とにより、また、配置されたサービスの属性情報を使用することにより、ユ ーザ・エージェントはユーザが必要とするサービスを説明する述部を作るこ とができる。 サービス要求はディレクトリ・エージェントに直接送られる。lprプロトコ ルをサポートしているプリンタで、UNRESTRICTED_ACCESS、かつ毎分12ペー ジ印刷できる12階にあるプリンタを考える。また、属性要求が示す、12階に あるプリンタ、毎分12ページ印刷するプリンタ、UNRESTRICTED_ACCESSで提 供するプリンタが遠くにあると仮定する。それらが同じプリンタかどうかを チェックするためには、以下のリクエストを発行する。 lpr//(& (PAGES PER MINUTE==12) (UNRESTRICTED_ACCESS) (LOCATION==12th FLOOR))/ このようなプリンタが存在しないことを仮定するした場合、ディレクトリ・ エージェントは、レスポンス番号0のサービス応答と、戻り値無しで応答す る。 ユーザ・エージェントは、この時プリンタを見つけるために、"where(場所)" の尺度として12階を使用し、それ程制限的ではないクエリーを試みる。 lpr//(LOCATION==12th FLOOR)/ この場合、1つの応答が返る。 Returned URL: service:lpr://igore.wco.ftp.com:515/draft プリンタのアドレス指定は、要求されたプリンタを管理しているホスト名を 含む igore.wco.ftp.com:515である。ファイルはそのホストのポートにスプ ールすることにより印刷される。'draft'は、lprサーバがサポートするプリ ントキュー名を指す。 Veizades, et. al. Standards Track [Page 22] RFC 2165 Service Location Protocol June 1997 ディレクトリ・エージェントが存在しない場合、上記のリクエストはマルチ キャストされる。この場合、リクエストはディレクトリ・エージェントでは なく、"service:printer"のサービス指定マルチキャストアドレスに送られ る。述部を満たすことができるサービス・エージェントは応答を返す。リク エストの文字セットをサポートできないサービス・エージェントは、SvrRply でCHARSET_NOT_UNDERSTOODを返さなければならない。その他全ての状況にお いて、応答を満たすことができないサービス・エージェントは、応答を全く 送らない。 ユーザ・エージェントが、クエリーにマッチするサービスが無いと確信でき る唯一の方法は、リクエスト(CONFIG_INTERVAL_8)をリトライすることであ る。レスポンスが無い場合、ユーザ・エージェントは諦め、そのようなプリ ンタは無いと仮定する。 クエリーの他の表現方法は、'join'クエリーである。そのシンタックスは括 弧や論理演算子を全く持たない。個々の用語は(全体的にANDで)結合される。 最初のクエリーを書き直した例を示す。 lpr//PAGES PER MINUTE==12, UNRESTRICTED_ACCESS, LOCATION==12th FLOOR/ 5.2. ディレクトリ・エージェント・ディスカバリー要求 通常、サービス要求はサービス応答を返す。この唯一の例外は、サービスタ イプが"directory-agent"のサービス要求である。このサービス要求はDA広 告で応答される。 ディレクトリ・エージェント(DA)の配置された情報が無ければ、ユーザ・エ ージェントやサービス・エージェントは、DAを発見するためにサービス要求 を使用する。(DAの情報を持つためにクライアントが配置するメカニズムに ついては15.1を参照のこと。)ディレクトリ・エージェント・ディスカバリ ーに使用されるそのようなサービス要求は、フォームの述部を含む。 directory-agent/// このクエリーは、常にディレクトリ・エージェント・ディスカバリーマルチ キャストアドレスに送信される。ディレクトリ・エージェントのサービスタ イプは"directory-agent"であり、リクエスト内で使用されるサービスタイ プである。スコープは要求には含まれないため、全てのディレクトリ・エー ジェントが応答する。これは、全ディレクトリ・エージェントが応答しなけ ればならないスコープを省略する最適な要求である。通常、スコープを持つ ディレクトリ・エージェントは、そのスコープを使った要求に応答するだけ である。命名局は含まれないため、"IANA"が想定される。我々は、利用可能 な全ディレクトリエージェントに到達したい。スコープが提供される場合、 そのスコープをサポートするDAのみが応答を返すはずである。 Veizades, et. al. Standards Track [Page 23] RFC 2165 Service Location Protocol June 1997 DA広告応答は、次のフォームに類似する様々なソースから来るかもしれない。 返されるURL: service:directory-agent://slp-resolver.catch22.com 返されるScope: ACCOUNTING 返されるURL: service:directory-agent://204.182.15.66 返されるScope: JANITORIAL SERVICES DA広告フォーマットは14章に記述される。 目的が単に何らかのディレクトリ・エージェントを発見することであれば、 最初の応答を処理する。しかし、目的が到達可能な全DAを発見することであ れば、リクエストはある間隔後(CONFIG_INTERVAL_5を推奨する)再送されな ければならない。この再送されたリクエストは、既に応答していたDAのリス トを含む。7章と20.1を参照のこと。既に応答していたDAのリストが無い場 合、リクエストを受信したディレクトリ・エージェントは、応答するだけで ある。新しい応答が全く無くなると、全DAが発見されたと仮定する。 DAがCONFIG_INTERVAL_6秒後、応答に失敗した場合、UA、あるいはサービス ・エージェントは別のDAを使用すべきである。DAのアドレスは、以前のディ スカバリー試行や以前の配置から、あるいはDHCPを使用してキャッシュされ る(15.2を参照)。そのようなDAが応答しない場合、DAディスカバリーは新し いDAを見つけるために使用されるべきである。わずかCONFIG_INTERVAL_7秒 が経過するだけで、存在するDAが無いということを想定し、マルチキャスト をベースにしたサービス要求が使用されるべきである。 5.3. 述部文法の用語説明 要素を区切る括弧、コンマ、スラッシュに依存する述部は簡単な構造を持つ。 正しい使用例を本ドキュメントを通して記述する。文法で使用する用語は次 の通りである。 predicate: サービス要求に置かれ、どのような情報を返すかを決めるために、サ ービス・エージェント、あるいはディレクトリ・エージェントにより 解釈される。 scope: サービス要求にこれが存在しない場合、リクエストはスコープ無しで 登録されたサービスとのみマッチする。存在する場合、スコープ下で 登録されたサービスのみ、あるいはスコープされていないサービスが、 リクエストとマッチする。 Veizades, et. al. Standards Track [Page 24] RFC 2165 Service Location Protocol June 1997 where-clause: どのサービスが要求にマッチするかを決める。where-clauseが空の場 合、全てのサービスとマッチする。要求は特定のサービスタイプを持 つサービスに制限されるため、where-clauseがどのサービスの要求と マッチしているか選び出す唯一の要因ではない。 where-list: where-listは論理式である。これは単一表現、分離、あるいは結合か もしれない。単一表現は、where-clauseとマッチするように当てはめ なければならない。ORリストの表現がマッチするならば、分離はマッ チする。ANDリストの全要素がマッチするならば、結合はマッチする。 論理否定演算子が無いことに注意すること。これは、与えられた標準 とマッチする"全てを除く"というものを返す概念が無いためである。 where-listはネストと複文が可能である。3つの個々の式全てが真で あるに違いないという例を以下に示す。 (& (| ) (& ) ) スペース、タブ、キャリッジ・リターンは、query-itemsの外側のど こにでも付加することができることに注意すること。各リストは2つ 以上の項目を持ち、リストはネストが可能である。全体の論理式を満 たすサービスはwhere-clauseとマッチする。 古い表現だが、許容されるべきである。これらはと同義 語である。 query-item: クエリー項目形式: '(' ')' または、 '(' ')' Veizades, et. al. Standards Track [Page 25] RFC 2165 Service Location Protocol June 1997 この例を示す。 (SOME ATTRIBUTE == SOME VALUE) (RESERVED) (QUEUE LENGTH <= 234) query-join: query-joinは、クエリーとマッチするようにサービスが満足しなけれ ばならない、コンマで区切られた条件リストである。項目は論理的に 結合すると考えられる。query-joinはこのようになる。 ATTR1=VALUE1, KEYWORD1, KEYWORD2, ATTR2>=34 は、以下のwhere-listと等しい。 (& (ATTR1=VALUE1) (KEYWORD1) (KEYWORD2) (ATTR2>=34)) query-joinはwhere-listと混ぜて使用することはできない。これは、 論理式を組み立てずに必要な条件文を提供するための、都合の良いメ カニズムとして提供される。 5.4. サービス要求述部文法 サービス要求は、リクエスト本体の述部を含むことより必要なサービスを正 確に記述できる。この述部は、以下に示す文法に従って構成されなければな らない。 ::= ['.']'/''/''/' ::= サービスタイプを表す文字列。英数文字と、'+'、'-'の みが許される。 ::= 命名局を表す文字列。英数文字と、'+'、'-'のみが許さ れる。このフィールドが省略された場合、"IANA"と仮定 する。 ::= ディレクトリエージェントのスコープを表す文字列。こ の文字列には、'/'、','(コンマ)、':'は使用できない。 スコープの"LOCAL"、"REMOTE"は予約語である。 ::= サービスタイプで与えられる属性のクラス名。このタグ は、エスケープ指定されたものを除き(17.1を参照)、次 の文字を含むことはできない。 '(', ')', ',', '=', '!', '>','<', '/', '*' Veizades, et. al. Standards Track [Page 26] RFC 2165 Service Location Protocol June 1997 ::= 値を持たない属性のクラス名。この文字列は、キーワー ドとして内側にスペースを記述できないという以外、 と同等の制限を持つ。 ::= | | ::= 何も無いか、スペース。 ::= '(' '&' ')' | '(' '|' ')' | '(' ')' '(' ')' ::= | ::= | | ',' | ',' ::= ::= "!=" | "==" | '<' | "<=" | '>' | ">=" ::= 様々な文字列(attr-valsが解釈される方法は20.5を参照)。 意味のある文字列は、エスケープ指定されたものを除き (17.1を参照)、'/'、','、'='、'<'、'>'、'*'を含むこ とはできない。 '('と')'は、バイナリ値をエンコードするための属性値 として使用されるかもしれない。バイナリエンコーディ ング(20.5を参照)は、上記の予約語を含むかもしれない。 5.5. 要求の文字列マッチング 全ての文字列は、クエリー上マッチしている文字列に関して無感覚である。 前にある、あるいは後ろにある空白はマッチする際に考慮されるべきではな いが、文字列の内部にある空白は適切である。 例えば、" Some String "は"SOME STRING"とマッチするが、"some string" とはマッチしない。 Veizades, et. al. Standards Track [Page 27] RFC 2165 Service Location Protocol June 1997 文字列マッチングは同一文字セットにのみ実行される。リクエストの文字セ ットがサポート不足でリクエストが満足できない場合、 CHARSET_NOT_UNDERSTOODエラーが返される。 何の言語指定規則も使用せず、('<'のような比較記号を使用して)文字列比 較や登録をする。その順序は、文字の値により厳密にされる。つまり、 US-ASCIIでは"0" < "A"が真であるので、"0"は値48を持ち、"A"は値65を持 つ。 特殊文字'*'は文字列に先行する、あるいは後続する部分文字列とのマッチ ングを認める。文字列が'*'に先行している場合、どの文字列で終わる属性 値ともマッチする。'*'を使用して文字列が終了している場合、どの文字列 で始まる属性値ともマッチする。最終的に、文字列の最初と最後が'*'の場 合は、文字列はその文字列を含むどんな属性値ともマッチする。 例: "bob*"は"bob"、"bobcat"、"bob and sue"とマッチし、"*bob"は"bob"、 "bigbob"、"sue and bob"とマッチし、"*bob*"は"bob"、"bobcat"、 "bigbob"、"a bob I know"とマッチする。 文字列のマッチングはエスケープシーケンスが代用されると終了する。17章、 5.3、17.1を参照のこと。 6. サービス応答メッセージフォーマット サービス応答メッセージのフォーマットを以下に示す。 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Location header (function = SrvRply) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Code | URL Entry count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | \ . \ | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 各サービス応答メッセージはURLエントリのリストから構成される。 Veizades, et. al. Standards Track [Page 28] RFC 2165 Service Location Protocol June 1997 エラーコードは以下に示すものの内1つをとる。 0 成功 LANGUAGE_NOT_SUPPORTED サービス情報が全く登録されていない、あるいは1カ国語だけ を使用するビットがセットされて届くリクエストにおいて、サ ポートしていない言語でUAからリクエストを受信した場合、SA、 あるいはDAはこの値を返す。17章を参照。 PROTOCOL_PARSE_ERROR 解析できない、あるいは宣言された文字列長がメッセージを超 過しているSrvRplyを受信した場合、SA、あるいはDAはこのエ ラーを返す。 SCOPE_NOT_SUPPORTED DAによりサポートされていないスコープを持つリクエストを受 信した場合、DAはこのエラーを返す。SAは単にマルチキャスト 要求に答えないため、このエラーを返さない。 CHARSET_NOT_UNDERSTOOD DA、あるいはSAがサポートしていない文字セットのリクエスト、 又は登録を受信した場合、このエラーを返す。 個々のは、4.2に定義された形式を持つ。応答にあるURLエント リは、長さフィールドを除き、エントリ間に区切り文字を全く持たない。URL の長さフィールドはURL文字列の終わりがどこかを示す。URL認証者ブロック の存在が'U'ビットで知らされている場合、認証者ブロック長は4.3に書かれ ているブロック内の情報により決定される。ユーザ・エージェントは、実際 に示されたサービスを提供するために証明されたURLを広告しているサービ ス・エージェントを決定するために、認証ブロック使用するかもしれない。 URLエントリのリスト内において、リスト内の他のURLが保護スコープでない サービスを指す間に、幾つかのURLが保護スコープ(16.1を参照)にあるサー ビスを指す場合、後者はまだ認証ブロックを持っていなければならないが、 認証者の長さは0で示され、認証をする必要はなくなる。 7. サービスタイプ要求メッセージフォーマット サービスタイプ要求は、ネットワーク上でサポートされているサービスの全 タイプを決定するために使用される。 Veizades, et. al. Standards Track [Page 29] RFC 2165 Service Location Protocol June 1997 サイトネットワーク上(ディレクトリ・エージェントとサービス・エージェ ントのどちらかに広告された)の利用可能な全てのサービスを見つけ出すた めに、リクエストは直接DA(とはいえ、サービス・ロケーション・ゼネラル ・マルチキャスト・アドレスにも送信される)に送信される。どのDAも利用 可能でない場合、ユーザ・エージェントは全ての応答を受け取ることを保証 するために、1つ以上のリクエストを発行する。次の個々のリクエストにお いて、ユーザ・エージェントはそれらのサービスタイプを含む。リクエスト からCONFIG_INTERVAL_3を含む新しい応答が届かない場合、ユーザ・エージ ェントは利用可能なサービスタイプの完全なセットを取得できたと仮定する。 サービスタイプ要求のフォーマットを以下に示す。 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Location header (function = SrvTypeRqst) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of prev resp string || +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of naming authority | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ , continued \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of Scope String | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ , continued \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ がコンマで区切られたリストであること に注意すること。(20.1を参照。) 'length of prev responder list'フィー ルドは、コンマで区切られたリスト文字列の長さを示す。3つの要素を持つ 前の応答者リストは次の形式をとる。 ,, Veizades, et. al. Standards Track [Page 30] RFC 2165 Service Location Protocol June 1997 命名局を含む場合、指定された命名局を持つサービスタイプへのサービスタ イプ要求の応答を制限する。このフィールドが省略された場合(つまり、フ ィールド長が0)、デフォルトの命名局("IANA")と仮定する。フィールド長が -1の場合、全ての命名局からサービスタイプが要求される。 Scope Stringフィールドを含む場合、指定されたスコープを持つ、あるいは スコープを持たないサービスタイプへの応答を制限する。このフィールドが 省略された場合、(指定された命名局から)全てのサービスタイプが返る。 8. サービスタイプ応答メッセージフォーマット サービスタイプ応答のフォーマットを以下に示す。 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Location header (function = SrvTypeRply) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Code | number of service types | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ サービスタイプアイテムのフォーマットを以下に示す。 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of Service Type String | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ , continued \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Veizades, et. al. Standards Track [Page 31] RFC 2165 Service Location Protocol June 1997 エラーコードは以下に示すものの内1つをとる。 0 成功 PROTOCOL_PARSE_ERROR SrvTypeRqstが解析できない応答を受信した場合、SA、あるい はDAはこのエラーを返す。 SCOPE_NOT_SUPPORTED DAがサポートしていないスコープを持つためのセットである SrvTypeRqstを受信した場合、スコープを持つために配置され たDAはこのエラーを返す。SAはこのエラーを返さず、単にマル チキャスト要求を暗黙のうちに破棄する。 CHARSET_NOT_UNDERSTOOD DAがサポートしていない文字セットでSrvTypeRqstを受信した 場合、このエラーを使用しなければならない。 サービスタイプ名はで提供される。サービスタイプ が"IANA"以外の命名局を持つ場合、以下に示すサービスタイプ文字列と、 "."文字を返すべきである。このフィールドの正規定義は20.2.1を参照のこ と。ユーザ・エージェントは、サービスタイプのハッシュを基に、サービス 指定マルチキャストアドレスを算出する(3.6.2を参照)。このマルチキャス トアドレスは、サービスと属性要求を直接SAに出す際に使用される。 サービスタイプ応答で見つかるかもしれないサービスタイプ文字列の例を以 下に示す。 service:lpr:// service:http:// service:nfs:// 9. サービス登録メッセージフォーマット サービス・エージェントがディレクトリ・エージェントを発見後、サービス ・エージェントはその広告されたサービスを一度に登録し始める。サービス ・エージェントは再登録する前に、CONFIG_INTERVAL_11により指定された範 囲内で均一に分布したあるランダム時間待たなければならない。登録はサー ビスの全属性を明記しているサービス登録メッセージを使用して行われる。 16.1 保護スコープにあるサービス登録の場合、サービスはURL認証ブロック と属性認証ブロックの両方を含まなければならない(4.3を参照)。このよう な場合、サービスエージェントは'U'ビットと'A'ビットの両方をセットしな ければならない(4章を参照)。 Veizades, et. al. Standards Track [Page 32] RFC 2165 Service Location Protocol June 1997 ディレクトリ・エージェントは各サービス登録要求を認証しなければならな い。認証ブロックが含まれている場合、ディレクトリ・エージェントはサー ビスを登録する前に認証を確認しなければならない。これは、前の構成、サ ービスエージェントを持つセキュリティ協会のメンテナンス、適切な証明書 を取得することのどれかからキー情報の取得を要求する。 サービス登録のフォーマットを以下に示す。 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Location header (function = SrvReg) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length of Attr List String | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ , Continued. \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (if present) Attribute Authentication Block ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ は4.2の終わりに、または20.3に定義されている。 メッセージヘッダ内に'A'ビットがセットされ、存在しているだけの属性認 証ブロックについては4.3に定義されている。 サービス登録はコネクションレスプロトコル(例えばUDP)や、コネクション に適応したプロトコル(例えばTCP)に使用される。登録操作が1つのデータと して送ることができる情報より、多くの情報を含んでいる場合、サービス・ エージェントはDAを使用して自分自身を登録するためにコネクションに適応 したプロトコルを使用しなければならない。サービス・エージェントが何度 もサービスインスタンスに同一属性クラスを登録する場合、ディレクトリ・ エージェントはサービス・インスタンスのために属性クラスに関連する全属 性を上書きする。個々の登録は、広告を出すサービスの各言語に対応して作 られなければならない。 SAが、DAを使用してサービスの登録を試み、その登録がサイトパスMTUより 大きい場合、DAはINVALID_REGISTRATIONと'Overflow'バイトをセットし、エ ラーとしてSrvAckを応答する。 Veizades, et. al. Standards Track [Page 33] RFC 2165 Service Location Protocol June 1997 サービス登録情報の例を以下に示す。 Lifetime (秒): 16ビット符号無し整数 URL (少なくとも): service::// Attributes (もしあれば): (ATTR1=VALUE),KEYWORD,(ATTR2 = VAL1, VAL2) 広告されたサービスを継続的に提供するために、サービス・エージェントは 登録満了になるLifetimeより前に再登録処理を開始すべきである。 サービス登録(3時間有効)の例を以下に示す。 Lifetime: 10800 URL: service:lpr://igore.wco.ftp.com:515/draft Attributes: (SCOPE=DEVELOPMENT), (PAPER COLOR=WHITE), (PAPER SIZE=LETTER), UNRESTRICTED_ACCESS, (LANGUAGE=POSTSCRIPT, HPGCL), (LOCATION=12 FLOOR) 同一の登録をドイツ語で書いたものを以下に示す。ただし、"lpr"、"service"、 "SCOPE"は予約語で、もともと(英語で)登録された言語であることに注意す ること。 Lifetime: 10800 URL: service:lpr://igore.wco.ftp.com:515/draft Attributes: (SCOPE=ENTWICKLUNG), (PAPIERFARBE=WEISS), (PAPIERFORMAT=BRIEF), UNBEGRENTZTER_ZUGANG, (DRUECKERSPRACHE=POSTSCRIPT,HPGCL), (STANDORT=11 ETAGE) スコープ内の登録はSCOPE属性を含まなければならない。スコープ外の登録 は、全てのスコープ外のディレクトリ・エージェントを使用して登録されな ければならない。 前もって登録されたサービスの登録証明書は、最新のものであると考えられ る。このような属性登録が保護スコープ(16.1を参照)で実行される場合、新 しい属性認証ブロックも含まれ、登録メッセージヘッダ内の'A'ビットがセ ットされる 新しい登録の属性は前の登録と置き換えられるが、前に含まれていた属性、 更新で存在しなくなった属性には影響しない。 Veizades, et. al. Standards Track [Page 34] RFC 2165 Service Location Protocol June 1997 例えば、属性A=1、B=2、C=3が登録されているservice:x://a.orgを考えてみ る。1つの新しい登録が属性C=30、D=40でservice:x://a.orgに来ると、更新 後のサービスの属性は、A=1、B=2、C=30、D=40となる。 上記の例では、SCOPEは(英語で)DEVELOPMENT、(ドイツ語で)ENTWICKLUNGが セットされる。メッセージ内の全文字列が、ヘッダで指定されるある言語で なければならないということを思い出しなさい。文字列SCOPEは、サービス ・ロケーション・プロトコル内の予約語であるため解釈されない(17.2を参照)。 ディレクトリ・エージェントは認証でサーバーエラーを返すかもしれない。 このエラーはサービスロケーションメッセージヘッダのエラーコードフィー ルドで伝えられる。ディレクトリ・エージェントは、未サポートのスコープ が指定された場合、サービスの登録を拒否しなければならない。この場合、 SrvAckにSCOPE_NOT_SUPPORTEDエラーが戻される。ディレクトリ・エージェ ントが、全サービス登録を受け入れなければならないディレクトリ・エージ ェントで無い限り、未サポートのスコープを持つサービス登録を受け入れて はならない。 スコープの無いサービス登録は全リクエストとマッチする。従って、特定の スコープを指定する要求は、そのようなスコープを持つサービスと、スコー プの無いサービスを返す。全登録のスコープを使用すべきであることを強く 提案する。詳しくは16章、3.7を参照のこと。 登録に伴われたURLエントリが、認証ブロック(4.3を参照)も含んでいる場合、 DAは示された認証を実行し、後でサービス認証メッセージの結果を返さなけ ればならない。 10. サービス認証メッセージフォーマット サービス認証は、サービス登録やサービス登録取消を受けたり、処理したり したDAの結果として送られる。成功を示す認証はエラーコードが0である。 一度DAがサービス登録を認証すると、情報をクライアントに利用可能にする。 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Location header (function = SrvAck) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Veizades, et. al. Standards Track [Page 35] RFC 2165 Service Location Protocol June 1997 エラーコードは以下に示すものの内1つをとる。 0 成功 PROTOCOL_PARSE_ERROR SrvRegやSrvDeregが解析できない、あるいは宣言した文字列長 を超えたメッセージを受信した場合、DAはこのエラーを返す。 INVALID_REGISTRATION SrvRegやSrvDeRegが無効である場合、DAはこのエラーを返す。 例えば、不正なURL、未知、あるいはおかしな属性、未登録の サービスを登録取消にすることは全てこのエラーを発生させる。 SCOPE_NOT_SUPPORTED 未サポートのスコープを持つ設定になっているSrvReqを受信し た場合、スコープを持つ構成のDAはこのエラーを返す。 CHARSET_NOT_UNDERSTOOD DAがサポートしていない文字セットでSrvRegやSrvDeregを受信 する場合、このエラーを返す。 AUTHENTICATION_ABSENT DAが要求されたスコープ内で、幾つかの登録されたサービスの 認証を必要とする構成を持ち、登録内に認証ブロックが無い場 合、DAはこのエラーを返す。 AUTHENTICATION_FAILED 登録が、認証されているURL、あるいは属性データ上で、正し い計算結果(4.3を参照)とのマッチに失敗する認証ブロックを 含む場合、DAはこのエラーを返す。 ディレクトリ・エージェントがサービス登録を受け入れ、既にエントリが存 在する場合、新しいライフタイム情報で、時には新しい属性と属性値で、存 在するエントリを更新する。そうでなければ、登録が受け入れ可能な(必要 な認証検査を含む全ての)ディレクトリ・エージェントが新しいエントリを 生成し、サービス・エージェントにサービス認証内の'F'ビットをセットし 返る。 Veizades, et. al. Standards Track [Page 36] RFC 2165 Service Location Protocol June 1997 11. サービス登録取消メッセージフォーマット サービスがもはや利用可能で無い場合、サービス・エージェントは登録時の ディレクトリ・エージェントから自分自身の登録を取消さなければならない。 サービスは自分自身の登録を取消すために以下のPDUを使用する。 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Location header (function = SrvDereg) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of URL | URL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ URL of Service to Deregister, contd. \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (if present) authentication block ..... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of string | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ , continued \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ サービス・エージェントは、ディレクトリ・エージェントから応答が無い場 合、この操作をリトライすべきである。ディレクトリ・エージェントは、サ ービス認証メッセージを使用してこの操作を認証する。一度サービス・エー ジェントが成功を示す認証を受信すると、サービスがもはやディレクトリ・ エージェントにより広告されていないと仮定する。サービス登録取消の認証 内のエラーコードは、10章に記述されている幾つかの値を持つ。 サービス登録取消情報は、以下の形式をディレクトリエージェントに送る。 service::// Attribute tags (必要なら): ATTR1,KEYWORD,ATTR2 これはディレクトリエージェントのサービス情報から指定された属性の登録 取消を行う。属性タグが含まれていない場合、登録時の全言語、全スコープ 内の全てのサービス情報は登録が取消される。プリンタから登録取消を行う には、前述の例を使用して以下のように記述する。 service:lpr://igore.wco.ftp.com:515/draft Veizades, et. al. Standards Track [Page 37] RFC 2165 Service Location Protocol June 1997 サービスが初めURL認証ブロックを含むURLエントリで登録されていた場合、 サービス登録取消メッセージヘッダは'U'ビットがセットされていなければ ならなく、この時URLエントリには、4.3に説明のあるURLデータ、タイムス タンプ、認証者長で計算された認証者を持つ認証ブロックが続く。この計算 において、登録されたURLのライフタイムを残存する現在値は何の意味も持 たず、URLデータのライフタイムは0であると考えられる。 12. 属性要求メッセージフォーマット 属性要求は属性情報を取得するために使用される。UAは要求を提供し、適切 な属性情報を返す。 UAがあるサービスタイプのみを提供する場合、応答はサービスタイプの全属 性/値を含む。この応答はサービスが存在する属性のみを含み、属性要求を 受け取ったDAやSAにより広告される。与えられたサービスの様々なインスタ ンスは、サービスタイプにより定義された属性に非常によく異なる値を持つ ため、ユーザ・エージェントは全サービス・エージェントにより返された全 属性の集合を作り上げなければならない。属性情報はサービス要求を作り上 げるのに使用される。 UAがURLを提供する場合、その応答はURLと一致するサービス情報を含むはず である。 属性要求は'select clause'を含む。これは、返された情報量を制限するた めに使用できる。選択条項が空の場合は、全情報が返される。そうでなけれ ば、UAは属性タグとキーワードをコンマで区切られたリストとして提供する。 サービスのために属性やキーワードが定義される場合、属性の登録値と共に、 属性応答として返される。選択された属性がURLやサービスタイプに登録さ れなかった場合、その属性やキーワード情報は容易には戻らない。 Veizades, et. al. Standards Track [Page 38] RFC 2165 Service Location Protocol June 1997 属性要求メッセージのフォーマットを以下に示す。 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Location header (function = AttrRqst) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |length of prev resp list string|| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ , continued \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of URL | URL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ URL, continued \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ , continued \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ , continued \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ は7章で紹介されたように正確に機能す る。20.1も参照のこと。 URLは2種類の形式を取ること可能である。"service:http:"のような単純な サービスタイプか、"service:lpr://igore.wco.ftp.com:515/draft"のよう なURLのどちらかである。前者の場合、サービスタイプに全属性と各属性の 完全な値が返される。後者の場合は、URLが定義されているサービスに属性 のみが返される。 Scope文字列は、サービスタイプが特定の範囲に合う属性情報のみを返すよ うに生成されたサービスタイプの属性要求により提供される。このフィール ドは、完全なURLが属性要求に送られる場合は無視される。Scope文字列のエ ンコード規則は5.4に記述がある。 Veizades, et. al. Standards Track [Page 39] RFC 2165 Service Location Protocol June 1997 選択リストは次のフォームを取る。 ::= | ',' ::= | | '*' ::= 属性の部分的なクラス名 クラス名の前に'*'がある場合、部分的なタグから始 まる全クラス名とマッチする。クラス名の後に'*'が ある場合、部分的なタグで終わる全クラス名とマッチ する。'*'が先行、後続する場合、部分的なタグを含 む全クラス名とマッチする。 との定義は、5.4を参照のこと。 select-listの例を、プリンタを例にして以下に示す。 PAGES PER MINUTE, UNRESTRICTED_ACCESS, LOCATION ディレクトリ・エージェントに送信される場合、前回の応答側の数は0で、 前回の応答アドレス指定は存在しない。これらのフィールドは、サービス要 求として正確にマルチキャストが繰り返される時にのみ使用される。 13. 属性応答メッセージフォーマット 属性応答メッセージのフォーマットを以下に示す。 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Location header (function = AttrRply) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Code | length of string | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ エラーコードは以下に示すものの内1つをとる。 0 成功 Veizades, et. al. Standards Track [Page 40] RFC 2165 Service Location Protocol June 1997 LANGUAGE_NOT_SUPPORTED サービス情報が全く登録されていない、あるいは1カ国語だけ を使用するビットがセットされて届くリクエストにおいて、サ ポートしていない言語でUAからリクエストを受信した場合、SA、 あるいはDAはこの値を返す。17章を参照。 PROTOCOL_PARSE_ERROR AttrRqstが解析できない、あるいは宣言した文字列長を超えた メッセージを受信した場合、DAやSAはこのエラーを返す。 SCOPE_NOT_SUPPORTED あるスコープを持つ構成のDAは、未サポートのスコープを持つ AttrRqstを受信した場合にこのエラーを返す。SAは未サポート のスコープへのマルチキャストAttrRqstメッセージを暗黙のう ちに破棄する。 CHARSET_NOT_UNDERSTOOD DAが未サポートの文字セットでAttrRqstを受信する場合、この エラーを返す。SAは未サポートの文字列セットを使用したマル チキャストAttrRqstメッセージを暗黙のうちに破棄する。 (属性リスト)は、サービス登録内の属性リストと同一形式をと る。このフィールドの正式定義は20.3を参照のこと。 "lpr"の属性要求は以下の要求を引き出すことが可能である (UNRESTRICTED_ACCESSはキーワードである)。 (PAPER COLOR=WHITE,BLUE), (PAPER SIZE=LEGAL,LETTER,ENVELOPE,TRACTOR FEED), UNRESTRICTED_ACCESS, (PAGES PER MINUTE=1,3,12), (LOCATION=12th, NEAR ARUNA'S OFFICE), (QUEUES=LEGAL,LETTER,ENVELOPE,LETTER HEAD) メッセージヘッダに'A'ビットがセットされている場合、属性応答は属性認 証ブロック集合を持つ。この場合、属性認証者は、保護スコープ内のあるSA により登録された、完全な属性リストを正確に返されなければならない。こ の場合、そのURLは保護スコープ内に含まれ、UAは選択条項ではないURLを含 む。AttrRqstが特定の属性のみを返す指定をする場合、DAは新しい認証者を 計算しないため(一般的には不可能)、単に認証者ブロック無しで属性を返す。 Veizades, et. al. Standards Track [Page 41] RFC 2165 Service Location Protocol June 1997 保護スコープ内のサービスで認証済みの属性を取得したいUAは、特定のURL を含み、AttrRqstを使用した選択リストがあってはならない。 14. ディレクトリ・エージェント広告メッセージフォーマット ディレクトリ・エージェント広告メッセージのフォーマットを以下に示す。 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Location header (function = DAAdvert) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Code | Length of URL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ URL \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length of | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | \ , continued \ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ DA広告がサービス要求の結果として返る場合はエラーコードがセットされる。 余計なDA広告の場合、コードは常に0にセットされる。エラーコードは6章に 示す値を取る。 URLはディレクトリ・エージェントの場所と一致する。は、以 下に示すDAがサポートする範囲のコンマで区切られたリストである。 ::= | ',' ::= スコープを表す文字列 に関する正式規則は5.4を参照のこと。 ディレクトリ・エージェント・ディスカバリー要求に答えるために送られる DA広告は、余計なDA広告と同一フォーマットを持つ。例を以下に示す。 URL: service:directory-agent://SLP-RESOLVER.CATCH22.COM SCOPE List: ADMIN Veizades, et. al. Standards Track [Page 42] RFC 2165 Service Location Protocol June 1997 ディレクトリ・エージェントは、アドレス指定が返る時に届けられ、"ADMIN" と呼ばれるスコープをサポートする。 15. ディレクトリ・エージェント 15.1. はじめに ディレクトリ・エージェントは多くのサービス・エージェントに作用する。 ディレクトリ・エージェントはサービス・エージェントから情報を取得し、 その情報をユーザ・エージェントに提供するために、1つの接触点として動 作する。 (ディレクトリ・エージェントの無い環境での)サービス・エージェントへの ユーザ・エージェントマルチキャストのクエリーは、ディレクトリ・エージ ェントへのユーザ・エージェントのユニキャストのクエリーと同じである。 ユーザ・エージェントは、選択されたディレクトリ・エージェントが失敗す る場合に備えて、相互のディレクトリ・エージェントの存在に関する情報を キャッシュしても良い。 プロトコル(3.7を参照)のスケーラビリティを強化することは別として、複 数のDAを実行することにより、オペレーションの強固さを提供する。DAの1 つが故障した際、DAはアクセス可能なサービス情報をコピーするかもしれな い。将来、企業ネットワークや大きな管理ドメインのため、ディレクトリ・ エージェントは、サービス・ロケーション情報の分散データベースのメンテ ナンスを調整するために、このプロトコルの外部のメカニズムを使用できる。 個々のサービス・エージェントは、使用するために設置されている全DAに登 録しなければならない。UAは使用するために設置されているDAの中から選択 することができる。 局地的に、ディレクトリ・エージェントの整合性は、プロトコルのメカニズ ムを使用することで保証される。ディレクトリ・エージェントのプロトコル はまだどのようなディレクトリにも存在しない。むしろ、SAによりDAの 受動的な検出は、結局サービス情報がDA間に矛盾なく登録されることを保証 する。無効なデータは、サービス・エージェントが失敗した場合でも、一時 的な古い登録だけを捨てるディレクトリ・エージェントにより老化する。 15.2. ディレクトリ・エージェントの発見 ユーザ、あるいはサービス・エージェントは特定のDAを使用するために静的 に設置可能である。これは、マルチキャスト、あるいはブロードキャストが 不可能なネットワークに属するアプリケーションが無い限り発見を妨害する。 代わりに、DHCP[2, 11]を使用するホストは、ディレクトリ・エージェント のアドレスを取得するためにそれを使用可能である。 DHCPオプション78と 79はこの目的[21]のために割り当てられた。 DAを発見するための3つ目の方法は、動的に行うことである。これはディレ クトリ・エージェント・ ディスカバリー要求(5.2を参照)を発行することに より行う。 Veizades, et. al. Standards Track [Page 43] RFC 2165 Service Location Protocol June 1997 最後に、エージェントは以下のように受動的に通知される。 最初にディレクトリ・エージェントがオンラインで届くと、余計なDA広告を サービス・ロケーション・ゼネラル・マルチキャストアドレスに送る。DAが 特定の範囲、あるいは範囲の組をサポートする場合、DAはレスポンス中に設 定される。この属性のクラスは、'SCOPE'である。 どのCONFIG_INTERVAL_9のディレクトリ・エージェントも、余計なDA広告を 送る。結局、このことは、関係する全てのアプリケーションによりDAが発見 されることを保証する。 最初にディレクトリ・エージェントが届くと、XIDは0で始まり、XIDは余計 なDA広告を送る度にインクリメントされる。カウントが1周した場合、XIDは 0xFFFFから、0ではなく0x0100になるべきである。 ディレクトリ・エージェントが、不揮発性記憶内に全てのサービス情報を蓄 積する場合、'状態不明'としてXIDの初期値を0x100にすべきである。メモリ 内にのみサービス登録を記憶する場合、状態無しでリスタートする。DAは状 態無しということを、XIDを0にリセットして示すべきである。 余計なDA広告を受信する全サービス・エージェントは、XIDを調べるべきで ある。ディレクトリ・エージェントが以前通信したことが無く、あるいは XIDが前回のものより小さく、256未満であれば、サービス・エージェントは かつてサービス登録証明書のあったDAであっても、サービス登録証明書を持 っていないと仮定する。この場合で、DAが適切な範囲であれば、SAはランダ ム間隔のCONFIG_INTERVAL_10後に、ディレクトリ・エージェントと一緒に全 サービス情報を登録する。 最初にサービス・エージェントやユーザ・エージェントがオンラインで届く と、5.2に記述されている静的、あるいはDHCP構成を使用しない限り、ディ レクトリ・エージェント・ディスカバリー要求を発行しなければならない。 上記の2つの事象のどちらにおいても、1つのサービス・エージェントは、全 ての新たに発見されたディレクトリ・エージェントと共に情報を登録する。 スコープが使用されていると、サービス・エージェントは内部で広告されて いる範囲の集合を選択すべきで、登録されることを望むスコープをサポート するディレクトリ・エージェントを登録する必要がある。サービスは、登録 しないというように明確に配置されていない限り、スコープをサポートする DAとスコープを持たないDAにより登録されなければならない(22.1を参照)。 Veizades, et. al. Standards Track [Page 44] RFC 2165 Service Location Protocol June 1997 一旦ユーザ・エージェントがディレクトリ・エージェントに気づくと、クエ リーをそのディレクトリ・エージェントにユニキャストする。これにより、 複数のディレクトリ・エージェントが検出される場合、通信をする1つを選 択する。スコープがサポートされる場合、ユーザ・エージェントはそのクエ リーを、クエリーに答える適切なドメインのスコープに依存する異なるディ レクトリ・エージェントに指示する。 プロトコルは、結局一貫する情報を取得するために全ての(同一スコープの) DAを引き起こす。従って、1つのDAはサービス情報を取得するために忠実で あるべきである。一時的にDA間に矛盾があるかもしれない。 16. スコープの発見と使用 スコープは、サービス・ロケーション・プロトコルがそのスケーラビリティ を強化するメカニズムである。スコープ本来の使用は、管理ラインに沿って、 サイトネットワークを組織化する機能を提供するためである。サービスの集 合は、特定の建物、地理範囲、あるいはある目的を与えられた組織の部門に 割り当てられる。システムの利用者は、このドメイン内のサービスが捜索さ れる前に、トップレベルの選択として、これらの組織的な要素を与えられる。 幾つかのDAにより、適度なサービスが可能なサイズを超えて増大したサイト ネットワークは、スコープメカニズムを使用することができる。DAは属性ク ラス"SCOPE"を持つ。この属性値は、このディレクトリ・エージェントのあ る管理領域を表す文字列リストである。文字列の意味と言語は、スコープが 存在する特定ドメインの管理実態の選択である、殆ど完全なスコープを記述 するために使用される。SCOPEの値は、システム管理者がその値を設定する ように、設定の変更が可能である。スコープ"LOCAL"と"REMOTE"は予約語で あり、使用してはならない。これらの予約値の使用は、将来のプロトコル仕 様で記述される必要がある。 属性SCOPEを持つサービスは、同一スコープをサポートするDA、あるいはス コープを持たないDAにのみ登録されるべきである。 ディレクトリ・エージェントは、これらの利用可能なスコープを広告する。 この時、サービス・エージェントは登録するスコープを選択でき、スコープ を持たない全てのDAと同様に、そのスコープ内の全てのディレクトリ・エー ジェントを登録すべきである。この規則に従った登録における多くの失敗は、 サービス広告が全てのユーザ・エージェントに利用可能ではないことを意味 する。 Veizades, et. al. Standards Track [Page 45] RFC 2165 Service Location Protocol June 1997 スコープを持つディレクトリ・エージェントは、スコープ情報を含むディレ クトリ・エージェント・ディスカバリー要求のレスポンスとして広告を返す。 "service:directory-agent"スキームは、IANA命名局で登録されることに注 意すること(命名局フィールドを空にしておくことにより自動的に選択され る)。 問合わせ: directory-agent/MATH DEPT// 以下のDA広告を受信できる。 返されるURL: service:directory-agent://diragent.blah.edu 返されるSCOPE: MATH DEPT スコープ値を持たない応答の際は、同一ディレクトリ・エージェントである。 返されるURL: service:directory-agent://diragent.void.com 返されるSCOPE: ディレクトリ・エージェントが1つ以上のスコープをサポートしている際の 応答を以下に示す。 返されるURL: service:directory-agent://srv.domain.org 返されるSCOPE: MATH DEPT,ENGLISH DEPT,CS DEPT スコープを持たないDAは、どのようなディレクトリ・エージェント・ディス カバリー要求にも応答する。 スコープのメンバーがあるということは、エージェントがそのスコープをサ ポートするこれらのディレクトリ・エージェントを使用すべきであるという ことを意味する。ユーザ・エージェントは、示されたスコープをサポートす るDAに、全てのリクエストを送信する。サービスはこれらのスコープ内にDA と共に登録される。特定のスコープに登録されたサービスを見つけるために、 UAは示されたスコープをサポートするDAに対してリクエストを送信しなけれ ばならない。プロトコルに組み込まれるスコープメンバー数には制限が無い。 すなわち、ユーザ・エージェント、あるいはサービス・エージェントは1つ 以上のスコープのメンバーである。アクセスを制限するために、幾つかの外 部の認証メカニズムを付加しない限り、メンバーシップは全てオープンであ る。 16.1. 保護スコープ スコープメンバーシップはスコープ内のサービスのために、セキュリティア クセスと認証も定義することができる。このようなスコープは保護スコープ と呼ばれる。確かに、サービス・エージェントが、それらを広告するサービ ス提供を認証済みであるということをユーザ・エージェントが望む場合、ユ ーザ・エージェントは、スコープ内のサービス・エージェントに分散させた 必要な認証メカニズムとキーを持つために構成された保護スコープからサー ビスに要求すべきである。 Veizades, et. al. Standards Track [Page 46] RFC 2165 Service Location Protocol June 1997 保護スコープ内でサービスのために分散されたURLのディレクトリエージェ ントは、サービスが提供する認証を証明するのに、暗号で強度の認証を提供 できないサービスエージェントのために、どんな登録、あるいは登録取消も 却下する。 例えば、学内の記録係がメールで学生の成績情報を作るために稼働中のプリ ンタを発見したい場合、記録係は適切な保護スコープ内に登録されている成 績情報を印刷するサービス・エージェントを要求する。正常な状態では、各 サービスエージェントは2回有効になることに注意すること。1つはディレク トリエージェントを登録する時、もう1つはユーザエージェントがサービス 応答を受け取ったURLを有効にする時である。これは、悪意のあるサービス ・エージェントと同様、悪意のあるディレクトリ・エージェントの可能性を 禁ずる。 保護スコープ内のサービスは、URLエントリと属性のために、別々の認証を 提供するということに注意すること。これはプロトコル操作の必要性から自 然と付いてくるものである。そのサービスタイプ内でサービスが必要なサー ビスタイプと属性を指定するユーザ・エージェントは、ディレクトリ・エー ジェントから属性情報を受け取らない。それらは、適切なURLエントリを受 け取るだけである。その情報は認証されているニーズを返すだけである。 一方、情報が返される時、特定のURL(12章を参照)のための属性情報を受け 取るユーザエージェントは、属性を認証する必要がある(13章を参照)。この 場合、認証するためにより多くのデータがあるかもしれないが、この操作は 通常ユーザが利用可能なネットワーク資源をブラウズしている間だけ、実行 される。 17. 言語と文字エンコードの問題 全てのサービス登録は、サービス属性がメッセージヘッダ内の適切なコード を指定することより書かれている文字列の言語を宣言する。個々の言語のた めに、サービスは別々の登録が起こるように広告をする。これらの各登録は、 同一サービスを参照することを示す同一URLを使用する あるサービスが完全に登録取消をする場合(URLは属性情報無しで、サービス 登録取消要求として与えられる)、そのサービスは1回のみ登録取消が必要で ある。これは、登録されている全ての言語において有効なサービス登録取消 である。 Veizades, et. al. Standards Track [Page 47] RFC 2165 Service Location Protocol June 1997 一方、属性情報がサービス登録取消要求に含まれる場合、選択された属性の 別々のサービスと登録取消は、サービス・エージェントからDAに提供された サービス情報を持つ各言語に対応しなければならない。様々な言語のサービ ス登録は相互に理解不能である。これらは、登録されたサービスタイプとURL を除き、情報を全く共有しない。"言語依存"のクエリーとマッチさせる方法 は存在しない。その代わりクエリーは、クエリーと同一言語の登録に対して マッチしている文字列を使用して処理される。 標準化されているサービスタイプは、全属性と値文字列の定義を持つ。属性 タグと値の他言語への公式の翻訳は、標準の一部として生成され、提案され る。これは全ての言語に対して利用可能という訳ではない。サービスタイプ の一部として定義されないこれらの言語は、サービスタイプの属性文字列の 標準定義の最も良い翻訳が使用される。 全てのサービス要求はメッセージヘッダ内の要求された言語を指定する。リ クエストとして同一言語が登録されている場合、ディレクトリ・エージェン ト、あるいはサービス・エージェントはリクエストとして同一言語で応答す る。この言語がサポートされていなく、1カ国語を使用するビットが指定さ れていない場合、応答は(英語のような)デフォルトの言語で送られる。ヘッ ダの'1カ国語を使用するビット'フラグがセットされ、要求された言語がサ ポートされていない場合、SrvRplyはエラーフィールドに LANGUAGE_NOT_SUPPORTEDがセットされ返される。 SA、あるいはDAにサポートされた言語のクエリーがあるが、利用可能なサー ビス情報と異なる表現形式を持つ場合、そのクエリーは最も良い原理でサー ビスされなければならない。これが不可能な場合、同一言語のどのような表 現形式とでもマッチする。 17.1. 文字エンコードと文字列の問題 IANAのデータベースに存在する文字エンコーディング値 http://www.isi.edu/in-notes/iana/assignments/character-sets と、MIBEnum値により参照される値を持つ値。 エンコーディングは、サービス・ロケーション・プロトコルヘッダに続く全 文字列データの翻訳を決定する。例えば、ASCIIとUNICODEを混合する方法は ない。全レスポンスはリクエストの文字セット内にあるか、US-ASCIIを使用 しなければならない。受信メッセージの文字セットを操作、あるいは格納で きないリクエストがDAやSAに送られる、あるいは登録証明書がDAに送られる 場合、そのリクエストは失敗する。この場合、SA、あるいはDAは、SrvAckメ ッセージ内にCHARSET_NOT_UNDERSTOODエラーを返す。US-ASCIIを使用してい るリクエストは、決してこの結果では失敗しないため、全SAとDAはこの文字 セットを受け付けることができなければならない。 Veizades, et. al. Standards Track [Page 48] RFC 2165 Service Location Protocol June 1997 特定の文字はプロトコルの文脈として不正である。プロトコルが大量な文字 列に基づくため、幾つかの文脈文字はプロトコル区切り文字として使用され る。これらの場合、区切り文字は'データテキスト'として使用してはならな い。 17.1.1. 文字エスケープシーケンスの代用 サービス・ロケーション・プロトコルは、HTTP2.0[5]とSGML[15]により一貫 する'エスケープメカニズム'を持つ。文字シーケンス"&#"が1桁以上続く場 合、セミコロン';'で次に続く全体のシーケンスは、1文字として解釈される。 数字はヘッダで指定されるように、リクエストの文字セットで10進の値とし て解釈される。従って、US-ASCIIの,はコンマと解釈される。これらのエ スケープ文字列の代入は、SrvReqとAttrRqstメッセージ内の全ての と文字列表現で行わなければならない。'実体参照'ではなく、HTMLで定義さ れるような数値文字参照だけは認められる。これらのエスケープ値は、属性 タグと値の文字列内に、予約語を含むためのメカニズムを提供するためだけ に使用されるべきである。 これらのエスケープ値の解釈は、1つの点でHTMLと異なる。HTMLでのエスケ ープ値は、ISO Latin-1文字セットにあると考えられる。サービス・ロケー ション内で、これらはメッセージヘッダ内に定義された文字セットとして解 釈される このエスケープメカニズムは、属性タグと値を含むコンマのような文字を認 め、これ以外の場合は、コンマがプロトコル区切り文字として不正である。 異なる言語での属性タグと値は、相互に理解できないと考えられる。ある言 語でのクエリーは、その言語が登録されたサービス情報を使用すべきである。 17.2. 言語依存文字列 サービス・タイプ名のような、幾つかの文字列は標準定義をもつ。これらの 文字列は、翻訳された言語の単語としてではなく、トークンとして考えるべ きである。 Veizades, et. al. Standards Track [Page 49] RFC 2165 Service Location Protocol June 1997 予約語 章 xDefinition --------------- ------- -------------------------------------- SCOPE 3, 15 リクエストとのマッチを制限するために使用さ れる。 SERVICE 6, 9 DAに登録された、あるいはサービス要求から返 された全てのサービス・ロケーション情報のURL スキーム。 20.2.1 全てのサービス登録と応答で使用される。 domain names 20.4 登録と応答で使用される十分に制限されたドメ イン名。 IANA 3.3 デフォルトの命名局。 LOCAL 16 予約済み。 REMOTE 16 予約済み。 TRUE 20.5 ブーリアン値で真。 FALSE 20.5 ブーリアン値で偽。 18. サービス・ロケーション処理 18.1. サービス・ロケーション接続 サービス・ロケーション要求、あるいは属性要求が、サービス、あるいはデ ータグラムからオーバーフローするようなディレクトリ・エージェントから UDPで応答する場合、ユーザ・エージェントはエージェントに対してコネク ションをオープンし、接続要求を再発行することができる。応答はオーバー フロービットがセットされ戻される(4章を参照)。応答は、1つのデータグラ ムに入るのと同じくらい多くのデータを含む。MTU情報が経路上で利用可能 でない場合、MTUは1400であると仮定する。この値は、設定の変更が可能で ある(22章を参照)。 あるリクエストが(重複、あるいはIPデータグラムの欠落のため)解析できな い、オーバーフローなデータを結果として返す場合、オーバーフローなデー タを確かに取得することを望むユーザ・エージェントは、データを持つディ レクトリ・エージェント、あるいはサービス・エージェントを使用してTCP 接続を確立しなければならない。リクエストが新しいXIDにより再送される と、コネクション上に応答が返される。 登録データが1つのデータグラムの長さを超える時は、サービス登録はディ レクトリ・エージェントとのコネクションを確立し、コネクションストリー ム上に登録を送信すべきである。 Veizades, et. al. Standards Track [Page 50] RFC 2165 Service Location Protocol June 1997 ディレクトリ・エージェントとサービス・エージェントは接続要求に応答し なければならない。登録データがデータグラムに入らないサービスは、登録 を送信するためにTCPを使用することができるはずである。ユーザ・エージ ェントは、TCPを使用してサービスと属性要求を作ることができるはずであ る。これらが実行に失敗する場合、部分的な応答と(あるいは)再発行は、応 答のサイズを減らすために、より選択的な尺度で要求を行う。 エージェントにより開始されたコネクションは、単一トランザクションのた めに使用される。また、複数のトランザクションにも使用される。メッセー ジヘッダには長さフィールドがあるため、エージェントはコネクションに沿 って複数のリクエストを送信し、受領と応答のリターンストリームを読むこ とができる。 開始中のエージェントはTCP接続を閉じる責任がある。DAは未使用の接続を 閉じる前に、少なくともCONFIG_INTERVAL_12間待つべきである。DAとSAは、 コネクションをオープンしたエージェントがクローズを無視する場合でも、 強固なオペレーションを保証するために、未使用の接続を閉じるべきである。 18.2. 非同期仮定 与えられたホストが別のものを開始する前には、完全な1つのトランザクシ ョン要求がない。エージェントは、UDP、あるいはTCPを使用して開始された 複数の未完成のトランザクションを持つことができる。 18.3. 同一効果 全てのサービス・ロケーションの動作は同一効果を持つ。もちろん、登録と 登録取消はDAの状態を変化させるが、同一XIDを使用し、これらの動作を繰 り返すことは、いつも同じ効果を持つ。新しいXIDで登録を繰り返すことは、 登録のライフタイムを延ばす効果がある。 19. セキュリティの考察 サービス・ロケーション・プロトコルは、スコープメカニズムの一部として、 サービス・エージェントの認証を提供し、その結果、登録証明書の一部とし てデータの安全性を授かる。このプロトコルの目的がユーザ達へサービスを 広告することであるため、このプロトコルが高感度でない環境で使用される 際には、一般的に秘密性は必要無いかもしれない。将来必要であれば、特殊 な仕組みは秘密性を提供することができるかもしれない。秘密性を必要とす るサイトは、サービス・ロケーションメッセージに秘密性を提供するために、 IPカプセル化セキュリティペイロード(ESP)[3]を実行すべきである。 Veizades, et. al. Standards Track [Page 51] RFC 2165 Service Location Protocol June 1997 保護スコープを使用することにより、相手に管理されたサーバ上のサービス を広告するために、容易にこのプロトコルを使用でき、これによりユーザの プライベート情報へのアクセスを行うことができる。更に、このプロトコル を使用している相手は、サービス開始の選択的な拒否を採用する相手をより 簡単に見つける。(例えばインターネットに直接接続される)潜在的に敵対す る環境のサイトは、高感度のディレクトリエージェント、あるいはサービス エージェントを配置する前に、保護スコープと関連した分散するキーの利点 を考慮すべきである。 サービス・ロケーションはブートストラッププロトコルと同様に効果的であ る。これは、前の構成が不可能な環境で使用される。このような状況では、 "暗黙の了解"の一定量が必要とされる。事前の構成無しで、上述したセキュ リティメカニズムを使用することは不可能である。サービス・ロケーション は、それらを可能にする、キー分散に関するIETFのセキュリティエリアから 提供されたメカニズムを利用する。この時、サービス・ロケーションを使用 する前に、幾つかの暗号の情報がエンドシステムにより再配置できる場合、 それは保護スコープの使用と関連した恩恵を授かることのみが可能である。 ユーザ・エージェントのために、これは認証局の公開鍵を供給するのと同程 度簡単である。付録Bを参照のこと。 20. サービス・ロケーション・メッセージを使用した文字列形式 以下の表は、フィールドとプロトコル要素の正式な定義を示す節を紹介して いる。 プロトコル要素 章 使用部分 ----------------------------------- ------------ ------------ 20.1 SrvReq サービス要求 5.4 SrvReq URL 20.2 SrvReg, SrvDereg, SrvRply 20.3 SrvReg, SrvRply, AttrRply 9 SrvReg 11 SrvDereg 20.2.1 AttrRqst Veizades, et. al. Standards Track [Page 52] RFC 2165 Service Location Protocol June 1997 20.1. 前の応答者のアドレス指定 前述の応答者のアドレス指定を以下に示す。 ::= | , つまり、リストはスペースが間に無いコンマで区切られる。アドレス指定は、 前のレスポンスを供給したディレクトリ・エージェント、あるいはサービス ・エージェントのアドレスである。サービス・ロケーションでのアドレス指 定のフォーマットは、20.4に定義されている。コンマ区切り文字は各 間で必要である。ドットでの10進のIPアドレス表記法の使用は、 ドメインネームサービスを持たない環境でのみ使用されるべきである。 例: RESOLVO.NEATO.ORG,128.127.203.63 20.2. "service:"スキームの正式な記述 "service:"スキームを持つURLは、サービス・ロケーションのSrvReg、 SrvDereg、SrvRply、AttrRqstメッセージで使用される。URLはRFC1738[6]で 定義されている。"service:"スキームを持つURLは、少なくとも以下のもの を含まなければならない。 ::= service::// where: service 応答を返すための、サービス・ロケーションのURLスキー ム。 文字列。サービス・タイプは、"service type"の指定部 分の指定を展開し、IANAに登録することにより規格化さ れる。20.2.1と3.3を参照のこと。 サービスのサービスアクセスポイント。サービスがアク セスできるネットワークアドレス、あるいはドメイン名。 20.4を参照のこと。 "service:"スキームは正当なURLで続く。それは特定のサービスである。与 えられたサービスアクセスでサービスをアクセスするために 使用したプロトコルは、サービス・タイプ名である。このケース以外の場合、 属性情報が全ての必要な構成とプロトコル情報を含むような方法で、サービ ス・タイプが定義されていなければならない。 Veizades, et. al. Standards Track [Page 53] RFC 2165 Service Location Protocol June 1997 従って、ユーザ・エージェントは、"service:"URLのみ、あるいはサービス を利用するためのサービス属性と結合した"service:"URLのどちらかを利用 することができる。 20.2.1. サービスタイプ文字列 サービス・タイプはサービスのタイプを記述する文字列である。これらの文 字列は、英数字、'+'、型名のみから構成される。 サービス・タイプ名に'.'と(同一制限を持つ)文字列が続く場合、その'接尾 語'はサービスの命名局であると考えられる。命名局が省略された場合、IANA が命名局であると仮定される。 社内、あるいは試験的に開発されたサービス・タイプの利用は、標準化され たサービス・タイプと競合しないように提供された、幾つかの名前と属性の 意味を持つようにする。 20.3. 属性情報 属性要求が空の結果を返さない場合、が属性応答で返される。 ::= | , ::= (=) | ::= | , は、';'の後に、1つ以上の数字で続く"&#"文字列を評価する前 に走査されなければならない。17.1.1を参照のこと。 キーワードはのみを持つ。また、属性は持たない。 複数の属性の区切りとして使用されるコンマと同様、コンマは 内に記述することはできない。の例を以下に示す。 (SCOPE=ADMINISTRATION) (COLOR=RED, WHITE, BLUE) (DELAY=10 MINS),BUSY,(LATEST BUILD=10-5-95),(PRIORITY=L,M,H) 3番目の例は、リスト内に3つの属性を持つ。カラーの値は赤、白、青をとる ことが可能である。本ドキュメント中に幾つかの他の応答の例がある。 Veizades, et. al. Standards Track [Page 54] RFC 2165 Service Location Protocol June 1997 20.4. サービス・ロケーションでのアドレス指定 サービス・ロケーションで使用されるアドレス指定を以下に示す。 ::= [:@][:] ::= 完全に限定されたドメイン名 | ドットでの10進のIPア ドレス表記法 ドメインネームサーバが利用不可能な場合、SAとDAはドットでの10進を用い たIPアドレスを使用しなければならない。そうでなければ、ホストのアドレ ス割り付けが、期間上無効なIPアドレスを作るので、可能な限り完全なドメ イン名を使用することが望ましい。 一般的に、正しいホストドメイン名(あるいはアドレス)が返される。通信規 約に非標準のポートがある場合、それも同様に返されるべきである。幾つか のアプリケーションは:@構文を利用できるが、秘密性を維 持するためのメカニズムが確立されるまで、その使用は推奨しない。 サービス・ロケーションのアドレス指定は、標準URLフォーマット[6]と一致 する。 20.5. 属性値のエンコード規則 属性値と属性タグは、文字比較の用途としてはCASE INSENSITIVEである。 属性値は、不明な値がエンコードされる場合を除き、例外として'('、')'、 '='、'>'、'<'、'/'、'*'、','(コンマ)を含む、幾つかの文字から成る文字 列である。これらの文字は、17.1.1に記述した文字値のエスケープメカニズ ムを使用することを含む。 一方、属性はどのような値でも取ることができ、一般的な文字列とそれらを 区別する、ブーリアン、整数値、不明な値の3つのタイプの値がある。 - ブーリアンは"TRUE"、あるいは"FALSE"のどちらかの値である。これは 言語を問わない(すなわち、フランス語やTeluguでのブーリアン値TRUE の"TRUE"は英語と同一である)。ブーリアン属性は1つの値のみをとる。 Veizades, et. al. Standards Track [Page 55] RFC 2165 Service Location Protocol June 1997 - 整数値は連続した数として表現される。範囲は"-2147483648"から "2147483647"までである。数値表現のこれ以外の形式は、数値として解 釈されない。例えば、"0x342"のような16進数は整数値として解釈され ず、文字列として解釈される。 - 不明な値(つまりバイナリ値)は、radix-64表記法で表現される。シンタ ックスは以下の通り。 ::= (:) ::= オリジナルデータのバイト数 ::= オリジナルデータのradix-64エンコード は16ビットのバイナリ値である。Radix-64は3バイトのバイナリデ ータを、完全に印刷可能、かつメールで送信可能なキャラクタ範囲の4 バイトのASCIIデータにエンコードする。Radix-64フォーマットの正式 な定義はRFC1521[7] MIME Part Oneの21ページ、5.2 Base64 Content Transfer Encodingを参照のこと。 21. プロトコル要求事項 この節ではユーザ・エージェント、サービス・エージェント、ディレクトリ ・エージェントのための、様々なプロトコル要求が記述されている。 21.1. ユーザ・エージェント要求事項 ユーザ・エージェントがすると思われること: - 最初にDAを見つけることなく使用できるように、デフォルトのDAを構成 するための適用方法を提供すること。 - DHCPからDAのアドレスを要求することが可能であれば、そのようにする こと。 - 認証されないサービス応答を無視すること。 - サイトにおいてDAとSAによりリクエストがサービスできない場合でも、 デフォルトの言語と文字セットに変換可能であるため、どのような言語、 あるいは文字セットのリクエスト発行をも可能にすること。 - 広告されたサービスを利用する前に、サービス要求の一部として戻され た幾つかのURLエントリにおいて認証ブロックを要求すること。 Veizades, et. al. Standards Track [Page 56] RFC 2165 Service Location Protocol June 1997 ユーザ・エージェントがすべきこと: - DAのアドレスを取得するために、DHCPとコンタクトを取ろうとすること。 - 可能であれば、全てのリクエストでスコープを使用すること。 - UAにスコープが配置されている場合、スコープのあるDAに対してリクエ ストを発行すること。 - 余計なDA広告のための、サービス・ロケーション・ゼネラル・マルチキ ャストアドレスに耳を貸す。このことは、要求を作ることになるので、 利用可能なディレクトリ・エージェントの組を増加させる。15.2を参照 のこと。 - サービスを利用する前に、保護スコープに属するものとして広告された 幾つかの受信済みURLエントリに対して、認証ブロックを必要とするよ うに構成すること。 UAがDA広告を聞かない場合、新しいDAは受動的に検出されない。配置された DAを持たない、DAを発見できない、余計なDA広告を聞いていないUAは、DAに 気づかれないままになる。各クエリーを実行する、あるいはサービス・エー ジェントにマルチキャストクエリーを単に使用する前に、DAディスカバリー を実行することができる。 ユーザ・エージェントがしなければならないこと: - ユニキャスト要求を行い、DAから応答を受け取ること。タイムアウト間 隔以内に応答が来ない場合、トランザクションはリクエストの再送を使 用することにより信頼を得ること。 - UAが開始される際に、ディレクトリ・エージェント・ディスカバリー要 求の発行を使用して、DAを検出することができること。 - リクエストをマルチキャストアドレスに送信できること。サービス指定 マルチキャストアドレスは、サービス・タイプのハッシュを基に計算さ れる。3.6.2を参照のこと。 - マルチキャスト要求後、多数の応答を扱うことができること。実装は、 タイムアウトまでに最初の応答か全ての応答が返る、あるいは結果が集 まるまで保持し続けるように設定の変更が可能であるかもしれない。 - 応答のための適切なIPSecセキュリティ協会が存在する際は、認証され ないサービス応答や属性応答を無視すること。 Veizades, et. al. Standards Track [Page 57] RFC 2165 Service Location Protocol June 1997 - まず第一に、いつDHCPからそのIPアドレスを取得したか、また、いつス コープ情報やDHCPからDAのアドレスを取得することを試行したのか。 - 適切なIPSecセキュリティ協会が存在しても、全てのサービス・ロケー ションメッセージで、IP認証ヘッダ、あるいはIPカプセル化ペイロード を使用すること。 - US-ASCII文字セットを使用し、リクエストを発行すること。 - 保護スコープを使用する構成の場合、署名されたデータを確認するため に"md5WithRSAEncryption"[4]を使用すること。 21.2. サービス・エージェント要求事項 サービス・エージェントがすると思われること: - DHCPを通して、ローカルディレクトリ・エージェントのアドレスを得る こと。 - 非US-ASCII文字エンコードのリクエストを受け入れること。これは、特 にUNICODE[1]とUTF-8[24]エンコードが推奨される。 - 非US-ASCII文字エンコードのDAを使用してサービスを登録すること。こ れは、特にUNICODE[1]とUTF-8[24]エンコードが推奨される。 サービス・エージェントがすべきこと: - 広告されているサービスの、サービス指定マルチキャストアドレスを聞 くこと。受信要求はフィルタをかけられるべきである。SAのアドレス指 定が前回の応答者アドレス指定リストにある場合、SAは応答しないはず である。そうでなければ、マルチキャストクエリーへの応答は、リクエ ストを送信したUAに対してユニキャストされるはずである。 - サービス・ロケーションポートへのブロードキャスト要求とTCP接続要 求を聞き、応答すること。 - 認証ブロックを計算するために設定の変更が可能であり、これにより保 護スコープ内に登録できること。これは、サービスエージェントが認証 者を計算するための必要なキーを持つような構成を必要とする。 サービス・エージェントがしなければならないこと: - クエリーとしてサービス・ロケーション・ゼネラル・マルチキャストア ドレスを聞くこと(例えば、サービスタイプ要求)。クエリーにサービス ・エージェントが応答する場合、サービス・エージェントはこのように しなければならない。 Veizades, et. al. Standards Track [Page 58] RFC 2165 Service Location Protocol June 1997 最初に、'前回の応答者'リストに無いことを確かめるためのチェックし なければならない。 - 余計なDA広告のための、サービス・ロケーション・ゼネラル・マルチキ ャストアドレスを聞くこと。これが検出され、DAが正しいスコープを持 つ(あるいはスコープを持たない)場合、現在広告されている全てのサー ビスはDAにより登録されなければならない(単一のDA(22.1を参照)を使 用するだけに配置された、あるいは既にDAが検出されていた場合を除き、 一定の規則(15.2を参照)に従わなければならない)。 - まず第一に、いつDHCPからそのIPアドレスを取得したか、また、いつス コープ情報やDHCPからDAのアドレスを取得することを試行したのか。 - DAに対して、登録と登録取消をユニキャストすること。タイムアウト間 隔以内に応答が来ない場合、トランザクションはリクエストの再送を使 用することにより信頼を得ること。 - UAが開始される際に、ディレクトリ・エージェント・ディスカバリー要 求の発行を使用して、DAを検出することができること(単一のDAを使用 するだけの構成を除く。22.1を参照)。 - 適切なIPSecセキュリティ協会が存在しても、全てのサービス・ロケー ションメッセージで、IP認証ヘッダ、あるいはIPカプセル化ペイロード を使用すること。 - US-ASCII文字エンコードを使用したDAでサービス情報を登録できること。 また、US-ASCII文字エンコードを使用したUAからのリクエストに答えな ければならない。 - 登録されたサービス情報がライフタイムを経過する前に、DAを使用して 登録すること。 - 保護スコープを使用するために構成されている場合、署名されたデータ を生成するために"md5WithRSAEncryption"[4]を使用すること。 21.3. ディレクトリ・エージェント要求事項 ディレクトリ・エージェントがすると思われること: - 非US-ASCII文字エンコードの登録とリクエストを受け入れること。これ は、特にUNICODE[1]とUTF-8[24]エンコードが推奨される。 Veizades, et. al. Standards Track [Page 59] RFC 2165 Service Location Protocol June 1997 ディレクトリ・エージェントがすべきこと: - スコープ内の登録が暗号の強度な認証者の計算を必要とするように、保 護スコープとして一定のスコープを配置できること。これは、保護スコ ープのためのサービス登録が完了する前に、DAが認証に必要なキーを所 有すること、あるいは、DAが信頼した認証局[23]で生成された認証を取 得することを要求する。 ディレクトリ・エージェントがしなければならないこと: - 起動時にサービス・ロケーション・ゼネラル・マルチキャストアドレス に対して余計なDA広告を送信し、定期的にこれを繰り返すこと。この応 答は、繰り返されるたびにインクリメントされるXIDを持つ。DAが状態 を持ち開始する場合、XIDを0x0100で初期化する。DAが状態を持たずに 開始する場合、XIDを0x0000で初期化する。 - セキュリティ協会が管理する実体からの、認証されないサービス登録や サービス登録取消を無視すること。 - ディレクトリ・エージェント・ディスカバリー要求のためのディレクト リ・エージェント・ディスカバリー・マルチキャストアドレスを聞くこ と。前回の応答者アドレス指定リストがDAのアドレス指定を含む場合、 これらの要求にフィルターをかけること。 - サービス・ロケーションポートに対するブロードキャスト要求を聞くこ と。 - ユニキャスト要求、登録、登録取消、サービスのための、TCPとUDPのサ ービス・ロケーションポートを聞くこと。 - ディレクトリ・エージェントを配置するために使用されるスコープ情報 の方法を提供すること。 - サービス登録のライフタイムが満了した場合、登録を満了すること。 - ディレクトリ・エージェントがスコープを使用して配置された場合、全 てのリクエストと、このスコープを持たない登録取消を拒絶しなければ ならない。DAはSCOPE_NOT_SUPPORTEDエラーで応答する。1つの例外は、 全てのDAは、スコープを持たないDAディスカバリー要求に応答しなけれ ばならないということである。 - ディレクトリ・エージェントがスコープ無しで配置されている際は、全 ての登録とリクエストを受け入れなければならない。 Veizades, et. al. Standards Track [Page 60] RFC 2165 Service Location Protocol June 1997 - 応答のための適切なIPSecセキュリティ協会が存在する際は、認証され ないサービス・ロケーションメッセージを無視すること。 - 適切なIPSecセキュリティ協会が存在しても、サービス・ロケーション メッセージで、IP認証とIPカプセル化セキュリティペイロードを使用す ること。 - US-ASCIIのリクエストと登録を受け入れること。 - 保護スコープで配置されている場合、そのような、配置された保護スコ ープに属することを意味するサービスを広告している、サービス登録証 明書を(少なくとも"md5WithRSAEncryption"[4]を使用して)認証するこ と。 22. 設定の変更が可能なパラメータとデフォルト値 サービス・ロケーションには幾つかの設定パラメータがある。デフォルト値 はこれらの設定パラメータの選択を必要とせずにプロトコル操作を許可する が、他の値はサイト管理者により選択される。設定の変更が可能なパラメー タは、様々なシナリオでより効果的であるように、サービス・ロケーション の実行を許可する。 マルチキャスト対ブロードキャスト 全てのサービス・ロケーション自体はデフォルトでマルチキャ ストを使用しなければならない。ブロードキャストメッセージ を使用する能力は、UAとSAのために設定の変更が可能でなけれ ばならない。ブロードキャストメッセージは、全てのサービス ・ロケーション自体が、マルチキャストをサポートするハード ウェア、あるいはソフトウェアを持たない環境で使用される必 要がある。 マルチキャストの範囲 マルチキャスト要求は、サイト内の全てのサブネットに送信さ れるべきである。サイトのデフォルトのマルチキャスト範囲は 32である。この値は、変更可能である。サイトのマルチキャス トTTLの値は、現在未割り当てのオプションを使用することに よりDHCPから取得できる。 ディレクトリ・エージェント・アドレス ディレクトリ・エージェントアドレスディスカバリーメカニズ ムは再設定可能でなければならない。この設定には3つの可能 性がある。デフォルトのアドレス、非デフォルトのアドレス、 DAの位置を決めるDHCPの使用は、15.2に記述がある。DHCPが応 答しない場合、デフォルト値は、"非デフォルトアドレス"を使 用したDHCPを使用すべきである。この場合、UA、あるいはSAは ディレクトリ・エージェント・ディスカバリークエリーを行わ なければならない。 Veizades, et. al. Standards Track [Page 61] RFC 2165 Service Location Protocol June 1997 ディレクトリ・エージェントスコープ割り当て スコープ、あるいはDAのスコープは設定可能でなければならな い。DAのデフォルト値は、別の方法で設定されていない場合、 スコープを持たない。 MTUパス MTUパスのデフォルトは1400と仮定する。この値は、幾つかの サイトの構造基盤としては大きすぎる値かもしれない。この理 由は、この値が全てのSAとDAで設定可能でなければならないこ とを意味する。 保護スコープのためのキー 地方自治が"保護スコープ"として特定のスコープを明示した場 合、それらのスコープを利用しているエージェントは、保護ス コープ内のサービスのために、広告されたURLと共にサービス から送られたデータを認証するためのキーを取得することがで きなければならない。例えば、サービスエージェントは認証デ ータを生成するのに秘密鍵を使用する。デフォルトでは、サー ビスエージェントは、サービス登録証明書と登録取消証明書を 含むように、かつ署名されたデータを生成するのに "md5WithRSAEncryption"[4]を使用する(付録B、4.3を参照)。 この認証データは、一致する公開鍵を持つユーザエージェント とディレクトリエージェントにより証明される。 22.1. サービス・エージェント: 定義済みディレクトリ・エージェントの利用 サービス・エージェントのデフォルト構成は、受動的に稼働中のDAを発見し、 適切にスコープされる全てのDAに登録することである。 サービス・エージェントは、オペレーションの特別なモードを認めるため設 定の変更が可能であるべきである。これには、前に配置されたDAのみを使用 する。これはDAを積極的に、あるいは受動的にも検出しないということを意 味する。 サービス・エージェントがこの方法で配置されている場合、DAの情報は静的 な構成、あるいはDHCPを使用して、別の経路で届かなければならない。 サービス情報の有用性は、DA間で一貫していない。結局DA間で一貫性を達成 するメカニズムは、それらのサービス情報が分散されないようにSAにより無 視される。利用するために配置されたDAが故障時には、SAをオープンしたま まにしておく。 Veizades, et. al. Standards Track [Page 62] RFC 2165 Service Location Protocol June 1997 22.2. タイムアウト間隔 サイトに配置されているサービス・ロケーションに特別な条件(非常に遅い リンクなど)がある場合、これらの値は設定の変更が可能にすべきである。 名称 章 デフォルト値 意味 ----------------- ------- ------------- ----------------------- CONFIG_INTERVAL_0 4.1 1分 XIDにより応答をキャッシュ する時間 CONFIG_INTERVAL_1 4.4 10800秒 広告が満了した登録ライフタ (例: 3時間) イム時間 CONFIG_INTERVAL_2 5 各秒、徐々に 新しい値が届くまでマルチキ 緩める ャストクエリーを試行する CONFIG_INTERVAL_3 5 15秒 完全なマルチキャストクエリ ー応答(全ての値)を待つ最大 値 CONFIG_INTERVAL_4 9 3秒 再起動時での登録待ち時間 CONFIG_INTERVAL_5 5.2 3秒 DAディスカバリーへの再送時 間、3回試みる CONFIG_INTERVAL_6 5.2 5秒 DAにリクエストを送るのを止 める時間 CONFIG_INTERVAL_7 5.2 15秒 DAディスカバリを止める時間 CONFIG_INTERVAL_8 5.1 15秒 SAにリクエストを送るのを止 める時間 CONFIG_INTERVAL_9 15.2 3時間 SAが受動的に新しいDAを検出 するためのDAの鼓動 CONFIG_INTERVAL_10 15.2 1-3秒 稼働中でないDAディスカバリ ーにサービスを登録するため に待つ時間 CONFIG_INTERVAL_11 9 1-3秒 稼働中のDAディスカバリーに サービスを登録するために待 つ時間 CONFIG_INTERVAL_12 18.1 5分 DAとSAが未使用のコネクショ ンをクローズするまでの時間 CONFIG_INTERVAL_9での注意: 一方で、常に鼓動を持つことが有利であるか もしれないが、多くのオーバーヘッドが発生する重大なリスクを引き起こす。 この値は、規定通りのプロトコルが大切な帯域幅を操作することを防ぐため に高く設定すべきである。 23. 設定の変更が不可能なパラメータ ディレクトリ・エージェントへのユニキャスト要求のIPポート番号を以下に 示す。 UDP/TCPポート番号: 427 Veizades, et. al. Standards Track [Page 63] RFC 2165 Service Location Protocol June 1997 マルチキャスト・アドレス サービス・ロケーション・ゼネラル・ マルチキャスト・アドレス: 224.0.1.22 ディレクトリ・エージェント・ディスカバリ・ マルチキャスト・アドレス: 224.0.1.35 サービス指定ディスカバリーマルチキャストアドレスとして使用される1024 以降のマルチキャストアドレスはIANAにより割り当てられる。 エラーコード: No Error 0 LANGUAGE_NOT_SUPPORTED 1 PROTOCOL_PARSE_ERROR 2 INVALID_REGISTRATION 3 SCOPE_NOT_SUPPORTED 4 CHARSET_NOT_UNDERSTOOD 5 AUTHENTICATION_ABSENT 6 AUTHENTICATION_FAILED 7 24. 謝辞 本プロトコルは他のサービス・ロケーション・プロトコルの既存のアイディ アを幾つかお借りしている。Leo McLaughlinとMike Ritter(Metricom)には 本ドキュメントの初期版で多くの入力をして頂いた。また、分散マルチキャ ストプロトコルではSteve Deering(Xerox)の見識を頂いたことに感謝する。 HarjonoとCharlie Perkinsにはリソース・ディスカバリー・プロトコルにお いてワイヤープロトコルをベースにしたURLの基礎を提供して頂いた。また、 Peerlogic, Inc.にはこの仕事をサポートしてくれたことに感謝する。最後 に、本ドキュメントに明記したセキュリティ・アーキテクチャ実現の手助け をしてくれたJeff Schillerに感謝する。 Veizades, et. al. Standards Track [Page 64] RFC 2165 Service Location Protocol June 1997 A. 付録: ISO 639より:1988 (E/F): "Code for the representation of names of languages" 小文字で2文字の記号が使用される。ISO 639[14]の登録局は、Infoterm、 Osterreiches Normungsinstitut(ON)、Postfach 130、A-1021 ウィーン、オ ーストリアである。ISO 639/RA Newsletter No.1/1989から追加分を含む。 RFC 1766を参照のこと。 aa Afar ga アイルランド語 mg マダガスカル語 ab Abkhazian gd スコットランドゲール語 mi マオリ語 af アフリカーンス語 gl Galician mk マケドニア語 am アムハラ語 gn グアラニー語 ml マラヤーラム語 ar アラビア語 gu Gujarati mn モンゴル語 as アッサム語 mo Moldavian ay Aymara ha Hausa mr Marathi az アゼルバイジャン語 he ヘブライ語 ms マレー語 hi ヒンディー語 mt マルタ語 ba Bashkir hr クロアチア語 my ビルマ語 be 白ロシア語 hu ハンガリー語 bg ブルガリア語 hy アルメニア語 na ナウル語 bh Bihari ne ネパール語 bi Bislama ia 国際語 nl オランダ語 bn ベンガル語 in インドネシア語 no ノルウェー語 bo チベット語 ie Interlingue br ブルトン語 ik Inupiak oc Occitan is アイスランド語 om (Afan) Oromo ca カタロニア語 it イタリア語 or Oriya co コルシカ方言 ja 日本語 cs チェコ語 jw ジャワ語 pa パンジャブ語 cy ウェールズ語 pl ポーランド語 ka ゲルジア語 ps Pashto, Pushto da デンマーク語 kk カザフ語 pt ポルトガル語 de ドイツ語 kl グリーンランド語 dz ブータン語 km カンボジア語 qu Quechua rw Kinyarwanda el ギリシャ語 kn Kannada rm Rhaeto-Romance en 英語 ko 韓国語 rn Kirundi eo エスペラント語 ks カシミール語 ro 古代ローマ語 es スペイン語 ku クルド語 ru ロシア語 et エストニア語 ky キルギス語 eu バスク語 la ラテン語 fa ペルシャ語 ln 舌音 fi フィンランド語 lo Laothian fj フィジー語 lt リトアニア語 fo Faeroese lv ラトビア語、レット語 fr フランス語 fy フリースランド語 Veizades, et. al. Standards Track [Page 65] RFC 2165 Service Location Protocol June 1997 sa サンスクリット語 ta タミル語 ug Uigar sd Sindhi te Telugu uk ウクライナ語 sg Sangro tg Tajik ur ウルドゥ語 sh セルボクロアチア語 th タイ語 uz ウズベク語 si シンハラ語 ti Tigrinya sk スロバキア語 tk トルクメン語 vi ベトナム語 sl スロベニア語 tl タガログ語 vo Volapuk sm サモア語 tn Setswana sn Shona to トンガ語 wo Wolof so ソマリ語 tr トルコ語 sq アルバニア語 ts Tsonga xh Xhosa sr セルビア語 tt タタール語 ss Siswati tw Twi yi イディッシュ語 st Sesotho yo Yoruba su Sundanese sv スウェーデン語 za Zhuang sw スワヒリ語 zh 中国語 zu ズールー語 B. SLP証明書 証明書はSLPにおいて、信頼され、保護スコープの公開鍵を供給するために 使用される。公開鍵を前提に、この付録はサービス・ロケーション・プロト コル内での証明書の使用を論議する。 保護スコープの秘密鍵の所有は、信頼されたSAであるということと等しい。 保護スコープの信頼性は、信頼されたホストにより保持されているこれらの 全秘密鍵に依存し、また合法なサービス登録/登録取消のためだけに使用す る。 正しい認証局(CA)へアクセスことにより、DAとUAは保護スコープと一致する 公開鍵を保持する必要がない(先進的である)。DAとUAは公開鍵をCAに要求す る。CAはそのユニークな秘密鍵を使用して証明書を生成する。この秘密鍵は 他のどのシステムとも共有されず、安全であり続けなければならない。証明 書は、証明書の満了日と同様に、与えられた保護スコープが、与えられた公 開鍵を持つことを宣言する。 証明書のASCII(mail-safe)文字列フォーマットは、下記のようにタグと値の ペアである。 "certificate-alg=" 1*ASN1CHAR CRLF "scope-charset=" 1*DIGIT CRLF "scope=" 1*RADIX-64-CHAR CRLF "timestamp=" 16HEXDIGIT CRLF Veizades, et. al. Standards Track [Page 66] RFC 2165 Service Location Protocol June 1997 "public-key=" 1*RADIX-64-CHAR CRLF "cert-digest=" 1*RADIX-64-CHAR CRLF ASN1CHAR = DIGIT | '.' HEXDIGIT = DIGIT | 'a'..'f' | 'A'..'F' RADIX-64-CHAR = DIGIT | 'a'..'z' | 'A'..'Z' | '+' | '/' | '=' radix-64表記法はRFC 1521[7]に記述されている。空白はRadix-64文字列と 一致するバイナリ値の計算において無視される。スコープ、公開鍵、あるい は認証ダイジェストの値が72文字を超える場合は、Radix-64表記法は行を分 けダイジェストを分割する。証明書の文字列の最初のカラムはタグの記入の みで開始する。これは(タグが正当なRadix-64値から成り立っているので) Radix-64値の解析で曖昧さを取り除く。 certificate-algは、"cert-digest"を生成するために使用されたアルゴリズ ムのオブジェクト識別子の値を持つASN.1文字列である。scope-charsetは、 スコープが表されている文字セットのMIBEnum値の10進表記である。 スコープ文字列のradix-64エンコーディングは、スコープ文字列がどのよう な文字セットのASCII表現でも認めている。 8バイトNTPフォーマットのタイムスタンプは、16進法で表現される。このタ イムスタンプは証明書が満了する時間である。 公開鍵のフォーマットは、certificate-algにより識別され、使用された暗 号システムのタイプに依存する。CAが取得される公開鍵を持つ証明書を生成 すると、証明書の文字エンコード上のダイジェストDを計算するために、 certificate-algにより識別されるメッセージダイジェストアルゴリズムを 使用する。CAはこの時、証明書に含まれる認証ダイジェストを生成するため に、CAの秘密鍵を使用してこの値を暗号化する。 CAはオフラインで証明書を生成する。証明書を配布するメカニズムは、サー ビス・ロケーション・プロトコルで指定されていないが、将来指定されるか もしれない。CAはメッセージダイジェストと公開鍵解読に使用するアルゴリ ズムを指定する。DA、あるいはSAは、CAのために前に配置された公開鍵を持 ち、かつ保護スコープのための公認の新しい公開鍵を取得するために、 certificate-algで指定されたアルゴリズムをサポートする証明書を取得す る必要があるだけである。 DA、あるいはUAは、certificate-algにより識別されたメッセージダイジェ ストアルゴリズムを使用して、メッセージダイジェストDを計算して証明書 を確認できる。 Veizades, et. al. Standards Track [Page 67] RFC 2165 Service Location Protocol June 1997 メッセージダイジェストアルゴリズムへのインプットは、認証ダイジェスト を除く、証明書の文字エンコードである。認証ダイジェストは、D'を生成す るCAの公開鍵を使用して解読される。DがD'と同一の場合、証明書は正当で ある。保護スコープの公開鍵は、証明書のタイムスタンプで示された満了日 まで使用される。 証明書は、必ず証明されなければいけないため、電子メール、あるいはファ イル転送のような、信頼のない経路を伝わって配布される。CAの公開鍵は信 頼のある経路を使用して配られなければならない。 C. MD5とRSAを使用したSLPセキュリティ配置例 我々のサイトに、保護スコープ"CONTROLLED"があるとする。我々は、RSAを 利用し、スコープの公開鍵のペアである秘密鍵を生成する。秘密鍵は、保護 スコープ内の全てのSAにより、秘密鍵リング上に保持される。公開鍵は、保 護スコープをサポートする全てのDAと、DAを利用する全てのSAで利用可能で ある。 URLを登録/登録取消するために、(4.3に記述があるように)認証されること が必要なデータは、デジタル署名を生成するためにMD5[22]を使用してダイ ジェストが行われ、この時、保護スコープの秘密鍵と共にRSAにより暗号化 される。RSAの出力は、認証者ブロックの認証者データフィールドで使用さ れる。 DA、あるいはUAは、認証ブロックの中を見て、認証を確認する適切な方法を 発見する。署名されたデータを確認するために、"md5WithRSAEncryption"[4] アルゴリズムが使用されると仮定する。DA、あるいはUAは、SAが正確に行っ たように、md5を使用してURLエントリのメッセージダイジェストを計算する。 認証者ブロックは、"CONTROLLED"という名前にあるUA、あるいはDAの公開鍵 リングにある"CONTROLLED"スコープのための公開鍵を使用して解読される。 UA、あるいはDAにより計算されたダイジェストが、SAのダイジェストと同じ ならば、そのURLエントリは有効である。 D. 可動ノードによるSLP証明書の使用例 例えば、可動ノードが保護スコープの利用を必要であるとする。最初、可動 ノードは1つの公開鍵をその公開鍵リングに付加することにより前もって配 置されている。我々はそれをCA-Keyと呼ぶ。このキーは、付録Bで記述した フォーマットでSLP証明書を取得するために使用される。対応する秘密鍵は、 必要なフォーマットの証明書を生成するためにCAにより使用される。 CAはネットワーク接続されていないコンピュータを使用して、システム管理 者により操作可能である。証明書の有効期限はサイトの方針に依存する。保 護されたスコープの期間、範囲、公開鍵は、'md5sum'の入力として使用され る。RSAがCAの秘密鍵を使用して、この合計は暗号化される。 Veizades, et. al. Standards Track [Page 68] RFC 2165 Service Location Protocol June 1997 このradix64エンコードは、付録Bで定義される証明書のエンコードに基づく mail-safe文字列に付加される。 保護スコープで"CONTROLLED"と呼ばれる証明書は、可動ノードで利用可能で ある。例えば、それはWebページにあるかもしれない。可動ノードは、 CONTROLLED範囲の公開鍵を取得するために、証明書を処理することができる。 このキーを本当に(付録Cのように)使用して良いのか、信頼する根拠は未だ 無い。信頼するためには、cert-digestを取り除き、ASCIIエンコードされた 証明書のmd5チェックサムを計算することである。次に、CAの公開鍵とRSAを 使用しているcert-digestを暗号化する。cert-digestがMD5の結果とマッチ するなら、その証明書は(満了するまで)信頼できる。 可動ノードは、動的に取得するために、1つのキー(CAキー)のみを必要とし、 保護スコープを利用する。我々が任意のUAにより、保護された範囲のSAにア クセス管理するどのようなメソッドも定義しないことに注意すること。 E. 付録: これ以外の記事 3つの関連したリソースディスカバリープロトコルは、AppleTalk protocol family[12]、Legato Resource Administration Platform[25]、Xerox Clearinghouse system[20]の一部であるNBPとZIPである。ドメイン名とアド レス表現は、サービス・ロケーション・プロトコルで広く使用される。これ らについてはRFC1034とRFC1035[17, 18]を参照のこと。ルータのディスカバ リープロトコルの例は、Router Discovery[10]とNeighbor Discovery[19]に 含まれる。 Veizades, et. al. Standards Track [Page 69] RFC 2165 Service Location Protocol June 1997 参考文献 [1] Unicode Technical Report #4. The unicode standard, version 1.1 (volumes 1 and 2). Technical Report (ISBN 0-201-56788-1) and (ISBN 0-201-60845-6), Unicode Consortium, 1994. [2] Alexander, S. and R. Droms. DHCP Options and BOOTP Vendor Extensions. RFC 2131, March 1997. [3] Atkinson, R. IP Encapsulating Security Payload. RFC 1827, August 1995. [4] Balenson, D. Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers. RFC 1423, February 1993. [5] Berners-Lee, T. and D. Connolly. Hypertext Markup Language - 2.0. RFC 1866, November 1995. [6] Berners-Lee, T., L. Masinter, and M. McCahill. Uniform Resource Locators (URL). RFC 1738, December 1994. [7] Borenstein, N. and N. Freed. MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies. RFC 2045, November 1996. [8] Bradner, Scott. Key words for use in RFCs to Indicate Requirement Levels. BCP 14, RFC 2119, March 1997. [9] CCITT. Specification of the Abstract Syntax Notation One (ASN.1). Recommendation X.208, 1988. [10] Deering, Stephen E., editor. ICMP Router Discovery Messages. RFC 1256, September 1991. [11] Droms, Ralph. Dynamic Host Configuration Protocol. RFC 2131, March 1997. [12] Gursharan, S., R. Andrews, and A. Oppenheimer. Inside AppleTalk. Addison-Wesley, 1990. [13] Guttman, E. The service: URL scheme, November 1996. Work In Progress. [14] Geneva ISO. Code for the representation of names of languages. ISO 639:1988 (E/F), 1988. Veizades, et. al. Standards Track [Page 70] RFC 2165 Service Location Protocol June 1997 [15] ISO 8879, Geneva. Information Processing -- Text and Office Systems - Standard Generalized Markup Language (SGML). , 1986. [16] Mills, D. Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI. RFC 2030, October 1996. [17] Mockapetris, P. Domain Names - Concepts and Facilities. STD 13, RFC 1034, November 1987. [18] Mockapetris, P. DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION. STD 13, RFC 1035, November 1987. [19] Narten, T., E. Nordmark, and W. Simpson. Neighbor Discovery for IP version 6 (IPv6). RFC 1970, August 1996. [20] Oppen, D. and Y. Dalal. The clearinghouse: A decentralized agent for locating named objects in a distributed environment. Technical Report Tech. Rep. OPD-78103, Xerox Office Products Division, 1981. [21] Perkins, C. DHCP Options for Service Location Protocol, August 1996. Work In Progress. [22] Rivest, Ronald. The MD5 Message-Digest Algorithm. RFC 1321, April 1992. [23] Schneier, Bruce. Applied Cryptography: Protocols, Algorithms, and Source Code in C. John Wiley, New York, NY, USA, 1994. [24] X/Open Preliminary Specification. File System Safe UCS Transformation Format (FSS_UTF). Technical Report Document Number: P316, X/Open Company Ltd., 1994. [25] Legato Systems. The Legato Resource Administration Platform. Legato Systems, 1991. Veizades, et. al. Standards Track [Page 71] RFC 2165 Service Location Protocol June 1997 著者の連絡先 このメモに関する質問は、以下の連絡先までお願いする。 John Veizades Erik Guttman @Home Network Sun Microsystems 385 Ravendale Dr. Gaisbergstr. 6 Mountain View, CA 94043 69115 Heidelberg Germany Phone: +1 415 944 7332 Phone: +1 415 336 6697 Fax: +1 415 944 8500 Email: veizades@home.com Email: Erik.Guttman@eng.sun.com Charles E. Perkins Scott Kaplan Sun Microsystems 2550 Garcia Avenue 346 Fair Oaks St. Mountain View, CA 94043 San Francisco, CA 94110 Phone: +1 415 336 7153 Phone: +1 415 285 4526 Fax: +1 415 336 0670 EMail: cperkins@Corp.sun.com Email: scott@catch22.com Veizades, et. al. Standards Track [Page 72]