RFC3059 日本語訳

Network Working Group                                         E. Guttman
Request for Comments: 3059                              Sun Microsystems
Category: Standards Track                                  February 2001

Guttmanがコメントのために要求するワーキンググループE.をネットワークでつないでください: 3059年のサン・マイクロシステムズカテゴリ: 標準化過程2001年2月

       Attribute List Extension for the Service Location Protocol

サービス位置のプロトコルのための属性リスト拡張子

Status of this Memo

この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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

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

Copyright(C)インターネット協会(2001)。 All rights reserved。

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.

Service Locationプロトコル、バージョン2(SLPv2)はサービスがメッセージのただ一つの交換で発見されるためにメカニズムを提供します。 メッセージのこの交換は現在、サービスの属性のいずれも含んでいません。 このドキュメントはUserエージェント(UA)が、サービスの属性が拡大としてService Replyメッセージに含められているよう要求できる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. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1。 用語. . . . . . . . . . . . . . . . . . . . . . . 2 1.2。 記法コンベンション. . . . . . . . . . . . . . . . . . 3 2。 リスト拡張子. . . . . . . . . . . . . . . . . . . 3 3を結果と考えてください。 IANA問題. . . . . . . . . . . . . . . . . . . . . . 4 4。 国際化問題. . . . . . . . . . . . . . 4 5。 セキュリティ問題. . . . . . . . . . . . . . . . . . . . 4 6。 承認. . . . . . . . . . . . . . . . . . . . . . . . 4参照. . . . . . . . . . . . . . . . . . . . . . . . . . . . 5作者のアドレスの.5の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 6

Guttman                     Standards Track                     [Page 1]

RFC 3059           Attribute List Extension for SLPv2      February 2001

SLPv2 February 2001のためのGuttman標準化過程[1ページ]RFC3059属性リスト拡張子

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.

Service Locationプロトコル(2[3]がサービスがメッセージのただ一つの交換で発見されるためにメカニズムを提供するバージョン)。 UAはService Requestメッセージを送ります、そして、DAかSAが(適宜)Service Replyメッセージを送ります。

   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.

すぐにすべてのサービス情報を得ることができるのは明確に有利です。 Service Locationプロトコルは異なった情報の種類を得るメッセージを切り離します。 この拡大はメッセージの基本的な交換に最適化を可能にします。(それは、現在、Service Replyメッセージにサービス属性を含んでいません)。

   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が、サービスの属性がService Replyメッセージに含まれているよう要求できる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拡張子をサポートしないと、それは単に、Service Reply(拡大のない)を返すでしょう。 この拡大のサポートはOPTIONALです。 特定番号をそれが認識されないなら受信機が拡大を無視しなければならないのを示す範囲からそれに割り当ててあるので、既存の実装はAttrlist拡張子を無視するでしょう。 RFC2608[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 ExtensionなしでService Replyメッセージを受け取るなら、それは、SAかDAが拡大をサポートしないと仮定しなければなりません。 この場合、UAはそれがこれらのサービスに属性を得るためにService Replyメッセージで得る各URLのためにAttribute Requestを送らなければなりません。

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)Aは、何らかのサービスで接触するようにユーザの代理に取り組みながら、処理します。 UAはServiceエージェントかディレクトリエージェントからのサービス情報を検索します。

   Service Agent (SA)
         A process working on the behalf of one or more services to
         advertise the services.

1の利益に取り組むプロセスか以上がサービスの広告を出すためにサービスを提供するエージェント(SA)にサービスを提供してください。

   Directory Agent (DA)
         A process which collects service advertisements.  There can
         only be one DA present per given host.

ディレクトリエージェント(DA)Aは処理します(サービス広告を集めます)。 与えられたホストあたりの現在の1DAしかあることができません。

Guttman                     Standards Track                     [Page 2]

RFC 3059           Attribute List Extension for SLPv2      February 2001

SLPv2 February 2001のためのGuttman標準化過程[2ページ]RFC3059属性リスト拡張子

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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[2]で説明されるように本書では解釈されることであるべきですか?

2. Attribute List Extension

2. 属性リスト拡張子

   The format of the Attribute List Extension is as follows:

Attribute List Extensionの形式は以下の通りです:

       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.../
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 拡大ID=0x0002| 次の拡大は相殺されました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オフセット、contd| サービスURL Length| サービスURL/ +++++++++++++++++++++++++++++++++| 属性リストの長さ| 属性リスト/+++++++++++++++++++++++++++++++++|# AttrAuthsについて|(存在しているなら) 認証ブロックを結果と考えてください…/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Extension ID is 0x0002.

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

