[要約] RFC 3059は、Service Location Protocol（SLP）の属性リスト拡張に関する仕様です。このRFCの目的は、SLPの機能を拡張し、ネットワーク上のサービスの発見と管理をより効果的に行うことです。
Network Working Group E. Guttman
Request for Comments: 3059 Sun Microsystems
Category: Standards Track February 2001
Attribute List Extension for the Service Location Protocol
サービスロケーションプロトコルの属性リスト拡張子
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
Abstract
概要
The Service Location Protocol, Version 2 (SLPv2) provides a mechanism for a service to be discovered in a single exchange of messages. This exchange of messages does not presently include any of the service's attributes. This document specifies a SLPv2 extension which allows a User Agent (UA) to request a service's attributes be included as an extension to Service Reply messages. This will eliminate the need for multiple round trip messages for a UA to acquire all service information.
サービスロケーションプロトコル、バージョン2（SLPV2）は、単一のメッセージ交換でサービスを発見するメカニズムを提供します。このメッセージの交換には、現在、サービスの属性は含まれていません。このドキュメントは、ユーザーエージェント（UA）がサービスの返信メッセージの拡張機能としてサービスの属性を要求できるようにするSLPV2拡張機能を指定します。これにより、UAがすべてのサービス情報を取得するための複数の往復メッセージが必要になります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Notation Conventions . . . . . . . . . . . . . . . . . . 3
2. Attribute List Extension . . . . . . . . . . . . . . . . . . . 3
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
4. Internationalization Considerations . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 6
The Service Location Protocol, Version 2 [3] provides a mechanism for a service to be discovered in a single exchange of messages. The UA sends a Service Request message and the DA or SA (as appropriate) sends a Service Reply message.
サービスロケーションプロトコル、バージョン2 [3]は、単一のメッセージ交換でサービスを発見するメカニズムを提供します。UAはサービスリクエストメッセージを送信し、DAまたはSA（必要に応じて）はサービス返信メッセージを送信します。
It is clearly advantageous to be able to obtain all service information at once. The Service Location Protocol separates messages which obtain different classes of information. This extension enables an optimization to the basic exchange of messages, which currently does not include service attributes in Service Reply messages.
すべてのサービス情報を一度に取得できることは明らかに有利です。サービスロケーションプロトコルは、さまざまなクラスの情報を取得するメッセージを分離します。この拡張機能により、メッセージの基本的な交換を最適化できます。これには、現在サービス属性にサービス属性が含まれていません。
This document specifies a SLPv2 extension which allows a UA to request that a service's attributes be included in Service Reply messages. This will eliminate the need for multiple round trip messages for a UA to acquire all service information.
このドキュメントは、UAがサービスの返信メッセージにサービスの属性を含めることを要求できるSLPV2拡張機能を指定します。これにより、UAがすべてのサービス情報を取得するための複数の往復メッセージが必要になります。
If the DA or SA does not support the Attrlist extension, it will simply return a Service Reply (without the extension). Support of this extension is OPTIONAL. Existing implementations will ignore the Attrlist extension since it has been assigned a identifying number from the range which indicates that the receiver MUST ignore the extension if it is not recognized. See RFC 2608 [3].
DAまたはSAがアトリスト拡張機能をサポートしていない場合、単にサービスの返信を返します（拡張機能なし）。この拡張機能のサポートはオプションです。既存の実装では、範囲から識別番号が割り当てられているため、既存の実装は無視します。これは、レシーバーが認識されていない場合は拡張機能を無視する必要があることを示します。RFC 2608 [3]を参照してください。
If the UA receives a Service Reply message without an Attrlist Extension it must assume the SA or DA does not support the extension. In this case, the UA must send an Attribute Request for each URL it obtains in the Service Reply message in order to obtain the attributes for these services.
UAがアトリスト拡張機能のないサービス返信メッセージを受信した場合、SAまたはDAが拡張機能をサポートしていないと仮定する必要があります。この場合、UAは、これらのサービスの属性を取得するために、サービス返信メッセージで取得する各URLの属性要求を送信する必要があります。
User Agent (UA) A process working on the user's behalf to establish contact with some service. The UA retrieves service information from the Service Agents or Directory Agents.
ユーザーエージェント（UA）ユーザーに代わって取り組んでいるプロセスは、サービスとの連絡を確立します。UAは、サービスエージェントまたはディレクトリエージェントからサービス情報を取得します。
Service Agent (SA) A process working on the behalf of one or more services to advertise the services.
サービスエージェント（SA）サービスを宣伝するための1つ以上のサービスに代わって作業するプロセス。
Directory Agent (DA) A process which collects service advertisements. There can only be one DA present per given host.
ディレクトリエージェント（DA）サービス広告を収集するプロセス。指定されたホストごとに存在するDAは1つしかありません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [2]に記載されているように解釈される。
The format of the Attribute List Extension is as follows:
属性リスト拡張子の形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension ID = 0x0002 | Next Extension Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset, contd.| Service URL Length | Service URL /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute List Length | Attribute List /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|# of AttrAuths |(if present) Attribute Authentication Blocks.../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Extension ID is 0x0002.
拡張機能IDは0x0002です。
The Next Extension Offset value indicates the position of the next extension as offset from the beginning of the SLP message. If the next extension offset value is 0, there are no more extensions in the message.
次の拡張オフセット値は、SLPメッセージの先頭からのオフセットとしての次の拡張機能の位置を示します。次の拡張オフセット値が0の場合、メッセージに拡張機能はもうありません。
A UA sends an Attribute List Extension with a Service Request. The Service URL Length and Attribute List Length are set to 0 and the Service URL and Attribute List fields omitted in this case. The UA thereby requests that the SA or DA include an Attribute List Extension in its Service Reply by including such an 'empty' Attribute List Extension in the Service Request.
UAは、サービスリクエストを使用して属性リスト拡張子を送信します。サービスURLの長さと属性リストの長さは0に設定され、この場合は省略されているサービスURLおよび属性リストフィールドが省略されています。これにより、UAは、SAまたはDAに、サービスリクエストにこのような「空の」属性リスト拡張子を含めることにより、サービス返信に属性リスト拡張子を含めることを要求します。
A SA or DA which supports the Attribute List Extension returns one Attribute List extension for every URL Entry in the Service Reply message. The order of the Attribute List Extensions SHOULD be the same as the URL Entries in the Service Reply.
属性リスト拡張子をサポートするSAまたはDAは、サービス返信メッセージのすべてのURLエントリに対して1つの属性リスト拡張子を返します。属性リスト拡張機能の順序は、サービス返信のURLエントリと同じでなければなりません。
The Service URL [4] identifies the corresponding URL Entry.
サービスURL [4]は、対応するURLエントリを識別します。
The Attribute List field is the entire attribute list of the service. These attributes must be in the same language as that indicated in the Service Request message.
属性リストフィールドは、サービスの属性リスト全体です。これらの属性は、サービス要求メッセージに示されているものと同じ言語でなければなりません。
If the Service Request message includes a SLP SPI string, then the attribute list extension MUST include an authentication block. If the SA or DA does not support or is unable to return an authentication block for the SLP SPI included in the Service Request, then the SA or DA MUST NOT return an Attribute List Extension. The format of the authentication block(s) is exactly the same as would be included in an Attribute Reply or Service Registration message.
サービス要求メッセージにSLP SPI文字列が含まれている場合、属性リスト拡張子には認証ブロックを含める必要があります。SAまたはDAがサービスリクエストに含まれるSLP SPIの認証ブロックをサポートしていない、または返すことができない場合、SAまたはDAは属性リスト拡張子を返してはなりません。認証ブロックの形式は、属性の返信またはサービス登録メッセージに含まれるものとまったく同じです。
IANA has assigned an extension ID number of 0x0002 for the Attribute List Extension.
IANAは、属性リスト拡張子に拡張機能ID番号0x0002を割り当てました。
The Service Location Protocol, version 2 has mechanisms for allowing attributes to be transmitted with explicit language tagging [6]. The same mechanisms are used for this protocol extension.
サービスロケーションプロトコルであるバージョン2には、属性を明示的な言語タグ付けで送信できるメカニズムがあります[6]。このプロトコル拡張には同じメカニズムが使用されます。
The Service Location Protocol, version 2 has mechanisms for allowing authenticators to be returned with attribute lists so that UAs are able to verify a digital signature over the attributes they obtain. This same mechanism is used for this protocol extension. The Attribute List Extension used in conjunction with SLPv2 is no less secure than SLPv2 without the extension.
Service Location Protocol、バージョン2には、Authenticatorを属性リストで返すことができるメカニズムがあり、UASが取得した属性に対するデジタル署名を検証できるようにします。この同じメカニズムは、このプロトコル拡張に使用されます。SLPV2と組み合わせて使用される属性リスト拡張は、拡張機能なしでSLPV2と同じくらい安全です。
The author benefited from preliminary conversations about this extension with Charlie Perkins.
著者は、チャーリー・パーキンスとのこの延長に関する予備的な会話の恩恵を受けました。
References
参考文献
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[1] Bradner、S。、「インターネット標準プロセス - リビジョン3」、BCP 9、RFC 2026、1996年10月。
[2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
[3] Guttman、E.、Perkins、C.、Veizades、J。and M. Day、「Service Location Protocol、Version 2」、RFC 2608、1999年6月。
[4] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and service: Schemes", RFC 2609, June 1999.
[4] Guttman、E.、Perkins、C。and J. Kempf、「サービステンプレートとサービス：スキーム」、RFC 2609、1999年6月。
[5] Narten, T and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[5] Narten、TおよびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[6] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
[6] Alvestrand、H。、「言語の識別のためのタグ」、BCP 47、RFC 3066、2001年1月。
Author's Address
著者の連絡先
Erik Guttman Sun Microsystems Eichhoelzelstr. 7 74915 Waibstadt Germany
Erik Guttman Sun Microsystems Eichhoelzelstr。7 74915 Waibstadtドイツ
Phone: +49 6227 356 202
EMail: Erik.Guttman@sun.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。