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.

著作権(C)インターネット協会(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
        
1. Introduction
1. はじめに

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がATTRLIST拡張をサポートしていない場合、それは単に(拡張子なし)サービス応答を返します。この拡張機能のサポートはオプションです。それが認識されない場合、受信機は、拡張子を無視しなければならないことを示す範囲から識別番号が割り当てられているので、既存の実装はATTRLIST拡張子を無視します。 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がATTRLIST拡張せずにサービスの応答メッセージを受信した場合には、SAまたはDAが拡張をサポートしていないと仮定しなければなりません。この場合、UAは、それは、これらのサービスの属性を取得するために、サービスの応答メッセージで取得した各URLのための属性要求を送信する必要があります。

1.1. Terminology
1.1. 用語

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.2. Notation Conventions
1.2. 表記規則

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].

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[2]。

2. Attribute List Extension
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は0×0002です。

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は、属性リストの拡張を返してはなりません。認証ブロック(S)のフォーマットは、属性返信またはサービス登録メッセージに含まれるであろうと全く同じです。

3. IANA Considerations
3. IANAの考慮事項

IANA has assigned an extension ID number of 0x0002 for the Attribute List Extension.

IANAは、属性リストの拡張のために0×0002の拡張のID番号が割り当てられています。

4. Internationalization Considerations
4.国際化に関する注意事項

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]。同機構は、このプロトコルの拡張のために使用されます。

5. Security Considerations
5.セキュリティについての考慮事項

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.

サービスロケーションプロトコル、バージョン2は、UAが、彼らが取得する属性を介してデジタル署名を検証することができるようにオーセンティケータは、属性リストを返すことができるようにするためのメカニズムを持っています。この同じメカニズムは、このプロトコル拡張のために使用されています。一覧拡張子がSLPv2のと併せて使用される属性は、拡張子なしSLPv2のよりも少ない安全なものはありません。

6. Acknowledgments
6.謝辞

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]ブラドナーの、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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。

[3] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.

[3]ガットマン、E.、パーキンス、C.、Veizades、J.とM.日、 "サービスロケーションプロトコル、バージョン2"、RFC 2608、1999年6月。

[4] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and service: Schemes", RFC 2609, June 1999.

[4]ガットマン、E.、パーキンス、C.及びJ.ケンプ、 "サービステンプレートおよびサービス:スキーム"、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

エリック・グットマンSun MicrosystemsのEichhoelzelstr。 7 74915ヴァイプシュタットドイツ

Phone: +49 6227 356 202 EMail: Erik.Guttman@sun.com

電話:+49 6227 356 202 Eメール:Erik.Guttman@sun.com

Full Copyright Statement

完全な著作権声明

Copyright (C) The Internet Society (2001). All Rights Reserved.

著作権(C)インターネット協会(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 Editor機能のための基金は現在、インターネット協会によって提供されます。