RFC2608 日本語訳
2608 Service Location Protocol, Version 2. E. Guttman, C. Perkins, J.Veizades, M. Day. June 1999. (Format: TXT=129475 bytes) (Updates RFC2165) (Updated by RFC3224) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group E. Guttman
Request for Comments: 2608 C. Perkins
Updates: 2165 Sun Microsystems
Category: Standards Track J. Veizades
@Home Network
M. Day
Vinca Corporation
June 1999
Guttmanがコメントのために要求するワーキンググループE.をネットワークでつないでください: 2608のC.パーキンスアップデート: 2165年のサン・マイクロシステムズカテゴリ: 規格はツルニチニチソウ社の1999年6月にJ.Veizades@Home Network M.日を追跡します。
Service Location Protocol, Version 2
サービス位置のプロトコル、バージョン2
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
Abstract
要約
The Service Location Protocol provides a scalable framework for the discovery and selection of network services. Using this protocol, computers using the Internet need little or no static configuration of network services for network based applications. This is especially important as computers become more portable, and users less tolerant or able to fulfill the demands of network system administration.
Service Locationプロトコルはネットワーク・サービスの発見と品揃えにスケーラブルなフレームワークを提供します。 このプロトコルを使用して、ネットワークにインターネットの必要性まずネットワーク・サービスの静的な構成を使用しないコンピュータがアプリケーションを基礎づけました。 コンピュータが、より携帯用になるのでこれが特に重要であり、ユーザは、許容性があるか、またはネットワークシステム管理の要求をより実現させることができません。
Table of Contents
目次
1. Introduction 3
1.1. Applicability Statement . . . . . . . . . . . . . . . 3
2. Terminology 4
2.1. Notation Conventions . . . . . . . . . . . . . . . . . 4
3. Protocol Overview 5
4. URLs used with Service Location 8
4.1. Service: URLs . . . . . . . . . . . . . . . . . . . . 9
4.2. Naming Authorities . . . . . . . . . . . . . . . . . 10
4.3. URL Entries . . . . . . . . . . . . . . . . . . . . . 10
5. Service Attributes 10
6. Required Features 12
6.1. Use of Ports, UDP, and Multicast . . . . . . . . . . 13
1. 序論3 1.1。 適用性証明. . . . . . . . . . . . . . . 3 2。 用語4 2.1。 記法コンベンション. . . . . . . . . . . . . . . . . 4 3。 概要5 4について議定書の中で述べてください。 Service Location8 4.1と共に使用されるURL。 サービス: URL. . . . . . . . . . . . . . . . . . . . 9 4.2。 当局. . . . . . . . . . . . . . . . . 10 4.3を任命します。 URLエントリー. . . . . . . . . . . . . . . . . . . . . 10 5。 属性10 6を修理してください。 必要な特徴12 6.1。 ポート、UDP、およびマルチキャスト. . . . . . . . . . 13の使用
Guttman, et al. Standards Track [Page 1] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[1ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
6.2. Use of TCP . . . . . . . . . . . . . . . . . . . . . 14
6.3. Retransmission of SLP messages . . . . . . . . . . . 15
6.4. Strings in SLP messages . . . . . . . . . . . . . . . 16
6.4.1. Scope Lists in SLP . . . . . . . . . . . . . . 16
7. Errors 17
8. Required SLP Messages 17
8.1. Service Request . . . . . . . . . . . . . . . . . . . 19
8.2. Service Reply . . . . . . . . . . . . . . . . . . . . 21
8.3. Service Registration . . . . . . . . . . . . . . . . . 22
8.4. Service Acknowledgment . . . . . . . . . . . . . . . . 23
8.5. Directory Agent Advertisement. . . . . . . . . . . . . 24
8.6. Service Agent Advertisement. . . . . . . . . . . . . . 25
9. Optional Features 26
9.1. Service Location Protocol Extensions . . . . . . . . . 27
9.2. Authentication Blocks . . . . . . . . . . . . . . . . 28
9.2.1. SLP Message Authentication Rules . . . . . . . 29
9.2.2. DSA with SHA-1 in Authentication Blocks . . . 30
9.3. Incremental Service Registration . . . . . . . . . . 30
9.4. Tag Lists . . . . . . . . . . . . . . . . . . . . . . 31
10. Optional SLP Messages 32
10.1. Service Type Request . . . . . . . . . . . . . . . . 32
10.2. Service Type Reply . . . . . . . . . . . . . . . . . 32
10.3. Attribute Request . . . . . . . . . . . . . . . . . . 33
10.4. Attribute Reply . . . . . . . . . . . . . . . . . . . 34
10.5. Attribute Request/Reply Examples . . . . . . . . . . . 34
10.6. Service Deregistration . . . . . . . . . . . . . . . 36
11. Scopes 37
11.1. Scope Rules . . . . . . . . . . . . . . . . . . . . . 37
11.2. Administrative and User Selectable Scopes. . . . . . . 38
12. Directory Agents 38
12.1. Directory Agent Rules . . . . . . . . . . . . . . . . 39
12.2. Directory Agent Discovery . . . . . . . . . . . . . . 39
12.2.1. Active DA Discovery . . . . . . . . . . . . . 40
12.2.2. Passive DA Advertising . . . . . . . . . . . . 40
12.3. Reliable Unicast to DAs and SAs. . . . . . . . . . . . 41
12.4. DA Scope Configuration . . . . . . . . . . . . . . . 41
12.5. DAs and Authentication Blocks. . . . . . . . . . . . . 41
13. Protocol Timing Defaults 42
14. Optional Configuration 43
15. IANA Considerations 44
16. Internationalization Considerations 45
17. Security Considerations 46
A. Appendix: Changes to the Service Location Protocol from
v1 to v2 48
B. Appendix: Service Discovery by Type: Minimal SLPv2 Features 48
C. Appendix: DAAdverts with arbitrary URLs 49
D. Appendix: SLP Protocol Extensions 50
D.1. Required Attribute Missing Option . . . . . . . . . . 50
6.2. TCP. . . . . . . . . . . . . . . . . . . . . 14 6.3の使用。 SLPメッセージ. . . . . . . . . . . 15 6.4のRetransmission。 SLPメッセージ. . . . . . . . . . . . . . . 16 6.4.1におけるストリング。 範囲はSLP. . . . . . . . . . . . . . 16 7に記載します。 誤り17 8。 必要なSLPメッセージ17 8.1。 要求. . . . . . . . . . . . . . . . . . . 19 8.2を修理してください。 回答. . . . . . . . . . . . . . . . . . . . 21 8.3を修理してください。 登録. . . . . . . . . . . . . . . . . 22 8.4を修理してください。 承認. . . . . . . . . . . . . . . . 23 8.5を修理してください。 ディレクトリエージェント広告。 . . . . . . . . . . . . 24 8.6. エージェント広告を修理してください。 . . . . . . . . . . . . . 25 9. オプション機能26 9.1。 位置のプロトコル拡大. . . . . . . . . 27 9.2を修理してください。 認証ブロック. . . . . . . . . . . . . . . . 28 9.2.1。 SLP通報認証は.2に.299.2を統治します。 認証におけるSHA-1とDSAは.309.3を妨げます。 増加のサービス登録. . . . . . . . . . 30 9.4。 リスト. . . . . . . . . . . . . . . . . . . . . . 31 10にタグ付けをしてください。 任意のSLPメッセージ32 10.1。 タイプ要求. . . . . . . . . . . . . . . . 32 10.2を修理してください。 タイプ回答. . . . . . . . . . . . . . . . . 32 10.3を修理してください。 要求. . . . . . . . . . . . . . . . . . 33 10.4を結果と考えてください。 回答. . . . . . . . . . . . . . . . . . . 34 10.5を結果と考えてください。 要求/回答の例. . . . . . . . . . . 34 10.6を結果と考えてください。 Deregistration. . . . . . . . . . . . . . . 36 11を調整してください。 範囲37 11.1。 範囲は.37 11.2を統治します。 管理とユーザの選択可能な範囲。 . . . . . . 38 12. ディレクトリエージェント38 12.1。 ディレクトリエージェント規則. . . . . . . . . . . . . . . . 39 12.2。 ディレクトリエージェント発見. . . . . . . . . . . . . . 39 12.2.1。 活発なDA発見. . . . . . . . . . . . . 40 12.2.2。 受け身のDA広告. . . . . . . . . . . . 40 12.3。 DAsとSAsへの信頼できるユニキャスト。 . . . . . . . . . . . 41 12.4. DA範囲構成. . . . . . . . . . . . . . . 41 12.5。 DAsと認証ブロック。 . . . . . . . . . . . . 41 13. タイミングデフォルト42 14について議定書の中で述べてください。 任意の構成43 15。 IANA問題44 16。 国際化問題45 17。 セキュリティ問題46A.付録: v1からv2 48B.AppendixまでのService Locationプロトコルへの変化: タイプによる発見を修理してください: 最小量のSLPv2の特徴48C.付録: 任意のURL49 D.AppendixとDAAdverts: SLPは拡大50D.1について議定書の中で述べます。 必要な属性なくなったオプション. . . . . . . . . . 50
Guttman, et al. Standards Track [Page 2] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[2ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
E. Acknowledgments 50
F. References 51
G. Authors' Addresses 53
H. Full Copyright Statement 54
G.作者のE.承認50F.参照51ものは、53時間完全な著作権が声明54であると扱います。
1. Introduction
1. 序論
The Service Location Protocol (SLP) provides a flexible and scalable framework for providing hosts with access to information about the existence, location, and configuration of networked services. Traditionally, users have had to find services by knowing the name of a network host (a human readable text string) which is an alias for a network address. SLP eliminates the need for a user to know the name of a network host supporting a service. Rather, the user supplies the desired type of service and a set of attributes which describe the service. Based on that description, the Service Location Protocol resolves the network address of the service for the user.
Service Locationプロトコル(SLP)はネットワークでつながれたサービスの存在、位置、および構成に関してフレキシブルでスケーラブルなフレームワークを情報入手をホストに提供するのに提供します。 伝統的に、ユーザは、ネットワーク・アドレスで別名であるネットワークホスト(人間の読み込み可能なテキスト文字列)の名前を知っていることによって、職に就かなければなりませんでした。 SLPはユーザがサービスをサポートするネットワークホストの名前を知る必要性を排除します。 むしろ、ユーザは必要なタイプのサービスとサービスについて説明する1セットの属性を供給します。 その記述に基づいて、Service Locationプロトコルはユーザのためのサービスのネットワーク・アドレスを決議します。
SLP provides a dynamic configuration mechanism for applications in local area networks. Applications are modeled as clients that need to find servers attached to any of the available networks within an enterprise. For cases where there are many different clients and/or services available, the protocol is adapted to make use of nearby Directory Agents that offer a centralized repository for advertised services.
SLPはローカル・エリア・ネットワークで動的設定メカニズムをアプリケーションに提供します。 サーバを見つける必要があるクライアントが企業の中で利用可能なネットワークのどれかに付いたので、アプリケーションはモデル化されます。 利用可能な多くの異なったクライアント、そして/または、サービスがあるケースにおいて、プロトコルは、広告を出しているサービスのために集結された倉庫を提供する近いディレクトリエージェントを利用するために適合させられます。
This document updates SLPv1 [RFC 2165], correcting protocol errors, adding some enhancements and removing some requirements. This specification has two parts. The first describes the required features of the protocol. The second describes the extended features of the protocol which are optional, and allow greater scalability.
プロトコル誤りを修正して、いくつかの増進を加えて、いくつかの要件を取り除いて、このドキュメントはSLPv1[RFC2165]をアップデートします。 この仕様には、2つの部品があります。 1番目はプロトコルの必要な特徴について説明します。 2番目は任意であり、よりすばらしいスケーラビリティを許容するプロトコルの拡張特徴について説明します。
1.1. Applicability Statement
1.1. 適用性証明
SLP is intended to function within networks under cooperative administrative control. Such networks permit a policy to be implemented regarding security, multicast routing and organization of services and clients into groups which are not be feasible on the scale of the Internet as a whole.
SLPが協力的な運営管理コントロールの下におけるネットワークの中で機能することを意図します。 そのようなネットワークは、政策がサービスとクライアントのセキュリティ、マルチキャストルーティング、および組織に関してそうしないグループに実施されることを許可します。全体でインターネットのスケールで可能であってください。
SLP has been designed to serve enterprise networks with shared services, and it may not necessarily scale for wide-area service discovery throughout the global Internet, or in networks where there are hundreds of thousands of clients or tens of thousands of services.
SLPは共有されたサービスを企業網に供給するように設計されています、そして、それは広い領域サービス発見のために必ず世界的なインターネット中、または、何十万人ものクライアントか何万ものサービスがあるネットワークで比例するかもしれないというわけではありません。
Guttman, et al. Standards Track [Page 3] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[3ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
2. Terminology
2. 用語
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しかあることができません。
Service Type Each type of service has a unique Service Type
string.
サービスのサービスType Eachタイプには、ユニークなService Typeストリングがあります。
Naming Authority The agency or group which catalogues given
Service Types and Attributes. The default Naming
Authority is IANA.
Service TypesとAttributesを考えて、カタログに載る政府機関かグループとAuthorityを命名します。 デフォルトNaming AuthorityはIANAです。
Scope A set of services, typically making up a logical
administrative group.
Aが設定した論理的な管理グループを通常構成しているサービスの範囲。
URL A Universal Resource Locator [8].
URLのA普遍的なリソースロケータ[8]。
2.1. Notation Conventions
2.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 [9].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[9]で説明されるように本書では解釈されることであるべきですか?
Syntax Syntax for string based protocols follow the
conventions defined for ABNF [11].
ストリングがプロトコルを基礎づけたので、構文SyntaxはABNF[11]のために定義されたコンベンションに続きます。
Strings All strings are encoded using the UTF-8 [23]
transformation of the Unicode [6] character set and
are NOT null terminated when transmitted. Strings
are preceded by a two byte length field.
Allが結ぶストリングは、ユニコード[6]文字集合のUTF-8[23]変換を使用することでコード化されて、伝えられる場合、終えられた状態でヌルではありません。 2バイトの長さの分野はストリングに先行します。
<string-list> A comma delimited list of strings with the
following syntax:
リスト>Aを結んでいる<コンマは以下の構文でストリングのリストを区切りました:
string-list = string / string `,' string-list
''ストリングリスト=ストリング/ストリング'、ストリングリスト
In format diagrams, any field ending with a \ indicates a variable length field, given by a prior length field in the protocol.
形式ダイヤグラムで、\があるどんな分野結末もプロトコルの先の長さの分野によって与えられた可変長フィールドを示します。
Guttman, et al. Standards Track [Page 4] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[4ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
3. Protocol Overview
3. プロトコル概要
The Service Location Protocol supports a framework by which client applications are modeled as 'User Agents' and services are advertised by 'Service Agents.' A third entity, called a 'Directory Agent' provides scalability to the protocol.
プロトコルが'ディレクトリエージェント'が、'ユーザエージェント'とサービスが'サービスエージェント'A3番目の実体によって広告に掲載されるときクライアントアプリケーションがモデル化されると呼んだフレームワークをサポートするService Locationはスケーラビリティをプロトコルに提供します。
The User Agent issues a 'Service Request' (SrvRqst) on behalf of the client application, specifying the characteristics of the service which the client requires. The User Agent will receive a Service Reply (SrvRply) specifying the location of all services in the network which satisfy the request.
Userエージェントはクライアントアプリケーションを代表して'サービスRequest'(SrvRqst)を発行します、クライアントが必要とするサービスの特性を指定して。 Userエージェントは、ネットワークにおける要望に応じるすべてのサービスの位置を指定しながら、Service Reply(SrvRply)を受け取るでしょう。
The Service Location Protocol framework allows the User Agent to directly issue requests to Service Agents. In this case the request is multicast. Service Agents receiving a request for a service which they advertise unicast a reply containing the service's location.
Service Locationプロトコルフレームワークで、Userエージェントは直接Serviceエージェントに要求を出すことができます。 この場合、要求はマルチキャストです。 彼らが広告を出すサービスを求める要求を受け取って、エージェントにサービスを提供してください。サービスの位置を含むユニキャストa回答。
+------------+ ----Multicast SrvRqst----> +---------------+
| User Agent | | Service Agent |
+------------+ <----Unicast SrvRply------ +---------------+
+------------+ ----マルチキャストSrvRqst---->+---------------+ | ユーザエージェント| | サービスエージェント| +------------+ <。----ユニキャストSrvRply------ +---------------+
In larger networks, one or more Directory Agents are used. The Directory Agent functions as a cache. Service Agents send register messages (SrvReg) containing all the services they advertise to Directory Agents and receive acknowledgements in reply (SrvAck). These advertisements must be refreshed with the Directory Agent or they expire. User Agents unicast requests to Directory Agents instead of Service Agents if any Directory Agents are known.
より大きいネットワーク1人以上のディレクトリエージェントは使用されています。 ディレクトリエージェントはキャッシュとして機能します。 サービスエージェントは、それらがディレクトリエージェントに広告を出すすべてのサービスを含むレジスタメッセージ(SrvReg)を送って、回答(SrvAck)で承認を受けます。 ディレクトリエージェントと共にこれらの広告をリフレッシュしなければならない、さもなければ、それらは期限が切れます。 ユーザエージェントユニキャストは、ディレクトリエージェントが知られているようもしあればServiceエージェントの代わりにディレクトリエージェントに要求します。
+-------+ -Unicast SrvRqst-> +-----------+ <-Unicast SrvReg- +--------+ | User | | Directory | |Service | | Agent | | Agent | | Agent | +-------+ <-Unicast SrvRply- +-----------+ -Unicast SrvAck-> +--------+
+-------+ ユニキャストSrvRqst->+-----------+ <-ユニキャストSrvReg+--------+ | ユーザ| | ディレクトリ| |サービス| | エージェント| | エージェント| | エージェント| +-------+ <-ユニキャストSrvRply+-----------+ ユニキャストSrvAck->+--------+
User and Service Agents discover Directory Agents two ways. First,
they issue a multicast Service Request for the 'Directory Agent'
service when they start up. Second, the Directory Agent sends an
unsolicited advertisement infrequently, which the User and Service
Agents listen for. In either case the Agents receive a DA
Advertisement (DAAdvert).
ユーザとServiceエージェントは2つの方法でディレクトリエージェントを発見します。 まず最初に、始動すると、彼らは'ディレクトリエージェント'のためのService Requestが修理するマルチキャストを発行します。 2番目、エージェントが求められていない広告をまれに送るディレクトリ。(UserとServiceエージェントはそのディレクトリの聞こうとします)。 どちらの場合ではも、エージェントはDA Advertisement(DAAdvert)を受け取ります。
+---------------+ --Multicast SrvRqst-> +-----------+
| User or | <--Unicast DAAdvert-- | Directory |
| Service Agent | | Agent |
+---------------+ <-Multicast DAAdvert- +-----------+
+---------------+--マルチキャストSrvRqst->+-----------+ | またはユーザ。| <--ユニキャストDAAdvert--| ディレクトリ| | サービスエージェント| | エージェント| +---------------+ <-マルチキャストDAAdvert+-----------+
Guttman, et al. Standards Track [Page 5] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[5ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
Services are grouped together using 'scopes'. These are strings which identify services which are administratively identified. A scope could indicate a location, administrative grouping, proximity in a network topology or some other category. Service Agents and Directory Agents are always assigned a scope string.
サービスは、'範囲'を使用することで一緒に分類されます。 これらは行政上特定されるサービスを特定するストリングです。 範囲は位置、管理組分け、ネットワーク形態での近接またはある他のカテゴリを示すかもしれません。 範囲ストリングはいつもサービスエージェントとディレクトリエージェントに割り当てられます。
A User Agent is normally assigned a scope string (in which case the User Agent will only be able to discover that particular grouping of services). This allows a network administrator to 'provision' services to users. Alternatively, the User Agent may be configured with no scope at all. In that case, it will discover all available scopes and allow the client application to issue requests for any service available on the network.
通常、範囲ストリングはUserエージェントに割り当てられます(その場合、Userエージェントはその特定のサービスの組分けを発見できるだけでしょう)。 これはユーザに対する'支給'サービスにネットワーク管理者を許容します。 あるいはまた、Userエージェントは全く範囲なしで構成されるかもしれません。 その場合、それは、すべての利用可能な範囲を発見して、クライアントアプリケーションがネットワークで利用可能などんなサービスを求める要求も出すのを許容するでしょう。
+---------+ Multicast +-----------+ Unicast +-----------+ | Service | <--SrvRqst-- | User | --SrvRqst-> | Directory | | Agent | | Agent | | Agent | | Scope=X | Unicast | Scope=X,Y | Unicast | Scope=Y | +---------+ --SrvRply--> +-----------+ <-SrvRply-- +-----------+
+---------+ マルチキャスト+-----------+ ユニキャスト+-----------+ | サービス| <--SrvRqst--| ユーザ| --SrvRqst->。| ディレクトリ| | エージェント| | エージェント| | エージェント| | 範囲はXと等しいです。| ユニキャスト| Y、範囲はXと等しいです。| ユニキャスト| 範囲はYと等しいです。| +---------+--SrvRply-->+-----------+ <-SrvRply--+-----------+
In the above illustration, the User Agent is configured with scopes X and Y. If a service is sought in scope X, the request is multicast. If it is sought in scope Y, the request is unicast to the DA. Finally, if the request is to be made in both scopes, the request must be both unicast and multicast.
Userエージェントが範囲XとY.Ifによって構成されて、サービスが範囲Xで求められるという上記のイラストでは、ことである、要求はマルチキャストです。 それが範囲Yで探されるなら、要求はDAへのユニキャストです。 最終的に、要求が両方の範囲で作られていることであるなら、要求はユニキャストとマルチキャストの両方であるに違いありません。
Service Agents and User Agents may verify digital signatures provided with DAAdverts. User Agents and Directory Agents may verify service information registered by Service Agents. The keying material to use to verify digital signatures is identified using a SLP Security Parameter Index, or SLP SPI.
サービスエージェントとUserエージェントはDAAdvertsが提供されたデジタル署名について確かめるかもしれません。 ユーザエージェントとディレクトリエージェントはServiceエージェントによって登録されたサービス情報について確かめるかもしれません。 デジタル署名について確かめるのに使用する合わせることの材料は、SLP Security Parameter Index、またはSLP SPIを使用することで特定されます。
Every host configured to generate a digital signature includes the SLP SPI used to verify it in the Authentication Block it transmits. Every host which can verify a digital signature must be configured with keying material and other parameters corresponding with the SLP SPI such that it can perform verifying calculations.
デジタル署名を生成するために構成されたすべてのホストがそれが伝えるAuthentication Blockでそれについて確かめるのに使用されるSLP SPIを入れます。 計算結果を確かめながら働くことができるようにSLP SPIと共に対応する材料と他のパラメタを合わせることでデジタル署名について確かめることができるすべてのホストを構成しなければなりません。
SAs MUST accept multicast service requests and unicast service requests. SAs MAY accept other requests (Attribute and Service Type Requests). SAs MUST listen for multicast DA Advertisements.
SAsはマルチキャストサービスのリクエストとユニキャストサービスのリクエストを受け入れなければなりません。 SAsは他の要求(属性とService Type Requests)を受け入れるかもしれません。 SAsはマルチキャストDA Advertisementsの聞こうとしなければなりません。
The features described up to this point are required to implement. A minimum implementation consists of a User Agent, Service Agent or both.
この時点までに説明された特徴が、実装するのに必要です。 最小の実装はUserエージェント、Serviceエージェントまたは両方から成ります。
There are several optional features in the protocol. Note that DAs MUST support all these message types, but DA support is itself
プロトコルにおけるいくつかのオプション機能があります。 DAsがこれらのすべてのメッセージタイプをサポートしなければなりませんが、DAサポートがそれ自体であることに注意してください。
Guttman, et al. Standards Track [Page 6] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[6ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
optional to deploy on networks using SLP. UAs and SAs MAY support these message types. These operations are primarily for interactive use (browsing or selectively updating service registrations.) UAs and SAs either support them or not depending on the requirements and constraints of the environment where they will be used.
ネットワークでSLPを使用することで展開するために、任意です。 UAsとSAsはこれらのメッセージタイプをサポートするかもしれません。 これらの操作は主として対話的な使用のためのもの(ブラウズするか、または選択的にサービス登録証明書をアップデートします。)です。 UAsとSAsは依存ではなく、要件と規制でのそれらが使用される環境の彼らをサポートします。
Service Type Request A request for all types of service on the
network. This allows generic service browsers
to be built.
ネットワークにおけるすべてのタイプのサービスを求めるType Request A要求を修理してください。 これは、ジェネリックサービスブラウザが組立てられるのを許容します。
Service Type Reply A reply to a Service Type Request.
サービスType Reply AはService Type Requestに答えます。
Attribute Request A request for attributes of a given type of
service or attributes of a given service.
与えられたタイプのサービスの属性か与えられたサービスの属性を求めるRequest A要求を結果と考えてください。
Attribute Reply A reply to an Attribute Request.
属性Reply AはAttribute Requestに答えます。
Service Deregister A request to deregister a service or some
attributes of a service.
サービスDeregister Aはサービスのサービスかいくつかの属性を「反-レジスタ」に要求します。
Service Update A subsequent SrvRqst to an advertisement.
This allows individual dynamic attributes to
be updated.
UpdateのAその後のSrvRqstを広告に調整してください。 これは、個々のダイナミックな属性をアップデートするのを許容します。
SA Advertisement In the absence of Directory Agents, a User
agent may request Service Agents in order
to discover their scope configuration. The
User Agent may use these scopes in requests.
SA Advertisement In、ディレクトリエージェントの不在、Userエージェントは彼らの範囲構成を発見するためにServiceエージェントを要求するかもしれません。 Userエージェントは要求でこれらの範囲を使用するかもしれません。
In the absence of Multicast support, Broadcast MAY be used. The location of DAs may be staticly configured, discovered using SLP as described above, or configured using DHCP. If a message is too large, it may be unicast using TCP.
Multicastサポートがないとき、Broadcastは使用されるかもしれません。 DAsの位置は、DHCPを使用することで静的に構成されるか、上で説明されるようにSLPを使用していると発見されるか、または構成されるかもしれません。 メッセージが大き過ぎるなら、それはTCPを使用するユニキャストであるかもしれません。
A SLPv2 implementation SHOULD support SLPv1 [22]. This support includes:
SLPv2実装SHOULDサポートSLPv1[22]。 このサポートは:
1. SLPv2 DAs are deployed, phasing out SLPv1 DAs.
1. SLPv1 DAsを段階的に廃止して、SLPv2 DAsは配布されます。
2. Unscoped SLPv1 requests are considered to be of DEFAULT scope.
SLPv1 UAs MUST be reconfigured to have a scope if possible.
2. Unscoped SLPv1要求がDEFAULT範囲のものであると考えられます。 できれば、範囲を持つためにSLPv1 UAsを再構成しなければなりません。
3. There is no way for an SLPv2 DA to behave as an unscoped SLPv1
DA. SLPv1 SAs MUST be reconfigured to have a scope if possible.
3. SLPv2 DAがunscoped SLPv1 DAとして振る舞う方法が全くありません。 できれば、範囲を持つためにSLPv1 SAsを再構成しなければなりません。
4. SLPv2 DAs answer SLPv1 requests with SLPv1 replies and SLPv2
requests with SLPv2 replies.
4. SLPv2 DAsはSLPv2回答でSLPv1回答による要求とSLPv2要求にSLPv1に答えます。
Guttman, et al. Standards Track [Page 7] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[7ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
5. SLPv2 DAs use registrations from SLPv1 and SLPv2 in the same
way. That is, incoming requests from agents using either version
of the protocol will be matched against this common set of
registered services.
5. 同様に、SLPv2 DAsはSLPv1とSLPv2から登録証明書を使用します。 すなわち、プロトコルのどちらのバージョンも使用しているエージェントからの入って来る要求はこの一般的な登録されたサービスに取り組まされるでしょう。
6. SLPv2 registrations which use Language Tags which are greater
than 2 characters long will be inaccessible to SLPv1 UAs.
6. 長い間2つ以上のキャラクタであるLanguage Tagsを使用するSLPv2登録証明書がSLPv1 UAsに近づきがたくなるでしょう。
7. SLPv2 DAs MUST return only service type strings in SrvTypeRply
messages which conform to SLPv1 service type string syntax, ie.
they MUST NOT return Service Type strings for abstract service
types.
7. SLPv2 DAsはSLPv1サービスタイプストリング構文に従うSrvTypeRplyメッセージでサービスタイプストリングだけを返さなければなりません、ie。それらは抽象的なサービスタイプのためにストリングをService Typeに返してはいけません。
8. SLPv1 SrvRqsts and AttrRqsts by Service Type do not match Service
URLs with abstract service types. They only match Service URLs
with concrete service types.
8. Service TypeによるSLPv1 SrvRqstsとAttrRqstsは抽象的なサービスタイプにService URLを合わせません。 彼らは具体的なサービスタイプにService URLを合わせるだけです。
SLPv1 UAs will not receive replies from SLPv2 SAs and SLPv2 UAs will not receive replies from SLPv1 SAs. In order to interoperate UAs and SAs of different versions require a SLPv2 DA to be present on the network which supports both protocols.
SLPv1 UAsはSLPv2 SAsから回答を受け取らないでしょう、そして、SLPv2 UAsはSLPv1 SAsから回答を受け取らないでしょう。 異なった見解のUAsとSAsを共同利用するには、SLPv2 DAが両方のプロトコルをサポートするネットワークで現在であるのを必要であってください。
The use of abstract service types in SLPv2 presents a backward compatibility issue for SLPv1. It is possible that a SLPv1 UA will request a service type which is actually an abstract service type. Based on the rules above, the SLPv1 UA will never receive an abstract Service URL reply. For example, the service type 'service:x' in a SLPv1 AttrRqst will not return the attributes of 'service:x:y://orb'. If the request was made with SLPv2, it would return the attributes of this service.
SLPv2における抽象的なサービスタイプの使用はSLPv1のために後方の互換性問題を提示します。 SLPv1 UAが実際に抽象的なサービスタイプであるサービスタイプを要求するのは、可能です。 規則に基づいて、上では、SLPv1 UAが抽象的なService URL回答を決して受け取らないでしょう。 例えば、サービスタイプ'サービス: SLPv1 AttrRqstのx'は'サービス:x:y://球'の属性を返さないでしょう。 SLPv2と共に要求をするなら、それはこのサービスの属性を返すでしょうに。
4. URLs used with Service Location
4. Service Locationと共に使用されるURL
A Service URL indicates the location of a service. This URL may be of the service: scheme [13] (reviewed in section 4.1), or any other URL scheme conforming to the URI standard [8], except that URLs without address specifications SHOULD NOT be advertised by SLP. The service type for an 'generic' URL is its scheme name. For example, the service type string for "http://www.srvloc.org" would be "http".
Service URLはサービスの位置を示します。 このURLは役に立つかもしれません: 体系[13](セクション4.1で、見直されます)、またはいかなる他のURL体系もURI規格[8]に従って、アドレス指定SHOULD NOTのないそのURLを除いて、SLPによって広告を出されてください。 'ジェネリック'URLのためのサービスタイプはその体系名です。 例えば、" http://www.srvloc.org "のためのサービスタイプストリングは"http"でしょう。
Reserved characters in URLs follow the rules in RFC 2396 [8].
URLの控え目なキャラクタはRFC2396[8]で約束を守ります。
Guttman, et al. Standards Track [Page 8] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[8ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
4.1. Service: URLs
4.1. サービス: URL
Service URL syntax and semantics are defined in [13]. Any network service may be encoded in a Service URL.
サービスURL構文と意味論は[13]で定義されます。 どんなネットワーク・サービスもService URLでコード化されるかもしれません。
This section provides an introduction to Service URLs and an example showing a simple application of them, representing standard network services.
このセクションはそれらの簡単なアプリケーションを示しているService URLと例に序論を提供します、標準のネットワーク・サービスを表して。
A Service URL may be of the form:
Service URLはフォームのものであるかもしれません:
"service:"<srvtype>"://"<addrspec>
「サービス: 「<srvtype>」://「<addrspec>」
The Service Type of this service: URL is defined to be the string up to (but not including) the final `:' before <addrspec>, the address specification.
このサービスのService Type: 'URLは(しかし、包含しない)決勝までのストリングになるように定義される': '<addrspec>、アドレス指定の前に。
<addrspec> is a hostname (which should be used if possible) or dotted decimal notation for a hostname, followed by an optional `:' and port number.
'<addrspec>はホスト名のためのホスト名(できれば、使用されるべきである)かドット付き10進法です、続かれて任意である、':'そして、ポートナンバー。
A service: scheme URL may be formed with any standard protocol name by concatenating "service:" and the reserved port [1] name. For example, "service:tftp://myhost" would indicate a tftp service. A tftp service on a nonstandard port could be "service:tftp://bad.glad.org:8080".
サービス: 体系URLは「以下を修理してください」というどんな標準プロトコル名でも連結することによって形成されて、ことであるかもしれません。 そして、予約されたポート[1]名前。 例えば、「サービス: tftp://myhost」はtftpサービスを示すでしょう。 標準的でないポートにおけるtftpサービスはそうであるかもしれません。「サービス: tftp://bad.glad.org: 8080。」
Service Types SHOULD be defined by a "Service Template" [13], which provides expected attributes, values and protocol behavior. An abstract service type (also described in [13]) has the form
サービスTypes SHOULDが「サービステンプレート」[13]によって定義されて、どれが提供されるかが属性、値、およびプロトコルの振舞いを予想しました。 抽象的なサービスタイプ、(また、説明されたコネ[13])には、フォームがあります。
"service:<abstract-type>:<concrete-type>".
「サービス: <抽象型>: <コンクリートタイプ>。」
The service type string "service:<abstract-type>" matches all services of that abstract type. If the concrete type is included also, only these services match the request. For example: a SrvRqst or AttrRqst which specifies "service:printer" as the Service Type will match the URL service:printer:lpr://hostname and service:printer:http://hostname. If the requests specified "service:printer:http" they would match only the latter URL.
サービスタイプストリング「サービス: <抽象型>」はその抽象型のすべてのサービスに合っています。 また、具体的なタイプが含まれているなら、これらのサービスだけが要求に合っています。 例えば: Service Typeとして「サービス: プリンタ」を指定するSrvRqstかAttrRqstがURLサービス:プリンタ:lpr://ホスト名とサービス:プリンタ: http://hostname に合うでしょう。 要求が「サービス:プリンタ:http」を指定するなら、それらは後者のURLだけに合っているでしょうに。
An optional substring MAY follow the last `.' character in the <srvtype> (or <abstract-type> in the case of an abstract service type URL). This substring is the Naming Authority, as described in Section 9.6. Service types with different Naming Authorities are quite distinct. In other words, service:x.one and service:x.two are different service types, as are service:abstract.one:y and service:abstract.two:y.
'任意のサブストリングは最終に続くかもしれません'。'<のキャラクタは>(または、抽象的なサービスタイプURLの場合における<抽象型>)をsrvtypeします。 このサブストリングはセクション9.6で説明されるようにNaming Authorityです。 異なったNaming Authoritiesがあるサービスタイプは全く異なっています。 言い換えれば、サービス: x.1とサービス: x.twoはサービス: 要約1つ: yとサービス: 要約2のように異なったサービスタイプです: y。
Guttman, et al. Standards Track [Page 9] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[9ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
4.2. Naming Authorities
4.2. 当局を任命します。
A Naming Authority MAY optionally be included as part of the Service Type string. The Naming Authority of a service defines the meaning of the Service Types and attributes registered with and provided by Service Location. The Naming Authority itself is typically a string which uniquely identifies an organization. IANA is the implied Naming Authority when no string is appended. "IANA" itself MUST NOT be included explicitly.
Naming AuthorityはService Typeストリングの一部として任意に含まれるかもしれません。 サービスのNaming AuthorityはService Locationによってともに記名されて、提供されたService Typesと属性の意味を定義します。 通常、Naming Authority自身は唯一組織を特定するストリングです。 ストリングを全く追加しないとき、IANAは暗示しているNaming Authorityです。 明らかに"IANA"自体を含んではいけません。
Naming Authorities may define Service Types which are experimental, proprietary or for private use. Using a Naming Authority, one may either simply ignore attributes upon registration or create a local- use only set of attributes for one's site. The procedure to use is to create a 'unique' Naming Authority string and then specify the Standard Attribute Definitions as described above. This Naming Authority will accompany registration and queries, as described in Sections 8.1 and 8.3. Service Types SHOULD be registered with IANA to allow for Internet-wide interoperability.
Authoritiesを命名するのは、実験的で、独占であるService Typesを定義するか、または私用のためにそうするかもしれません。 Naming Authority、1を使用すると、属性について人のサイトに登録の属性が単に無視されるか、または設定されただけである地方の使用は作成されるかもしれません。 用いる手順は、上で説明されるように'ユニークな'Naming Authorityストリングを作成して、次に、Standard Attribute Definitionsを指定することです。 このNaming Authorityはセクション8.1と8.3で説明されるように登録と質問に伴うでしょう。 登録されていて、インターネット全体の相互運用性を考慮するIANAと共にTypes SHOULDを調整してください。
4.3. URL Entries
4.3. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Lifetime | URL Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|URL len, contd.| URL (variable length) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|# of URL auths | Auth. blocks (if any) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| 生涯| URLの長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |contd| URL len、URL(可変長)\+++++++++++++++++++++++++++++++++|# URL authsについて| Authブロック(もしあれば)\+++++++++++++++++++++++++++++++++
SLP stores URLs in protocol elements called URL Entries, which associate a length, a lifetime, and possibly authentication information along with the URL. URL Entries, defined as shown above, are used in Service Replies and Service Registrations.
SLPはURL Entriesと呼ばれるプロトコル要素にURLを格納します。EntriesはURLに伴う長さ、生涯、およびことによると認証情報を関連づけます。 上で示されると定義されたURL EntriesはService RepliesとService Registrationsで使用されます。
5. Service Attributes
5. サービス属性
A service advertisement is often accompanied by Service Attributes. These attributes are used by UAs in Service Requests to select appropriate services.
サービス広告はしばしばService Attributesによって伴われます。 これらの属性は、適切なサービスを選択するのにService RequestsでUAsによって使用されます。
The allowable attributes which may be used are typically specified by a Service Template [13] for a particular service type. Services which are advertised according to a standard template MUST register all service attributes which the standard template requires. URLs with schemes other than "service:" MAY be registered with attributes.
使用されるかもしれない許容できる属性はService Template[13]によって特定のサービスタイプに通常指定されます。 標準のテンプレートに従って広告に掲載されているサービスは標準のテンプレートが必要とするすべてのサービス属性を示さなければなりません。 計画を伴うURL、「サービス:」 属性に登録されるかもしれません。
Guttman, et al. Standards Track [Page 10] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[10ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
Non-standard attribute names SHOULD begin with "x-", because no standard attribute name will ever have those initial characters.
どんな標準の属性名にもそれらの初期のキャラクタがないのでSHOULDが「x」で始める標準的でない属性名。
An attribute list is a string encoding of the attributes of a service. The following ABNF [11] grammar defines attribute lists:
属性リストはサービスの属性をコード化するストリングです。 以下のABNF[11]文法は属性リストを定義します:
attr-list = attribute / attribute `,' attr-list
attribute = `(' attr-tag `=' attr-val-list `)' / attr-tag
attr-val-list = attr-val / attr-val `,' attr-val-list
attr-tag = 1*safe-tag
attr-val = intval / strval / boolval / opaque
intval = [-]1*DIGIT
strval = 1*safe-val
boolval = "true" / "false"
opaque = "\FF" 1*escape-val
safe-val = ; Any character except reserved.
safe-tag = ; Any character except reserved, star and bad-tag.
reserved = `(' / `)' / `,' / `\' / `!' / `<' / `=' / `>' / `~' / CTL
escape-val = `\' HEXDIG HEXDIG
bad-tag = CR / LF / HTAB / `_'
star = `*'
記載..属性..属性..リスト..属性..タグ..リスト..タグ..リスト..等しい..リスト..タグ..金庫..タグ..不透明..等しい..金庫..本当..誤る..不透明なもの..ff..エスケープ..安全 どんなキャラクタも予約されていた状態で除きます。=に金庫でタグ付けをしてください。 '星と悪いタグ予約されるのを除いたどんなキャラクタ、予約された''/'\'/'!'/'<'/'='/'>'/'~'/CTLエスケープ-valは'\'HEXDIG HEXDIG悪いタグ=CR / LF / HTAB /と等しい'という_='('/')'/'星='*も'
The <attr-list>, if present, MUST be scanned prior to evaluation for all occurrences of the escape character `\'. Reserved characters MUST be escaped (other characters MUST NOT be escaped). All escaped characters must be restored to their value before attempting string matching. For Opaque values, escaped characters are not converted - they are interpreted as bytes.
存在しているなら、評価の前に'\'という拡張文字のすべての発生のために<attr-リスト>をスキャンしなければなりません。 控え目なキャラクタから逃げなければなりません(他のキャラクタから逃げてはいけません)。 ストリングマッチングを試みる前に、すべての逃げられたキャラクタを彼らの値に回復しなければなりません。 Opaque値において、逃げられたキャラクタは変換されません--彼らはバイトとして解釈されます。
Boolean Strings which have the form "true" or "false" can
only take one value and may only be compared with
'='. Booleans are case insensitive when compared.
「本当である」か「誤ること」にフォームを持っているブールStringsは1つの値しか取ることができないで、'='と比較されるだけであるかもしれません。 比べると、論理演算子は大文字と小文字を区別しないです。
Integer Strings which take the form [-] 1*<digit> and fall
in the range "-2147483648" to "2147483647" are
considered to be Integers. These are compared using
integer comparison.
フォーム[-]1*<ケタ>を取って、範囲「-2147483648」に「2147483647」に落ちる整数Stringsは整数であると考えられます。 これらは、整数比較を使用することで比較されます。
String All other Strings are matched using strict lexical
ordering (see Section 6.4).
ストリングAll他のStringsは、厳しい語彙注文を使用することで取り組んでいます(セクション6.4を見てください)。
Opaque Opaque values are sequences of bytes. These are
distinguished from Strings since they begin with
the sequence "\FF". This, unescaped, is an illegal
UTF-8 encoding, indicating that what follows is a
sequence of bytes expressed in escape notation which
constitute the binary value. For example, a '0' byte
is encoded "\FF%%BODY%%0".
不透明なOpaque値はバイトの系列です。 「自分達が系列で」 \ffを始めるので、これらはStringsと区別されます。」 非エスケープしたこれが不法なUTF-8コード化である、続くことがバイトの系列であることを示すのがどれが2進の値を構成するかをエスケープ記法で言い表しました。 \ff%%BODY%%インチ「例えば、'0'バイトはコード化されます」。
Guttman, et al. Standards Track [Page 11] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[11ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
A string which contains escaped values other than from the reserved set of characters is illegal. If such a string is included in an <attr-list>, <tag-list> or search filter, the SA or DA which receives it MUST return a PARSE_ERROR to the message.
予約されたキャラクタ以外の逃げられた値を含む五弦は不法です。 そのようなストリングが>、<タグリスト>または検索がフィルターにかける<attr-リストに含まれているなら、それを受けるSAかDAがPARSE_ERRORをメッセージに返さなければなりません。
A keyword has only an <attr-tag>, and no values. Attributes can have one or multiple values. All values are expressed as strings.
キーワードには、<のattrタグの>しか持っていませんが、どんな値もありません。 属性は1か複数の値を持つことができます。 すべての値がストリングとして言い表されます。
When values have been advertised by a SA or are registered in a DA, they can take on implicit typing rules for matching incoming requests.
値がSAによって広告を出されるか、またはDAに示されたとき、それらは合っている入って来る要求のための暗黙の型宣言規則を帯びることができます。
Stored values must be consistent, i.e., x=4,true,sue,\ff%%BODY%%0%%BODY%%0 is disallowed. A DA or SA receiving such an <attr-list> MUST return an INVALID_REGISTRATION error.
格納された値が一貫しているに違いない、すなわち、本当のx=4は訴えて、\ffは00円です。00円は禁じられます。 >がINVALID_REGISTRATION誤りを返さなければならないそのような<attr-リストを受け取るDAかSA。
6. Required Features
6. 必要な特徴
This section defines the minimal implementation requirements for SAs and UAs as well as their interaction with DAs. A DA is not required for SLP to function, but if it is present, the UA and SA MUST interact with it as defined below.
このセクションはDAsとの彼らの相互作用と同様にSAsとUAsのための最小限の器具要件を定義します。 SLPが機能するのにDAは必要ではありませんが、それが存在しているなら、UAとSA MUSTは以下で定義されるようにそれと対話します。
A minimal implementation may consist of either a UA or SA or both. The only required features of a UA are that it can issue SrvRqsts according to the rules below and interpret DAAdverts, SAAdverts and SrvRply messages. The UA MUST issue requests to DAs as they are discovered. An SA MUST reply to appropriate SrvRqsts with SrvRply or SAAdvert messages. The SA MUST also register with DAs as they are discovered.
最小限の器具はUAかSAか両方のどちらかから成るかもしれません。 UAの唯一の必要な特徴は以下の規則に従ってSrvRqstsを発行して、DAAdverts、SAAdverts、およびSrvRplyメッセージを解釈できるということです。 彼らが発見されるようにUaはDAsに要求を出さなければなりません。 SrvRplyと適切なSrvRqstsかSAAdvertメッセージに関するSA MUST回答。 また、彼らが発見されるようにSA MUSTはDAsとともに記名します。
UAs perform discovery by issuing Service Request messages. SrvRqst messages are issued, using UDP, following these prioritized rules:
UAsは、Service Requestにメッセージを発行することによって、発見を実行します。 これらの最優先する規則に従って、UDPを使用して、SrvRqstメッセージを発行します:
1. A UA issues a request to a DA which it has been configured with
by DHCP.
1. UAはそれがDHCPによって構成されたDAに要求を出します。
2. A UA issues requests to DAs which it has been statically
configured with.
2. UAはそれが静的に構成されたDAsに要求を出します。
3. UA uses multicast/convergence SrvRqsts to discover DAs, then uses
that set of DAs. A UA that does not know of any DAs SHOULD retry
DA discovery, increasing the waiting interval between subsequent
attempts exponentially (doubling the wait interval each time.)
The recommended minimum waiting interval is CONFIG_DA_FIND
seconds.
3. UAはDAsを発見するのにマルチキャスト/集合SrvRqstsを使用して、次に、DAsのそのセットを使用します。 その後の試みの待ち間隔を指数関数的(その都度、待ち間隔を倍にします。)に増加させて、少しのDAs SHOULD再試行DA発見も知らないUA お勧めの最小の待ち間隔はCONFIG_DA_FIND秒です。
Guttman, et al. Standards Track [Page 12] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[12ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
4. A UA with no knowledge of DAs sends requests using multicast
convergence to SAs. SAs unicast replies to UAs according to the
multicast convergence algorithm.
4. DAsに関する知識のないUAは、マルチキャスト集合をSAsに使用することで要求を送ります。 マルチキャスト集合アルゴリズムによると、SAsユニキャストはUAsに答えます。
UAs and SAs are configured with a list of scopes to use according to these prioritized rules:
UAsとSAsはこれらの最優先する規則に従って使用する範囲のリストによって構成されます:
1. With DHCP.
1. DHCPと共に。
2. With static configuration. The static configuration may be
explicitly set to NO SCOPE for UAs, if the User Selectable Scope
model is used. See section 11.2.
2. 静的な構成で。 UAsのためにNO SCOPEに設定されて、User Selectable Scopeモデルが使用されているなら、静的な構成は明らかにそうです。 セクション11.2を見てください。
3. In the absence of configuration, the agent's scope is "DEFAULT".
3. 構成がないとき、エージェントの範囲は「デフォルト」です。
A UA MUST issue requests with one or more of the scopes it has been configured to use.
Uaが1で要求を出さなければならない、さらに範囲では、さもなければ、それが使用に構成されました。
A UA which has been statically configured with NO SCOPE LIST will use DA or SA discovery to determine its scope list dynamically. In this case it uses an empty scope list to discover DAs and possibly SAs. Then it uses the scope list it obtains from DAAdverts and possibly SAAdverts in subsequent requests.
NO SCOPE LISTによって静的に構成されたUAは、ダイナミックに範囲リストを決定するのにDAかSA発見を使用するでしょう。 この場合、それは、DAsとことによるとSAsを発見するのに空の範囲リストを使用します。 そして、それはその後の要求でDAAdvertsとことによるとSAAdvertsから得る範囲リストを使用します。
The SA MUST register all its services with any DA it discovers, if the DA advertises any of the scopes it has been configured with. A SA obtains information about DAs as a UA does. In addition, the SA MUST listen for multicast unsolicited DAAdverts. The SA registers by sending SrvReg messages to DAs, which reply with SrvReg messages to indicate success. SAs register in ALL the scopes they were configured to use.
SA MUSTはどんなDAにもすべてのサービスを登録します。DAがそれが構成された範囲のどれかの広告を出すなら、それは発見します。 SAはUAが得るようにDAsの情報を得ます。 さらに、SA MUSTはマルチキャストの求められていないDAAdvertsの聞こうとします。 SAは、メッセージをSrvRegに送ることによって、DAsに登録します。(DAsは成功を示すSrvRegメッセージで返答します)。 SAsはすべてに使用に構成にされているのでそれらが範囲であったのを登録します。
6.1. Use of Ports, UDP, and Multicast
6.1. ポート、UDP、およびマルチキャストの使用
DAs MUST accept unicast requests and multicast directory agent discovery service requests (for the service type "service:directory- agent").
DAsはユニキャスト要求とマルチキャストディレクトリエージェント発見サービスのリクエストを受け入れなければなりません(サービスには、「サービス: ディレクトリエージェント」をタイプしてください)。
SAs MUST accept multicast requests and unicast requests both. The SA can distinguish between them by whether the REQUEST MCAST flag is set in the SLP Message header.
SAsはマルチキャスト要求と要求のユニキャスト両方を受け入れなければなりません。 REQUEST MCAST旗がSLP Messageヘッダーに設定されるかどうかによってSAはそれらを見分けることができます。
The Service Location Protocol uses multicast for discovering DAs and for issuing requests to SAs by default.
Service Locationプロトコルは、DAsを発見して、SAsに要求を出すのにデフォルトでマルチキャストを使用します。
The reserved listening port for SLP is 427. This is the destination port for all SLP messages. SLP messages MAY be transmitted on an ephemeral port. Replies and acknowledgements are sent to the port
SLPにおいて、予約された聴取ポートは427です。 これはすべてのSLPメッセージのための仕向港です。 SLPメッセージはエフェメラルポートで送られるかもしれません。 回答と承認をポートに送ります。
Guttman, et al. Standards Track [Page 13] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[13ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
from which the request was issued. The default maximum transmission unit for UDP messages is 1400 bytes excluding UDP and other headers.
要求は出されました。 UDPメッセージのためのデフォルトマキシマム・トランスミッション・ユニットはUDPと他のヘッダーを除いた1400バイトです。
If a SLP message does not fit into a UDP datagram it MUST be truncated to fit, and the OVERFLOW flag is set in the reply message. A UA which receives a truncated message MAY open a TCP connection (see section 6.2) with the DA or SA and retransmit the request, using the same XID. It MAY also attempt to make use of the truncated reply or reformulate a more restrictive request which will result in a smaller reply.
SLPメッセージがUDPデータグラムに収まらないなら、合うようにそれに先端を切らせなければなりません、そして、OVERFLOW旗は応答メッセージに設定されます。 端が欠けているメッセージを受け取るUAはDAかSAと共にTCP接続を開いて(セクション6.2を見ます)、要求を再送するかもしれません、同じXIDを使用して。 また、それは、端が欠けの回答かreformulateの使用をより小さい回答をもたらすより制限している要求にするのを試みるかもしれません。
SLP Requests messages are multicast to The Administratively Scoped SLP Multicast [17] address, which is 239.255.255.253. The default TTL to use for multicast is 255.
SLP RequestsメッセージはAdministratively Scoped SLP Multicast[17]アドレスへのマルチキャストであり、どれがあるか。239.255 .255 .253。 マルチキャストの使用へのデフォルトTTLは255歳です。
In isolated networks, broadcasts will work in place of multicast. To that end, SAs SHOULD and DAs MUST listen for broadcast Service Location messages at port 427. This allows UAs which do not support multicast the use of Service Location on isolated networks.
孤立しているネットワークでは、マルチキャストに代わって放送は働くでしょう。 そのために、SAs SHOULDとDAsはポート427で放送Service Locationメッセージの聞こうとしなければなりません。 これは孤立しているネットワークにおけるService Locationの使用をマルチキャストを支持しないUAsに許します。
Setting multicast TTL to less than 255 (the default) limits the range of SLP discovery in a network, and localizes service information in the network.
255(デフォルト)未満にマルチキャストTTLを設定するのは、ネットワークがSLP発見の範囲を制限して、ネットワークでサービス情報を局所化します。
6.2. Use of TCP
6.2. TCPの使用
A SrvReg or SrvDeReg may be too large to fit into a datagram. To send such large SLP messages, a TCP (unicast) connection MUST be established.
SrvRegかSrvDeRegがデータグラムに収まることができないくらい大きいかもしれません。 そのような大きいSLPメッセージを送るために、TCP(ユニキャスト)接続を確立しなければなりません。
To avoid the need to implement TCP, one MUST insure that:
必要がないように、道具TCP、以下のことを保障しなければなりません。
- UAs never issue requests larger than the Path MTU. SAs can omit
TCP support only if they never have to receive unicast requests
longer than the path MTU.
- UAsはPath MTUより大きい要求を決して出しません。 彼らが経路MTUよりユニキャスト要求長い間決して受信する必要はない場合にだけ、SAsはTCPサポートを省略できます。
- UAs can accept replies with the 'OVERFLOW' flag set, and make use
of the first result included, or reformulate the request.
- UAsは'OVERFLOW'旗のセットによる回答を受け入れて、含まれていた最初の結果、またはreformulateの使用を要求にすることができます。
- Ensure that a SA can send a SrvRply, SrvReg, or SrvDeReg in
a single datagram. This means limiting the size of URLs,
the number of attributes and the number of authenticators
transmitted.
- SAが単一のデータグラムでSrvRply、SrvReg、またはSrvDeRegを送ることができるのを確実にしてください。 属性の数と固有識別文字の数は、これが、URLのサイズを制限することを意味すると伝えました。
DAs MUST be able to respond to UDP and TCP requests, as well as multicast DA Discovery SrvRqsts. SAs MUST be able to respond to TCP unless the SA will NEVER receive a request or send a reply which will exceed a datagram in size (e.g., some embedded systems).
DAsはUDP、TCP要求、およびマルチキャストDAディスカバリーSrvRqstsに応じることができなければなりません。 SAがサイズ(例えばいくつかの組込み型システム)で要求を決して受け取らないか、またはデータグラムを超えている回答を送らないなら、SAsはTCPに応じることができなければなりません。
Guttman, et al. Standards Track [Page 14] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[14ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
A TCP connection MAY be used for a single SLP transaction, or for multiple transactions. Since there are length fields in the message headers, SLP Agents can send multiple requests along a connection and read the return stream for acknowledgments and replies.
TCP接続はただ一つのSLP取引、または複数の取引に使用されるかもしれません。 長さの分野がメッセージヘッダーにあるので、SLPエージェントは、接続に沿って複数の要求を送って、承認と回答のためにリターンの流れを読むことができます。
The initiating agent SHOULD close the TCP connection. The DA SHOULD wait at least CONFIG_CLOSE_CONN seconds before closing an idle connection. DAs and SAs SHOULD close an idle TCP connection after CONFIG_CLOSE_CONN seconds to ensure robust operation, even when the initiating agent neglects to close it. See Section 13 for timing rules.
開始しているエージェントSHOULDはTCP接続を終えます。 無駄な接続を終える前に、DA SHOULDは少なくともCONFIG_CLOSE_コン秒を待ちます。 DAsとSAs SHOULDはCONFIG_CLOSE_コン秒以降体力を要している操作を確実にするために無駄なTCP接続を終えます、開始しているエージェントが、それを閉じるのを忘れるときさえ。 タイミング規則に関してセクション13を見てください。
6.3. Retransmission of SLP messages
6.3. SLPメッセージのRetransmission
Requests which fail to elicit a response are retransmitted. The initial retransmission occurs after a CONFIG_RETRY wait period. Retransmissions MUST be made with exponentially increasing wait intervals (doubling the wait each time). This applies to unicast as well as multicast SLP requests.
応答を引き出さない要求が再送されます。 初期の「再-トランスミッション」はCONFIG_RETRY待ちの期間の後に現れます。 指数関数的に増加する待ち間隔でRetransmissionsを作らなければなりません(その都度待ちを倍にして)。 これはマルチキャストSLP要求と同様にユニキャストに適用されます。
Unicast requests to a DA or SA should be retransmitted until either a response (which might be an error) has been obtained, or for CONFIG_RETRY_MAX seconds.
DAかSAへのユニキャスト要求は応答(誤りであるかもしれない)を得たか、またはCONFIG_RETRY_MAX秒の間、再送されるべきです。
Multicast requests SHOULD be reissued over CONFIG_MC_MAX seconds until a result has been obtained. UAs need only wait till they obtain the first reply which matches their request. That is, retransmission is not required if the requesting agent is prepared to use the 'first reply' instead of 'as many replies as possible within a bounded time interval.'
マルチキャストは、SHOULDが_MAX秒CONFIG_M.C.の上結果を得るまで再発行されるよう要求します。 彼らが彼らの要求に合っている最初の回答を得るまで、UAsは待つだけでよいです。 要求しているエージェントが'境界がある時間間隔以内にできるだけ多くの回答'の代わりにする'での最初の回答'を使用する用意ができているなら、すなわち、「再-トランスミッション」は必要ではありません。
When SLP SrvRqst, SrvTypeRqst, and AttrRqst messages are multicast, they contain a <PRList> of previous responders. Initially the <PRList> is empty. When these requests are unicast, the <PRList> is always empty.
SLP SrvRqst、SrvTypeRqst、およびAttrRqstメッセージがマルチキャストであるときに、それらは前の応答者の<PRList>を含んでいます。 初めは、<PRList>は空です。 これらの要求がユニキャストであるときに、<PRList>はいつも空です。
Any DA or SA which sees its address in the <PRList> MUST NOT respond to the request.
<PRList>のアドレスを見るどんなDAやSAも要求に応じてはいけません。
The message SHOULD be retransmitted until the <PRList> causes no further responses to be elicited or the previous responder list and the request will not fit into a single datagram or until CONFIG_MC_MAX seconds elapse.
メッセージSHOULDは<PRList>がこれ以上応答を引き出させないか、または前の応答者リストと要求が単一のデータグラムに収まらないまで再送されるか、または_MAX秒CONFIG_M.C.まで経過します。
UAs which retransmit a request use the same XID. This allows a DA or SA to cache its reply to the original request and then send it again, should a duplicate request arrive. This cached information should only be held very briefly. XIDs SHOULD be randomly chosen to avoid
要求を再送するUAsが同じXIDを使用します。 これで、DAかSAがオリジナルの要求に回答をキャッシュして、次に、再びそれを送ります、写し要求が到着するなら。 このキャッシュされた情報は非常に簡潔に保持されるだけであるべきです。 選ばれて、XIDs SHOULDが手当たりしだいにそうである、避ける。
Guttman, et al. Standards Track [Page 15] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[15ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
duplicate XIDs in requests if UAs restart frequently.
UAsが頻繁に再開するなら、要求にXIDsをコピーしてください。
6.4. Strings in SLP messages
6.4. SLPメッセージのストリング
The escape character is a backslash (UTF-8 0x5c) followed by the two hexadecimal digits of the escaped character. Only reserved characters are escaped. For example, a comma (UTF-8 0x29) is escaped as `\29', and a backslash `\' is escaped as `\5c'. String lists used in SLP define the comma to be the delimiter between list elements, so commas in data strings must be escaped in this manner. Backslashes are the escape character so they also must always be escaped when included in a string literally.
拡張文字は逃げられたキャラクタの2つの16進数字がいうことになったバックスラッシュ(UTF-8 0x5c)です。 控え目なキャラクタだけ逃げられます。 '例えば、コンマ(UTF-8 0x29)'29円'として逃げられます、そして、'\'というバックスラッシュ'\5c'として逃げられます。 SLPで使用されるストリングリストがリスト要素の間のデリミタになるようにコンマを定義するので、この様にデータ列のコンマから逃げなければなりません。 バックスラッシュが拡張文字であるので、また、ストリングに文字通り含まれていると、いつもそれらから逃げなければなりません。
String comparison for order and equality in SLP MUST be case insensitive inside the 0x00-0x7F subrange of UTF-8 (which corresponds to ASCII character encoding). Case insensitivity SHOULD be supported throughout the entire UTF-8 encoded Unicode [6] character set.
大文字と小文字を区別しない内部がUTF-8(ASCII文字コード化に対応する)の0×00 0x7FのサブレンジであったならSLP MUSTの注文と平等のための比較を結んでください。 大文字小文字の同一視SHOULD、あらゆる点で支持されて、全体のUTF-8がユニコード[6]文字の組をコード化したということになってください。
The case insensitivity rule applies to all string matching in SLPv2, including Scope strings, SLP SPI strings, service types, attribute tags and values in query handling, language tags, previous responder lists. Comparisons of URL strings, however, is case sensitive.
大文字小文字の同一視規則はSLPv2で合っているすべてのストリングに適用されます、質問取り扱い、言語タグ、前の応答者リストにScopeストリング、SLP SPIストリング、サービスタイプ、属性タグ、および値を含んでいて。 しかしながら、URLストリングの比較は大文字と小文字を区別しています。
White space (SPACE, CR, LF, TAB) internal to a string value is folded to a single SPACE character for the sake of string comparisons. White space preceding or following a string value is ignored for the purposes of string comparison. For example, " Some String " matches "SOME STRING".
ストリング値への内部の余白(SPACE、CR、LF、TAB)はストリング比較のために単独のSPACEキャラクタに折り重ねられます。 ストリング値に先行するか、または続く余白はストリング比較の目的のために無視されます。 例えば、「いくらかのString」は「何らかのストリング」に合っています。
String comparisons (using comparison operators such as `<=' or `>=') are done using lexical ordering in UTF-8 encoded characters, not using any language specific rules.
UTF-8でコード化されたキャラクタを命令しながら、ストリング比較('<='か'>='などの比較オペレータを使用する)に語彙で使用します、どんな言語の特定の規則も使用しないで。
The reserved character `*' may precede, follow or be internal to a string value in order to indicate substring matching. The query including this character matches any character sequence which conforms to the letters which are not wildcarded.
予約されたキャラクタ'*'は、サブストリングマッチングを示すために先行するか、続くか、またはストリング値に内部であるかもしれません。 このキャラクタを含む質問はwildcardedされない手紙に従うどんなキャラクタシーケンスにも合っています。
6.4.1. Scope Lists in SLP
6.4.1. SLPの範囲リスト
Scope Lists in SLPv2 have the following grammar:
SLPv2の範囲Listsには、以下の文法があります:
scope-list = scope-val / scope-val `,' scope-list
scope-val = 1*safe
safe = ; Any character except reserved.
reserved = `(' / `)' / `,' / `\' / `!' / `<' / `=' / `>' / `~' / CTL
/ `;' / `*' / `+'
escape-val = `\' HEXDIG HEXDIG
''範囲範囲リスト=範囲-val/val'、範囲リスト範囲-valは1*金庫金庫=と等しいです。 ''. 予約された予約された='('/')'/'を除いたどんなキャラクタ、/'\'/'!'/'<'/'='/'>'/'~'/ CTL /';'/'*'/'+'エスケープ-valは'\'HEXDIG HEXDIGと等しいです。
Guttman, et al. Standards Track [Page 16] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[16ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
Scopes which include any reserved characters must replace the escaped character with the escaped-val format.
どんな控え目なキャラクタも含んでいる範囲は逃げられたキャラクタを逃げられたval形式に取り替えなければなりません。
7. Errors
7. 誤り
If the Error Code in a SLP reply message is nonzero, the rest of the message MAY be truncated. No data is necessarily transmitted or should be expected after the header and the error code, except possibly for some optional extensions to clarify the error, for example as in section D.1.
SLP応答メッセージのError Codeが非零であるなら、メッセージの残りは先端を切られるかもしれません。 データを全く必ず送るべきであるというわけではありませんし、またヘッダーとエラーコードの後とことによるといくつかの任意の拡大以外に、誤りをはっきりさせると予想するべきではありません、例えば、セクションD.1のように。
Errors are only returned for unicast requests. Multicast requests are silently discarded if they result in an error.
誤りはユニキャスト要求のために返されるだけです。 誤りをもたらすなら、マルチキャスト要求は静かに捨てられます。
LANGUAGE_NOT_SUPPORTED = 1: There is data for the service type in
the scope in the AttrRqst or SrvRqst, but not in the requested
language.
PARSE_ERROR = 2: The message fails to obey SLP syntax.
INVALID_REGISTRATION = 3: The SrvReg has problems -- e.g., a zero
lifetime or an omitted Language Tag.
SCOPE_NOT_SUPPORTED = 4: The SLP message did not include a scope in
its <scope-list> supported by the SA or DA.
AUTHENTICATION_UNKNOWN = 5: The DA or SA receives a request for an
unsupported SLP SPI.
AUTHENTICATION_ABSENT = 6: The DA expected URL and ATTR
authentication in the SrvReg and did not receive it.
AUTHENTICATION_FAILED = 7: The DA detected an authentication error in
an Authentication block.
VER_NOT_SUPPORTED = 9: Unsupported version number in message header.
INTERNAL_ERROR = 10: The DA (or SA) is too sick to respond.
DA_BUSY_NOW = 11: UA or SA SHOULD retry, using exponential back off.
OPTION_NOT_UNDERSTOOD = 12: The DA (or SA) received an unknown option
from the mandatory range (see section 9.1).
INVALID_UPDATE = 13: The DA received a SrvReg without FRESH set, for
an unregistered service or with inconsistent Service Types.
MSG_NOT_SUPPORTED = 14: The SA received an AttrRqst or SrvTypeRqst
and does not support it.
REFRESH_REJECTED = 15: The SA sent a SrvReg or partial SrvDereg to a
DA more frequently than the DA's min-refresh-interval.
_ではなく、言語_が=1を支持しました: サービスタイプへのデータがAttrRqstかSrvRqstの範囲にありますが、要求された言語であるというわけではありません。 _誤り=2を分析してください: メッセージはSLP構文に従いません。 無効の_登録=3: SrvRegには、問題があります--例えば、生涯がない省略されたLanguage Tag。 _ではなく、範囲_が=4を支持しました: SLPメッセージはSAかDAによって支持された<範囲リスト>の範囲を含んでいませんでした。 認証_未知=5: DAかSAがサポートされないSLP SPIを求める要求を受け取ります。 認証_は=6を欠席します: DAはSrvRegでURLとATTR認証を予想して、それを受けませんでした。 認証_は=7に失敗しました: DAはAuthenticationブロックに認証誤りを検出しました。 _ではなく、VER_が=9を支持しました: メッセージヘッダーのサポートされないバージョン番号。 内部の_誤り=10: DA(または、SA)は反応できないくらいうんざりしています。 _現在忙しいDA_=11: 下に指数の後部を使用して、UAかSA SHOULDが再試行します。 _ではなく、オプション_が=12を理解していました: DA(または、SA)は義務的な範囲から未知のオプションを受け取りました(セクション9.1を見てください)。 無効の_アップデート=13: DAは登録されていないサービスか矛盾したService Typesと共に用意ができているFRESHなしでSrvRegを受けました。 _ではなく、エムエスジー_が=14を支持しました: SAはAttrRqstかSrvTypeRqstを受けて、それを支持しません。 _拒絶された=15をリフレッシュしてください: SAはDAが分が間隔が壮快であるより頻繁にSrvRegか部分的なSrvDeregをDAに送りました。
8. Required SLP Messages
8. 必要なSLPメッセージ
All length fields in SLP messages are in network byte order. Where ' tuples' are defined, these are sequences of bytes, in the precise order listed, in network byte order.
ネットワークバイトオーダーにはSLPメッセージのすべての長さの分野があります。 'tuples'が定義されるところでは、これらはネットワークバイトオーダーでリストアップされた正確なオーダーで、バイトの系列です。
SLP messages all begin with the following header:
SLPメッセージは以下のヘッダーと共にすべて始まります:
Guttman, et al. Standards Track [Page 17] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[17ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
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-ID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length, contd.|O|F|R| reserved |Next Ext Offset|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Extension Offset, contd.| XID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Language Tag Length | Language Tag \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | contd| 長さ、O|F|R| 予約されます。|次のExtは相殺します。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | contd| 次のExtension Offset、XID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 言語タグの長さ| 言語タグ\+++++++++++++++++++++++++++++++++
Message Type Abbreviation Function-ID
メッセージタイプ略語機能ID
Service Request SrvRqst 1
Service Reply SrvRply 2
Service Registration SrvReg 3
Service Deregister SrvDeReg 4
Service Acknowledge SrvAck 5
Attribute Request AttrRqst 6
Attribute Reply AttrRply 7
DA Advertisement DAAdvert 8
Service Type Request SrvTypeRqst 9
Service Type Reply SrvTypeRply 10
SA Advertisement SAAdvert 11
サービスのリクエストSrvRqst1サービス回答SrvRply2サービス登録SrvReg3サービスDeregister SrvDeReg4サービスは、SrvAck5属性要求AttrRqst6属性回答AttrRply7DA広告DAAdvert8サービスタイプがSrvTypeRqst9サービスタイプ回答SrvTypeRply10SA広告SAAdvert11を要求すると認めます。
SAs and UAs MUST support SrvRqst, SrvRply and DAAdvert. SAs MUST also support SrvReg, SAAdvert and SrvAck. For UAs and SAs, support for other messages are OPTIONAL.
SAsとUAsはSrvRqst、SrvRply、およびDAAdvertを支持しなければなりません。 また、SAsはSrvReg、SAAdvert、およびSrvAckを支持しなければなりません。 UAsとSAs、他のメッセージのサポートがOPTIONALであるので。
- Length is the length of the entire SLP message, header included.
- The flags are: OVERFLOW (0x80) is set when a message's length
exceeds what can fit into a datagram. FRESH (0x40) is set on
every new SrvReg. REQUEST MCAST (0x20) is set when multicasting
or broadcasting requests. Reserved bits MUST be 0.
- Next Extension Offset is set to 0 unless extensions are used.
The first extension begins at 'offset' bytes, from the message's
beginning. It is placed after the SLP message data. See
Section 9.1 for how to interpret unrecognized SLP Extensions.
- XID is set to a unique value for each unique request. If the
request is retransmitted, the same XID is used. Replies set
the XID to the same value as the xid in the request. Only
unsolicited DAAdverts are sent with an XID of 0.
- Lang Tag Length is the length in bytes of the Language Tag field.
- Language Tag conforms to [7]. The Language Tag in a reply MUST
be the same as the Language Tag in the request. This field must
be encoded 1*8ALPHA *("-" 1*8ALPHA).
- 長さは全体のヘッダーを含んでいるSLPメッセージの長さです。 - 旗は以下の通りです。 メッセージの長さがデータグラムに収まることができることを超えているとき、OVERFLOW(0×80)は用意ができています。 FRESH(0×40)はあらゆる新しいSrvReg. REQUEST MCASTで用意ができています。(0×20) マルチキャスティングであるときに、設定されるか、または要求を放送しています。 予約されたビットは0であるに違いありません。 - 拡大が使用されていない場合、次のExtension Offsetは0に用意ができています。 最初の拡大は'オフセット'のバイトでメッセージの始めから始まります。 それはSLPメッセージデータの後に置かれます。 セクション9.1を見て、どう認識されていないSLP Extensionsを解釈してくださいか。 - XIDはそれぞれのユニークな要求のためにユニークな値に用意ができています。 要求が再送されるなら、同じXIDは使用されています。 回答は要求にxidと同じ値にXIDを設定します。 0のXIDと共に求められていないDAAdvertsだけを送ります。 - ラングTag LengthはLanguage Tag分野のバイトで表現される長さです。 - 言語Tagは[7]に従います。 回答におけるLanguage Tagは要求でLanguage Tagと同じであるに違いありません。 この分野はコード化された1*8ALPHA*(「-」1*8ALPHA)であるに違いない。
Guttman, et al. Standards Track [Page 18] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[18ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
If an option is specified, and not included in the message, the receiver MUST respond with a PARSE_ERROR.
オプションが指定されて、メッセージに含まれていないなら、受信機はPARSE_ERRORと共に応じなければなりません。
8.1. Service Request
8.1. サービスのリクエスト
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 = SrvRqst = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <PRList> | <PRList> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <service-type> | <service-type> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <scope-list> | <scope-list> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of predicate string | Service Request <predicate> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <SLP SPI> string | <SLP SPI> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サービスLocationヘッダー(機能=SrvRqst=1)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | <PRList>の長さ| <PRList>ストリング\+++++++++++++++++++++++++++++++++| <サービスタイプ>の長さ| <サービスタイプ>は\+++++++++++++++++++++++++++++++++を結びます。| <範囲リスト>の長さ| <範囲リスト>は\+++++++++++++++++++++++++++++++++を結びます。| 述部ストリングの長さ| サービスのリクエスト<述部>\+++++++++++++++++++++++++++++++++| <SLP SPI>ストリングの長さ| <SLP SPI>ストリング\+++++++++++++++++++++++++++++++++
In order for a Service to match a SrvRqst, it must belong to at least one requested scope, support the requested service type, and match the predicate. If the predicate is present, the language of the request (ignoring the dialect part of the Language Tag) must match the advertised service.
ServiceがSrvRqstに合うように、それは、少なくとも1つの要求された範囲に属して、要求されたサービスタイプを支持して、述部に合わなければなりません。 述部が存在しているなら、要求(Language Tagの方言一部を無視する)の言語は広告を出しているサービスに合わなければなりません。
<PRList> is the Previous Responder List. This <string-list> contains dotted decimal notation IP (v4) addresses, and is iteratively multicast to obtain all possible results (see Section 6.3). UAs SHOULD implement this discovery algorithm. SAs MUST use this to discover all available DAs in their scope, if they are not already configured with DA addresses by some other means.
<PRList>はPrevious Responder Listです。 この<ストリングリスト>はドット付き10進法IP(v4)アドレスを含んでいて、すべての可能な結果を得る繰り返しマルチキャスト(セクション6.3を見る)です。 UAs SHOULDはこの発見アルゴリズムを実行します。 SAsは彼らの範囲ですべての利用可能なDAsを発見するのにこれを使用しなければなりません、彼らがDAアドレスによってある他の手段で既に構成されないなら。
A SA silently drops all requests which include the SA's address in the <PRList>. An SA which has multiple network interfaces MUST check if any of the entries in the <PRList> equal any of its interfaces. An entry in the PRList which does not conform to an IPv4 dotted decimal address is ignored: The rest of the <PRList> is processed normally and an error is not returned.
SAは静かに<PRList>のSAのアドレスを含んでいるすべての要求を落とします。 複数のネットワーク・インターフェースを持っているSAは、<PRList>のエントリーのどれかがインタフェースのどれかと等しいかどうかチェックしなければなりません。 IPv4ドット付き10進法アドレスに従わないPRListのエントリーは無視されます: 通常、<PRList>の残りは処理されます、そして、誤りは返されません。
Once a <PRList> plus the request exceeds the path MTU, multicast convergence stops. This algorithm is not intended to find all instances; it finds 'enough' to provide useful results.
<PRList>と要求がいったん経路MTUを超えていると、マルチキャスト集合は止まります。 このアルゴリズムがすべての例を見つけることを意図しません。 それは役に立つ結果を提供するためには'十分'を見つけます。
The <scope-list> is a <string-list> of configured scope names. SAs and DAs which have been configured with any of the scopes in this list will respond. DAs and SAs MUST reply to unicast requests with a
<範囲リスト>は構成された範囲名のリストを結んでいる<>です。 このリストの範囲のいずれでも構成されたSAsとDAsは応じるでしょう。 DAsとSAsはaとのユニキャスト要求に答えなければなりません。
Guttman, et al. Standards Track [Page 19] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[19ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
SCOPE_NOT_SUPPORTED error if the <scope-list> is omitted or fails to include a scope they support (see Section 11). The only exceptions to this are described in Section 11.2.
<が>を範囲で記載するなら、_SUPPORTED誤りではなく、SCOPE_が忘れられるか、または彼らが支える範囲を含んでいません(セクション11を見てください)。 唯一の例外がセクション11.2にこれに説明されます。
The <service-type> string is discussed in Section 4. Normally, a SrvRqst elicits a SrvRply. There are two exceptions: If the <service-type> is set to "service:directory-agent", DAs respond to the SrvRqst with a DAAdvert (see Section 8.5.) If set to "service:service-agent", SAs respond with a SAAdvert (see Section 8.6.) If this field is omitted, a PARSE_ERROR is returned - as this field is REQUIRED.
セクション4でサービスタイプ>が結ぶ<について議論します。 通常、SrvRqstはSrvRplyを引き出します。 2つの例外があります: <サービスタイプ>が「サービス: ディレクトリエージェント」に用意ができているなら、DAsはDAAdvertと共にSrvRqstに応じます(セクション8.5を見てください)。 「サービス: サービスエージェント」に設定されるなら、SAsはSAAdvertと共に応じます(セクション8.6を見てください)。 この分野を省略するなら、この分野がREQUIREDであるので、PARSE_ERRORを返します。
The <predicate> is a LDAPv3 search filter [14]. This field is OPTIONAL. Services may be discovered simply by type and scope. Otherwise, services are discovered which satisfy the <predicate>. If present, it is compared to each registered service. If the attribute in the filter has been registered with multiple values, the filter is compared to each value and the results are ORed together, i.e., "(x=3)" matches a registration of (x=1,2,3); "(!(Y=0))" matches (y=0,1) since Y can be nonzero. Note the matching is case insensitive. Keywords (i.e., attributes without values) are matched with a "presence" filter, as in "(keyword=*)".
<述部>はLDAPv3検索フィルタ[14]です。 この分野はOPTIONALです。 サービスは単にタイプと範囲によって発見されるかもしれません。 さもなければ、サービスは発見されます(<述部>を満たします)。 存在しているなら、それはそれぞれの登録されたサービスと比較されます。 すなわち、「(x=3)」がフィルタの属性が複数の値に示されて、フィルタが各値と比較されて、結果が一緒にORedであるなら、登録に合っている、(x=1、2、3)。 「((Y=0))」は、Yが非零であるかもしれないので、合っています(y=0、1)。 マッチングが大文字と小文字を区別しないことに注意してください。 キーワード(すなわち、値のない属性)は「(キーワード=*)」のように「存在」フィルタに合わせられています。
An incoming request term MUST have the same type as the attribute in a registration in order to match. Thus, "(x=33)" will not match ' x=true', etc. while "(y=foo)" will match 'y=FOO'. "(|(x=33)(y=foo))" will be satisfied, even though "(x=33)" cannot be satisfied, because of the `|' (boolean disjunction).
入って来る要求用語には、登録における属性と同じタイプが、合うようになければなりません。 したがって、「」 (x=33)意志は= 本当に'xに合わないことなど'が意志のマッチ'y=FOO'をゆったり過ごします「(y=foo)」という。 '「(x=33)」は‘で満足することができませんが、「(| (x=33)(y=foo))」は満足するでしょう。|'(論理演算子分裂)'。
Wildcard matching MUST be done with the '=' filter. In any other case, a PARSE_ERROR is returned. Request terms which include wildcards are interpreted to be Strings. That is, (x=34*) would match 'x=34foo', but not 'x=3432' since the first value is a String while the second value is an Integer; Strings don't match Integers.
'='フィルタでワイルドカードマッチングをしなければなりません。 いかなる他の場合ではも、PARSE_ERRORを返します。 ワイルドカードを含んでいる用語がStringsになるように解釈されるよう要求してください。 すなわち、(x=34*)は2番目の値がIntegerですが、最初の値がStringであるので、'x=3432'ではなく'x=34foo'に合っているでしょう。 ストリングはIntegersに合っていません。
Examples of Predicates follow. <t> indicates the service type of the SrvRqst, <s> gives the <scope-list> and <p> is the predicate string.
Predicatesに関する例は従います。 <t>は、SrvRqstのサービスタイプ、<s>が<範囲リスト>に与えるのを示します、そして、<p>は述部ストリングです。
<t>=service:http <s>=DEFAULT <p>= (empty string)
This is a minimal request string. It matches all http
services advertised with the default scope.
<t>はサービスと等しいです: (空のストリング)DEFAULT<p http<s>=>=これは最小量の要求ストリングです。 それはデフォルト範囲で広告に掲載されたすべてのhttpサービスに合っています。
<t>=service:pop3 <s>=SALES,DEFAULT <p>=(user=wump)
This is a request for all pop3 services available in
the SALES or DEFAULT scope which serve mail to the user
`wump'.
<t>はサービスと等しいです: pop3<s>=SALES、ユーザ'wump'にメールに役立つSALESかDEFAULT範囲で利用可能なすべてのpop3サービスを求めて(ユーザ=wump)DEFAULT<p>=これは要求です。
Guttman, et al. Standards Track [Page 20] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[20ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
<t>=service:backup <s>=BLDG 32 <p>=(&(q<=3)(speed>=1000))
This returns the backup service which has a queue length
less than 3 and a speed greater than 1000. It will
return this only for services registered with the BLDG 32
scope.
<t>はサービスと等しいです: バックアップ<s>はこれが3未満の待ち行列の長さと1000以上の速度を持っているアフターサービスを返すBLDG32<p>=((q<=3)(速度>=1000))と等しいです。 それはBLDG32範囲に登録されたサービスのためだけにこれを返すでしょう。
<t>=service:directory-agent <s>=DEFAULT <p>=
This returns DAAdverts for all DAs in the DEFAULT scope.
<t>はサービスと等しいです: DEFAULT<pディレクトリエージェント<s>=>=これはDEFAULT範囲のすべてのDAsのためにDAAdvertsを返します。
DAs are discovered by sending a SrvRqst with the service type set to "service:directory-agent". If a predicate is included in the SrvRqst, the DA SHOULD respond only if the predicate can be satisfied with the DA's attributes. The <scope-list> MUST contain all scopes configured for the UA or SA which is discovering DAs.
DAsは、タイプが「サービス: ディレクトリエージェント」に設定するサービスと共にSrvRqstを送ることによって、発見されます。 述部がSrvRqstに含まれているなら、DAの属性に述部を満たすことができる場合にだけ、DA SHOULDは応じます。 <範囲リスト>はDAsを発見しているUAかSAのために構成されたすべての範囲を含まなければなりません。
The <SLP SPI> string indicates a SLP SPI that the requester has been configured with. If this string is omitted, the responder does not include any Authentication Blocks in its reply. If it is included, the responder MUST return a reply which has an associated authentication block with the SLP SPI in the SrvRqst. If no replies may be returned because the SLP SPI is not supported, the responder returns an AUTHENTICATION_UNKNOWN error.
<SLP SPI>ストリングはリクエスタが構成されたSLP SPIを示します。 このストリングが省略されるなら、応答者は回答で少しのAuthentication Blocksも入れません。 それが含まれているなら、応答者はSrvRqstのSLP SPIと共に関連認証ブロックを持っている回答を返さなければなりません。 SLP SPIが支持されないので回答を全く返さないかもしれないなら、応答者はAUTHENTICATION_UNKNOWN誤りを返します。
8.2. Service Reply
8.2. サービス回答
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 = 2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | URL Entry count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| <URL Entry 1> ... <URL Entry N> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サービスLocationヘッダー(機能=SrvRply=2)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | エラーコード| URL Entryカウント| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | <URLエントリー1>… <URLエントリーN>\+++++++++++++++++++++++++++++++++
The service reply contains zero or more URL entries (see Section 4.3). A service reply with zero URL entries MUST be returned in response to a unicast Service Request, if no matching URLs are present. A service reply with zero URL entries MUST NOT be sent in response to a multicast or broadcast service request (instead, if there was no match found or an error processing the request, the service reply should not be generated at all).
サービス回答はゼロか、より多くのURLエントリーを含んでいます(セクション4.3を見てください)。 ユニキャストService Requestに対応してURLエントリーがないのによるサービス回答を返さなければなりません、どんな合っているURLも存在していないなら。 マルチキャストか放送サービスのリクエストに対応してURLエントリーがないのによるサービス回答を送ってはいけません(代わりに、見つけられたマッチが全くなかったか、そして、エラー処理が全く発生するべきではありません要求、サービスが、返答する)。
If the reply overflows, the UA MAY simply use the first URL Entry in the list. A URL obtained by SLP may not be cached longer than Lifetime seconds, unless there is a URL Authenticator block present.
回答があふれるなら、UA MAYはリストで単に最初のURL Entryを使用します。 SLPによって得られたURLはLifetime秒より長い間、キャッシュされないかもしれません、存在しているURL Authenticatorブロックがない場合。
Guttman, et al. Standards Track [Page 21] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[21ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
In that case, the cache lifetime is indicated by the Timestamp in the URL Authenticator (see Section 9.2).
生涯をキャッシュしてください。その場合、URL Authenticator(セクション9.2を見る)でTimestampによって示されます。
An authentication block is returned in the URL Entries, including the SLP SPI in the SrvRqst. If no SLP SPI was included in the request, no Authentication Blocks are returned in the reply. URL Authentication Blocks are defined in Section 9.2.1.
SrvRqstにSLP SPIを含むURL Entriesで認証ブロックを返します。 要求にSLP SPIを全く含んでいなかったなら、回答でAuthentication Blocksを全く返しません。 URL Authentication Blocksはセクション9.2.1で定義されます。
If a SrvRply is sent by UDP, a URL Entry MUST NOT be included unless it fits entirely without truncation.
SrvRplyがUDPによって送られて、完全なトランケーションなしで合わない場合、URL Entryを含んではいけません。
8.3. Service Registration
8.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 = SrvReg = 3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| <URL-Entry> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of service type string | <service-type> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <scope-list> | <scope-list> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of attr-list string | <attr-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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サービスLocationヘッダー(機能=SrvReg=3)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | <URL、-、エントリー>\+++++++++++++++++++++++++++++++++| 勤続年数タイプストリング| タイプ>を調整している<\+++++++++++++++++++++++++++++++++| <範囲リスト>の長さ| <は>\+++++++++++++++++++++++++++++++++を範囲で記載します。| attr-リストストリングの長さ| <は>\+++++++++++++++++++++++++++++++++をattr記載します。|# AttrAuthsについて|(存在しているなら) 認証ブロックを結果と考えてください…\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The <entry> is a URL Entry (see section 4.3). The Lifetime defines how long a DA can cache the registration. SAs SHOULD reregister before this lifetime expires (but SHOULD NOT more often than once per second). The Lifetime MAY be set to any value between 0 and 0xffff (maximum, around 18 hours). Long-lived registrations remain stale longer if the service fails and the SA does not deregister the service.
<エントリー>はURL Entry(セクション4.3を見る)です。 Lifetimeは、どれくらい長いDAが登録をキャッシュできるかを定義します。 この生涯の前のSAs SHOULD reregisterが期限が切れる、(SHOULD NOT、 よりしばしば、1秒あたり一度) Lifetimeは0と0xffff(18時間の周りで最大の)の間のどんな値にも用意ができるかもしれません。 サービスが失敗して、SAがどんな「反-レジスタ」にもサービスしないなら、長命の登録証明書は、より長い間、聞き古したである残っています。
The <service-type> defines the service type of the URL to be registered, regardless of the scheme of the URL. The <scope-list> MUST contain the names of all scopes configured for the SA, which the DA it is registering with supports. The default value for the <scope-list> is "DEFAULT" (see Section 11).
<サービスタイプ>は、URLの計画にかかわらず登録されるためにURLのサービスタイプを定義します。 <範囲リスト>がSAのために構成されたすべての範囲の名前を含まなければならない、どれ、それがサポートに登録しているDA。 <範囲リスト>のためのデフォルト値は「デフォルト」(セクション11を見る)です。
The SA MUST register consistently with all DAs. If a SA is configured with scopes X and Y and there are three DAs, whose scopes are "X", "Y" and "X,Y" respectively, the SA will register the with all three DAs in their respective scopes. All future updates and deregistrations of the service must be sent to the same set of DAs in
SA MUSTは一貫してすべてのDAsとともに記名します。 SAが範囲XとYで構成されて、3DAs(範囲は、それぞれ「X」と「Y」と「X、Y」である)があると、SAはそれらのそれぞれの範囲のすべての3ダスとともに記名するでしょう。 中でサービスのすべての将来のアップデートと「反-登録証明書」をDAsの同じセットに送らなければなりません。
Guttman, et al. Standards Track [Page 22] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[22ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
the same scopes the service was initially registered in.
同じくらいは、サービスが初めは登録されたのを見ます。
The <attr-list>, if present, specifies the attributes and values to be associated with the URL by the DA (see Section 5).
存在しているなら、<attr-リスト>は、DAでURLに関連しているように属性と値を指定します(セクション5を見てください)。
A SA configured with the ability to sign service registrations MUST sign each of the URLs and Attribute Lists using each of the keys it is configured to use, and the DA it is registering with accepts. (The SA MUST acquire DAAdverts for all DAs it will register with to obtain the DA's SLP SPI list and attributes, as described in Section 8.5). The SA supplies a SLP SPI in each authentication block indicating the SLP SPI configuration required to verify the digital signature. The format of the digital signatures used is defined in section 9.2.1.
サービス登録証明書にサインする能力によって構成されたSAはそれぞれのURLとそれぞれ使用するのが構成されているキーのAttribute Lists使用にサインしなければなりません、そして、それがともに記名しているDAは受け入れます。 (SA MUSTはそれがDAのSLP SPIリストと属性を得るためにともに記名するすべてのDAsのためにDAAdvertsを獲得します、セクション8.5で説明されるように。) SAはSLP SPI構成がデジタル署名について確かめるのが必要であることを示すそれぞれの認証ブロックでSLP SPIを供給します。 使用されるデジタル署名の書式はセクション9.2.1で定義されます。
Subsequent registrations of previously registered services MUST contain the same list of SLP SPIs as previous ones or else DAs will reject them, replying with an AUTHENTICATION_ABSENT error.
前のものかDAsが彼らを拒絶するとき、以前に登録されたサービスのその後の登録証明書はSLP SPIsの同じリストを含まなければなりません、AUTHENTICATION_ABSENT誤りで返答して。
A registration with the FRESH flag set will replace *entirely* any previous registration for the same URL in the same language. If the FRESH flag is not set, the registration is an "incremental" registration (see Section 9.3).
FRESH旗がセットしたことでの登録は*に*完全に取って代わるでしょう。同じ言語の同じURLのためのどんな前の登録。 FRESH旗が設定されないなら、登録は「増加」の登録(セクション9.3を見る)です。
8.4. Service Acknowledgment
8.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = SrvAck = 5) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サービスLocationヘッダー(機能=SrvAck=5)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | エラーコード| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A DA returns a SrvAck to an SA after a SrvReg. It carries only a two byte Error Code (see Section 7).
DAはSrvRegの後のSAにSrvAckを返します。それはError Codeを2バイトだけ運びます(セクション7を見てください)。
Guttman, et al. Standards Track [Page 23] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[23ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
8.5. Directory Agent Advertisement
8.5. ディレクトリエージェント広告
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 = 8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | DA Stateless Boot Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|DA Stateless Boot Time,, contd.| Length of URL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ URL \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of <scope-list> | <scope-list> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of <attr-list> | <attr-list> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of <SLP SPI List> | <SLP SPI List> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # Auth Blocks | Authentication block (if any) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サービスLocationヘッダー(機能=DAAdvert=8)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | エラーコード| DAの国がないブーツタイムスタンプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |DA Stateless Boot Time、contd| URLの長さ| URL| <範囲リスト>の長さ| <は>\+++++++++++++++++++++++++++++++++を範囲で記載します。| <attr-リスト>の長さ| <は>\+++++++++++++++++++++++++++++++++をattr記載します。| <SLP SPIリスト>の長さ| <SLP SPIリスト>ストリング\+++++++++++++++++++++++++++++++++| # Authブロック| 認証ブロック(もしあれば)\+++++++++++++++++++++++++++++++++
The Error Code is set to 0 when the DAAdvert is multicast. If the DAAdvert is being returned due to a unicast SrvRqst (ie. a request without the REQUEST MCAST flag set) the DA returns the same errors a SrvRply would.
DAAdvertがマルチキャストであるときに、Error Codeは0に用意ができています。 ユニキャストのためDAAdvertを返しているなら、SrvRqst(ie REQUEST MCAST旗のない要求はセットした)DAはSrvRplyが返す同じ誤りを返します。
The <scope-list> of the SrvRqst must either be omitted or include a scope which the DA supports. The DA Stateless Boot Timestamp indicates the state of the DA (see section 12.1).
SrvRqstの<範囲リスト>は省略されなければならないか、またはDAが支える範囲を含まなければなりません。 DA Stateless Boot TimestampはDAの州を示します(セクション12.1を見てください)。
The DA MAY include a list of its attributes in the DAAdvert. This list SHOULD be kept short, as the DAAdvert must fit into a datagram in order to be multicast.
DA MAYはDAAdvertに属性のリストを含んでいます。 DAAdvertが収まらなければならないように、このリストSHOULDが短いのが保たれて、マルチキャストになるようにデータグラムに収まってください。
A potential scaling problem occurs in SLPv2 if SAs choose too low a Lifetime. In this case, an onerous amount of reregistration occurs as more services are deployed. SLPv2 allows DAs to control SAs frequency of registration. A DA MAY reissue a DAAdvert with a new set of attributes at any time, to change the reregistration behavior of SAs. These apply only to subsequent registrations; existing service registrations with the DA retain their registered lifetimes.
SAsが低過ぎるLifetimeを選ぶなら、潜在的スケーリング問題はSLPv2に起こります。 この場合、より多くのサービスが配備されるとき、再登録の煩わしい量は起こります。 SLPv2はDAsに登録のSAs頻度を制御させます。 DA MAYは、いつでも、SAsの再登録動きを変えるために新しいセットの属性があるDAAdvertを再発行します。 これらはその後の登録証明書だけに適用されます。 DAとの既存のサービス登録証明書は彼らの登録された生涯を保有します。
If the DAAdvert includes the attribute "min-refresh-interval" it MUST be set to a single Integer value indicating a number of seconds. If this attribute is present SAs MUST NOT refresh any particular service advertisement more frequently than this value. If SrvReg with the FRESH FLAG not set or SrvDereg with a non-empty tag list updating a
DAAdvertが属性を含んでいるなら、それが「分は間隔をリフレッシュしなければならないこと」が独身のIntegerに値が秒数を示すように設定します。 この属性が存在しているなら、SAsはこの値よりどんな特定のサービス広告頻繁にもリフレッシュしてはいけません。 FRESH FLAGとSrvRegがセットしなかったか、または非空のタグがあるSrvDeregがaをアップデートしながら記載するなら
Guttman, et al. Standards Track [Page 24] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[24ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
particular service are received more often than the value for the DA's advertised "min-refresh-interval" attribute the DA SHOULD reject the message and return a REFRESH_REJECTED error in the SrvAck.
広告に掲載されたDAの「分は間隔をリフレッシュであること」がDA SHOULDを結果と考えるので、値がSrvAckでメッセージを拒絶して、REFRESH_REJECTED誤りを返すよりしばしば特定のサービスを受けます。
The URL is "service:directory-agent://"<addr> of the DA, where <addr> is the dotted decimal numeric address of the DA. The <scope-list> of the DA MUST NOT be NULL.
URLがそうである、「サービス: ディレクトリエージェント、://「DAの<addr>。」(そこでは、<addr>がDAのドット付き10進法数値アドレスです)。 <は>を範囲で記載します。DA MUST NOTでは、NULLになってください。
The SLP SPI List is the list of SPIs that the DA is capable of verifying. SAs MUST NOT register services with authentication blocks for those SLP SPIs which are not on the list. DAs will reject service registrations which they cannot verify, returning an AUTHENTICATION_UNKNOWN error.
SLP SPI ListはDAが確かめることができるSPIsのリストです。 SAsはリストにないそれらのSLP SPIsのための認証ブロックにサービスを登録してはいけません。 AUTHENTICATION_UNKNOWN誤りを返して、DAsは彼らが確かめることができないサービス登録証明書を拒絶するでしょう。
The format of DAAdvert signatures is defined in Section 9.2.1.
DAAdvert署名の書式はセクション9.2.1で定義されます。
The SLP SPI which is used to verify the DAAdvert is included in the Authentication Block. When DAAdverts are multicast, they may have to transmit multiple DAAdvert Authentication Blocks. If the DA is configured to be able to generate signatures for more than one SPI, the DA MUST include one Authentication Block for each SPI. If all these Authentication Blocks do not fit in a single datagram (to multicast or broadcast) the DA MUST send separate DAAdverts so that Authentication Blocks for all the SPIs the DA is capable of generating are sent.
DAAdvertについて確かめるのに使用されるSLP SPIはAuthentication Blockに含まれています。 DAAdvertsがマルチキャストであるときに、彼らは複数のDAAdvert Authentication Blocksを伝えなければならないかもしれません。 DAが1SPIのために署名を発生させることができるように構成されるなら、DA MUSTは各SPIあたり1Authentication Blockを含んでいます。 これらのすべてのAuthentication Blocksが単一のデータグラム(マルチキャストか放送への)をうまくはめ込まないなら、DA MUSTは、DAが発生させることができるすべてのSPIsのためのAuthentication Blocksを送るように別々のDAAdvertsを送ります。
If the DAAdvert is being sent in response to a SrvRqst, the DAAdvert contains only the authentication block with the SLP SPI in the SrvRqst, if the DA is configured to be able to produce digital signatures using that SLP SPI. If the SrvRqst is unicast to the DA (the REQUEST MCAST flag in the header is not set) and an unsupported SLP SPI is included, the DA replies with a DAAdvert with the Error Code set to an AUTHENTICATION_UNKNOWN error.
SrvRqstに対応してDAAdvertを送るなら、DAAdvertはSrvRqstにSLP SPIがある認証ブロックだけを含んでいます、DAがそのSLP SPIを使用することでデジタル署名を起こすことができるように構成されるなら。 SrvRqstがDAへのユニキャスト(ヘッダーのREQUEST MCAST旗は設定されない)であり、サポートされないSLP SPIが含まれているなら、Error CodeとDAAdvertとのDA回答はAUTHENTICATION_UNKNOWN誤りにセットしました。
UAs SHOULD be configured with SLP SPIs that will allow them to verify DA Advertisements. If the UA is configured with SLP SPIs and receives a DAAdvert which fails to be verified using one of them, the UA MUST discard it.
UAs SHOULD、彼らにDA Advertisementsについて確かめさせるSLP SPIsで、構成されてください。 UAが彼らのひとりを使用することでSLP SPIsによって構成されて、確かめられないDAAdvertを受けるなら、Uaはそれを捨てなければなりません。
8.6. Service Agent Advertisement
8.6. サービスエージェント広告
User Agents MUST NOT solicit SA Advertisements if they have been configured to use a particular DA, if they have been configured with a <scope-list> or if DAs have been discovered. UAs solicit SA Advertisements only when they are explicitly configured to use User Selectable scopes (see Section 11.2) in order to discover the scopes that SAs support. This allows UAs without scope configuration to make use of either DAs or SAs without any functional difference
彼らが特定のDAを使用するために構成されたならユーザエージェントがSA Advertisementsに請求してはいけない、彼らが<によって構成されたなら、>を範囲で記載するか、またはさもなければ、DAsであるなら発見されてください、そうした。 彼らがUser Selectable範囲を使用するために明らかに構成されるときだけ(セクション11.2を見てください)、UAsは、SAsが支える範囲を発見するためにSA Advertisementsに請求します。 これで、範囲構成のないUAsは少しも機能的な違いなしでDAsかSAsのどちらかを利用できます。
Guttman, et al. Standards Track [Page 25] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[25ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
except performance.
性能を除いて。
A SA MAY be configured with attributes, and SHOULD support the attribute 'service-type' whose value is all the service types of services represented by the SA. SAs MUST NOT respond if the SrvRqst predicate is not satisfied. For example, only SAs offering 'nfs' services SHOULD respond with a SAAdvert to a SrvRqst for service type "service:service-agent" which includes a predicate "(service- type=nfs)".
SA MAY、構成されていて、属性、およびSHOULDサポートによる値がすべてのサービスタイプのサービスである属性'サービスタイプ'はSAを表しました。 SrvRqst述部が満たされていないなら、SAsは応じてはいけません。 例えば、SHOULDがサービスのためにSAAdvertと共にSrvRqstに反応させる'nfs'サービスを提供するSAsだけが「サービス: サービスエージェント」をタイプします(述部を含んでいます)「(サービスタイプはnfsと等しいです)」という。
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 = SAAdvert = 11) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of URL | URL \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of <scope-list> | <scope-list> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of <attr-list> | <attr-list> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # auth blocks | authentication block (if any) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サービスLocationヘッダー(機能=SAAdvert=11)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | URLの長さ| URL\+++++++++++++++++++++++++++++++++| <範囲リスト>の長さ| <は>\+++++++++++++++++++++++++++++++++を範囲で記載します。| <attr-リスト>の長さ| <は>\+++++++++++++++++++++++++++++++++をattr記載します。| # authブロック| 認証ブロック(もしあれば)\+++++++++++++++++++++++++++++++++
The SA responds only to multicast SA discovery requests which either include no <scope-list> or a scope which they are configured to use.
SAは<範囲リストがない>かそれらが使用するために構成される範囲を含んでいるマルチキャストSA発見要求だけに応じます。
The SAAdvert MAY include a list of attributes the SA supports. This attribute list SHOULD be kept short so that the SAAdvert will not exceed the path MTU in size.
SAAdvertはSAが支持する属性のリストを含むかもしれません。 この属性はSAAdvertが超えていない保たれた短いそうがサイズが経路MTUであったならSHOULDを記載します。
The URL is "service:service-agent://"<addr> of the SA, where <addr> is the dotted decimal numeric address of the SA. The <scope-list> of the SA MUST NOT be null.
URLがそうである、「サービス: サービスエージェント、://「SAの<addr>。」(そこでは、<addr>がSAのドット付き10進法数値アドレスです)。 <は>を範囲で記載します。SA MUST NOTでは、ヌルになってください。
The SAAdvert contains one SAAdvert Authentication block for each SLP SPI the SA can produce Authentication Blocks for. If the UA can verify the Authentication Block of the SAAdvert, and the SAAdvert fails to be verified, the UA MUST discard it.
SAAdvertはSAがAuthentication Blocksを生産できる各SLP SPIあたり1つのSAAdvert Authenticationブロックを含んでいます。 UAがSAAdvertのAuthentication Blockについて確かめることができて、SAAdvertが確かめられないなら、Uaはそれを捨てなければなりません。
9. Optional Features
9. オプション機能
The features described in this section are not mandatory. Some are useful for interactive use of SLP (where a user rather than a program will select services, using a browsing interface for example) and for scalability of SLP to larger networks.
このセクションで説明された特徴は義務的ではありません。 或るものはSLP(例えばブラウジングインタフェースを使用して、プログラムよりむしろユーザはそこでサービスを選択する)の対話的な使用と、より大きいネットワークへのSLPのスケーラビリティの役に立ちます。
Guttman, et al. Standards Track [Page 26] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[26ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
9.1. Service Location Protocol Extensions
9.1. サービス位置のプロトコル拡大
The format of a Service Location Extension is:
Service Location 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 | Next Extension Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset, contd.| Extension Data \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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| 次の拡大は相殺されました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | contd| オフセット、拡大Data\+++++++++++++++++++++++++++++++++
Extension IDs are assigned in the following way:
拡大IDは以下の方法で割り当てられます:
0x0000-0x3FFF Standardized. Optional to implement. Ignore if
unrecognized.
0x4000-0x7FFF Standardized. Mandatory to implement. A UA or SA
which receives this option in a reply and does not understand
it MUST silently discard the reply. A DA or SA which receives
this option in a request and does not understand it MUST return
an OPTION_NOT_UNDERSTOOD error.
0x8000-0x8FFF For private use (not standardized). Optional to
implement. Ignore if unrecognized.
0x9000-0xFFFF Reserved.
標準化された0×0000 0x3FFF。 実行するために、任意です。 認識されていないなら、無視します。 標準化された0×4000 0x7FFF。 実行するために、義務的です。 回答でこのオプションを受け取って、それを理解していないUAかSAが静かに回答を捨てなければなりません。 要求にこのオプションを受け取って、それを理解していないDAかSAが__どんなUNDERSTOOD誤りもOPTIONに返してはいけません。 0×8000 0x8FFF Forの私用(標準化されません)。 実行するために、任意です。 認識されていないなら、無視します。 予約された0×9000 0xFFFF。
The three byte offset to next extension indicates the position of the next extension as offset from the beginning of the SLP message.
次の拡大に相殺された3バイトはSLPメッセージの始まりから相殺されるように次の拡大の位置を示します。
The offset value is 0 if there are no extensions following the current extension.
現在の拡大に続く拡大が全くなければ、オフセット値は0です。
If the offset is 0, the length of the current Extension Data is determined by subtracting total length of the SLP message as given in the SLP message header minus the offset of the current extension.
オフセットが0であるなら、SLPメッセージヘッダーで現在の拡大のオフセットを引いて与えるようにSLPメッセージの全長を引き算するExtension Dataが決定している電流の長さです。
Extensions defined in this document are in Section D. See section 15 for procedures that are required when specifying new SLP extensions.
本書では定義された拡大が新しいSLP拡張子を指定するとき必要である手順のためのセクションD.See部15にあります。
Guttman, et al. Standards Track [Page 27] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[27ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
9.2. Authentication Blocks
9.2. 認証ブロック
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Block Structure Descriptor | Authentication Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLP SPI String Length | SLP SPI String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Structured Authentication Block ... \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ブロック構造記述子| 認証ブロック長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイムスタンプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SLP SPIストリング長| SLP SPIストリング\+++++++++++++++++++++++++++++++++| 認証ブロックを構造化します… \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Authentication blocks are returned with certain SLP messages to verify that the contents have not been modified, and have been transmitted by an authorized agent. The authentication data (contained in the Structured Authentication Block) is typically case sensitive. Even though SLP registration data (e.g., attribute values) are typically are not case sensitive, the case of the registration data has to be preserved by the registering DA so that UAs will be able to verify the data used for calculating digital signature data.
コンテンツが変更されていなくて、委任代理人によって伝えられたことを確かめるあるSLPメッセージと共に認証ブロックを返します。 認証データ(Structured Authentication Blockでは、含まれている)は通常大文字と小文字を区別しています。 SLP登録データ(例えば、属性値)は通常、そうですが、ケースは敏感ではありません、登録データに関するケースが登録しているDAによって保存されなければなりません、したがって、そのUAsがあるでしょう。計算のデジタル署名データに使用されるデータについて確かめることができます。
The Block Structure Descriptor (BSD) identifies the format of the Authenticator which follows. BSDs 0x0000-0x7FFF will be maintained by IANA. BSDs 0x8000-0x8FFF are for private use.
Block Structure Descriptor(BSD)は続くAuthenticatorの形式を特定します。 BSDs、0×0000 0x7FFFがIANAによって維持されるでしょう。 BSDs、0×8000 0x8FFFが私用のためのものです。
The Authentication Block Length is the length of the entire block, starting with the BSD.
BSDから始まって、Authentication Block Lengthは全体のブロックの長さです。
The Timestamp is the time that the authenticator expires (to prevent replay attacks.) The Timestamp is a 32-bit unsigned fixed-point number of seconds relative to 0h on 1 January 1970. SAs use this value to indicate when the validity of the digital signature expires. This Timestamp will wrap back to 0 in the year 2106. Once the value of the Timestamp wraps, the time at which the Timestamp is relative to resets. For example, after 06h28 and 16 seconds 5 February 2106, all Timestamp values will be relative to that epoch date.
Timestampは固有識別文字が期限が切れる(反射攻撃を防ぐ)時間です。 Timestampは1970年1月1日の0hに比例した秒の32ビットの無記名の固定小数点数です。 SAsは、デジタル署名の正当性がいつ期限が切れるかを示すのにこの値を使用します。 このTimestampは2106年の間、0への後部を包装するでしょう。 かつてのTimestamp機密の値、Timestampがリセットに比例している時。 例えば、06h28と2106年2月5日、すべてのTimestampがその時代に比例しているのを評価する16秒以降、デートしてください。
The SLP Security Parameters Index (SPI) string identifies the key length, algorithm parameters and keying material to be used by agents to verify the signature data in the Structured Authentication Block. The SLP SPI string has the same grammar as the <scope-val> defined in Section 6.4.1.
Structured Authentication Blockの署名データについて確かめるのにエージェントによって使用されるように、SLP Security Parameters Index(SPI)ストリングはキー長、アルゴリズムパラメタ、および合わせることの材料を特定します。 SLP SPIストリングには、>がセクション6.4.1で定義した<範囲-valと同じ文法があります。
Reserved characters in SLP SPI strings must be escaped using the same convention as used throughout SLPv2.
SLPv2中で同じくらい中古の同じコンベンションを使用することでSLP SPIストリングの控え目なキャラクタから逃げなければなりません。
Guttman, et al. Standards Track [Page 28] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[28ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
SLP SPIs deployed in a site MUST be unique. An SLP SPI used for BSD=0x0002 must not be the same as used for some other BSD.
サイトで配備されたSLP SPIsはユニークであるに違いありません。 BSD=0x0002に使用されるSLP SPIはある他のBSDに使用されるのと同じであるはずがありません。
All SLP agents MUST implement DSA [20] (BSD=0x0002). SAs MUST register services with DSA authentication blocks, and they MAY register them with other authentication blocks using other algorithms. SAs MUST use DSA authentication blocks in SrvDeReg messages and DAs MUST use DSA authentication blocks in unsolicited DAAdverts.
すべてのSLPエージェントがDSA[20](BSD=0x0002)を実行しなければなりません。 SAsはDSA認証ブロックにサービスを登録しなければなりません、そして、それらは他のアルゴリズムを使用する他の認証ブロックにそれらを登録するかもしれません。SAsはSrvDeRegメッセージでのDSA認証ブロックを使用しなければなりません、そして、DAsは求められていないDAAdvertsでのDSA認証ブロックを使用しなければなりません。
9.2.1. SLP Message Authentication Rules
9.2.1. SLP通報認証規則
The sections below define how to calculate the value to apply to the algorithm identified by the BSD value. The components listed are used as if they were a contiguous single byte aligned buffer in the order given.
下のセクションはBSD値によって特定されたアルゴリズムに適用するために値について計算する方法を定義します。 記載されたコンポーネントはまるでそれらが与えられたオーダーで隣接のただ一つのバイト並べられたバッファであるかのように使用されています。
URL
16-bit Length of SLP SPI String, SLP SPI String.
16-bit Length of URL, URL,
32-bit Timestamp.
SLP SPIストリング、URLの16ビットの長さのSLP SPIストリング。 URL、URL、16ビットの長さの32ビットのタイムスタンプ。
Attribute List
16-bit Length of SLP SPI String, SLP SPI String,
16-bit length of <attr-list>, <attr-list>,
32-bit Timestamp.
SLP SPI String、SLP SPI String、<attr-リスト>、<attr-リスト>、32ビットのTimestampの16ビットの長さのListの16ビットのLengthを結果と考えてください。
DAAdvert
16-bit Length of SLP SPI String, SLP SPI String,
32-bit DA Stateless Boot Timestamp,
16-bit Length of URL, URL,
16-bit Length of <attr-list>, <attr-list>,
16-bit Length of DA's <scope-list>, DA's <scope-list>,
16-bit Length of DA's <SLP SPI List>, DA's <SLP SPI List>,
32-bit Timestamp.
DAAdvertの16ビットの長さのSLP SPIストリング、SLP SPIストリング、32ビットのDA国がないブーツタイムスタンプ、16ビットの長さのURL、URL、<attr-リスト>の16ビットの長さ、<attr-リスト>、DAの<範囲リスト>の16ビットの長さ、DAの<範囲リスト>、DAの<SLP SPIリスト>の16ビットの長さ、DAの<SLP SPIは>を記載します、32ビットのタイムスタンプ。
The first SLP SPI is the SLP SPI in the Authentication
Block. This SLP SPI indicates the keying material and other
parameters to use to verify the DAAdvert. The SLP SPI List is
the list of SLP SPIs the DA itself supports, and is able to
verify.
最初のSLP SPIはAuthentication BlockのSLP SPIです。 このSLP SPIはDAAdvertについて確かめるのに使用する合わせることの材料と他のパラメタを示します。 SLP SPI ListはDA自身がサポートして、確かめることができるSLP SPIsのリストです。
SAAdvert
16-bit Length of SLP SPI String, SLP SPI String,
16-bit Length of URL, URL,
16-bit Length of <attr-list>, <attr-list>,
16-bit Length of <scope-list>, <scope-list>,
32-bit Timestamp.
SAAdvertの16ビットの長さのSLP SPIストリング、SLP SPIストリング、16ビットの長さのURL、URL、<attr-リスト>の16ビットの長さ、<は>をattr記載します、<範囲リスト>の16ビットの長さ、<範囲リスト>、32ビットのタイムスタンプ。
Guttman, et al. Standards Track [Page 29] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[29ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
9.2.2 DSA with SHA-1 in Authentication Blocks
9.2.2 SHA-1が認証ブロックにあるDSA
BSD=0x0002 is defined to be DSA with SHA-1. The signature calculation is defined by [20]. The signature format conforms to that in the X.509 v3 certificate:
BSD=0x0002は、SHA-1とDSAになるように定義されます。 署名計算は[20]によって定義されます。 署名形式はX.509 v3証明書でそれに従います:
1. The signature algorithm identifier (an OID)
2. The signature value (an octet string)
3. The certificate path.
1. 署名アルゴリズム識別子(OID)2。 署名価値(八重奏ストリング)の3。 証明書経路。
All data is represented in ASN.1 encoding:
すべてのデータがASN.1コード化で表されます:
id-dsa-with-sha1 ID ::= {
iso(1) member-body(2) us(840) x9-57 (10040)
x9cm(4) 3 }
sha1とイドdsa ID:、:= iso(1)は(2) 私たち(840)x9-57(10040)x9cm(4)3をメンバーと同じくらい具体化させます。
i.e., the ASN.1 encoding of 1.2.840.10040.4.3 followed immediately by:
すなわち、ASN.1コード化、1.2 .840 .10040 .4 .3はすぐ以下で続きました。
Dss-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
以下をDss-Sig評価してください:= 系列r整数、s整数
i.e., the binary ASN.1 encoding of r and s computed using DSA and SHA-1. This is followed by a certificate path, as defined by X.509 [10], [2], [3], [4], [5].
すなわち、rとsの2進のASN.1コード化は、DSAとSHA-1を使用することで計算されました。 証明書経路はX.509[10]、[2]、[3]、[4]、[5]によって定義されるようにこれのあとに続いています。
Authentication Blocks for BSD=0x0002 have the following format. In the future, BSDs may be assigned which have different formats.
BSD=0x0002のための認証Blocksには、以下の形式があります。 将来、異なった形式を持っているBSDsは割り当てられるかもしれません。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASN.1 encoded DSA signature \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASN.1はDSA署名\+++++++++++++++++++++++++++++++++をコード化しました。
9.3. Incremental Service Registration
9.3. 増加のサービス登録
Incremental registrations update attribute values for a previously registered service. Incremental service registrations are useful when only a single attribute has changed, for instance. In an incremental registration, the FRESH flag in the SrvReg header is NOT set.
増加の登録証明書は以前に登録されたサービスのために属性値をアップデートします。 例えば、ただ一つの属性だけが変化したとき、増加のサービス登録証明書は役に立ちます。 増加の登録では、SrvRegヘッダーのFRESH旗は設定されません。
The new registration's attributes replace the previous registration's, but do not affect attributes which were included previously and are not present in the update.
新規登録の属性は、登録の前のものを取り替えますが、以前に含まれていた属性に影響しないで、またアップデートでは存在していません。
Guttman, et al. Standards Track [Page 30] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[30ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
For example, suppose service:x://a.org has been registered with attributes A=1, B=2, C=3. If an incremental registration comes for service:x://a.org with attributes C=30, D=40, then the attributes for the service after the update are A=1, B=2, C=30, D=40.
サービス: x://a.orgが例えば属性A=1に登録されたなら、B=2、C=3です。 D=40、増加の登録はサービスをしに来ます: 属性C=30があるx://a.orgなら、次に、アップデートの後のサービスのための属性はA=1です、B=2、D=40、C=30。
Incremental registrations MUST NOT be performed for services registered with Authentication Blocks. These must be registered with ALL attributes, with the FRESH flag in the SrvReg header set. DAs which receive such registration messages return an AUTHENTICATION_FAILED error.
Authentication Blocksに登録されたサービスのために増加の登録証明書を実行してはいけません。 すべての属性、SrvRegヘッダーセットにおけるFRESH旗にこれらを登録しなければなりません。 そのような登録メッセージを受け取るDAsがAUTHENTICATION_FAILED誤りを返します。
If the FRESH flag is not set and the DA does not have a prior registration for the service, the incremental registration fails with error code INVALID_UPDATE.
FRESH旗が設定されないで、またDAにサービスのための先の登録がないなら、エラーコードINVALID_UPDATEに応じて、増加の登録は失敗します。
The SA MUST use the same <scope-list> in an update message as was used in the prior registration. If this is not done, the DA returns a SCOPE_NOT_SUPPORTED error. In order to change the scope of a service advertisement it MUST be deregistered first and reregistered with a new <scope-list>.
SA MUSTは先の登録に使用されたアップデートメッセージで同じ<範囲リスト>を使用します。 これが完了していないなら、DAは__どんなSUPPORTED誤りもSCOPEに返しません。 サービス広告の範囲を変えるために、それは、新しい<範囲でリスト>を最初に、反登録して、再登録しなければなりませんでした。
The SA MUST use the same <service-type> in an update message as was used in a prior registration of the same URL. If this is not done, the DA returns an INVALID_UPDATE error.
SA MUSTは同じURLの先の登録に使用されたアップデートメッセージで同じ<サービスタイプ>を使用します。 これが完了していないなら、DAはINVALID_UPDATE誤りを返します。
9.4. Tag Lists
9.4. タグリスト
Tag lists are used in SrvDeReg and AttrReq messages. The syntax of a <tag-list> item is:
タグリストはSrvDeRegとAttrReqメッセージで使用されます。 リスト>にタグ付けををしている<品目の構文は以下の通りです。
tag-filter = simple-tag / substring
simple-tag = 1*filt-char
substring = [initial] any [final]
initial = 1*filt-char
any = `*' *(filt-char `*')
final = 1*filt-char
filt-char = Any character excluding <reserved> and <bad-tag> (see
grammar in Section 5).
<を除いたどんなどんな='*'*(filt-炭の'*')最終的な=1*filt-炭もfilt炭にする1*filt[初期の]サブストリング=いずれ[最終的な]も頭文字をつけるタグフィルタ=サブストリングの簡単な簡単なタグ/タグ=1*filt-炭=炭=キャラクタも>と<の悪いタグの>を予約しました(セクション5で文法を見てください)。
Wild card characters in a <tag-list> item match arbitrary sequences of characters. For instance "*bob*" matches "some bob I know", "bigbob", "bobby" and "bob".
リスト>にタグ付けををしている<品目のワイルドカードキャラクタはキャラクタの気紛れな順番に合っています。 「」 例えば、*ボブ*」は「私が知っているあるボブ」、"bigbob"、「巡査」、および「ボブ」に合っています。
Guttman, et al. Standards Track [Page 31] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[31ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
10. Optional SLP Messages
10. 任意のSLPメッセージ
The additional requests provide features for user interaction and for efficient updating of service advertisements with dynamic attributes.
追加要求はユーザ相互作用とサービス広告の効率的なアップデートのための特徴をダイナミックな属性に提供します。
10.1. Service Type Request
10.1. タイプが要求するサービス
The Service Type Request (SrvTypeRqst) allows a UA to discover all types of service on a network. This is useful for general purpose service browsers.
Service Type Request(SrvTypeRqst)はUAにネットワークですべてのタイプのサービスを発見させます。 これは汎用のサービスブラウザの役に立ちます。
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 = 9) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of PRList | <PRList> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of Naming Authority | <Naming Authority String> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <scope-list> | <scope-list> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サービスLocationヘッダー(機能=SrvTypeRqst=9)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PRListの長さ| <PRList>ストリング\+++++++++++++++++++++++++++++++++| Naming Authorityの長さ| +++++++++++++++++++++++++++++++++と権威ストリング>\を命名する<。| <範囲リスト>の長さ| <範囲リスト>は\+++++++++++++++++++++++++++++++++を結びます。
The <PRList> list and <scope-list> are interpreted as in Section 8.1.
<PRList>リストと<範囲リスト>はセクション8.1で解釈されます。
The Naming Authority string, if present in the request, will limit the reply to Service Type strings with the specified Naming Authority. If the Naming Authority string is absent, the IANA registered service types will be returned. If the length of the Naming Authority is set to 0xFFFF, the Naming Authority string is omitted and ALL Service Types are returned, regardless of Naming Authority.
要求に存在しているなら、Naming Authorityストリングは回答を指定されたNaming AuthorityがあるService Typeストリングに制限するでしょう。 Naming Authorityストリングが欠けると、登録されたサービスがタイプするIANAを返すでしょう。 Naming Authorityの長さを0xFFFFに設定するなら、Naming Authorityストリングを省略します、そして、すべてのService Typesを返します、Naming Authorityにかかわらず。
10.2. Service Type Reply
10.2. サービスタイプ回答
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 = 10) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | length of <srvType-list> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| <srvtype--list> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サービスLocationヘッダー(機能=SrvTypeRply=10)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | エラーコード| <srvType-リスト>の長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | <srvtype--リスト>\+++++++++++++++++++++++++++++++++
The service-type Strings (as described in Section 4.1) are provided in <srvtype-list>, which is a <string-list>.
サービスタイプStrings(セクション4.1で説明されるように)を<srvtype-リスト>に提供します。(>はリストを結んでいる<>です)。
Guttman, et al. Standards Track [Page 32] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[32ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
If a service type has a Naming Authority other than IANA it MUST be returned following the service type string and a `.' character. Service types with the IANA Naming Authority do not include a Naming Authority string.
'サービスに続いて、サービスタイプがそれを返さなければならないIANA以外のNaming Authorityを持っているなら、ストリングとa''文字をタイプしてください。 IANA Naming AuthorityがあるサービスタイプはNaming Authorityストリングを入れません。
10.3. Attribute Request
10.3. 属性要求
The Attribute Request (AttrRqst) allows a UA to discover attributes of a given service (by supplying its URL) or for an entire service type. The latter feature allows the UA to construct a query for an available service by selecting desired features. The UA may request that all attributes are returned, or only a subset of them.
UAが与えられたサービス(URLを供給するのによる)の属性を発見するのを許容するか、またはAttribute Request(AttrRqst)は全体のサービスタイプのためにそうします。 後者の特徴で、UAは、必要な特徴を選択することによって、利用可能なサービスのための質問を構成できます。 UAはすべての属性が返されるという要求、またはそれらの部分集合だけがそうするかもしれません。
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 = 6) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of PRList | <PRList> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of URL | URL \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <scope-list> | <scope-list> string \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <tag-list> string | <tag-list> string \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <SLP SPI> string | <SLP SPI> string \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サービスLocationヘッダー(機能=AttrRqst=6)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PRListの長さ| <PRList>ストリング\+++++++++++++++++++++++++++++++++| URLの長さ| URL\+++++++++++++++++++++++++++++++++| <範囲リスト>の長さ| <範囲リスト>は\+++++++++++++++++++++++++++++++++を結びます。| リスト>にタグ付けををしている<ストリングの長さ| リスト>にタグ付けををしている<ストリング\+++++++++++++++++++++++++++++++++| <SLP SPI>ストリングの長さ| <SLP SPI>ストリング\+++++++++++++++++++++++++++++++++
The <PRList>, <scope-list> and <SLP SPI> string are interpreted as in Section 8.1.
<PRList>、範囲リスト>と<SLP SPI>ストリングがセクション8.1で解釈される<。
The URL field can take two forms. It can simply be a Service Type (see Section 4.1), such as "http" or "service:tftp". In this case, all attributes and the full range of values for each attribute of all services of the given Service Type is returned.
URL分野は2つの形を取ることができます。それは単にService Typeであるかもしれません(セクション4.1を見る)、"http"や「サービス: tftp」のように。 与えられたService Typeのサービスが返されるすべての各属性のためのこの場合値のすべての属性と最大限の範囲。
The URL field may alternatively be a full URL, such as "service:printer:lpr://igore.wco.ftp.com:515/draft" or "nfs://max.net/znoo". In this, only the registered attributes for the specified URL are returned.
あるいはまた、URL分野は「サービス:プリンタ:lpr://igore.wco.ftp.com: 515/草稿」か「nfs://max.net/znoo」などの完全なURLであるかもしれません。 これでは、指定されたURLのための登録された属性だけが返されます。
The <tag-list> field is a <string-list> of attribute tags, as defined in Section 9.4 which indicates the attributes to return in the AttrRply. If <tag-list> is omitted, all attributes are returned. <tag-list> MUST be omitted and a full URL MUST be included when attributes when a SLP SPI List string is included, otherwise the DA will reply with an AUTHENTICATION_FAILED error.
リスト>にタグ付けををしている<分野は属性タグのリストを結んでいる<>です、AttrRplyで戻るために属性を示すセクション9.4で定義されるように。 <タグリスト>が省略されるなら、すべての属性が返されます。 <タグリスト>を省略しなければなりません。属性であるときに、SLP SPI Listストリングが含まれているとき、完全なURLを含まなければなりません。さもなければ、DAはAUTHENTICATION_FAILED誤りで返答するでしょう。
Guttman, et al. Standards Track [Page 33] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[33ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
10.4. Attribute Reply
10.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = AttrRply = 7) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | length of <attr-list> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| <attr-list> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|# of AttrAuths | Attribute Authentication Block (if present) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サービスLocationヘッダー(機能=AttrRply=7)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | エラーコード| <attr-リスト>の長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | <は>\+++++++++++++++++++++++++++++++++をattr記載します。|# AttrAuthsについて| 属性Authentication Block(存在しているなら)\+++++++++++++++++++++++++++++++++
The format of the <attr-list> and the Authentication Block is as specified for SrvReg (see Section 9.2.1).
<attr-リスト>とAuthentication Blockの形式がSrvRegに指定されるようにあります(セクション9.2.1を見てください)。
Attribute replies SHOULD be returned with the original case of the string registration intact, as they are likely to be human readable. In the case where the AttrRqst was by service type, all attributes defined for the service type, and all their values are returned.
回答SHOULDを結果と考えてください。ストリング登録のオリジナルのケースが完全な状態で返してください、それらが人間読み込み可能である傾向があるときに。 AttrRqstがサービスであった場合では、タイプ、サービスタイプのために定義されたすべての属性、およびそれらのすべての値を返します。
Although white space is folded for string matching, attribute tags and values MUST be returned with their original white space preserved.
ストリングマッチングのために余白を折り重ねますが、それらの元の余白が保持されている状態で、属性タグと値を返さなければなりません。
Only one copy of each attribute tag or String value should be returned, arbitrarily choosing one version (with respect to upper and lower case and white space internal to the strings): Duplicate attributes and values SHOULD be removed. An arbitrary version of the string value and tag name is chosen for the merge. For example: "(A=a a,b)" merged with "(a=A A,B)" may yield "(a=a a,B)".
コピー1部のそれぞれの属性タグかString価値だけを返すべきです、任意に、1つのバージョン(大文字と小文字とストリングへの内部の余白に関する)を選んで: 属性と値のSHOULDをコピーしてください。取り外されます。 ストリング値とタグ名の任意のバージョンはマージに選ばれています。 例えば: 「(A=a a、b)」 合併されて「(a=A A、B)」という、もたらすかもしれません「(a=a a、B)」という。
10.5. Attribute Request/Reply Examples
10.5. 属性要求/回答の例
Suppose that printer services have been registered as follows:
以下の通りプリンタサービスを登録してあると仮定してください:
Registered Service:
URL = service:printer:lpr://igore.wco.ftp.com/draft
scope-list = Development
Lang. Tag = en
Attributes = (Name=Igore),(Description=For developers only),
(Protocol=LPR),(location-description=12th floor),
(Operator=James Dornan \3cdornan@monster\3e),
(media-size=na-letter),(resolution=res-600),x-OK
登録されたサービス: URL=サービス:プリンタ:lpr://草稿範囲igore.wco.ftp.com/リストはDevelopmentラングと等しいです。 タグ=アンAttributesは(名前=Igore)、(開発者だけのための記述=)、(プロトコル=LPR)、(12位置記述=階)、(オペレータ=ジェームスDornan\ 3cdornan@monster \3e)、(Naメディアサイズ=手紙)、(解決=res-600)、x-OKと等しいです。
URL = service:printer:lpr://igore.wco.ftp.com/draft
scope-list = Development
URL= サービス:プリンタ:lpr://草稿範囲igore.wco.ftp.com/リスト=開発
Guttman, et al. Standards Track [Page 34] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[34ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
Lang. Tag = de
Attributes = (Name=Igore),(Description=Nur fuer Entwickler),
(Protocol=LPR),(location-description=13te Etage),
(Operator=James Dornan \3cdornan@monster\3e),
(media-size=na-letter),(resolution=res-600),x-OK
ラング。 タグ=de Attributes=(名前=Igore)、(オペレータ=ジェームスDornan\ 3cdornan@monster \3e)、(Naメディアサイズ=手紙)(解決=res-600)がxで承認する(記述=ヌールfuer Entwickler)(プロトコル=LPR)、(位置記述=13te Etage)
URL = service:printer:http://not.wco.ftp.com/cgi-bin/pub-prn
scope-list = Development
Lang. Tag = en
Attributes = (Name=Not),(Description=Experimental IPP printer),
(Protocol=http),(location-description=QA bench),
(media-size=na-letter),(resolution=other),x-BUSY
URL=サービス:プリンタ: http://not.wco.ftp.com/cgi-bin/pub-prn 範囲リストはDevelopmentラングと等しいです。 =アンAttributes=にタグ付けをしてください、(=を命名してください、)、(実験的なIPP記述=プリンタ)、(プロトコル=http)、(QA位置記述=ベンチ)、(Naメディアサイズ=手紙)の、そして、(解決=他)のx-BUSY
Notice the first printer, "Igore" is registered in both English and German. The `<' and `>' characters in the Operator attribute value which are part of the Email address had to be escaped, as they are reserved characters for values.
最初のプリンタ、"Igore"が英語とドイツ語の両方に登録されるのに注意してください。 Operator属性におけるキャラクタが評価するメールアドレスの一部である'<'と'>'逃げられなければなりませんでした、彼らが値のための控え目なキャラクタであるので。
Attribute tags are not translated, though attribute values may be, see [13].
属性値は翻訳されますが、属性タグは翻訳されないで、[13]を見てください。
The attribute Request:
属性Request:
URL = service:printer:lpr://igore.wco.ftp.com/draft
scope-list = Development
Lang. Tag = de
tag-list = resolution,loc*
URL=サービス:プリンタ:lpr://草稿範囲igore.wco.ftp.com/リストはDevelopmentラングと等しいです。 タグ=deタグリスト=解決、loc*
receives the Attribute Reply:
Attribute Replyを受けます:
(location-description=13te Etage),(resolution=res-600)
(位置記述は13te Etageと等しいです)(解決=res-600)
The attribute Request:
属性Request:
URL = service:printer
scope-list = Development
Lang. Tag = en
tag-list = x-*,resolution,protocol
URL=サービス: プリンタ範囲リストはDevelopmentラングと等しいです。 タグ=アンタグリスト=x-*、解決は議定書を作ります。
receives an Attribute Reply containing:
Attribute Reply含有を受けます:
(protocols=http,LPR),(resolution=res-600,other),x-OK,x-BUSY
(解決=res-600で、他)の、そして、x OKの(http、プロトコル=LPR)、x忙しい
The first request is by service instance and returns the requested values, in German. The second request is by abstract service type (see Section 4) and returns values from both "Igore" and "Not".
最初の要求は、サービスインスタンスであって、ドイツ語で要求された値を返します。 2番目の要求は、抽象的なサービスタイプ(セクション4を見る)であって、"Igore"と“Not"の両方から値を返します。
Guttman, et al. Standards Track [Page 35] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[35ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
An attribute Authentication Block is returned if an authentication block with the SLP SPI in the AttrRqst can be returned. Note that the <attr-list> returned from a DA with an Authentication Block MUST be identical to the <attr-list> registered by a SA, in order for the authentication verification calculations to be possible.
SLP SPIがAttrRqstにある認証ブロックを返すことができるなら、属性Authentication Blockを返します。 Authentication BlockとDAから返された<attr-リスト>がSAによって登録された<attr-リスト>と同じであるに違いないことに注意してください、認証検証計算が可能であるように。
A SA or DA only returns an Attribute Authentication Block if the AttrRqst included a full URL in the request and no tag list.
AttrRqstが要求にもかかわらず、どんなタグリストにも完全なURLを含んでいなかった場合にだけ、SAかDAがAttribute Authentication Blockを返します。
If an SLP SPI is specified in a unicast request (the REQUEST MCAST flag in the header is not set) and the SA or DA cannot return an Authentication Block with that SLP SPI, an AUTHENTICATION_UNKNOWN error is returned. The # of Attr Auths field is set to 0 if there no Authentication Block is included, or 1 if an Authentication Block follows.
SLP SPIがユニキャスト要求で指定されて(ヘッダーのREQUEST MCAST旗は設定されません)、SAかDAがそのSLP SPIとAuthentication Blockを返すことができないなら、AUTHENTICATION_UNKNOWN誤りは返されます。 どんなAuthentication Blockもそこに含まれていないなら、Attr Auths分野の#、が0に設定されるか、または1はAuthentication Blockであるなら続きます。
10.6. Service Deregistration
10.6. サービスDeregistration
A DA deletes a service registration when its Lifetime expires. Services SHOULD be deregistered when they are no longer available, rather than leaving the registrations to time out.
Lifetimeが期限が切れると、DAはサービス登録を削除します。 サービスSHOULD、それらがもう登録証明書をタイムアウトに残すよりむしろ利用可能でないときに、反登録されます。
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 = 4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of <scope-list> | <scope-list> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| URL Entry \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of <tag-list> | <tag-list> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サービスLocationヘッダー(機能=SrvDeReg=4)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | <範囲リスト>の長さ| <は>\+++++++++++++++++++++++++++++++++を範囲で記載します。| URLエントリー\+++++++++++++++++++++++++++++++++| <タグリスト>の長さ| リスト>にタグ付けををしている<\+++++++++++++++++++++++++++++++++
The <scope-list> is a <string-list> (see section 2.1).
<範囲リスト>はリストを結んでいる<>(セクション2.1を見る)です。
The SA MUST retry if there is no response from the DA, see Section 12.3. The DA acknowledges a SrvDeReg with a SrvAck. Once the SA receives an acknowledgment indicating success, the service and/or attributes are no longer advertised by the DA. The DA deregisters the service or service attributes from every scope specified in the SrvDeReg which it was previously registered in.
セクション12.3は、DAからの応答が全くなければSA MUSTが再試行するのを見ます。 DAはSrvAckとSrvDeRegを承認します。 一度、SAは成功、サービス、そして/または、属性がもうDAによって広告を出されないのを示す承認を受けます。 あらゆる範囲からのサービスかサービス属性がそれが以前に登録されたSrvDeRegで指定したDA deregisters。
The SA MUST deregister all services with the same scope list used to register the service with a DA. If this is not done in the SrvDeReg message, the DA returns a SCOPE_NOT_SUPPORTED error. The Lifetime field in the URL Entry is ignored for the purposes of the SrvDeReg.
すべてが同じ範囲リストで調整するSA MUST「反-レジスタ」は以前はよくDAにサービスを登録していました。 SrvDeRegメッセージでこれをしないなら、DAは__どんなSUPPORTED誤りもSCOPEに返しません。 URL EntryのLifetime分野はSrvDeRegの目的のために無視されます。
Guttman, et al. Standards Track [Page 36] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[36ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
The <tag-list> is a <string-list> of attribute tags to deregister as defined in Section 9.4. If no <tag-list> is present, the SrvDeReg deregisters the service in all languages it has been registered in. If the <tag-list> is present, the SrvDeReg deregisters the attributes whose tags are listed in the tag spec. Services registered with Authentication Blocks MUST NOT include a <tag-list> in a SrvDeReg message: A DA will respond with an AUTHENTICATION_FAILED error in this case.
<タグリスト>はセクション9.4で定義されるように「反-レジスタ」への属性タグのリストを結んでいる<>です。 <タグリストがない>であるなら、プレゼント、SrvDeReg deregistersはそれを登録してあるすべての言語でサービスですか? <タグリスト>であるなら、プレゼント、SrvDeReg deregistersはタグがタグ仕様に記載されている属性ですか? Authentication Blocksに登録されたサービスはSrvDeRegのリスト>にタグ付けををしている<メッセージを含んではいけません: DAはこの場合AUTHENTICATION_FAILED誤りで応じるでしょう。
If the service to be deregistered was registered with an authentication block or blocks, a URL authentication block for each of the SLP SPIs registered must be included in the SrvDeReg. Otherwise, the DA returns an AUTHENTICATION_ABSENT error. If the message fails to be verified by the DA, an AUTHENTICATION_FAILED error is returned by the DA.
反登録されるべきサービスが認証ブロックかブロックに登録されたなら、それぞれのSLP SPIsが登録したので、SrvDeRegにURL認証ブロックを含まなければなりません。さもなければ、DAはAUTHENTICATION_ABSENT誤りを返します。 DAによってメッセージが確かめられないなら、AUTHENTICATION_FAILED誤りはDAによって返されます。
11. Scopes
11. 範囲
Scopes are sets of services. The primary use of Scopes is to provide the ability to create administrative groupings of services. A set of services may be assigned a scope by network administrators. A client seeking services is configured to use one or more scopes. The user will only discover those services which have been configured for him or her to use. By configuring UAs and SAs with scopes, administrators may provision services. Scopes strings are case insensitive. The default SCOPE string is "DEFAULT".
範囲はサービスのセットです。 Scopesのプライマリ使用は管理サービスの組分けを作成する能力を提供することです。 範囲はネットワーク管理者によって1セットのサービスに割り当てられるかもしれません。 サービスを求めているクライアントが1つを使用するために構成されるか、または以上は見られます。 ユーザはその人のために使用に構成されたそれらのサービスを発見するだけでしょう。 範囲があるUAsとSAsを構成することによって、管理者は支給サービスがそうするかもしれません。 ストリングが大文字と小文字を区別しないのを見ます。 デフォルトSCOPEストリングは「デフォルト」です。
Scopes are the primary means an administrator has to scale SLP deployments to larger networks. When DAs with NON-DEFAULT scopes are present on the network, further gains can be had by configuring UAs and SAs to have a predefined non-default scope. These agents can then perform DA discovery and make requests using their scope. This will limit the number of replies.
範囲は管理者が、より大きいネットワークにSLP展開について合わせて調整するために持っているプライマリ手段です。 NON-DEFAULT範囲があるDAsがネットワークに存在しているとき、事前に定義された非デフォルト範囲を持つためにUAsとSAsを構成することによって、さらなる利得を持つことができます。 これらのエージェントは、それらの範囲を使用することで次に、DA発見を実行して、要求をすることができます。 これは回答の数を制限するでしょう。
11.1. Scope Rules
11.1. 範囲規則
SLP messages which fail to contain a scope that the receiving Agent is configured to use are dropped (if the request was multicast) or a SCOPE_NOT_SUPPORTED error is returned (if the request was unicast). Every SrvRqst (except for DA and SA discovery requests), SrvReg, AttrRqst, SrvTypeRqst, DAAdvert, and SAAdvert message MUST include a <scope-list>.
受信エージェントが使用するために構成される範囲を含まないSLPメッセージを下げるか(要求がマルチキャストであったなら)、または_SUPPORTED誤りではなく、SCOPE_を返します(要求がユニキャストであったなら)。 あらゆるSrvRqst(DAとSA発見要求を除いた)、SrvReg、AttrRqst、SrvTypeRqst、DAAdvert、およびSAAdvertメッセージはa<範囲リスト>を含まなければなりません。
A UA MUST unicast its SLP messages to a DA which supports the desired scope, in preference to multicasting a request to SAs. A UA MAY multicast the request if no DA is available in the scope it is configured to use.
Uaがそうしなければならない、ユニキャスト、マルチキャスティングに優先した必要な範囲にSAsへの要求をサポートするDAへのそのSLPメッセージ。 UA MAYマルチキャスト、要求はDAでないなら使用するのが構成されている範囲で利用可能です。
Guttman, et al. Standards Track [Page 37] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[37ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
11.2. Administrative and User Selectable Scopes
11.2. 管理とユーザの選択可能な範囲
All requests and services are scoped. The two exceptions are SrvRqsts for "service:directory-agent" and "service:service-agent". These MAY have a zero-length <scope-list> when used to enable the user to make scope selections. In this case UAs obtain their scope list from DAAdverts (or if DAs are not available, from SAAdverts.)
すべての要求とサービスは見られます。 2つの例外が「サービス: ディレクトリエージェント」と「サービス: サービスエージェント」のためのSrvRqstsです。 これらの5月で、ユーザが範囲選択をするのを可能にするのに使用されると、無の長さの<は>を範囲で記載します。 この場合、UAsはDAAdvertsから彼らの範囲リストを得ます。(DAsがSAAdvertsから利用可能でないなら。)
Otherwise, if SAs and UAs are to use any scope other than the default (i.e., "DEFAULT"), the UAs and SAs are configured with lists of scopes to use by system administrators, perhaps automatically by way of DHCP option 78 or 79 [21]. Such administrative scoping allows services to be provisioned, so that users will only see services they are intended to see.
さもなければ、SAsとUAsが何かデフォルト(すなわち、「デフォルト」)以外の範囲を使用するつもりであるなら、UAsとSAsはDHCPオプション78か79[21]を通してシステム管理者で使用する範囲のリストによって恐らく自動的に構成されます。 そのような管理見るのは、ユーザが見ることを意図するサービスを見るだけであるように、サービスが食糧を供給されるのを許容します。
User configurable scopes allow a user to discover any service, but require them to do their own selection of scope. This is similar to the way AppleTalk [12] and SMB [19] networking allow user selection of AppleTalk Zone or workgroups.
ユーザの構成可能な範囲は、ユーザがどんなサービスも発見するのを許容しますが、それら自身の範囲の選択をするのを必要とします。 これはAppleTalk[12]とSMB[19]ネットワークがAppleTalk Zoneかワークグループのユーザ品揃えを許容する方法と同様です。
Note that the two configuration choices are not compatible. One model allows administrators control over service provision. The other delegates this to users (who may not be prepared to do any configuration of their system).
2つの構成選択は互換性がないことに注意してください。 1つのモデルがサービス支給のコントロールを管理者に許します。 もう片方がユーザ(彼らのシステムのあらゆる構成をするように準備されないかもしれません)へこれを代表として派遣します。
12. Directory Agents
12. ディレクトリエージェント
DAs cache service location and attribute information. They exist to enhance the performance and scalability of SLP. Multiple DAs provide further scalability and robustness of operation, since they can each store service information for the same SAs, in case one of the DAs fails.
DAsはサービス位置と属性情報をキャッシュします。 それらは、SLPの性能とスケーラビリティを高めるために存在しています。 複数のDAsが操作のさらなるスケーラビリティと丈夫さを提供します、彼らがそれぞれ同じSAsのためのサービス情報を保存できるので、DAsの1つが失敗するといけないので。
A DA provides a centralized store for service information. This is useful in a network with several subnets or with many SLP Agents. The DA address can be dynamically configured with UAs and SAs using DHCP, or by using static configuration.
DAは集結された店をサービス情報に提供します。 いくつかのサブネットか多くのSLPエージェントにとって、これはネットワークで役に立ちます。 DHCPを使用するUAsとSAs、または静的な構成を使用することによって、ダイナミックにDAアドレスを構成できます。
SAs configured to use DAs with DHCP or static configuration MUST unicast a SrvRqst to the DA, when the SA is initialized. The SrvRqst omits the scope list and sets the service type of the request to "service:directory-agent". The DA will return a DAAdvert with its attributes, SLP SPI list, and other parameters which are essential for proper SA to DA communication.
SAsが、DHCPとDAsを使用するのを構成したか、または静的な構成はDAへのユニキャストa SrvRqstを構成されなければなりませんでした。(その時、SAは初期化されます)。 SrvRqstは「サービス: ディレクトリエージェント」に範囲リストを省略して、要求のサービスタイプを設定します。 DAは適切なSAに、DAコミュニケーションに不可欠の属性、SLP SPIリスト、および他のパラメタがあるDAAdvertを返すでしょう。
Passive detection of DAs by SAs enables services to be advertised consistently among DAs of the same scope. Advertisements expire if not renewed, leaving only transient stale registrations in DAs, even
SAsによるDAsの受動検知は、サービスが同じ範囲のDAsの中に一貫して広告を出すのを可能にします。 更新されないなら広告は期限が切れて、DAsに一時的な聞き古した登録証明書だけを残しさえします。
Guttman, et al. Standards Track [Page 38] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[38ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
in the case of a failure of a SA.
SAの失敗の場合で。
A single DA can support many UAs. UAs send the same requests to DAs that they would send to SAs and expect the same results. DAs reduce the load on SAs, making simpler implementations of SAs possible.
独身のDAは多くのUAsをサポートすることができます。 UAsは彼らがSAsに発信して、同じ結果を予想するだろうというDAsへの同じ要求を送ります。 SAsの、より簡単な実装を可能にして、DAsはSAsで負荷を減少させます。
UAs MUST be prepared for the possibility that the service information they obtain from DAs is stale.
彼らがDAsから得るサービス情報が聞き古したである可能性のためにUAsを準備しなければなりません。
12.1. Directory Agent Rules
12.1. ディレクトリエージェント規則
When DAs are present, each SA MUST register its services with DAs that support one or more of its scope(s).
DAsが存在しているとき、各SA MUSTは範囲の1つ以上をサポートするDAsにサービスを登録します。
UAs MUST unicast requests directly to a DA (when scoping rules allow), hence avoiding using the multicast convergence algorithm, to obtain service information. This decreases network utilization and increases the speed at which UAs can obtain service information.
UAsは直接したがって、サービス情報を得るのにマルチキャスト集合アルゴリズムを使用するのを避けるDA(規則が許容するのを見るとき)へのユニキャスト要求がそうしなければなりません。 どのUAsがサービス情報を得ることができるかで、これは、ネットワーク利用を減少させて、スピードを出します。
DAs MUST flush service advertisements once their lifetime expires or their URL Authentication Block "Timestamp" of expiration is past.
彼らの寿命がいったん期限が切れるとDAsがサービス広告を洗い流さなければならない、さもなければ、それらの満了のURL Authentication Block「タイムスタンプ」は過去です。
DAAdverts MUST include DA Stateless Boot Timestamp, in the same format as the Authentication Block (see Section 9.2). The Timestamp in the Authentication Block indicates the time at which all previous registrations were lost (i.e., the last stateless reboot). The Timestamp is set to 0 in a DAAdvert to notify UAs and SAs that the DA is going down. DAs MUST NOT use equal or lesser Boot Timestamps to previous ones, if they go down and restart without service registration state. This would mislead SAs to not reregister with the DA.
DAAdvertsはAuthentication Blockと同じ形式でDA Stateless Boot Timestampを含まなければなりません(セクション9.2を見てください)。 Authentication BlockのTimestampは前のすべての登録証明書が失われた時(すなわち、最後の状態がないリブート)を示します。 TimestampはDAが落ちる予定であるようにUAsとSAsに通知するようにDAAdvertの0に用意ができています。 DAsは等しいか、より少ないBoot Timestampsを前のものに使用してはいけません、サービス登録状態なしで落ちて、再開するなら。 これはDAと共にどんな「再-レジスタ」にもSAsをミスリードしないでしょう。
DAs which receive a multicast SrvRqst for the service type "service:directory-agent" MUST silently discard it if the <scope- list> is (a) not omitted and (b) does not include a scope they are configured to use. Otherwise the DA MUST respond with a DAAdvert.
<範囲リスト>が省略されなかった(a)であり、(b)が使用に構成にされているので範囲を含んでいないなら、「サービス: ディレクトリエージェント」が静かにそうしなければならないサービスタイプのためにマルチキャストSrvRqstを受けるDAsがそれを捨てます。 さもなければ、DA MUSTはDAAdvertと共に応じます。
DAs MUST respond to AttrRqst and SrvTypeRqst messages (these are OPTIONAL only for SAs, not DAs.)
DAsはAttrRqstとSrvTypeRqstメッセージに応じなければなりません。(これらはDAsではなく、SAsのためだけのOPTIONALです。)
12.2. Directory Agent Discovery
12.2. ディレクトリエージェント発見
UAs can discover DAs using static configuration, DHCP options 78 and 79, or by multicasting (or broadcasting) Service Requests using the convergence algorithm in Section 6.3.
UAsは、静的な構成、DHCPオプション78と79を使用するか、またはマルチキャスティング(または、放送する)サービスRequestsでセクション6.3の集合アルゴリズムを使用することでDAsを発見できます。
Guttman, et al. Standards Track [Page 39] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[39ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
See Section 6 regarding unsolicited DAAdverts. Section 12.2.2 describes how SAs may reduce the number of times they must reregister with DAs in response to unsolicited DAAdverts.
求められていないDAAdvertsに関してセクション6を見てください。 セクション12.2 .2 SAsが彼らが求められていないDAAdvertsに対応したDAsに伴うより多くのreregisterにそうしなければならない回数をどう減少させるかもしれないかを説明します。
DAs MUST send unsolicited DAAdverts once per CONFIG_DA_BEAT. An unsolicited DAAdvert has an XID of 0. SAs MUST listen for DAAdverts, passively, as described in Section 8.5. UAs MAY do this. If they do not listen for unsolicited DAAdverts, however, they will not discover DAs as they become available. UAs SHOULD, in this case, do periodic active DA discovery, see Section 6.
DAsはCONFIG_DA_BEATに一度求められていないDAAdvertsを送らなければなりません。 求められていないDAAdvertには、0のXIDがあります。 SAsはセクション8.5で説明されるようにDAAdvertsの受け身に聞こうとしなければなりません。 UAsはこれをするかもしれません。 しかしながら、求められていないDAAdvertsの聞こうとしないと、利用可能になるとき、彼らはDAsを発見しないでしょう。 セクション6は、UAs SHOULDがこの場合周期的な活発なDA発見をするのを見ます。
A URL with the scheme "service:directory-agent" indicates the DA's location as defined in Section 8.5. For example: "service:directory-agent://foobawooba.org".
「サービス: ディレクトリエージェント」という体系があるURLはセクション8.5で定義されるようにDAの位置を示します。 例えば: 「サービス: ディレクトリエージェント://foobawooba.org。」
The following sections suggest timing algorithms which enhance the scalability of SLP.
以下のセクションは、SLPのスケーラビリティを高めるアルゴリズムを調節するのを示します。
12.2.1. Active DA Discovery
12.2.1. 活発なDA発見
After a UA or SA restarts, its initial DA discovery request SHOULD be delayed for some random time uniformly distributed from 0 to CONFIG_START_WAIT seconds.
UAかSAが再開した後に、初期のDA発見は、SHOULDが0〜CONFIG_START_WAIT秒まで一様に分配されたいくらかの無作為の時間遅れるよう要求します。
The UA or SA sends the DA Discovery request using a SrvRqst, as described in Section 8.1. DA Discovery requests MUST include a Previous Responder List. SrvRqsts for Active DA Discovery SHOULD NOT be sent more than once per CONFIG_DA_FIND seconds.
UAかSAが、セクション8.1で説明されるようにSrvRqstを使用することでDAディスカバリー要求を送ります。 DAディスカバリー要求はPrevious Responder Listを含まなければなりません。 SrvRqsts、Active DAディスカバリーSHOULD NOTのために、CONFIG_DA_FIND秒あたりの一度送られた以上はそうです。
After discovering a new DA, a SA MUST wait a random time between 0 and CONFIG_REG_ACTIVE seconds before registering their services.
新しいDA、SA MUSTが彼らのサービスを登録するレッジ_ACTIVE秒前の0とCONFIG_の間で無作為の時間を待つと発見した後に。
12.2.2. Passive DA Advertising
12.2.2. 受け身のDA広告
A DA MUST multicast (or broadcast) an unsolicited DAAdvert every CONFIG_DA_BEAT seconds. CONFIG_DA_BEAT SHOULD be specified to prevent DAAdverts from using more than 1% of the available bandwidth.
DA MUSTマルチキャスト、(放送) 求められていないDAAdvertはDA_BEATが後援するあらゆるCONFIG_をそうします。 CONFIG_DA_BEAT SHOULD、指定されて、DAAdvertsが利用可能な帯域幅の1%以上を使用するのを防いでください。
All UAs and SAs which receive the unsolicited DAAdvert SHOULD examine its DA stateless Boot Timestamp. If it is set to 0, the DA is going down and no further messages should be sent to it.
求められていないDAAdvert SHOULDを受けるすべてのUAsとSAsがDAの状態がないBoot Timestampを調べます。 それが0に設定されるなら、DAは落ちる予定です、そして、さらなるメッセージを全くそれに送るべきではありません。
If a SA detects a DA it has never encountered (with a nonzero timestamp,) the SA must register with it. SAs MUST examine the DAAdvert's timestamp to determine if the DA has had a stateless reboot since the SA last registered with it. If so it registers with the DA. SAs MUST wait a random interval between 0 and CONFIG_REG_PASSIVE before beginning DA registration.
SAがDAを検出するなら、それはそれでSA必須レジスタに一度も遭遇したことがありません(非零タイムスタンプで)。 SAsは、SAが最後にそれとともに記名して以来DAで状態がないリブートがあるかどうか決定するためにDAAdvertのタイムスタンプを調べなければなりません。 そうだとすれば、それはDAとともに記名します。 DA登録を始める前に、SAsは0とCONFIG_レッジ_PASSIVEの無作為の間隔を待たなければなりません。
Guttman, et al. Standards Track [Page 40] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[40ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
12.3. Reliable Unicast to DAs and SAs
12.3. DAsとSAsへの信頼できるユニキャスト
If a DA or SA fails to respond to a unicast UDP message in CONFIG_RETRY seconds, the message should be retried. The wait interval for each subsequent retransmission MUST exponentially increase, doubling each time. If a DA or SA fails to respond after CONFIG_RETRY_MAX seconds, the sender should consider the receiver to have gone down. The UA should use a different DA. If no such DA responds, DA discovery should be used to find a new DA. If no DA is available, multicast requests to SAs are used.
DAかSAがCONFIG_RETRY秒にユニキャストUDPメッセージに応じないなら、メッセージは再試行されるべきです。 その都度倍増する場合、それぞれのその後の「再-トランスミッション」のための待ち間隔は指数関数的に増加しなければなりません。 DAかSAがCONFIG_RETRY_MAX秒以降応じないなら、送付者は、受信機が落ちたと考えるべきです。 UAは異なったDAを使用するはずです。 どれかそのようなDAが応じないなら、DA発見は、新しいDAを見つけるのに使用されるべきです。 どんなDAも利用可能でないなら、SAsへのマルチキャスト要求は使用されています。
12.4. DA Scope Configuration
12.4. DA範囲構成
By default, DAs are configured with the "DEFAULT" scope. Administrators may add other configured scopes, in order to support UAs and SAs in non default scopes. The default configuration MUST NOT be removed from the DA unless:
デフォルトで、DAsは「デフォルト」範囲で構成されます。 管理者は、非デフォルト範囲でUAsとSAsをサポートするために他の構成された範囲を加えるかもしれません。 DAからデフォルト設定を取り除いてはいけない、:
- There are other DAs which support the "DEFAULT" scope, or
- または「デフォルト」が範囲であるとサポートする他のDAsがある。
- All UAs and SAs have been configured with non-default scopes.
- すべてのUAsとSAsは非デフォルト範囲で構成されました。
Non-default scopes can be phased-in as the SLP deployment grows. Default scopes should be phased out only when the non-default scopes are universally configured.
SLP展開が成長するとき、非デフォルト範囲を段階的に導入することができます。 非デフォルト範囲が一般に構成されるときだけ、デフォルト範囲は段階的に廃止されるべきです。
If a DA and SA are coresident on a host (quite possibly implemented by the same process), configuration of the host is considerably simplified if the SA supports only scopes also supported by the DA. That is, the SA SHOULD NOT advertise services in any scopes which are not supported by the coresident DA. This means that incoming requests can be answered by a single data store; the SA and DA registrations do not need to be kept separately.
DAとSAがホスト(全くことによると同じプロセスによって実装される)の上のコレジデントであるなら、SAがまた、DAが支えられた範囲だけを支えるなら、ホストの構成はかなり簡易型です。 すなわち、SA SHOULD NOTはコレジデントDAによって支えられない少しの範囲にもサービスの広告を出します。 これは、単一のデータ・ストアで入って来る要求に答えることができることを意味します。 別々にSAとDA登録証明書によって保たれる必要はありません。
12.5. DAs and Authentication Blocks
12.5. DAsと認証ブロック
DAs are not configured to sign service registrations or attribute lists. They simply cache services registered by Service Agents. DAs MUST NOT accept registrations including authentication blocks for SLP SPIs which it is not configured with, see Section 8.5.
DAsは、サービスが登録証明書か属性リストであると署名するために構成されません。 彼らは単にServiceエージェントによって登録されたサービスをキャッシュします。 セクション8.5は、DAsがそれが構成されないSLP SPIsのための認証ブロックを含む登録証明書を受け入れてはいけないのを見ます。
A DA protects registrations which are made with authentication blocks using SLP SPIs it is configured to use. If a service S is registered, a subsequent registration (which will replace the adertisement) or a deregistration (which will remove it) MUST include an Authentication Block with the corresponding SLP SPI, see Section 8.3 and Section 10.6.
DAは認証ブロックが使用するのが構成されているSLP SPIsを使用している状態でされる登録証明書を保護します。 サービスSが登録されているなら、その後の登録(adertisementを取り替える)か反登録(それを取り除く)が対応するSLP SPIとAuthentication Blockを含まなければなりません、とセクション8.3とセクション10.6は見ます。
Guttman, et al. Standards Track [Page 41] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[41ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
Example:
例:
A DA is configured to be able to verify Authentication Blocks with SLP SPIs "X,Y", that is X and Y.
それは、DAがSLP SPIs「X、Y」とAuthentication Blocksについて確かめることができるように構成されて、XとYです。
An SA registers a service with an Authentication Block with SPI "Z". The DA stores the registration, but discards the Authentication Block. If a UA requests a service with an SLP SPI string "Z", the DA will respond with an AUTHENTICATION_UNKNOWN error.
SAはSPI「Z」と共にAuthentication Blockにサービスを登録します。 DAは登録を保存しますが、Authentication Blockを捨てます。 UAがSLP SPIひも「Z」によるサービスを要求すると、DAは認証の_の未知の誤りで応じるでしょう。
An SA registers a service S with Authentication Blocks including SLP SPIs "X" and "Y". If a UA requests a service with an SLP SPI string "X" the DA will be able to return S (if the service type, language, scope and predicate of the SrvRqst match S) The DA will also return the Authentication Block with SLP SPI set to "X". If the DA receives a subsequent SrvDeReg for S (which will remove the advertisement) or a subsequent SrvReg for S (which will replace it), the message must include two URL Authentication Blocks, one each for SPIs "X" and "Y". If either of these were absent, the DA would return an AUTHENTICATION_ABSENT error.
SAはSLP SPIs「X」と「Y」を含んでいるAuthentication BlocksにサービスSを登録します。 また、UAがDAがSを返すことができるSLP SPIひも「X」によるサービスを要求すると(SrvRqstに関するサービスタイプ、言語、範囲、および述部がSに合っているなら)、DAは「X」に用意ができているSLP SPIがある認証ブロックを返すでしょう。 DAがSのためのその後のSrvDeReg(広告を取り除く)かSのためのその後のSrvReg(それを取り替える)を受けるなら、メッセージは2URL Authentication Blocks、SPIs「X」と「Y」のためのそれぞれものを含まなければなりません。 これらのどちらかが休むなら、DAはAUTHENTICATION_ABSENT誤りを返すでしょうに。
13. Protocol Timing Defaults
13. プロトコルタイミングはデフォルトとします。
Interval name Section Default Value Meaning
------------------- ------- ------------- ------------------------
CONFIG_MC_MAX 6.3 15 seconds Max time to wait for a
complete multicast query
response (all values.)
CONFIG_START_WAIT 12.2.1 3 seconds Wait to perform DA
discovery on reboot.
CONFIG_RETRY 12.3 2 seconds Wait interval before
initial retransmission
of multicast or unicast
requests.
CONFIG_RETRY_MAX 12.3 15 seconds Give up on unicast
request retransmission.
CONFIG_DA_BEAT 12.2.2 3 hours DA Heartbeat, so that SAs
passively detect new DAs.
CONFIG_DA_FIND 12.3 900 seconds Minimum interval to wait
before repeating Active
DA discovery.
CONFIG_REG_PASSIVE 12.2 1-3 seconds Wait to register services
on passive DA discovery.
CONFIG_REG_ACTIVE 8.3 1-3 seconds Wait to register services
on active DA discovery.
CONFIG_CLOSE_CONN 6.2 5 minutes DAs and SAs close idle
connections.
間隔名のセクションDefault Value Meaning------------------- ------- ------------- ------------------------ 完全なマルチキャスト質問応答(すべての値)を待つ_MAX6.3 15秒マックスM.C.のCONFIG_時間 リブートにDA発見を実行するCONFIG_START_WAIT12.2.1 3秒Wait。 マルチキャストかユニキャスト要求の初期の「再-トランスミッション」の前のCONFIG_RETRY12.3 2秒Wait間隔。 ユニキャストで上がっているCONFIG_RETRY_MAX12.3 15秒Giveは「再-トランスミッション」を要求します。 CONFIG_DA_BEAT12.2.2 3何時間ものDA Heartbeatによって、そのSAsは新しいDAsを受け身に検出します。 Active DA発見を繰り返す前の待ちへのMinimum間隔の間の_FIND12.3 900秒のCONFIG_DA。 受け身のDA発見のときにサービスを登録するCONFIG_レッジ_PASSIVE12.2 1-3秒Wait。 活発なDA発見のときにサービスを登録するCONFIG_レッジ_ACTIVE8.3 1-3秒Wait。 _CONFIG_CLOSEのコン6.2 5分のDAsとSAsは無駄な接続を終えます。
Guttman, et al. Standards Track [Page 42] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[42ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
14. Optional Configuration
14. 任意の構成
Broadcast Only
Any SLP agent SHOULD be configurable to use broadcast
only. See Sections 6.1 and 12.2.
Only Any SLPエージェントSHOULDを放送してください。放送だけを使用するのにおいて、構成可能であってください。 セクション6.1と12.2を見てください。
Predefined DA
A UA or SA SHOULD be configurable to use a predefined DA.
DA AのUAかSA SHOULDを事前に定義する、事前に定義されたDAを使用するのにおいて、構成可能であってください。
No DA Discovery
The UA or SA SHOULD be configurable to ONLY use
predefined and DHCP-configured DAs and perform no active
or passive DA discovery.
DAディスカバリーがないことのUAかSA SHOULDが事前に定義された使用とDHCPによって構成されたDAsだけに構成可能であり、どんなアクティブであるか受け身のDA発見も実行しません。
Multicast TTL
The default multicast TTL is 255. Agents SHOULD be
configurable to use other values. A lower value will
focus the multicast convergence algorithm on smaller
subnetworks, decreasing the number of responses and
increases the performance of service location. This
may result in UAs obtaining different results for the
identical requests depending on where they are connected
to the network.
マルチキャストTTLデフォルトマルチキャストTTLは255歳です。 エージェントSHOULD、他の値を使用するのにおいて、構成可能であってください。 下側の値は、応答の数を減少させて、マルチキャスト集合アルゴリズムの、より小さいサブネットワークに焦点を合わせて、サービス位置の性能を増強します。 これはそれらがネットワークに接続されるところによる同じ要求として異なった結果を得るUAsをもたらすかもしれません。
Timing Values
Time values other than the default MAY be configurable.
See Section 13.
デフォルト以外のタイミングValues Time値は構成可能であるかもしれません。 セクション13を見てください。
Scopes
A UA MAY be configurable to support User Selectable
scopes by omitting all predefined scopes. See
Section 11.2. A UA or SA MUST be configurable to use
specific scopes by default. Additionally, a UA or SA
MUST be configurable to use specific scopes for requests
for and registrations of specific service types. The
scope or scopes of a DA MUST be configurable. The
default value for a DA is to have the scope "DEFAULT" if
not otherwise configured.
A UA MAYがすべての事前に定義された範囲を省略することによってUser Selectableに範囲を支えるのにおいて構成可能であることを見ます。 セクション11.2を見てください。 UAかSA MUST、デフォルトで特定の範囲を使用するのにおいて、構成可能であってください。 さらに、UAかSA MUST、特定のサービスタイプの要求と登録証明書に特定の範囲を使用するのにおいて、構成可能であってください。 見るか、またはDA MUSTでは、構成可能であるように見ます。 DAのためのデフォルト値は別の方法で構成されないなら範囲「デフォルト」を持つことです。
DHCP Configuration
DHCP options 78 and 79 may be used to configure SLP. If
DA locations are configured using DHCP, these SHOULD
be used in preference to DAs discovered actively or
passively. One or more of the scopes configured using
DHCP MUST be used in requests. The entire configured
<scope-list> MUST be used in registration and DA
configuration messages.
DHCP Configuration DHCPオプション78と79は、SLPを構成するのに使用されるかもしれません。 DA位置がDHCP、これらのSHOULDを使用することで構成されるなら、活発か受け身に発見されたDAsに優先して、使用されてください。 範囲の1つ以上は、DHCP MUSTを使用して、要求で使用されるように構成しました。 登録とDA構成メッセージで全体の構成された<範囲リスト>を使用しなければなりません。
Guttman, et al. Standards Track [Page 43] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[43ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
Service Template
UAs and SAs MAY be configured by using Service Templates.
Besides simplifying the specification of attribute
values, this also allows them to enforce the inclusion
of 'required' attributes in SrvRqst, SrvReg and SrvDeReg
messages. DAs MAY be configured with templates to
allow them to WARN UAs and SAs in these cases. See
Section 10.4.
サービスTemplate UAsとSAsは、Service Templatesを使用することによって、構成されるかもしれません。 また、属性値の仕様を簡素化すること以外に、これで、それらはSrvRqst、SrvReg、およびSrvDeRegメッセージでの'必要な'属性の包含を実施できます。 DAsはテンプレートで構成されて、これらの場合でWARN UAsとSAsにそれらを許容するかもしれません。 セクション10.4を見てください。
SLP SPI for service discovery
Agents SHOULD be configurable to support SLP SPIs using
the following parameters: BSD=2 (DSA with SHA-1) and
a public key identified by the SLP SPI String. In
the future, when a Public Key Infrastructure exists,
SLP Agents may be able to obtain public keys and
cryptographic parameters corresponding to the names used
in SLP SPI Strings.
SLP SPI、サービス発見エージェントSHOULDにおいて、以下のパラメタを使用することでSLP SPIsをサポートするのにおいて構成可能であってください: BSD=2(SHA-1とDSA)とSLP SPI Stringによって特定された公開鍵。 未来に、SLPエージェントはSLP SPI Stringsで使用される名前に対応する公開鍵と暗号のパラメタを得ることができるかもしれません。(その時、公開鍵暗号基盤は存在します)。
Note that if the SLP SPI string chosen is identical
to a scope string, it is effectively the same as a
Protected Scope in SLPv1. Namely, every SA advertising
in that scope would be configured with the same Private
Key. Every DA and UA of that scope would be configured
with the appropriate Public Key to verify signatures
produced by those SAs. This is a convenient way to
configure SLP deployments in the absence of a Public Key
Infrastructure. Currently, it would be too difficult to
manage the keying of UAs and DAs if each SA had its own
key.
選ばれたSLP SPIストリングが範囲ストリングと同じであるなら、事実上、SLPv1でProtected Scopeと同じであることに注意してください。 すなわち、その範囲でのあらゆるSA広告が同じ兵士のKeyによって構成されるでしょう。 その範囲のあらゆるDAとUAは適切なPublic Keyによって構成されて、それらのSAsによって起こされた署名について確かめるでしょう。 これは公開鍵暗号基盤がないときSLP展開を構成する便利な方法です。 現在、各SAにそれ自身のキーがあるなら、UAsとDAsを合わせることを管理するのは難し過ぎるでしょうに。
SLP SPI for Directory Agent discovery
Agents SHOULD be configurable to support SLP SPIs as
above, to be used when discovering DAs. This SPI SHOULD
be sent in SrvRqsts to discover DAs and be used to verify
multicast DAAdvert messages.
SLP SPI、ディレクトリエージェント発見エージェントSHOULDにおいて、DAsを発見するとき、使用されるために上のサポートSLP SPIsに構成可能にしてください。 このSPI SHOULD、SrvRqstsで送って、DAsを発見して、使用されて、マルチキャストDAAdvertメッセージについて確かめてください。
SA and DA Private Key
SAs and DAs which can generate digital signatures require
a Private Key and a corresponding SLP SPI indentifier
to include in the Authentication Block. The SLP SPI
identifies the Public Key to use to verify the digital
signature in the Authentication Block.
Authentication Blockに含むデジタル署名を生成することができるKey SAsとDAsが兵士のKeyと対応するSLP SPI indentifierが必要であるSAとDA兵士。 SLP SPIは、Authentication Blockでデジタル署名について確かめるために使用にPublic Keyを特定します。
15. IANA Considerations
15. IANA問題
SLP includes four sets of identifiers which may be registered with IANA. The policies for these registrations (See [18]) are noted in each case.
SLPはIANAに登録されるかもしれない4セットの識別子を含んでいます。 これらの登録証明書のための方針、([18])がその都度注意されるのを確実にしてください。
Guttman, et al. Standards Track [Page 44] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[44ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
The Block Structure Descriptor (BSD) identifies the format of the Authenticator which follows. BSDs 0x8000-0x8FFF are for Private Use.
Block Structure Descriptor(BSD)は続くAuthenticatorの形式を特定します。 BSDs、0×8000 0x8FFFが兵士のUseのためのものです。
Further Block Structured Descriptor (BSD) values, from the range 0x0003-0x7FFF may be standardized in the future by submitting a document which describes:
一層のBlock Structured Descriptor(BSD)値、0×0003範囲0x7FFFから、将来、以下について説明するドキュメントを提出することによって、標準化されるかもしれません。
- The data format of the Structured Authenticator block.
- Structured Authenticatorブロックのデータの形式。
- Which cryptographic algorithm to use (including a reference
to a technical specification of the algorithm.)
- どの暗号アルゴリズムを使用したらよいですか。(アルゴリズムに関する技術仕様書の指示するものを含んでいます。)
- The format of any keying material required for
preconfiguring UAs, DAs and SAs. Also include any
considerations regarding key distribution.
- 材料を合わせるいずれの形式が、UAs、DAs、およびSAsをあらかじめ設定するのに必要です。 また、主要な分配に関するあらゆる問題を含めてください。
- Security considerations to alert others to the strengths and
weaknesses of the approach.
- アプローチの長所と短所に他のものの注意を喚起するセキュリティ問題。
The IANA will assign Cryptographic BSD numbers on the basis of IETF Consenus.
IANAはIETF Consenusに基づいて数をCryptographic BSDに割り当てるでしょう。
New function-IDs, in the range 12-255, may be standardized by the method of IETF Consensus.
範囲12-255では、新しい機能IDがIETF Consensusのメソッドで標準化されるかもしれません。
New SLP Extensions with types in the range 2-65535 may be registered following review by a Designated Expert.
タイプが続いて、登録されていて、2-65535がそうするかもしれない範囲にある新しいSLP ExtensionsはDesignated Expertで論評します。
New error numbers in the range 15-65535 are assigned on the basis of a Standards Action.
範囲15-65535の新しいエラー番号はStandards Actionに基づいて割り当てられます。
Protocol elements used with Service Location Protocol may also require IANA registration actions. SLP is used in conjunction with "service:" URLs and Service Templates [13]. These are standardized by review of a Designated Expert and a mailing list (See [13].)
また、Service Locationプロトコルと共に使用されるプロトコル要素はIANA登録行為を必要とするかもしれません。 に関連してSLPが使用されている、「サービス:」 URLとサービステンプレート[13]。 これらはDesignated Expertのレビューとメーリングリストによって標準化されます。([13]を見てください。)
16. Internationalization Considerations
16. 国際化問題
SLP messages support the use of multiple languages by providing a Language Tag field in the common message header (see Section 8).
SLPメッセージは、一般的なメッセージヘッダーのLanguage Tag野原を供給することによって、複数の言語の使用をサポートします(セクション8を見てください)。
Services MAY be registered in multiple languages. This provides attributes so that users with different language skills may select services interactively.
サービスは複数の言語で登録されるかもしれません。 これは、異なった語学力のユーザがインタラクティブにサービスを選択できるように、属性を提供します。
Attribute tags are not translated. Attribute values may be translated unless the Service Template [13] defines the attribute values to be 'literal'.
属性タグは翻訳されません。 Service Template[13]が'文字通り'ために属性値を定義しない場合、属性値は翻訳されるかもしれません。
Guttman, et al. Standards Track [Page 45] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[45ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
A service which is registered in multiple languages may be queried in multiple languages. The language of the SrvRqst or AttrRqst is used to satisfy the request. If the requested language is not supported, a LANGUAGE_NOT_SUPPORTED error is returned. SrvRply and AttrRply messages are always in the same language of the request.
複数の言語で登録されるサービスは複数の言語で質問されるかもしれません。 SrvRqstかAttrRqstの言語は、要望に応じるのに使用されます。 要求された言語をサポートしないなら、_SUPPORTED誤りではなく、LANGUAGE_を返します。 いつも要求の同じ言語にはSrvRplyとAttrRplyメッセージがあります。
A DA or SA MAY be configured with translations of Service Templates [13] for the same service type. This will allow the DA or SA to translate a request (say in Italian) to the language of the service advertisement (say in English) and then translate the reply back to Italian. Similarly, a UA MAY use templates to translate outgoing requests and incoming replies.
DAかSA MAY、Service Templates[13]に関する翻訳で、同じサービスタイプのために構成されてください。 これで、DAかSAがサービス広告(英語で、言う)の言語に要求(イタリア語で、言う)を翻訳して、次に、回答をイタリア語に翻訳して戻すでしょう。 同様に、UA MAYは、送信する要求と入って来る回答を翻訳するのにテンプレートを使用します。
The dialect field in the Language Tag MAY be used: Requests which can be fulfilled by matching a language and dialect will be preferred to those which match only the language portion. Otherwise, dialects have no effect on matching requests.
Language Tagの方言分野は使用されるかもしれません: 言語と方言を合わせることによって実現できる要求は言語部分だけに合っているものより好まれるでしょう。 さもなければ、方言は、要求に合いながら、影響を全くオンに与えません。
17. Security Considerations
17. セキュリティ問題
SLP provides for authentication of service URLs and service attributes. This provides UAs and DAs with knowledge of the integrity of service URLs and attributes included in SLP messages. The only systems which can generate digital signatures are those which have been configured by administrators in advance. Agents which verify signed data may assume it is 'trustworthy' inasmuch as administrators have ensured the cryptographic keying of SAs and DAs reflects 'trustworthiness.'
SLPはサービスURLとサービス属性の認証に備えます。 SLPメッセージにURLと属性を含んでいて、これはサービスの保全に関する知識をUAsとDAsに提供します。 デジタル署名を生成することができる唯一のシステムがあらかじめ管理者によって構成されたものです。 署名しているデータについて確かめるエージェントは、管理者が、SAsとDAsを暗号の合わせるのが'信頼できること'を反映するのを保証した限り、それが'信頼できる'と仮定するかもしれません。
Service Location does not provide confidentiality. Because the objective of this protocol is to advertise services to a community of users, confidentiality might not generally be needed when this protocol is used in non-sensitive environments. Specialized schemes might be able to provide confidentiality, if needed in the future. Sites requiring confidentiality should implement the IP Encapsulating Security Payload (ESP) [3] to provide confidentiality for Service Location messages.
サービスLocationは秘密性を提供しません。 このプロトコルの目的がユーザの共同体に対するサービスの広告を出すことであるので、このプロトコルが非敏感な環境で使用されるとき、一般に、秘密性は必要でないかもしれません。 将来必要であるなら、専門化している体系は秘密性を提供できるかもしれません。 秘密性を必要とするサイトは、IP Encapsulating Security有効搭載量(超能力)がService Locationメッセージに秘密性を提供する[3]であると実装するべきです。
If Agents are not configured to generate Authentication Blocks and Agents are not configured to verify them, an adversary might easily use this protocol to advertise services on servers controlled by the adversary and thereby gain access to users' private information. Further, an adversary using this protocol will find it much easier to engage in selective denial of service attacks. Sites that are in potentially hostile environments (e.g., are directly connected to the Internet) should consider the advantages of distributing keys associated with SLP SPIs prior to deploying the sensitive directory agents or service agents.
エージェントがAuthentication Blocksを生成するために構成されないで、またエージェントが彼らについて確かめるために構成されないなら、敵は、敵によって制御されたサーバにサービスの広告を出して、その結果、ユーザの個人情報へのアクセスを得るのに容易にこのプロトコルを使用するかもしれません。 さらに、このプロトコルを使用している敵は、選択しているサービス不能攻撃に従事しているのがはるかに簡単であることがわかるでしょう。 潜在的に敵対的環境(例えば、直接インターネットに関連づけられる)にはあるサイトは、展開の前のSLP SPIsに関連しているキーを分配する利点が敏感なディレクトリエージェントかサービスエージェントであると考えるべきです。
Guttman, et al. Standards Track [Page 46] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[46ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
SLP is useful as a bootstrap protocol. It may be used in environments in which no preconfiguration is possible. In such situations, a certain amount of "blind faith" is required: Without any prior configuration it is impossible to use any of the security mechanisms described above. SLP will make use of the mechanisms provided by the Security Area of the IETF for key distribution as they become available. At this point it would only be possible to gain the benefits associated with the use of Authentication Blocks if cryptographic information and SLP SPIs can be preconfigured with the end systems before they use SLP.
aがプロトコルを独力で進むとき、SLPは役に立ちます。 それは前構成がないのが可能である環境で使用されるかもしれません。 そのような状況で、ある量の「盲目的な信仰」が必要です: 少しも先の構成がなければ、上で説明されたセキュリティー対策のどれかを使用するのは不可能です。 SLPは利用可能になるのでIETFのSecurity Areaによって主要な分配に提供されたメカニズムを利用するでしょう。 ここに、SLPを使用する前にエンドシステムで暗号の情報とSLP SPIsをあらかじめ設定できるなら、単にAuthentication Blocksの使用に関連している利益を獲得するのは可能でしょう。
SLPv2 enables a number of security policies with the mechanisms it includes. A SLPv2 UA could, for instance, reject any SLP message which did not carry an authentication block which it could verify. This is not the only policy which is possible to implement.
SLPv2はそれが含むメカニズムで多くの安全保障政策を可能にします。 例えば、SLPv2 UAはそれが確かめることができた認証ブロックを運ばなかったどんなSLPメッセージも拒絶できました。 これは唯一の実装するのにおいて可能な方針ではありません。
Guttman, et al. Standards Track [Page 47] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[47ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
A. Appendix: Changes to the Service Location Protocol from v1 to v2
A。 付録: v1からv2までのService Locationプロトコルへの変化
SLP version 2 (SLPv2) corrects race conditions present in SLPv1 [22]. In addition, authentication has been reworked to provide more flexibility and protection (especially for DA Advertisements). SLPv2 also changes the formats and definition of many flags and values and reduces the number of 'required features.' SLPv2 clarifies and changes the use of 'Scopes', eliminating support for 'unscoped directory agents' and 'unscoped requests'. SLPv2 uses LDAPv3 compatible string encodings of attributes and search filters. Other changes (such as Language and Character set handling) adopt practices recommended by the Internet Engineering Steering Group.
SLPバージョン2(SLPv2)はSLPv1[22]の現在の競合条件を修正します。 さらに、認証は、より多くの柔軟性と保護(特にDA Advertisementsのための)を提供するために作りなおされました。 SLPv2はまた、多くの旗と値の形式と定義を変えて、'必要な特徴'の数を減少させます。SLPv2は'範囲'の使用をはっきりさせて、変えます、'「非-見」られたディレクトリエージェント'と'「非-見」られた要求'のサポートを排除して。 SLPv2は属性と検索フィルタのLDAPv3のコンパチブルストリングencodingsを使用します。 他の変化(Languageやキャラクターセット取り扱いなどの)はインターネットEngineering Steering Groupのそばのお勧めの習慣を採用します。
Effort has been made to make SLPv2 operate the same whether DAs are present or not. For this reason, a new message (the SAAdvert) has been added. This allows UAs to discover scope information in the absence of administrative configuration and DAs. This was not possible in SLPv1.
取り組みで、DAsが存在しているか否かに関係なく、SLPv2は同じように作動させられます。 この理由で、新しいメッセージ(SAAdvert)は加えられます。 これで、UAsは管理構成とDAsが不在のとき範囲情報を発見できます。 これはSLPv1で可能ではありませんでした。
SLPv2 is incompatible in some respects with SLPv1. If a DA which supports both SLPv1 and SLPv2 with the same scope is present, services advertised by SAs using either version of the protocol will be available to both SLPv1 and SLPv2 UAs. SLPv1 DAs SHOULD be phased out and replace with SLPv2 DAs which support both versions of the protocol.
SLPv2はある点でSLPv1と非互換です。 同じ範囲でSLPv1とSLPv2の両方をサポートするDAが存在していると、プロトコルのどちらのバージョンも使用することでSAsによって広告に掲載されたサービスはSLPv1とSLPv2 UAsの両方に利用可能になるでしょう。 SLPv1 DAs SHOULDは段階的に廃止されて、プロトコルの両方のバージョンをサポートするものをSLPv2 DAsに取り替えます。
SLPv1 allows services to be advertised and requested without a scope. Further, DAs can be configured without a scope. This is incompatible with SLPv2 and presents scalability problems. To facilitate this forward migration, SLPv1 agents MUST use scopes for all registrations and requests. SLPv1 DAs MUST be configured with a scope list. This constitutes a revision of RFC 2165 [22].
SLPv1は、サービスが範囲なしで広告を出して、要求されているのを許容します。 さらに、範囲なしでDAsを構成できます。 これは、SLPv2と非互換であり、スケーラビリティ問題を提示します。この前進の移行を容易にするために、SLPv1エージェントはすべての登録証明書と要求に範囲を使用しなければなりません。 範囲リストでSLPv1 DAsを構成しなければなりません。 これはRFC2165[22]の改正を構成します。
B. Appendix: Service Discovery by Type: Minimal SLPv2 Features
B。 付録: タイプによる発見を修理してください: 最小量のSLPv2の特徴
Service Agents may advertise services without attributes. This will enable only discovery of services by type. Service types discovered this way will have a Service Template [13] defined which specifies explicitly that no attributes are associated with the service advertisement. Service types associated with Service Templates which specify attributes MUST NOT be advertised by SAs which do not support attributes.
サービスエージェントは属性なしでサービスの広告を出すかもしれません。 これはタイプによるサービスの発見だけを可能にするでしょう。 このように発見されたサービスタイプはどんな属性もサービス広告に関連していないと明らかに指定する定義されたService Template[13]を持つでしょう。 属性を指定するService Templatesに関連しているサービスタイプは属性をサポートしないSAsによって広告を出されてはいけません。
While discovery of service by service type is a subset of the features possible using SLPv2 this form of discovery is consistent with the current generation of products that allow simple browsing of all services in a 'zone' or 'workgroup' by type. In some cases, attribute discovery, security and feature negotiation is handled by
サービスタイプによるサービスの発見はSLPv2を使用する可能な特徴の部分集合ですが、この形式の発見はタイプで'ゾーン'か'ワークグループ'における、すべてのサービスの簡単なブラウジングを許容する製品の現代と一致しています。 交渉が扱われるいくつかのケース、属性発見、セキュリティ、および特徴で
Guttman, et al. Standards Track [Page 48] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[48ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
application layer protocols - all that is required is the basic discovery of services that support a certain service.
応用層プロトコル--必要であるすべては基本的なあるサービスをサポートするサービスの発見です。
UAs requesting only service of that service type would only need to support service type and scope fields of the Service Request. UAs would still perform DA discovery and unicast SLPv2 SrvRqst messages to DAs in their scope once they were discovered instead of multicasting them.
そのサービスタイプのサービスだけを要求するUAsは、サービスがService Requestのタイプと範囲分野であるとサポートする必要があるだけでしょう。 彼らがマルチキャスティングの代わりにいったん発見されると、UAsは彼らの範囲でまだDA発見とユニキャストSLPv2 SrvRqstメッセージをDAsに実行しているでしょうに。彼ら。
SAs would also perform DA discovery and use a SLPv2 SrvReg to register all their advertised services with SLPv2 DAs in their scope. These advertisements would needless to say contain no attribute string.
SAsは、彼らのすべての広告を出しているサービスを彼らの範囲のSLPv2 DAsに登録するのにまた、DA発見を実行して、SLPv2 SrvRegを使用するでしょう。 広告が言うまでもなくそうするこれらは属性ストリングを全く含んでいません。
These minimal SAs could ignore the Language Tag in requests since SrvRqst messages would contain no attributes, hence no strings would be internationalized. Further, any non-null predicate string would fail to match a service advertisement with no attributes, so these SAs would not have to parse and interpret search filters. Overflow will never occur in SrvRqst, SrvRply or SrvReg messages so TCP message handling would not have to be implemented. Finally, all AttrRqst messages could be dropped by the SA, since no attributes are supported.
SrvRqstメッセージは属性を全く含んでいないでしょう、したがって、これらの最小量のSAsが要求でLanguage Tagを無視するかもしれません、したがって、ストリングが全く国際的にされないでしょう。 さらに、どんな非ヌル述部ストリングも属性なしでサービス広告に合っていないでしょう、これらのSAsが検索フィルタを分析して、したがって、解釈する必要はないでしょう。 オーバーフローがSrvRqst、SrvRplyまたはSrvRegメッセージに決して起こらないので、TCPメッセージハンドリングは実装される必要はないでしょう。 最終的に、属性が全くサポートされないので、SAはすべてのAttrRqstメッセージを下げることができました。
C. Appendix: DAAdverts with arbitrary URLs
C。 付録: 任意のURLがあるDAAdverts
Using Active DA Discovery, a SrvRqst with its service type field set to "service:directory-agent". DAs will respond with a DAAdvert containing a URL with the "service:directory-agent:" scheme. This is the same DAAdvert that such a DA would multicast in unsolicited DA advertisements.
Active DAディスカバリーを使用して、サービスタイプ分野があるSrvRqstは「サービス: ディレクトリエージェント」にセットしました。 DAAdvertがURLを含んでいてDAsが応じる、「: ディレクトリエージェントにサービスを提供してください」 計画してください。 これはそのようなDAがそうする同じDAAdvertです。求められていないDA広告におけるマルチキャスト。
A UA or SA which receives an unsolicited DAAdvert MUST examine the URL to determine if it has a recognized scheme. If the UA or SA does not recognize the DAAdvert's URL scheme, the DAAdvert is silently discarded. This document specifies only how to use URLs with the "service:directory-agent:" scheme.
求められていないDAAdvertを受けるUAかSAが、それで認識された体系があるかどうか決定するためにURLを調べなければなりません。 UAかSAがDAAdvertのURL体系を認識しないなら、DAAdvertは静かに捨てられます。 このドキュメントがURLを使用するためにその方法だけを指定する、「: ディレクトリエージェントにサービスを提供してください」 計画してください。
This provides the possibility for forward compatibility with future versions of SLP and enables other services to advertise their ability to serve as a clearinghouse for service location information.
これは、SLPの将来のバージョンを下位互換のための可能性に提供して、他のサービスがサービス位置情報のための情報センターとして機能する彼らの能力の広告を出すのを可能にします。
For example, if LDAPv3 [15] is used for service registration and discovery by a set of end systems, they could interpret a LDAP URL [16] to passively discover the LDAP server to use for this purpose. This document does not specify how this is done: SLPv2 agents without further support would simply discard this DAAdvert.
例えば、LDAPv3[15]がサービス登録と発見に1セットのエンドシステムによって使用されるなら、彼らはLDAPサーバがこのために使用すると受け身に発見するLDAP URL[16]を解釈するかもしれません。 このドキュメントは、これがどのように完了しているかを指定しません: さらなるサポートのないSLPv2エージェントは単にこのDAAdvertを捨てるでしょう。
Guttman, et al. Standards Track [Page 49] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[49ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
D. Appendix: SLP Protocol Extensions
D。 付録: SLPプロトコル拡張子
D.1. Required Attribute Missing Option
D.1。 必要な属性なくなったオプション
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 Type = 0x0001 | Extension Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template IDVer Length | Template IDVer String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Required Attr <tag-list> Length| Required Attr <tag-list> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 拡大タイプ=0x0001| 拡大の長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | テンプレートIDVerの長さ| テンプレートIDVerストリング\+++++++++++++++++++++++++++++++++|リスト>にタグ付けををしている必要なAttr<長さ| リスト>にタグ付けををしている必要なAttr<\+++++++++++++++++++++++++++++++++
Required attributes and the format of the IDVer string are defined by [13].
IDVerストリングの必要な属性と書式は[13]によって定義されます。
If a SA or DA receives a SrvRqst or a SrvReg which fails to include a Required Attribute for the requested Service Type (according to the Service Template), it MAY return the Required Attribute Extension in addition to the reply corresponding to the message. The sender SHOULD reissue the message with a search filter including the attributes listed in the returned Required Attribute Extension. Similarly, the Required Attribute Extension may be returned in response to a SrvDereg message that contains a required attribute tag.
SAかDAが要求されたService Type(Service Templateによると)のためにRequired Attributeを含んでいないSrvRqstかSrvRegを受けるなら、それはメッセージに対応する回答に加えてRequired Attribute Extensionを返すかもしれません。 送付者SHOULDは検索フィルタが返されたRequired Attribute Extensionに記載された属性を含んでいるメッセージを再発行します。 同様に、必要な属性タグを含むSrvDeregメッセージに対応してRequired Attribute Extensionを返すかもしれません。
The Template IDVer String is the name and version number string of the Service Template which defines the given attribute as required. It SHOULD be included, but can be omitted if a given SA or DA has been individually configured to have 'required attributes.'
Template IDVer Stringは必要に応じて与えられた属性を定義するService Templateの名前とバージョン数のストリングです。 それ、SHOULDを含まれていますが、与えられたSAかDAが'属性を必要とであった'ように個別に構成されたなら、省略できます。
The Required Attribute <tag-list> MUST NOT include wild cards.
Required Attribute<タグリスト>はワイルドカードを含んではいけません。
E. Acknowledgments
E。 承認
This document incorporates ideas from work on several discovery protocols, including RDP by Perkins and Harjono, and PDS by Michael Day. We are grateful for contributions by Ye Gu and Peter Ford. John Veizades was instrumental in the standardization of the Service Location Protocol. Implementors at Novell, Axis Communications and Sun Microsystems have contributed significantly to make this a much clearer and more consistent document.
このドキュメントはいくつかの発見プロトコルに対する仕事から考えを取り入れます、パーキンスとHarjonoによるRDP、およびマイケル・デーによるPDSを含んでいて。 私たちはYe Guとピーター・フォードによる貢献に感謝しています。 ジョンVeizadesはService Locationプロトコルの標準化で手段になっていました。 ノベル、枢軸Communications、およびサン・マイクロシステムズの作成者は、これをはるかに明確でより一貫したドキュメントにするようにかなり貢献しました。
Guttman, et al. Standards Track [Page 50] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[50ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
F. References
F。 参照
[1] Port numbers, July 1997.
ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers.
[1] 数、7月1997日の ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers を移植してください。
[2] ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment
DAM 4 to ISO/IEC 9594-2, December 1996.
[2] ISO/IEC JTC1/Sc21。 拡大を証明してください。 1996年12月の修正案ダム4からISO/IEC9594-2。
[3] ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment
DAM 2 to ISO/IEC 9594-6, December 1996.
[3] ISO/IEC JTC1/Sc21。 拡大を証明してください。 1996年12月の修正案ダム2からISO/IEC9594-6。
[4] ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment
DAM 1 to ISO/IEC 9594-7, December 1996.
[4] ISO/IEC JTC1/Sc21。 拡大を証明してください。 1996年12月の修正案ダム1からISO/IEC9594-7。
[5] ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment
DAM 1 to ISO/IEC 9594-8, December 1996.
[5] ISO/IEC JTC1/Sc21。 拡大を証明してください。 1996年12月の修正案ダム1からISO/IEC9594-8。
[6] Unicode Technical Report #8. The Unicode Standard, version 2.1.
Technical report, The Unicode Consortium, 1998.
[6] ユニコード技術報告書#8。 ユニコードStandard、バージョン2.1。 技術報告書、ユニコードConsortium、1998。
[7] Alvestrand, H., "Tags for the Identification of Languages",
RFC 1766, March 1995.
Alvestrand(H.)が「言語の識別のためにタグ付けをする」[7]、RFC1766、1995年3月。
[8] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[8]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、RFC2396、1998年8月。
[9] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[9] ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、BCP14、RFC2119、1997年3月。
[10] CCITT. The Directory Authentication Framework. Recommendation
X.509, 1988.
[10] CCITT。 ディレクトリ認証フレームワーク。 推薦X.509、1988。
[11] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[11] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[12] S. Gursharan, R. Andrews, and A. Oppenheimer. Inside AppleTalk.
Addison-Wesley, 1990.
[12] S.Gursharan、R.アンドリュース、およびA.オッペンハイマー。 AppleTalkの中で。 アディソン-ウエスリー、1990。
[13] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and
service: Schemes", RFC 2609, June 1999.
[13] Guttman(E.、パーキンス、C.、およびJ.ケンフ)は「Templatesを調整して、以下を修理します」。 「体系」、RFC2609、1999年6月。
[14] Howes, T., "The String Representation of LDAP Search Filters",
RFC 2254, December 1997.
[14] ハウズ、T.、「LDAP検索フィルタのストリング表現」、RFC2254、1997年12月。
[15] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
Access Protocol (v3)", RFC 2251, December 1997.
[15] ウォールとM.とハウズとT.とS.Kille、「ライトウェイト・ディレクトリ・アクセス・プロトコル(v3)」、RFC2251 1997年12月。
Guttman, et al. Standards Track [Page 51] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[51ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
[16] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255,
December 1997.
[16] ハウズとT.とM.スミス、「LDAP URL形式」、RFC2255、1997年12月。
[17] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365,
July 1998.
[17] マイヤー、D.、「行政上見られたIPマルチキャスト」、RFC2365、1998年7月。
[18] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs, BCP 26, RFC 2434,
October 1998.
[18]NartenとT.とH.Alvestrand、「1998年10月にRFCs、BCP26、RFC2434にIANA問題部に書くためのガイドライン。」
[19] Microsoft Networks. SMB File Sharing Protocol Extensions 3.0,
Document Version 1.09, November 1989.
[19] マイクロソフトネットワーク。 1989年11月にプロトコル拡大3.0、ドキュメントバージョン1.09を共有して、SMBはファイルします。
[20] National Institute of Standards and Technology. Digital
signature standard. Technical Report NIST FIPS PUB 186, U.S.
Department of Commerce, May 1994.
[20] 米国商務省標準技術局。 デジタル署名規格。 技術報告書NIST FIPSパブ186、米国商務省は1994がそうするかもしれません。
[21] Perkins, C. and E. Guttman, "DHCP Options for Service Location
Protocol", RFC 2610, June 1999.
[21] パーキンスとC.とE.Guttman、「サービス位置のプロトコルのためのDHCPオプション」、RFC2610、1999年6月。
[22] Veizades, J., Guttman, E., Perkins, C. and S. Kaplan, "Service
Location Protocol", RFC 2165, July 1997.
[22]VeizadesとJ.とGuttmanとE.とパーキンスとC.とS.キャプラン、「サービス位置のプロトコル」、RFC2165、1997年7月。
[23] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 2279, January 1998.
[23]Yergeau、1998年1月のF.、「UTF-8、ISO10646の変換形式」RFC2279。
Guttman, et al. Standards Track [Page 52] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[52ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
G. Authors' Addresses
G。 作者のアドレス
Erik Guttman Sun Microsystems Bahnstr. 2 74915 Waibstadt Germany
エリックGuttmanサン・マイクロシステムズBahnstr。 2 74915Waibstadtドイツ
Phone: +49 7263 911 701 EMail: Erik.Guttman@sun.com
以下に電話をしてください。 +49 7263 911 701はメールされます: Erik.Guttman@sun.com
Charles Perkins Sun Microsystems 901 San Antonio Road Palo Alto, CA 94040 USA
チャールズパーキンスサン・マイクロシステムズ901サンアントニオRoadカリフォルニア94040パロアルト(米国)
Phone: +1 650 786 6464 EMail: cperkins@sun.com
以下に電話をしてください。 +1 6464年の650 786メール: cperkins@sun.com
John Veizades @Home Network 425 Broadway Redwood City, CA 94043 USA
ジョンVeizades@Home Network425ブロードウェイカリフォルニア94043レッドウッドシティー(米国)
Phone: +1 650 569 5243 EMail: veizades@home.net
以下に電話をしてください。 +1 5243年の650 569メール: veizades@home.net
Michael Day Vinca Corporation. 1201 North 800 East Orem, Utah 84097 USA
マイケル日のツルニチニチソウ社。 1201 北部800の東ユタ84097オレーム(米国)
Phone: +1 801 376-5083 EMail: mday@vinca.com
以下に電話をしてください。 +1 801 376-5083 メールしてください: mday@vinca.com
Guttman, et al. Standards Track [Page 53] RFC 2608 Service Location Protocol, Version 2 June 1999
Guttman、他 標準化過程[53ページ]RFC2608サービス位置のプロトコル、バージョン1999年6月2日
H. Full Copyright Statement
H。 完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 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, et al. Standards Track [Page 54]
Guttman、他 標準化過程[54ページ]
一覧
スポンサーリンク