Next Extension Offset値は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はService RequestとAttribute List Extensionを送ります。 Service URL LengthとAttribute List Lengthはこの場合省略されている0、Service URL、およびAttribute List分野に用意ができています。 その結果、UAは、SAかDAがService ReplyにService Requestにそのような'空'のAttribute List Extensionを含んでいることによってAttribute List Extensionを含んでいるよう要求します。

   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.

Attribute List ExtensionをサポートするSAかDAがService ReplyメッセージのあらゆるURL Entryのために1Attribute Listに拡大を返します。 中のURL Entriesと同じくらいがService ReplyであったならAttribute List Extensions SHOULDを注文してください。

   The Service URL [4] identifies the corresponding URL Entry.

Service URL[4]は対応するURL Entryを特定します。

   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.

Attribute List分野はサービスの全体の属性リストです。 Service Requestメッセージのそんなに示されるのと同じ言語にはこれらの属性があるに違いありません。

Guttman                     Standards Track                     [Page 3]

RFC 3059           Attribute List Extension for SLPv2      February 2001

SLPv2 February 2001のためのGuttman標準化過程[3ページ]RFC3059属性リスト拡張子

   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.

Service RequestメッセージがSLP SPIストリングを含んでいるなら、属性リスト拡張子は認証ブロックを含まなければなりません。 Service RequestにSLP SPIのための認証ブロックを含んでいて、SAかDAがどんなサポートもしないか、または戻ることができないなら、SAかDA MUST NOTがAttribute List Extensionを返します。 認証ブロックの形式はまさにAttribute ReplyかService Registrationメッセージに含まれているだろうというのと同じです。

3. IANA Considerations

3. IANA問題

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

IANAはAttribute List Extensionのために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には、Service Locationプロトコルであり、明白な言語が[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.

Service Locationプロトコル、バージョン2には固有識別文字が属性リストと共に返されるのを許容するためのメカニズムがあるので、UAsはそれらが得る属性の上のデジタル署名について確かめることができます。 この同じメカニズムはこのプロトコル拡大に使用されます。 SLPv2に関連して使用されるAttribute List Extensionは拡大のないSLPv2ほど安全でないというわけではありません。

6. Acknowledgments

6. 承認

   The author benefited from preliminary conversations about this
   extension with Charlie Perkins.

作者はチャーリー・パーキンスとのこの拡大に関して予備の会話の利益を得ました。

Guttman                     Standards Track                     [Page 4]

RFC 3059           Attribute List Extension for SLPv2      February 2001

SLPv2 February 2001のためのGuttman標準化過程[4ページ]RFC3059属性リスト拡張子

References

参照

   [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
       9, RFC 2026, October 1996.

[1] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」

   [2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
       Levels", BCP 14, RFC 2119, March 1997.

[2] ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、BCP14、RFC2119、1997年3月。

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

[3] Guttman(E.、パーキンス、C.、Veizades、J.、およびM.日)は「1999年6月にRFC2608を位置のプロトコル、バージョン2インチ調整します」。

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

[4] Guttman(E.、パーキンス、C.、およびJ.ケンフ)は「Templatesを調整して、以下を修理します」。 「体系」、RFC2609、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問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。

   [6] Alvestrand, H., "Tags for the Identification of Languages", BCP
       47, RFC 3066, January 2001.

Alvestrand(H.)が「言語の識別のためにタグ付けをする」[6]、BCP47、RFC3066、2001年1月。

Author's Address

作者のアドレス

   Erik Guttman
   Sun Microsystems
   Eichhoelzelstr. 7
   74915 Waibstadt
   Germany

エリックGuttmanサン・マイクロシステムズEichhoelzelstr。 7 74915Waibstadtドイツ

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

以下に電話をしてください。 +49 6227 356 202はメールされます: Erik.Guttman@sun.com

Guttman                     Standards Track                     [Page 5]

RFC 3059           Attribute List Extension for SLPv2      February 2001

SLPv2 February 2001のためのGuttman標準化過程[5ページ]RFC3059属性リスト拡張子

Full Copyright Statement

完全な著作権宣言文

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

Copyright(C)インターネット協会(2001)。 All rights reserved。

   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.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

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

Guttman                     Standards Track                     [Page 6]

Guttman標準化過程[6ページ]