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
Service Location Protocol, Version 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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
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.
サービスロケーションプロトコルは、ネットワークサービスの発見と選択のためのスケーラブルなフレームワークを提供します。このプロトコルを使用して、インターネットを使用するコンピュータは、ネットワークベースのアプリケーションのためのネットワークサービスのほとんど、あるいはまったく静的な構成を必要としています。これは、コンピュータがよりポータブルになると特に重要であり、ユーザーがあまり寛容やネットワークシステム管理の需要を満たすことができます。
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
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
E. Acknowledgments 50 F. References 51 G. Authors' Addresses 53 H. Full Copyright Statement 54
E.謝辞50 Fで51人のG.の作者のアドレス53 H.全著作権ステートメント54を参照し
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.
サービスロケーションプロトコル（SLP）は、ネットワークサービスの存在、位置、および構成に関する情報へのアクセスをホストに提供するための柔軟かつスケーラブルなフレームワークを提供します。伝統的に、ユーザーはネットワークアドレスの別名であるネットワークホスト（人間が読めるテキスト文字列）の名前を知ることにより、サービスを見つけなければなりませんでした。 SLPは、ユーザーがサービスをサポートするネットワークホストの名前を知る必要がなくなります。むしろ、ユーザは、サービスの所望のタイプおよびサービスを記述する属性のセットを供給する。その説明に基づいて、サービスロケーションプロトコルは、利用者に対するサービスのネットワークアドレスを解決します。
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の[RFC 2165]を更新します。この仕様は、2つの部分があります。最初は、プロトコルの必要な機能について説明します。第二は、任意であり、プロトコルの拡張機能を説明し、およびスケーラビリティを可能にします。
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は、共有サービスを企業ネットワークにサービスを提供するように設計されており、それは必ずしも世界的なインターネットを通じて、または数千のクライアントのか、数十のサービスの数十万人があるネットワークで広域サービスの発見のためにスケールしないことがあります。
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.
Service Agent (SA) A process working on the behalf of one or more services to advertise the services.
サービスエージェント（SA）サービスを宣伝するために1つ以上のサービスのために働くのプロセス。
Directory Agent (DA) A process which collects service advertisements. There can only be one DA present per given host.
ディレクトリエージェント（DA）サービス通知を収集プロセス。唯一の特定のホストごとにDAが存在することができます。
Service Type Each type of service has a unique Service Type string.
サービスタイプは、サービスの各タイプには、独自のサービスタイプ文字列を持っています。
Naming Authority The agency or group which catalogues given Service Types and Attributes. The default Naming Authority is IANA.
当局にサービスのタイプと属性与えられたカタログ代理店またはグループに名前を付けます。権限の命名デフォルトはIANAです。
Scope A set of services, typically making up a logical administrative group.
スコープ一般的に論理的な管理グループを構成するサービスのセット。
URL A Universal Resource Locator [8].
URL Aユニバーサルリソースロケータ[8]。
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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[9]。
Syntax Syntax for string based protocols follow the conventions defined for ABNF [11].
文字列ベースのプロトコルのための構文構文は、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.
文字列のすべての文字列は、Unicode [6]文字セットのUTF-8 [23]の変換を使用して符号化して伝送する場合NULL終端されていないされています。文字列は、2バイトの長さフィールドが先行しています。
<string-list> A comma delimited list of strings with the following syntax:
<文字列リスト>次の構文を使用して文字列のカンマ区切りのリスト：
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.
フォーマット図において、\で終わる任意のフィールドは、プロトコルに先立って長さフィールドによって与えられ、可変長フィールドを示しています。
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.
サービスロケーションプロトコルは、クライアント・アプリケーションは、「ユーザーエージェント」としてモデル化され、サービスがによってアドバタイズされることにより、フレームワークをサポート「サービスエージェント」。 「ディレクトリエージェント」と呼ばれる第3のエンティティは、プロトコルにスケーラビリティを提供します。
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.
ユーザーエージェントは、クライアントが必要とするサービスの特性を指定して、クライアントアプリケーションの代わりに「サービス・リクエスト」（SrvRqst）を発行します。ユーザエージェントは、要求を満たすネットワーク内のすべてのサービスの場所を指定するサービス応答（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.
サービスロケーションプロトコルのフレームワークは、ユーザエージェントが直接サービスエージェントへの要求を発行することができます。この場合、リクエストがマルチキャストです。サービスエージェントは、ユニキャストサービスの場所を含む応答を広告サービスの要求を受けます。
+------------+ ----Multicast SrvRqst----> +---------------+
| User Agent | | Service Agent |
+------------+ <----Unicast 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）で確認応答を受け取る送ります。これらの広告は、ディレクトリエージェントでリフレッシュしなければならないか、または彼らが失効します。代わりに、サービスエージェントのディレクトリエージェントへのユーザーエージェントのユニキャスト要求は、任意のディレクトリエージェントが知られている場合。
+-------+ -Unicast SrvRqst-> +-----------+ <-Unicast SrvReg- +--------+
| User | | Directory | |Service |
| Agent | | Agent | | Agent |
+-------+ <-Unicast SrvRply- +-----------+ -Unicast 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).
ユーザとサービスエージェントはディレクトリエージェント二つの方法を発見します。彼らは、起動時にまず、彼らは「ディレクトリエージェント」サービスのマルチキャストサービスリクエストを発行します。第二に、ディレクトリエージェントは、ユーザとサービスエージェントがために聞いた、頻度の低い未承諾広告を送信します。いずれの場合も薬剤はDA広告（DAAdvert）を受け取ります。
+---------------+ --Multicast SrvRqst-> +-----------+
| User or | <--Unicast DAAdvert-- | Directory |
| Service Agent | | Agent |
+---------------+ <-Multicast DAAdvert- +-----------+
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.
ユーザエージェントは、通常、（その場合、ユーザエージェントは、サービスだけの特定のグループを発見することができるであろう）スコープ文字列が割り当てられます。これは、ユーザーに「プロビジョニング」サービスに、ネットワーク管理者を可能にします。また、ユーザーエージェントはまったくスコープを用いて構成することができます。その場合には、すべての利用可能なスコープを発見し、クライアントアプリケーションがネットワーク上で利用可能な任意のサービスのための要求を発行することができます。
+---------+ Multicast +-----------+ Unicast +-----------+
| Service | <--SrvRqst-- | User | --SrvRqst-> | Directory |
| Agent | | Agent | | Agent |
| Scope=X | Unicast | Scope=X,Y | Unicast | Scope=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.
サービスはスコープXに求められる場合は、上記の図では、ユーザエージェントがスコープXおよびYで構成され、要求がマルチキャストです。それはスコープ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.
サービスエージェントとユーザエージェントはDAAdvertsを備えたデジタル署名を検証することができます。ユーザエージェントとディレクトリエージェントは、サービスエージェントによって登録されたサービス情報を確認することができます。鍵材料は、SLPセキュリティ・パラメータ・インデックス、または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.
デジタル署名を生成するように構成されたすべてのホストは、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.
SAは、マルチキャストサービス要求とユニキャストサービス要求を受け入れなければなりません。 SAは他の要求（属性およびサービスタイプの要求を）受け入れることができます。 SAは、マルチキャストDA広告をリッスンする必要があります。
The features described up to this point are required to implement. A minimum implementation consists of a User Agent, Service Agent or both.
ここまで説明した機能を実装するために必要とされています。最小の実装は、ユーザエージェント、サービス・エージェントまたはその両方で構成されています。
There are several optional features in the protocol. Note that DAs MUST support all these message types, but DA support is itself 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.
プロトコルにはいくつかのオプション機能があります。 DASは、これらすべてのメッセージタイプをサポートしなければならないことに注意してください、しかし、DAのサポートは、それ自体SLPを使用してネットワーク上で展開するオプションです。 UAとSAは、これらのメッセージタイプをサポートするかもしれません。これらの操作は、（ブラウジングまたは選択的サービスの登録を更新する。）は、主に対話的に使用するためのものであるUAとSA、彼らが使用される環境の要件や制約に応じてそれらをサポートするかどうかのどちらか。
Service Type Request A request for all types of service on the network. This allows generic service browsers to be built.
サービスタイプ要求ネットワーク上のサービスのすべてのタイプのための要求。これは、一般的なサービスのブラウザが構築できます。
Service Type Reply A reply to a Service Type Request.
サービスタイプは、サービスタイプ要求に対する応答を返信します。
Attribute Request A request for attributes of a given type of service or attributes of a given service.
サービスまたは特定のサービスの属性の特定のタイプの属性を要求をリクエスト属性。
Attribute Reply A reply to an Attribute Request.
属性要求に対する応答を返信する属性。
Service Deregister A request to deregister a service or some attributes of a service.
サービスは、サービスまたはサービスのいくつかの属性を登録解除する要求を登録解除します。
Service Update A subsequent SrvRqst to an advertisement. This allows individual dynamic attributes to be updated.
サービスは、広告への以後の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の広告、ユーザーエージェントは、その範囲の設定を発見するために、サービスエージェントを要求することができます。ユーザエージェントは、要求にこれらのスコープを使用することができます。
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.
マルチキャストサポートがない場合には、ブロードキャストを使用することができます。 DAの位置は、静的に、構成された上記のようにSLPを使用して発見し、またはDHCPを使用して構成されてもよいです。メッセージが大きすぎる場合、それはTCPを使ってユニキャストすることができます。
A SLPv2 implementation SHOULD support SLPv1 [22]. This support includes:
SLPv2の実装はSLPv1の[22]をサポートすべきです。このサポートは含まれています：
2. Unscoped SLPv1 requests are considered to be of DEFAULT scope. SLPv1 UAs MUST be reconfigured to have a scope if possible.
2.有効範囲なしSLPv1の要求は、既定のスコープであると考えられます。 SLPv1のUAは、可能な場合はスコープを持つように再設定する必要があります。
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は、スコープ外でSLPv1 DAとして動作する方法はありません。 SLPv1のSAが可能な場合はスコープを持つように再設定する必要があります。
4. SLPv2 DAs answer SLPv1 requests with SLPv1 replies and SLPv2 requests with SLPv2 replies.
4. SLPv2のDAが返信SLPv2のでSLPv1の返信とSLPv2の要求にSLPv1の要求に答えます。
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のDAが同じようにSLPv1のとSLPv2のからの登録を使用します。これは、プロトコルのバージョンのいずれかを使用してエージェントからの着信要求が登録されたサービスのこの共通セットと照合されます、です。
6. SLPv2 registrations which use Language Tags which are greater than 2 characters long will be inaccessible to SLPv1 UAs.
長いSLPv1のユーザエージェントにアクセスできなくなります2つの文字を超えている言語タグを使用する6. SLPv2の登録。
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のDAがSLPv1のサービスタイプ文字列の構文に準拠しSrvTypeRplyメッセージ、すなわち唯一のサービスタイプ文字列を返さなければなりません。彼らは抽象的なサービスタイプのためのサービス・タイプの文字列を返してはなりません。
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. SLPv1のSrvRqstsとサービスの種類別AttrRqstsは抽象的なサービスタイプとサービスのURLと一致していません。彼らは具体的なサービスの種類とサービスの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のUAはSLPv2のSASおよびSLPv2のUAのからの返信がSLPv1ののSAからの応答を受信しません受け取ることができません。異なるバージョンのUAとSAを相互運用するために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は、抽象サービスURL応答を受け取ることはありません。たとえば、サービスタイプ「サービス：x」のためにSLPv1のAttrRqstで「：X：Y：// ORBサービス」の属性を返しません。リクエストがSLPv2のでなされた場合には、このサービスの属性を返します。
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".
サービスURLは、サービスの位置を示します。このURLは、サービスとすることができる：スキーム[13]（セクション4.1に概説）、又はURI規格に準拠した他の任意のURLスキーム[8]、アドレス指定なしのURLがSLPによってアドバタイズされるべきではないことを除い。 「ジェネリック」URLのサービスタイプは、そのスキーム名です。たとえば、「http://www.srvloc.org」のサービスタイプ文字列は、「HTTP」になります。
Reserved characters in URLs follow the rules in RFC 2396 [8].
URLでの予約文字は、[8] RFC 2396の規則に従ってください。
Service URL syntax and semantics are defined in [13]. Any network service may be encoded in a Service URL.
サービスURLの構文およびセマンティクスは、[13]で定義されています。任意のネットワークサービスは、サービスのURLにエンコードすることができます。
This section provides an introduction to Service URLs and an example showing a simple application of them, representing standard network services.
このセクションでは、サービスのURLと標準のネットワークサービスを表すそれらの簡単なアプリケーションを示す例を紹介します。
A Service URL may be of the form:
サービスの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.
このサービスのサービスタイプ：「<addrspec>の前に、アドレス指定：URLは `最終（は含まない）までの文字列であると定義されています。
<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>（可能な場合に使用されるべきである）ホスト名または任意に続くホスト名、 `のためのドット十進表記です。
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".
サービス：予約済みポート[1]名：スキームURLを連結する「サービス」によって、任意の標準的なプロトコル名を用いて形成することができます。例えば、 "サービス：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
サービスタイプは、予想される属性値、およびプロトコル動作を提供する「サービステンプレート」[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.
サービスタイプ文字列「サービス：<抽象型>」は、その抽象型のすべてのサービスを一致します。具体的な種類も含まれている場合のみ、これらのサービスは、要求に一致します。例：プリンタ：サービスタイプは、URLサービスにマッチしますよう：「プリンタサービス」を指定するSrvRqstかAttrRqst LPR：//ホスト名とサービス：プリンタ：のhttp：//ホスト名。リクエストは「：プリンタ：サービスの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項で説明したようにこの部分文字列は、命名機関です。異なる命名当局とサービスタイプが全く異なります。換言すれば、サービス：x.oneとサービス：abstract.one：yおよびサービス：abstract.two：Y x.twoは、サービスされているような、異なるサービスタイプです。
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.
命名機関は、必要に応じてサービスタイプ文字列の一部として含まれてもよいです。サービスの命名当局は、サービスのタイプと属性に登録されており、サービスの場所によって提供さの意味を定義します。命名機関自体は、典型的には、一意の組織を識別する文字列です。文字列が追加されていない場合IANAは、暗黙の命名機関です。 「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.
命名当局は、実験的な独自のまたは私的使用のためにあるサービスタイプを定義することもできます。命名機関を使用して、1はどちらか、単に登録時の属性を無視するか、一つだけのサイトのための属性の設定されたローカル・使用を作成することができます。使用する手順は、「ユニーク」命名権限文字列を作成し、上記のように標準的な属性定義を指定することです。セクション8.1および8.3に記載したように、この命名機関は、登録およびクエリを伴うであろう。サービスタイプは、インターネット全体の相互運用性を確保するためにIANAに登録する必要があります。
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) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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がURLと共に長さ、寿命、およびおそらくは認証情報を関連付けるURLエントリと呼ばれます。上記のように定義されたURLエントリは、返信やサービス登録サービスで使用されています。
A service advertisement is often accompanied by Service Attributes. These attributes are used by UAs in Service Requests to select appropriate services.
サービス広告は、多くの場合、サービス属性を伴っています。これらの属性は、適切なサービスを選択するために、サービス要求内のUAによって使用されています。
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.
使用することができる許容可能な属性は、典型的には、特定のサービスタイプのためのサービステンプレート[13]によって指定されます。標準テンプレートに基づいて広告を出しているサービスでは、標準テンプレートが必要とするすべてのサービス属性を登録する必要があります。 「サービス：」以外のスキームとURLが属性に登録されるかもしれません。
Non-standard attribute names SHOULD begin with "x-", because no standard attribute name will ever have those initial characters.
標準的な属性名はこれまで、これらの初期の文字を持ちませんので、非標準の属性名は、「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 = `*'
ATTRリスト=属性/属性 '、 'ATTRリスト属性= '（' ATTRタグ `= 'ATTR-VAL-リスト`）' / ATTRタグATTR-VAL-リスト= ATTR-VAL / ATTR-VAL ` 」ATTR-VAL-リストのattr-タグ= 1 *安全なタグATTR-VAL = INTVAL / strval / boolval /不透明INTVAL = [ - ] 1 * DIGITのstrval = 1 *安全-valのboolval = "真" /「偽「不透明= "\ FF" 1 *エスケープ-valの安全-VAL =;予約された以外の任意の文字。安全タグ=;予約された、スターと悪いタグ以外の任意の文字。予約= `（ '/'）'/`、 '/ `\'/`！」 / `< '/` =' / '> '/ `〜'/ 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-リスト>、存在する場合、エスケープ文字 `\」のすべての出現のための評価の前にスキャンする必要があります。予約文字は（他の文字をエスケープしてはならない）エスケープしなければなりません。すべてのエスケープ文字は、文字列の一致を試みる前に、その値に復元する必要があります。不透明な値については、文字が変換されないエスケープ - 彼らは、バイトとして解釈されます。
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.
フォーム「true」または「false」を持っているブール文字列は、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」が整数であると考えられることができます。これらは、整数の比較を用いて比較します。
String All other Strings are matched using strict lexical ordering (see Section 6.4).
文字列の他のすべての文字列は、厳密な字句順序付けを使用して一致している（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\00".
不透明な不透明値は、バイトの配列です。彼らはシーケンス「\ FF」で始まるため、これらは文字列と区別されます。これは、エスケープ、何以下はバイナリ値を構成するエスケープ表記でバイトのシーケンスであることを示す、違法UTF-8エンコーディングです。例えば、 '0' バイトは "\ FF \ 00" 符号化されています。
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リスト>に含まれている場合、<タグリスト>または検索フィルタ、それはメッセージにPARSE_ERRORを返さなければなりません受信SAまたはDA。
A keyword has only an <attr-tag>, and no values. Attributes can have one or multiple values. All values are expressed as strings.
キーワードは、<ATTRタグ>、およびなしの値を持っています。属性は、一つまたは複数の値を持つことができます。すべての値は、文字列として表現されています。
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\00\00 is disallowed. A DA or SA receiving such an <attr-list> MUST return an INVALID_REGISTRATION error.
格納された値、すなわち、X = 4、真、スー、\ FF \ 00 \ 00が許可され、一貫していなければなりません。そのような<ATTR-list>の受信DAまたはSAがINVALID_REGISTRATIONエラーを返さなければなりません。
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.
このセクションでは、最小の実装のSAとUAのための要件だけでなく、DASとの相互作用を定義します。 DAはSLPが機能するためには必要ありませんが、それが存在する場合は、以下に定義として、UAとSAはそれと対話する必要があります。
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に要求を発行しなければなりません。 SAはSrvRplyまたはSAAdvertメッセージで適切なSrvRqstsに返答しなければなりません。それらが発見されているようSAにもDAに登録しなければなりません。
UAs perform discovery by issuing Service Request messages. SrvRqst messages are issued, using UDP, following these prioritized rules:
UAは、サービス・リクエスト・メッセージを発行することにより、検出を実行します。 SrvRqstメッセージは、これらの優先順位のルールに従い、UDPを使用して、発行されています。
1. A UA issues a request to a DA which it has been configured with by DHCP.
1. A UAはそれがDHCPによってで構成されたDAに要求を発行します。
2. A UA issues requests to DAs which it has been statically configured with.
2. A UAは、それが静的に設定されていたDAに要求を発行します。
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は、その後のDAのセットを使用して、DAを検出するために、マルチキャスト/収束SrvRqstsを使用します。どんなのDAS知らないUAは、指数関数的に、後続の試行間待って間隔を長く、DA発見を再試行するべきである（待機間隔を毎回2倍になります。）推奨される最小の待機間隔はCONFIG_DA_FIND秒です。
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.
DAをの知識なし4. A UAは、SASへのマルチキャスト収束を使用して要求を送信します。 SAのユニキャスト、マルチキャスト、収束アルゴリズムに従ってのUAに返信。
UAs and SAs are configured with a list of scopes to use according to these prioritized rules:
UAとSAは、これらの優先順位のルールに従って使用するスコープのリストで構成されています。
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。ユーザ選択可能な範囲のモデルが使用されている場合は、静的な構成は、明示的に、UAのためのNO SCOPEに設定することができます。 11.2節を参照してください。
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.
静的、動的にその範囲のリストを決定するために、DAまたはSA発見を使用するNO SCOPEリストに設定されているUA。この場合、DASおよびおそらくSAを発見するために、空のスコープのリストを使用しています。そして、それは後続の要求で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.
DAは、それがで構成されたスコープのいずれかを広告する場合SAは、それが発見どんなDAとそのすべてのサービスを登録する必要があります。 UAが行うようにSAは、DASに関する情報を取得します。また、SAは、マルチキャスト迷惑DAAdvertsをリッスンする必要があります。 SAは、成功を示すためのSrvRegメッセージで応答ダスへのSrvRegメッセージを送信することで登録します。彼らが使用するように構成されたすべてのスコープ内のSAレジスタ。
DAs MUST accept unicast requests and multicast directory agent discovery service requests (for the service type "service:directory-agent").
DAがユニキャスト要求およびマルチキャストディレクトリエージェント発見サービス要求（サービスタイプの「：ディレクトリエージェントサービス」）を受け入れなければなりません。
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.
SAは、マルチキャスト要求およびユニキャスト要求の両方を受け入れなければなりません。 SAは、REQUEST MCASTフラグはSLPメッセージヘッダに設定されているか否かによって区別することができます。
The Service Location Protocol uses multicast for discovering DAs and for issuing requests to SAs by default.
サービスロケーションプロトコルは、DASを発見すると、デフォルトでのSAに要求を発行するためのマルチキャストを使用しています。
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 from which the request was issued. The default maximum transmission unit for UDP messages is 1400 bytes excluding UDP and other headers.
SLPのために予約リスニングポートは、これは、すべてのSLPメッセージの宛先ポートである427です。 SLPメッセージは、一時的なポートに送信されることができます。返信や確認応答は要求が発行されたポートに送信されます。 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フラグは、応答メッセージに設定されています。 TCP接続を開くことが切り詰められたメッセージを受信するUAは、同じXIDを使用して、DAまたはSAと（セクション6.2を参照）、要求を再送信します。また、切り捨て返事を利用したり、小さく返事になり、より制限の要求を再公式化しようとすることができます。
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は、メッセージが239.255.255.253である行政スコープSLPマルチキャストの[17]アドレスにマルチキャストされる要求します。マルチキャストに使用するデフォルトの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.
分離されたネットワークでは、ブロードキャスト、マルチキャストの代わりに動作します。そのために、SAをすべきであり、DASはポート427でブロードキャストサービスの場所のメッセージを受信しなければならないこれは、マルチキャストに分離されたネットワーク上のサービスの場所の使用をサポートしていないのUAができます。
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ディスカバリの範囲を制限し、ネットワーク内のサービス情報を局在化します。
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を実装する必要性を回避するために、1のことを保証しなければなりません：
- 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.
- UAはパスMTUよりも大きな要求を発行することはありません。彼らはパスMTUよりも長いユニキャスト要求を受信する必要はありません場合にのみ、SAはTCPのサポートを省略することができます。
- UAs can accept replies with the 'OVERFLOW' flag set, and make use of the first result included, or reformulate the request.
- UAは「OVERFLOW」フラグを設定して返信を受け入れ、そして含まれる第1の結果を利用すること、または要求を再定式化することができます。
- 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).
DAがマルチキャストDAディスカバリーSrvRqstsとしてだけでなく、UDPとTCPの要求に応えることができなければなりません。 SAは、要求を受信したり（例えば、いくつかの組み込みシステム）のサイズでデータグラムを超える応答を送信決してない限り、SAはTCPに応答できなければなりません。
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.
開始エージェントは、TCP接続を閉じる必要があります。 DAは、アイドル状態の接続を閉じる前に、少なくともCONFIG_CLOSE_CONN秒を待たなければなりません。 DASおよびSAは、開始剤としては、それを閉じるために怠った場合でも、堅牢な動作を保証するために、CONFIG_CLOSE_CONN秒後にアイドル状態のTCP接続を閉じる必要があります。ルールのタイミングについては、セクション13を参照してください。
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待機期間後に発生します。再送は、指数関数的に増加する待機間隔（待機たび倍加）を用いて行わなければなりません。これは、ユニキャストだけでなく、マルチキャスト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.'
結果が得られるまで、マルチキャスト要求はCONFIG_MC_MAX秒かけて再発行されるべきです。 UAは、彼らは彼らの要求と一致する最初の回答を得るまでだけ待つ必要があります。要求エージェントは、代わりに「最初の応答」を使用するように調製される場合には、再送が要求されない「で区切られた時間内にできるだけ多くの応答を」。
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.
<PRList>はそれ以上応答が誘発されないことになり、または前の応答者のリストまで、メッセージが再送されるべきであると要求は、単一のデータグラムに、またはCONFIG_MC_MAX秒が経過するまで適合しません。
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 duplicate XIDs in requests if UAs restart frequently.
要求を再送信するUAは、同じXIDを使用します。これは、DAやSAは、元の要求への応答をキャッシュして、再びそれを送信することができ、重複した要求が到着しなければなりません。このキャッシュされた情報は、ごく簡単に保持してください。 XIDは、ランダムにUAが頻繁に再起動する場合はリクエストに重複XIDを避けるように選択する必要があります。
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.
エスケープ文字はバックスラッシュ（UTF-8コードに5C）は、エスケープ文字の2つの16進数字が続きます。唯一の予約文字がエスケープされます。例えば、コンマ（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.
SLP順序と等価の文字列比較は、（ASCII文字コードに対応する）UTF-8の0x00-0x7Fのサブレンジ内の大文字と小文字を区別しなければなりません。ケース非感受性は、全体UTF-8でエンコードされたUnicode [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.
ケース非感受性のルールは、スコープの文字列、SLP SPI文字列、サービスの種類、クエリの処理にタグや属性値、言語タグ、前回の応答者のリストを含むSLPv2の中のすべての文字列マッチングに適用されます。 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）は、文字列比較のために、単一の空白文字に折り畳まれています。前後の文字列値を以下のホワイトスペースは、文字列の比較のために無視されます。たとえば、 "いくつかの文字列は" "SOME 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.
予約文字 `*」は前、後または部分一致を示すために、文字列値の内部にあってもよいです。この文字を含むクエリでは、ワイルドカードを使っていない文字に準拠する任意の文字列にマッチします。
Scope Lists in SLPv2 have the following grammar:
SLPv2の中にスコープリストは、次の文法を持っています：
scope-list = scope-val / scope-val `,' scope-list scope-val = 1*safe safe = ; Any character except reserved. reserved = `(' / `)' / `,' / `\' / `!' / `<' / `=' / `>' / `~' / CTL / `;' / `*' / `+' escape-val = `\' HEXDIG HEXDIG
スコープリスト=スコープ・ヴァル/スコープ・ヴァル `」スコープリストスコープ-VAL = 1 *安全な安全な=。予約された以外の任意の文字。予約= `（ '/'）'/`、 '/ `\'/`！」 / `< '/` =' / '> '/ `〜'/ CTL /`;」 / `* '/` +' エスケープ・ヴァル= `\」HEXDIG HEXDIG
Scopes which include any reserved characters must replace the escaped character with the escaped-val format.
すべての予約文字が含まれるスコープは、エスケープ・ヴァル・フォーマットでエスケープ文字を置き換える必要があります。
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応答メッセージでエラーコードがゼロでない場合は、メッセージの残りの部分は切り捨てられる可能性があります。データは必ず送信されないか、おそらくはセクション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.
LANGUAGE_NOT_SUPPORTED = 1：AttrRqstまたはSrvRqst内のスコープでサービスタイプのデータはなく、要求された言語では、あります。 PARSE_ERROR = 2：メッセージがSLP構文に従うことができません。 = 3 INVALID_REGISTRATIONは： - 例えば、ゼロ寿命又は省略言語タグのSrvRegは問題があります。 SCOPE_NOT_SUPPORTED = 4：SLPメッセージは、SAまたはDAによってサポートその<範囲リスト>にスコープが含まれていませんでした。 AUTHENTICATION_UNKNOWN = 5：DAまたはSAがサポートされていないSLP SPIに対する要求を受信します。 AUTHENTICATION_ABSENT = 6：DA期待URLとATTRのSrvRegで認証し、それを受信しませんでした。 AUTHENTICATION_FAILED = 7：DAは認証ブロック内の認証エラーを検出しました。 VER_NOT_SUPPORTED = 9：メッセージヘッダ内のサポートされていないバージョン番号。 INTERNAL_ERROR = 10：DA（またはSA）が対応するには余りにも病気です。 = 11 DA_BUSY_NOW：UAまたはSAは、バックオフ指数用いて、再試行すべきです。 OPTION_NOT_UNDERSTOOD = 12：DA（またはSA）は（セクション9.1を参照）を必須の範囲から未知のオプションを受信しました。 INVALID_UPDATE = 13：DAは、未登録のサービスのために、または一貫性のないサービスの種類と、FRESHセットなしのSrvRegを受けました。 = 14 MSG_NOT_SUPPORTEDは：SAはAttrRqstまたはSrvTypeRqstを受信し、それをサポートしていません。 REFRESH_REJECTED = 15：SAはDAの分リフレッシュ間隔よりも頻繁にDAへのSrvRegまたは部分的SrvDeregを送りました。
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メッセージのすべての長さフィールドは、ネットワークバイト順です。 「タプル」が定義されている場合、これらはネットワークバイト順に、記載された正確な順序でバイトの配列です。
SLP messages all begin with the following header:
SLPメッセージはすべて、以下のヘッダで始まります。
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 \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
サービス要求SrvRqst 1つのサービス応答SrvRply 2サービス登録のSrvReg 3サービス登録解除SrvDeReg 4サービス了承SrvAck 5項目要求AttrRqst 6属性AttrRply 7 DA広告DAAdvert 8サービス種別要求SrvTypeRqst 9サービスタイプ応答SrvTypeRply 10 SA広告SAAdvert 11返信
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およびUAはSrvRqst、SrvRplyとDAAdvertをサポートしなければなりません。 SAはまたのSrvReg、SAAdvertとSrvAckをサポートしなければなりません。 UAとSAのために、他のメッセージのサポートはオプションです。
- 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（0x80の）が設定されています。 FRESH（0x40の）は、すべての新しいのSrvRegに設定されています。要求をマルチキャストまたはブロードキャストしたときのREQUEST MCAST（0x20の）が設定されています。予約ビットは0でなければなりません - 拡張機能が使用されない限り、次に拡張オフセットが0に設定されています。最初の拡張は、メッセージの最初から、「オフセット」バイトから始まります。これは、SLPメッセージデータの後に置かれています。認識されていないSLP Extensionsを解釈する方法については、セクション9.1を参照してください。 - XIDは、それぞれのユニークな要求に一意の値に設定されています。要求が再送されている場合は、同じXIDが使用されています。回答は、要求の中のxidと同じ値にXIDを設定します。唯一の迷惑DAAdvertsが0のXIDで送信されます - ラングタグの長さは、言語タグ・フィールドのバイト単位の長さです。 - 言語タグは、[7]に従います。返信に言語タグは、要求の中言語タグと同じでなければなりません。このフィールドは、1 * 8ALPHAの*（ " - " 1 * 8ALPHA）をエンコードする必要があります。
If an option is specified, and not included in the message, the receiver MUST respond with a PARSE_ERROR.
オプションが指定され、メッセージに含まれていない場合、受信機はPARSE_ERRORで応じなければなりません。
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 \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
SrvRqstにマッチするサービスのためには、それは、少なくとも一つの要求された範囲に属する要求されたサービスの種類をサポートし、述語と一致する必要があります。述語が存在する場合、要求（言語タグの方言の一部を無視する）の言語は、宣言されたサービスと一致する必要があります。
<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>前のレスポンダ一覧です。この<文字列リスト>は、ドット十進表記のIP（V4）のアドレスが含まれており、すべての可能な結果を得るために反復的にマルチキャストである（6.3節を参照してください）。 UAはこの発見アルゴリズムを実装する必要があります。 SAは、彼らはすでにいくつかの他の手段でDAアドレスが設定されていない場合は、その範囲内のすべての利用可能な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>等しいそのインタフェースのいずれかの項目のいずれか。 <PRList>の残りの部分は正常に処理され、エラーが返されていません：IPv4のに準拠していません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.
リクエストがパスMTUを超えて<PRList>いったんプラス、マルチキャスト収束が停止します。このアルゴリズムは、すべてのインスタンスを検索するものではありません。それは有用な結果を提供するために、「十分」を検索します。
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
<スコープ一覧>構成されたスコープ名の<文字列リスト>です。このリスト内のスコープのいずれかで構成されているのSAおよびDASが応答します。 DASおよびSAが持つユニキャスト要求に応答しなければなりません
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.
<スコープリスト>を省略またはそれらがサポートする範囲を含めるに失敗した場合SCOPE_NOT_SUPPORTEDエラーが（セクション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.
<サービス型>文字列がSrvRqstはSrvRplyを誘発、セクション4通常で議論されています。 2つの例外があります。<サービスタイプ>場合に設定されている：（。セクション8.5を参照）DASはDAAdvertでSrvRqstに応え、「サービスディレクトリエージェント」「サービス：サービス・エージェント」に設定する場合は、SASの応答SAAdvertで（8.6節を参照してください。）このフィールドが省略された場合、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]です。このフィールドはオプションです。サービスには、種類や範囲によって簡単に発見することができます。そうでなければ、サービスは<述語>を満たすが発見されています。存在する場合、それは、各登録されたサービスと比較されます。フィルタ内の属性が複数の値で登録されている場合、フィルタは、各値と比較され、その結果が、一緒に論理和、すなわち、「（X = 3）」（x = 1,2,3）の登録と一致しています。 "（！（Y = 0））" マッチ（Y = 0,1）Yは非ゼロとすることができるからです。マッチングは大文字と小文字を区別しないことに注意してください。キーワードは（すなわち、値なし属性）「（キーワード= *）」のように、「プレゼンス」フィルタと一致しています。
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 = TRUE'、等一方 "（Y = FOO）" 'をyはFOOを=' 一致します。 "（|（X = 33）（Y = FOO））" にもかかわらず、満足される "（X = 33）" ための `、満足できません|」 （ブール論理和）。
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が返されます。ワイルドカードを含む要求条件は文字列であると解釈されます。即ち、（X = 34 *）最初の値ので、「X = 3432」「X = 34foo」と一致するが、ない第二の値が整数である文字列です。文字列は整数と一致していません。
Examples of Predicates follow. <t> indicates the service type of the SrvRqst, <s> gives the <scope-list> and <p> is the predicate string.
述語の例を以下に示します。 <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> =サービス：HTTP <S> = DEFAULT <P> =（空の文字列）これは、最小限のリクエスト文字列です。これは、デフォルトのスコープでアドバタイズされたすべての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、DEFAULT <P> =（ユーザー= wump）これは、ユーザー `wump」にメールを果たす販売やDEFAULTスコープで利用可能なすべてのPOP3サービスの要求です。
<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> = BLDG 32 <P> =（＆（Q <= 3）（速度> = 1000））、これは3よりキュー長以下、より速度大きくを有するバックアップサービスを返します1000それだけでBLDG 32スコープに登録されたサービスのためにこれを返します。
<t>=service:directory-agent <s>=DEFAULT <p>= This returns DAAdverts for all DAs in the DEFAULT scope.
<T> =サービス：ディレクトリエージェント<S> = DEFAULT <P> =これはデフォルトのスコープ内のすべての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.
DAには「：ディレクトリエージェントサービス」に設定されたサービスの種類とSrvRqstを送信することで発見されています。述語がSrvRqstに含まれている場合、DAは、述語はDAの属性に満足することができた場合にのみ応答する必要があります。 <範囲リスト> DAを発見された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を示しています。この文字列が省略された場合、応答者は、その応答内の任意の認証ブロックが含まれていません。それが含まれている場合、応答者はSrvRqstにSLP SPIに関連付けられた認証ブロックを有する応答を返さなければなりません。 SLP SPIがサポートされていないため、応答が返されないかもしれない場合、レスポンダはAUTHENTICATION_UNKNOWNエラーを返します。
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> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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).
サービス応答は、（4.3節を参照）は0個以上のURLエントリが含まれています。一致する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は、単にリストの最初のURLエントリを使用するかもしれません。 URLの認証ブロックが存在しない限り、SLPによって得られたURLは、生涯秒よりも長くキャッシュされない場合があります。
In that case, the cache lifetime is indicated by the Timestamp in the URL Authenticator (see Section 9.2).
その場合には、キャッシュの有効期間は、URL認証のタイムスタンプ（セクション9.2を参照）で示されています。
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のエントリで返されます。何SLP SPIがリクエストに含まれていなかった場合、認証ブロックは、応答で返されます。 URL認証ブロックは、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エントリが含まれてはいけません。
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...\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
<entry>はURL入力（4.3節を参照）です。寿命は、DAが登録をキャッシュできる時間を定義します。 SAは、この寿命が切れる前に再登録（しかしべきではない、より多くの場合、1秒に1回以上）すべきです。寿命が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のサービスタイプを定義します。 <スコープ・リスト> DAは、それがサポートに登録されたSAに設定されたすべてのスコープの名前を含まなければなりません。 <スコープ・リスト>のデフォルト値は「DEFAULT」（セクション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 the same scopes the service was initially registered in.
SAは、すべてのDAと一貫登録する必要があります。 SAは、スコープのXとYで構成され、そのスコープそれぞれ「X」、「Y」と「X、Y」の3つのDASは、存在する場合、SAは、それぞれのスコープ内のすべての3つのDAに登録します。サービスのすべての将来のアップデートと登録解除は、同じスコープで、DAが同じセットに送信されなければならないサービスは、最初に登録されました。
The <attr-list>, if present, specifies the attributes and values to be associated with the URL by the DA (see Section 5).
<ATTR-リスト>、存在する場合、（5節を参照）DAによってURLに関連付けられて属性と値を指定します。
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のそれぞれに署名し、それを使用するように設定された各キーを使用してリストを表示しなければなりませんサービス登録に署名する能力を持つように構成し、それはに登録されたDAを受け付けます。 （SAは、セクション8.5で説明したように、それは、DAのSLP SPIリストと属性を取得するために登録されるすべてのDAについてDAAdvertsを取得する必要があります）。 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.
以前に登録されたサービスのその後の登録は、以前のものとしてSLPのSPIの同じリストを含まなければならないか、他DAが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を参照）です。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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を返します。これは、（セクション7を参照）のみ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 = 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) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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がマルチキャストの場合にエラーコードが0に設定されています。 DAAdvertがユニキャストSrvRqstに起因して戻されている場合（すなわち、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ステートレスブートタイムスタンプは、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はDAAdvertでその属性のリストを含むことができます。 DAAdvertがマルチキャストするために、データグラムに適合しなければならないとして、このリストは、短くしてください。
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.
SAが低すぎる生涯を選択した場合、潜在的なスケーリング問題がSLPv2の中で起こります。より多くのサービスが展開されているように、この場合には、再登録の有償量が発生します。 SLPv2のは、DASは、登録のSAの周波数を制御することができます。 DAは、SAの再登録動作を変更するために、いつでも属性の新しいセットで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 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.
DAAdvertは「分リフレッシュ間隔」属性が含まれている場合、それは秒数を示す単一の整数値に設定しなければなりません。この属性が存在する場合のSAは、この値よりも頻繁に任意の特定のサービスの広告をリフレッシュしてはなりません。 SrvRegは、特定のサービスを更新し、空でないタグリストを設定したり、SrvDeregないFRESH FLAGとDAの広告を出して「分リフレッシュ間隔」の値よりも頻繁に受信している場合はDAがメッセージを拒否すべきである属性とREFRESH_REJECTED戻りますSrvAckでエラーが発生しました。
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.
<ADDR> <addrの>は、DAのドット付き10進数のアドレスであるDAのURLは、「：：ディレクトリエージェント//サービス」です。 <スコープ・リスト> DAのヌルにはできません。
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リストは、DAが検証可能であることのSPIの一覧です。 SAは、リストにないものをSLP SPIのための認証ブロックでサービスを登録してはなりません。 DAがAUTHENTICATION_UNKNOWNエラーを返す、彼らは確認できないサービス登録を拒否します。
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は、認証ブロックに含まれています。 DAAdvertsがマルチキャストされているとき、彼らは複数のDAAdvert認証ブロックを送信する必要があります。 DAは、複数のSPIのための署名を生成することができるように構成されている場合、DAは、各SPIのための1つの認証ブロックを含まなければなりません。これらすべての認証ブロックが（マルチキャストまたはブロードキャストに）単一のデータグラムに収まらない場合はDAが送信されている生成することが可能である認証ブロックしているすべてのSPIのためのように、DAは、個別の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.
DAAdvertがSrvRqstに応答して送信されている場合、DAはそのSLP SPIを使用してデジタル署名を生成することができるように構成されている場合、DAAdvertは、SrvRqstにSLP SPIを持つ唯一の認証ブロックを含みます。 SrvRqstがDAにユニキャストである（ヘッダにおけるREQUEST MCASTフラグがセットされていない）と、サポートされていないSLP SPIが含まれている場合、DAはAUTHENTICATION_UNKNOWNエラーに設定されたエラーコードでDAAdvertで応答します。
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.
UAは彼らがDA広告を確認することができますSLPののSPIを設定する必要があります。 UAはSLPのSPIで構成し、それらのいずれかを使用して検証することに失敗したDAAdvertを受信した場合、UAはそれを捨てなければなりません。
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 except performance.
彼らは、<スコープ・リスト>で構成されている場合や、DASが発見された場合、彼らは、特定のDAを使用するように設定されている場合、ユーザーエージェントは、SA広告を勧誘してはなりません。これらは明示的にそのSAのサポートスコープを発見するために、ユーザーが選択範囲を（11.2節を参照）を使用するように設定されている場合にのみ、UAはSA広告を勧誘します。これは、スコープの設定のないUAは、パフォーマンス以外の任意の機能的な違いなしたDAまたはSASのどちらかを利用することができます。
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は属性で構成することができ、その値はSAによって表されるサービスのすべてのサービスタイプである属性「サービス型」をサポートすべきです。 SrvRqst述語が満たされない場合はSAは応じてはいけません。たとえば、唯一のSAは、「NFS」のサービスは、サービスタイプのSrvRqstにSAAdvertで応答する必要があります提供する「サービス：サービス・エージェント」述語「（サービス型= 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) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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を超えないように、この属性リストは短くしてください。
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.
<ADDR> <addrの>は、SAのドット付き10進数のアドレスであるSA、のURLは、「：：サービス・エージェント//サービス」です。 <スコープ・リスト> SAのヌルにはできません。
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は、認証のためにブロックを生成することができ、各SLP SPI SAのための1つSAAdvert認証ブロックを含みます。 UAがSAAdvertの認証ブロックを確認することができ、かつSAAdvertを検証することに失敗した場合、UAはそれを捨てなければなりません。
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のスケーラビリティのためのものです。
The format of a Service Location Extension is:
サービスロケーション拡張の形式は次のとおりです。
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 \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
0x0000-0x3FFF標準化されました。実装するオプション。認識されていない場合は無視します。 0x4000-0x7FFF標準化されました。実装が必須。応答では、このオプションを受け取り、それは静かにReplyを捨てなければなりません理解していないUAまたはSA。リクエストでは、このオプションを受け取り、それがOPTION_NOT_UNDERSTOODエラーを返さなければなら理解していないDAまたはSA。私的使用のため0x8000-0x8FFF（標準化されていません）。実装するオプション。認識されていない場合は無視します。 0x9000-0xFFFF予約。
The three byte offset to next extension indicates the position of the next extension as offset from the beginning of the SLP message.
SLPメッセージの先頭からのオフセットとして、次の拡張子にオフセット3つのバイトは、次の拡張機能の位置を示しています。
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メッセージの全体の長さを減算することによって決定されます。
Extensions defined in this document are in Section D. See section 15 for procedures that are required when specifying new SLP extensions.
この文書で定義された拡張機能は、新しいSLP拡張子を指定するときに必要な手順については、セクションD.参照部15です。
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 ... \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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メッセージで戻され、そして認可エージェントによって送信されてきました。認証データ（構造化認証ブロック内に含まれる）は、典型的には、大文字と小文字が区別されます。 SLP登録データ（例えば、属性値）は、典型的には、大文字と小文字を区別しませんされていても、登録データの場合は、UAがデジタル署名データを計算するために使用されるデータを検証することができるであろうように、登録DAによって保存されなければなりません。
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.
ブロック構造記述子（BSD）は、以下の認証の形式を識別する。 BSD系0x0000-0x7FFFはIANAによって維持されます。 BSD系0x8000-0x8FFFは、私的使用のためのものです。
The Authentication Block Length is the length of the entire block, starting with the BSD.
認証ブロック長がBSDから始まる、ブロック全体の長さです。
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.
タイムスタンプは、認証の有効期限が切れた時点で（リプレイ攻撃を防ぐために。）タイムスタンプ場合、デジタルの妥当性1970年1月1日のSAに0hに相対秒の32ビットの符号なしの固定小数点数を示すためにこの値を使用しています署名は有効期限が切れます。タイムスタンプの値は、タイムスタンプがリセットさに対する相対時刻をラップしたら、このタイムスタンプは、今年2106に0に戻ってラップします。例えば、06h28と16秒2106年2月5日後に、すべてのタイムスタンプ値は、エポック日からの相対になります。
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.
SLPセキュリティパラメータインデックス（SPI）文字列が構造化認証ブロック内の署名データを検証するためにエージェントによって使用されるキーの長さ、アルゴリズムパラメータとキーイング材料を識別する。 SLP SPIストリングは、セクション6.4.1で定義された<範囲-VAL>と同じ文法を有しています。
Reserved characters in SLP SPI strings must be escaped using the same convention as used throughout SLPv2.
SLP SPI文字列での予約文字がSLPv2の全体で使用されるのと同じ規則を使用してエスケープする必要があります。
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のSPIは一意でなければなりません。 SLP SPIは、BSDのために使用さ= 0×0002は、他のいくつかの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 = 0×0002）。 SAはDSA認証ブロックでサービスを登録する必要があり、彼らは他のアルゴリズムを使用して他の認証ブロックとそれらを登録しても良いです。 SAは迷惑DAAdvertsでDSA認証ブロックを使用しなければならないSrvDeRegメッセージおよびDASでDSA認証ブロックを使用しなければなりません。
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ストリング、SLP SPI文字列のURL 16ビットの長さ。 URL、URL、32ビットのタイムスタンプの16ビット長。
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ストリング、SLP SPIストリング、<ATTRリスト>の16ビット長の一覧16ビット長の属性、<ATTRリスト>、32ビットのタイムスタンプ。
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.
SLP SPIストリング、SLP SPIストリング、32ビットDAステートレスブートタイムスタンプ、URLの16ビット長、URL、<ATTRリスト>、<ATTRリスト>の16ビット長のDAAdvert 16ビット長、16ビットDAの<スコープリスト>のビット長、DAの<スコープリスト>、DAの<SLP SPIリスト>、DAの<SLP SPIリスト>、32ビットのタイムスタンプの16ビットの長さ。
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.
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.
SLP SPIストリング、SLP SPIストリング、URLの16ビット長、URL、<ATTRリスト>の16ビット長のSAAdvert 16ビット長、<ATTRリスト>の、16ビット長<範囲リスト> <範囲リスト>、32ビットのタイムスタンプ。
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 = 0×0002は、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 }
i.e., the ASN.1 encoding of 1.2.840.10040.4.3 followed immediately by:
即ち、1.2.840.10040.4.3のASN.1符号化が直ちに続きます。
Dss-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
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のバイナリ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 = 0×0002の認証ブロックは次の形式を持っています。将来的には、BSDのは、異なるフォーマットを有する割り当てられてもよいです。
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 \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
新規登録者の属性は、以前の登録者を置き換えるが、以前に含まれており、更新には存在しないし、属性には影響を与えません。
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に登録されています。 X：インクリメンタル登録サービスに来る場合//a.org属性C = 30、D = 40とし、更新後のサービスの属性が= 40、B = 2、C = 30、D A = 1であります。
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.
インクリメンタル登録が認証ブロックに登録されたサービスのために行ってはなりません。これらのSrvRegヘッダーセットにおけるFRESHフラグで、すべての属性に登録されなければなりません。そのような登録メッセージを受信DAが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は、更新メッセージに同じ<範囲リスト>を使用しなければなりません。これを行わない場合、DAはSCOPE_NOT_SUPPORTEDエラーを返します。サービス広告の範囲を変更するためには、まず登録を抹消しなければならないし、新しい<スコープ・リスト>で再登録します。
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.
同じURLの事前登録で使用したようにSAは、更新メッセージに同じ<サービスタイプ>を使用しなければなりません。これを行わない場合、DAはINVALID_UPDATEエラーを返します。
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).
= [初期]タグフィルター=シンプルタグ/サブストリングの単純なタグ= 1 * FILT-チャーストリングは任意[最終]初期= 1 *のFILT-char型任意= '* '*（FILT-CHAR '*'）の最終= 1 * FILT-char型のFILT-CHAR =任意の文字<予約>を除くと、<悪いタグ>（第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」、「ボビー」と「ボブ」。
The additional requests provide features for user interaction and for efficient updating of service advertisements with dynamic attributes.
追加の要求は、ユーザーとの対話のためにと動的属性を持つサービス広告の効率的な更新のための機能を提供します。
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.
サービスタイプ要求（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 \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
命名権限文字列は、リクエストに存在する場合には、指定された命名権限を持つサービスタイプ文字列への応答を制限します。命名権限文字列が存在しない場合は、IANA登録されたサービスの種類が返されます。命名庁の長さが0xFFFFのに設定されている場合は、命名権限文字列が省略され、すべてのサービスタイプにかかわらず、当局の命名の、返されます。
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> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The service-type Strings (as described in Section 4.1) are provided in <srvtype-list>, which is a <string-list>.
サービスタイプ文字列は（セクション4.1を参照）<文字列リスト>は<srvtypeリスト>に設けられています。
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以外の命名権限を持っている場合は、サービスタイプ文字列とA `以下返されなければなりません。」キャラクター。 IANAの命名権限を持つサービスの種類は、命名機関の文字列が含まれていません。
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.
属性要求（AttrRqst）UAは、（そのURLを供給することにより）特定のサービスまたはサービス全体のタイプの属性を発見することを可能にします。後者の特徴は、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 \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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フィールドには、二つの形式を取ることができます。それは単に、このような「HTTP」または「：TFTPサービス」として、サービスの種類（4.1節を参照）することができます。この場合、特定のサービスタイプのすべてのサービスの各属性のすべての属性と値の全範囲が返されます。
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.
"：プリンタ：LPR：//igore.wco.ftp.com：515 /ドラフトサービス" または "NFS：//max.net/znoo" URLフィールドには、代わりのような完全な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リストの文字列が含まれている属性は、そうでない場合はDAがAUTHENTICATION_FAILEDエラーで応答するとき、完全な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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = AttrRply = 7) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | length of <attr-list> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| <attr-list> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|# of AttrAuths | Attribute Authentication Block (if present) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the <attr-list> and the Authentication Block is as specified for SrvReg (see Section 9.2.1).
<ATTRリスト>の形式と認証ブロック（セクション9.2.1を参照）のSrvRegに指定された通りです。
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.
彼らは、人間が読める形式である可能性が高いとの回答は、文字列の登録のオリジナルケースそのままに返されるべきである属性。 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)".
のみ各属性タグまたは文字列値の一つのコピーを任意に（大文字と小文字と文字列への内部ホワイトスペースに対して）のバージョンを選択し、返すべき：重複属性と値が除去されるべきです。文字列値とタグ名の任意のバージョンでは、マージのために選択されています。例えば： "（Aは、A = B）" "（= A、B）" を生じることができる "（= A A、B）" と合併。
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/draft。タグ= ENは=（名= Igore）、（説明=開発者だけの場合）、（プロトコル= LPR）、（場所-説明= 12階）、（演算子=ジェームズDornan \ 3cdornanモンスター\ 3eと@）、（する、メディア属性サイズ=文字NA）、（解像度= RES-600）、X OK
URL = service:printer:lpr://igore.wco.ftp.com/draft scope-list = Development
URL =サービス：プリンタ：LPR：//igore.wco.ftp.com/draftスコープリスト=開発
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
ロング。デイ=デ属性=（名= Igore）（開発者だけのための説明=）、（プロトコル= LPR）、（場所-説明= 13階）、（演算子=ジェームズDornan \ 3cdornanモンスター\ 3eと@）、（する、メディアサイズ=文字NA）、（解像度= RES-600）、X OK
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スコープリスト=開発ラング。タグ= ENは、=（名=未）、（説明=実験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」英語とドイツ語の両方で登録されています。彼らは値のために文字を予約されているオペレータで、 `<「と`>」の文字は、エスケープされなければならなかった電子メールアドレスの一部である属性値。
Attribute tags are not translated, though attribute values may be, see [13].
属性値がかもしれないが、タグが翻訳されていない属性、[13]を参照してください。
The attribute 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/draft。タグ=デタグリスト=解像度、LOC *
receives the Attribute Reply:
属性の返信を受信します。
(location-description=13te Etage),(resolution=res-600)
（位置記述= 13teエタージュ）、（解像度= RES-600）
The attribute Request:
属性要求：
URL = service:printer scope-list = Development Lang. Tag = en tag-list = x-*,resolution,protocol
URL =サービス：プリンタスコープリスト=開発ラング。タグ=タグリストアン= X - *、解像度、プロトコル
receives an Attribute Reply containing:
含む属性返信を受信します。
(protocols=http,LPR),(resolution=res-600,other),x-OK,x-BUSY
（プロトコルは= HTTP、LPR）、（解像度=のRES-600は、他）であり、X-OK、-X BUSY
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」の両方の値を返します。
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.
AttrRqstでSLP SPIと認証ブロックを返すことができる場合には、属性認証ブロックが返されます。認証確認の計算が可能であるためには、SAによって登録された認証ブロックとDAから返さする<ATTRリスト>と同一でなければならない<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は専用の属性認証ブロックを返します。
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はSPIは、AUTHENTICATION_UNKNOWNエラーが返されることSLPと認証ブロックを返すことができません。認証ブロックは、以下の場合に全く認証ブロックが含まれていない、または1であった場合のAttr AUTHSフィールドの＃が0に設定されています。
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.
その寿命が期限切れになったときにDAがサービス登録を削除します。彼らはもはや利用可能な場合、サービスではなくタイムアウトに登録を残すよりも、登録解除すべきではありません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = SrvDeReg = 4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of <scope-list> | <scope-list> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| URL Entry \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of <tag-list> | <tag-list> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
SAはDAからの応答がない場合は、12.3節を参照再試行しなければなりません。 DAはSrvAckとSrvDeRegを認めています。 SAが成功を示す肯定応答を受信すると、サービスおよび/または属性は、もはやDAによってアドバタイズされません。 DAは、それが以前に登録されたSrvDeRegで指定されたすべての範囲からサービスまたはサービスの属性の登録を解除します。
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はDAでサービスを登録するために使用したのと同じスコープリストですべてのサービスを登録解除しなければなりません。これはSrvDeRegメッセージで行われていない場合、DAはSCOPE_NOT_SUPPORTEDエラーを返します。 URL入力での寿命フィールドはSrvDeRegの目的のために無視されます。
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はそれはに登録されているすべての言語でサービスを登録解除する。<タグリスト>が存在する場合、SrvDeRegは、そのタグが、タグの仕様に記載されている属性の登録を解除します。認証ブロックに登録されたサービスは、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のSPIのそれぞれのURL認証ブロックはSrvDeRegに含まれている必要があります。そうしないと、DAはAUTHENTICATION_ABSENTエラーを返します。メッセージはDAによって検証することに失敗した場合、AUTHENTICATION_FAILEDエラーがDAによって返されます。
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".
スコープは、サービスのセットです。スコープの主な用途は、サービスの管理グループを作成する機能を提供することです。サービスのセットは、ネットワーク管理者によって範囲を割り当てることができます。サービスを求めるクライアントは、1つまたは複数のスコープを使用するように設定されています。ユーザーは彼または彼女が使用するために構成されているそれらのサービスを発見するでしょう。スコープとUAとSAを設定することで、5月提供サービスを管理者。スコープの文字列は大文字と小文字を区別しません。デフォルトのSCOPE文字列は "DEFAULT" です。
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の展開をスケールするために有することを意味しています。デフォルト以外のスコープを持つDASはネットワーク上に存在する場合には、更なる利益は、事前定義されたデフォルト以外のスコープを持っているUAとSAを設定することにより得ることができます。これらのエージェントは、DA発見を実行し、その範囲を使用して要求を行うことができます。これは、応答の数を制限します。
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メッセージが廃棄され、または（要求がユニキャストである場合）SCOPE_NOT_SUPPORTEDエラーが返されます。すべて（DAとSAディスカバリ要求を除く）SrvRqst、のSrvReg、AttrRqst、SrvTypeRqst、DAAdvert、およびSAAdvertメッセージは、<スコープ・リスト>を含まなければなりません。
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メッセージをユニキャストしなければなりません。何DAは、使用するように構成されている範囲で利用可能でない場合、UAは要求をマルチキャストすることができます。
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あります。スコープの選択を行うために、ユーザーを有効にするために使用された場合、これらは、長さゼロの<スコープリスト>を持っているかもしれません。この場合、UAは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とUAがデフォルト以外のスコープを使用している場合はそれ以外の場合は、（すなわち、「DEFAULT」）、UAとSAは、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ゾーンまたはワークグループのユーザ選択を可能にする方法と同様です。
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つの設定の選択肢に互換性がないことに注意してください。一つのモデルでは、管理者がサービス提供を制御できます。 （そのシステムの任意の構成を行うために準備することはできません）ユーザーに他の代表者、この。
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.
DAをキャッシュサービスの場所と属性情報を。彼らは、SLPのパフォーマンスとスケーラビリティを向上させるために存在します。それらが同じSAの各店舗サービス情報できるので、複数のDAは、ケースのDA失敗のいずれかで、動作の更なる拡張性と堅牢性を提供します。
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のエージェントとのネットワークに有用です。 DAアドレスが動的、または静的構成を使用して、UAとSA使用してDHCPを使用して構成することができます。
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.
SAはSAが初期化されるとき、DAにSrvRqstをユニキャストしなければならないDHCPまたは静的な構成でDAを使用するように構成されています。 SrvRqstは、スコープのリストを省略し、「サービス：ディレクトリエージェント」への要求のサービスタイプを設定します。 DAは、その属性、SLP SPIリスト、およびDA通信に適切なSAに不可欠な他のパラメータと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 in the case of a failure of a SA.
SAによるのDAの受動的検出は、サービスが同じスコープのDAの間一貫してアドバタイズすることを可能にします。更新されない場合は、広告も、SAの障害が発生した場合には、DAの中で唯一の過渡古い登録を残し、有効期限が切れます。
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が多くのUAをサポートすることができます。 UAは、彼らがのSAに送信し、同じ結果を期待したDAに同じ要求を送信します。 DAが可能なSAの単純な実装を行うこと、のSAの負荷を軽減します。
UAs MUST be prepared for the possibility that the service information they obtain from DAs is stale.
UAは、彼らがDAをから取得サービス情報が古くなっている可能性のために準備しなければなりません。
When DAs are present, each SA MUST register its services with DAs that support one or more of its scope(s).
DASが存在する場合、各SAは、その範囲（S）の一つ以上をサポートするDAにそのサービスを登録しなければなりません。
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.
UAは、したがって、サービス情報を取得するために、マルチキャスト収束アルゴリズムを使用して回避すること、（スコープ規則が許す）DAに直接リクエストをユニキャストしなければなりません。これは、ネットワーク利用率を低下させ、UAがサービス情報を取得することができる速度を増加させます。
DAs MUST flush service advertisements once their lifetime expires or their URL Authentication Block "Timestamp" of expiration is past.
彼らの寿命が期限切れになるか期限切れの彼らのURL認証ブロック「タイムスタンプ」は過去になるとDAがサービス通知をフラッシュする必要があります。
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は認証ブロック（セクション9.2を参照）と同じ形式で、DAステートレスブートタイムスタンプを含まなければなりません。認証ブロック内のタイムスタンプが以前のすべての登録が失われた時間（すなわち、最後のステートレス再起動）を示しています。タイムスタンプは、DAが下がっていることをUAとSAを通知するDAAdvertに0に設定されています。彼らがダウンして行くと、サービス登録状態ずに再起動する場合はDAが、以前のものに等しいかまたは小さいブートタイムスタンプを使用してはなりません。これは、DAに再登録しないようにSAを誤解させるでしょう。
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.
サービスタイプ「サービス：ディレクトリエージェント」のためのマルチキャストSrvRqstを受けたDAは、<スコープリストは>（a）は省略されていない場合は静かにそれを捨てなければなりませんし、（b）は、彼らが使用するように設定されている範囲が含まれていません。それ以外の場合はDAはDAAdvertで応じなければなりません。
DAs MUST respond to AttrRqst and SrvTypeRqst messages (these are OPTIONAL only for SAs, not DAs.)
DAが（これらは、唯一のSA用のDASオプションではありません。）AttrRqstとSrvTypeRqstメッセージに応答しなければなりません
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.
UAは、78および79、またはセクション6.3で収束アルゴリズムを使用してサービス要求をマルチキャスト（またはブロードキャスト）することにより、静的な設定、DHCPオプションを使用してDAを発見することができます。
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に応じて、彼らはDAに再登録しなければならない回数を減らすことができる方法を説明します。
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.
DAがCONFIG_DA_BEATごとに一度迷惑DAAdvertsを送らなければなりません。迷惑DAAdvertは、セクション8.5で説明したように0 SAのXIDは、受動的に、DAAdvertsをリッスンしなければならない持っています。 UAはこれを行うことができます。彼らは迷惑DAAdvertsをリッスンしていない場合は、彼らが利用可能になると、しかし、彼らはDAを検出しません。 UAは、この場合には、第6章を参照してください、定期的な能動的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のスケーラビリティを向上させるタイミングアルゴリズムを提案します。
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発見要求は一様に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.
8.1節で説明したようにUAまたはSAは、SrvRqstを使用してDA検出要求を送信します。 DAディスカバリー要求は、前のレスポンダのリストを含まなければなりません。アクティブDA検出のためのSrvRqstsは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は、そのサービスを登録する前に0とCONFIG_REG_ACTIVE秒の間のランダムな時間を待たなければなりません。
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は迷惑DAAdvertごとCONFIG_DA_BEAT秒マルチキャスト（またはブロードキャスト）しなければなりません。 CONFIG_DA_BEATは、利用可能な帯域幅の1％以上を使用してからDAAdvertsを防止するために指定する必要があります。
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を受けるすべてのUAとSAは、そのDAステートレスブートタイムスタンプを調べる必要があります。それが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は、それに登録する必要があります。 DAは、それに登録SA最後以来ステートレスの再起動があった場合にはSAが決定するためにDAAdvertのタイムスタンプを調べる必要があります。もしそうなら、それはDAに登録されます。 SAはDAの登録を開始する前に、0とCONFIG_REG_PASSIVE間のランダムな間隔を待たなければなりません。
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へのマルチキャスト要求が使用されています。
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:
デフォルトでは、DAが「DEFAULT」の範囲で設定されています。管理者は、デフォルト以外のスコープでUAとSAをサポートするために、他の構成されたスコープを追加することもできます。デフォルトの設定ではない限り、DAから削除されてはなりません。
- There are other DAs which support the "DEFAULT" scope, or
- そこ「DEFAULT」スコープをサポートする他のDAがあり、または
- All UAs and SAs have been configured with non-default scopes.
- すべてのUAとSAは、デフォルト以外のスコープで構成されています。
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は、共存のDAによってサポートされていない任意のスコープでサービスを宣伝するべきではありません。これは、着信要求は、単一のデータストアで答えることができることを意味します。 SAとDA登録は別に保管する必要はありません。
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.
DAのは、サービス登録や属性リストに署名するように設定されていません。彼らは、単にサービスエージェントによって登録されたサービスをキャッシュします。 DAのは、それが、セクション8.5を参照してください、で構成されていないSLP SPIのための認証ブロックを含む登録を受け入れてはいけません。
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 SPIを使用した認証ブロックで作られています登録を保護します。サービスSが登録されている場合、（adertisementを置換する）後続の登録又は登録解除（それが削除されます）は、対応するSLP SPIによる認証ブロックを含まなければなりません、セクション8.3およびセクション10.6を参照してください。
Example:
例：
A DA is configured to be able to verify Authentication Blocks with SLP SPIs "X,Y", that is X and Y.
DAはSLPのSPI「X、Y」と認証ブロックを検証することができるように構成され、それが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」と認証ブロックにサービスを登録します。 DAは、登録を格納しますが、認証ブロックを破棄します。 UAはSLP SPI文字列「Z」でサービスを要求する場合、DAはAUTHENTICATION_UNKNOWNエラーで応答します。
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のSPI「X」と「Y」を含む認証ブロックとサービスSを登録します。 UAはSLP SPI文字列「X」でサービスを要求するとDAはSを返すことができるようになります（サービスタイプ、言語、スコープとSrvRqstマッチSの述語があれば）DAもSLP SPIによる認証ブロックを返します。 「X」に設定してください。 DAは、（それに取って代わるであろう）（広告を削除します）Sに対する後続SrvDeRegまたはSに対する後続のSrvRegを受信した場合、メッセージは2つのURL認証ブロック、SPIの「X」と「Y」の各項目毎に1つずつ含まれている必要があります。これらのいずれかが存在しなかった場合、DAはAUTHENTICATION_ABSENTエラーを返します。
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.
Broadcast Only
Any SLP agent SHOULD be configurable to use broadcast
only. See Sections 6.1 and 12.2.
Predefined DA A UA or SA SHOULD be configurable to use a predefined DA.
事前定義されたDA A UAまたはSAは、事前定義された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んが事前に定義されたとDHCP設定のDAを使用して、アクティブまたはパッシブ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エージェントが他の値を使用するように構成可能であるべきです。低い値は、応答の数を減少させる、より小さなサブネットワーク上のマルチキャスト収束アルゴリズムを集中し、サービスの場所の性能を向上させるであろう。これは、UAが、それらがネットワークに接続されている場所に応じて、同じ要求に対して異なる結果を得ることをもたらすことができます。
Timing Values Time values other than the default MAY be configurable. See Section 13.
タイミングが設定可能で、デフォルト以外の時間値を値。第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は、すべての定義済みスコープを省略することにより、ユーザーが選択範囲をサポートする構成可能です。 11.2節を参照してください。 UAまたはSAは、デフォルトでは、特定のスコープを使用して構成可能でなければなりません。さらに、UAまたはSAは、特定のサービスタイプのための要求と登録のための特定のスコープを使用して構成可能でなければなりません。 DAの範囲またはスコープは、構成可能でなければなりません。 DAのデフォルト値は、それ以外の場合は設定されていない場合はスコープ「DEFAULT」を持つことです。
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の設定DHCPオプション78および79は、SLPを設定するために使用することができます。 DA位置がDHCPを使用して構成されている場合、これらは、能動的又は受動的に発見されたDAに優先して使用されるべきです。 DHCPを使用して構成されたスコープの1つ以上は要求で使用されなければなりません。全体の構成<範囲リスト>は、登録及びDA設定メッセージで使用されなければなりません。
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.
サービステンプレートUAとSAはサービステンプレートを使用して構成してもよいです。属性値の仕様を簡素化するだけでなく、これはまた、彼らは「必要」SrvRqst、のSrvRegとSrvDeRegメッセージの属性を含めることを強制することができます。 DAのは、彼らがこれらのケースではUAとSAをWARNできるようにするために、テンプレートを用いて構成することができます。 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は、以下のパラメータを使用して、SLP SPIをサポートするように構成されるべきである。BSD = 2（DSAとSHA-1）及びSLP SPIストリングによって識別公開鍵。公開鍵インフラストラクチャが存在する場合将来的には、SLPエージェントはSLP SPI文字列で使用される名前に対応する公開鍵と暗号パラメータを取得することができるかもしれません。
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 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は、DASを発見するときに使用する、上記のようにSLP SPIをサポートするように構成すべきである（SHOULD）。このSPIは、DASを発見するためにSrvRqstsに送られるべきであるとマルチキャスト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.
デジタル署名を生成することができSAおよびDA秘密鍵のSAおよびDASは、認証ブロック内に含まれるように秘密鍵及び対応するSLP SPIのindentifierを必要とします。 SLP SPIは、認証ブロック内のデジタル署名を検証するために使用する公開鍵を識別する。
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]参照します）。
The Block Structure Descriptor (BSD) identifies the format of the Authenticator which follows. BSDs 0x8000-0x8FFF are for Private Use.
ブロック構造記述子（BSD）は、以下の認証の形式を識別する。 BSD系0x8000-0x8FFFは、私的使用のためです。
Further Block Structured Descriptor (BSD) values, from the range 0x0003-0x7FFF may be standardized in the future by submitting a document which describes:
さらにブロック構造記述子（BSD）値、範囲から0x0003-0x7FFFは説明文書を提出することによって、将来的に標準化されてもよいです。
- The data format of the Structured Authenticator block.
- 構造化認証子ブロックのデータフォーマット。
- 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.
- のUA、DASおよびSAを事前設定するために必要な鍵材料のフォーマット。また、鍵の配布に関するいかなる考慮事項が含まれます。
- 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の合意に基づいて暗号BSD番号が割り当てられます。
New function-IDs, in the range 12-255, may be standardized by the method of IETF Consensus.
新しい機能IDは、範囲12から255で、IETFコンセンサスの方法によって標準化されてもよいです。
New SLP Extensions with types in the range 2-65535 may be registered following review by a Designated Expert.
範囲2から65535内の型を持つ新しいSLP拡張機能は、指定の専門家による検討の次に登録することができます。
New error numbers in the range 15-65535 are assigned on the basis of a Standards Action.
範囲15-65535の新しいエラー番号は、標準のアクションに基づいて割り当てられます。
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].)
サービスロケーションプロトコルで使用されるプロトコル要素もIANA登録アクションが必要な場合があります。 URLとサービステンプレート[13]：SLPは、「サービス」に関連して使用されます。これらは、指定専門家のレビューとメーリングリストによって標準化されている（[13]を参照してください。）
SLP messages support the use of multiple languages by providing a Language Tag field in the common message header (see Section 8).
SLPメッセージ（セクション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'.
属性タグは変換されません。サービステンプレートは、[13]属性値が「リテラル」であると定義されない限り、属性値を変換することができます。
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の言語は、要求を満たすために使用されます。要求された言語がサポートされていない場合、LANGUAGE_NOT_SUPPORTEDエラーが返されます。 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は、同じサービスタイプのサービステンプレート[13]の翻訳を用いて構成することができます。これは、DAまたはSAがサービス広告の言語に（イタリア語で言う）の要求を翻訳することができます（英語で言う）、その後、イタリアに戻って返事を翻訳します。同様に、UAは、発信要求、着信応答を翻訳するためのテンプレートを使用するかもしれません。
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.
言語タグで方言フィールドが使用されることがあります。言語と方言を照合することによって満たすことができる要求は、言語のみの部分と一致するものに優先されます。それ以外の場合は、方言が一致する要求に影響を与えません。
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と属性の整合性についての知識とUAとDAを提供します。デジタル署名を生成することができる唯一のシステムは、予め管理者によって設定されているものです。署名されたデータを検証する薬剤は、管理者は、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.
サービスの場所は、機密性を提供しません。このプロトコルの目的は、ユーザーのコミュニティにサービスを宣伝することであるため、このプロトコルは非敏感な環境で使用する場合、機密性は一般的に必要とされない場合があります。専門のスキームは、将来的に必要に応じて、機密性を提供することができるかもしれません。機密性を必要とするサイトでは、[3]サービスロケーションメッセージの機密性を提供するために、IPカプセル化セキュリティペイロード（ESP）を実装する必要があります。
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.
エージェントが認証ブロックを生成するように構成されていないと、エージェントがそれらを検証するように構成されていない場合は、敵は簡単に敵によって制御サーバー上のサービスを宣伝することにより、ユーザーの個人情報へのアクセスを得るために、このプロトコルを使用する場合があります。さらに、このプロトコルを使用して敵はそれがはるかに簡単にサービス攻撃の選択的拒否に従事しています。 （例えば、インターネットに直接接続されている）、潜在的に敵対的な環境にあるサイトは、従来敏感ディレクトリエージェントまたはサービス・エージェントを展開するSLPのSPIに関連付けられたキーを配布することの利点を考慮すべきです。
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.
SLPは、ブートストラッププロトコルとして有用です。何の事前設定が可能ではありませんした環境で使用することができます。このような状況では、「盲信」の一定量が必要とされています。事前に設定を行わなくても、上記のセキュリティメカニズムのいずれかを使用することは不可能です。彼らが利用可能になるようSLPは、鍵配布のためにIETFのセキュリティエリアによって提供されるメカニズムを利用します。彼らはSLPを使用する前に、暗号化情報とSLPのSPIは、エンドシステムで事前に設定することができます場合は、この時点で、唯一の認証ブロックの使用に関連する利益を得ることが可能であろう。
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メッセージを拒否することができます。これが実現することが可能であるだけで政策ではありません。
A. Appendix: Changes to the Service Location Protocol from v1 to v2
A.付録：V1からV2にサービスロケーションプロトコルの変更
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広告のために）より多くの柔軟性と保護を提供するために書き直されました。 SLPv2のは、多くのフラグと値のフォーマットと定義を変更し、数削減「必要な機能を。」 SLPv2のは明確にし、「対象範囲外のディレクトリ・エージェント」と「スコープを持たない要求」のサポートを排除し、「スコープ」の使用を変更します。 SLPv2のは属性と検索フィルタのLDAPv3の互換性のある文字列のエンコーディングを使用しています。 （そのような言語と文字セットの取り扱いなど）その他の変更は、インターネットエンジニアリング運営グループが推奨するプラクティスを採用します。
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）が追加されました。これは、UAが管理構成とDAが存在しない場合にスコープ情報を発見することができます。これは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が存在する場合、プロトコルのバージョンのいずれかを使用したSAによって通知サービスはSLPv1のとSLPv2のUAsの両方に利用可能であろう。 SLPv1のDAが段階的に廃止とプロトコルの両方のバージョンをサポートSLPv2のDAに置き換えるべきである（SHOULD）。
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のサービスは適用範囲なしで宣伝して要求することができます。さらに、DAを、スコープなしで構成することができます。これはSLPv2のと互換性がないとスケーラビリティの問題を提起します。この前方の移行を容易にするために、SLPv1のエージェントはすべての登録や要求のためのスコープを使用しなければなりません。 SLPv1のDAがスコープのリストを設定する必要があります。これは、RFC 2165 [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.
サービスエージェントは、属性なしでサービスを宣伝します。これは、タイプによって、サービスの唯一の発見を可能にします。サービスタイプは、サービステンプレート[13]を持つことになります。この方法は属性がサービス広告に関連付けされていないことを明示的に指定する定義されて発見されました。属性を指定するサービステンプレートに関連付けられているサービスの種類は、属性をサポートしていないのSAによってアドバタイズしてはなりません。
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 application layer protocols - all that is required is the basic discovery of services that support a certain service.
サービスタイプによるサービスの発見はSLPv2のを使用して可能な機能のサブセットですが発見のこの形式は、タイプ別の「ゾーン」や「ワークグループ」のすべてのサービスを簡単に閲覧できるように製品の現在の世代と一致しています。いくつかのケースでは、属性の検出、セキュリティと機能のネゴシエーションは、アプリケーション層のプロトコルで処理される - 要求されるすべては、特定のサービスをサポートするサービスの基本的な発見です。
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.
そのサービスタイプのサービスのみを要求するUAは唯一のサービスリクエストのサービスタイプと範囲フィールドをサポートする必要があります。彼らはそれらをマルチキャストするのではなく、発見された後、UAは、まだ彼らのスコープ内にDA DAへの発見およびユニキャストSLPv2のSrvRqstメッセージを実行することになります。
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.
SAはまた、DA検出を実行し、その範囲にSLPv2の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メッセージに属性が含まれていないであろうから、これら最小限のSAには文字列が国際化されないであろう、したがって、要求における言語タグを無視することができます。さらに、任意の非ヌル述語文字列は、属性を持たないサービスの広告を一致させるために失敗するので、これらのSAは、検索フィルタを解析し、解釈する必要はありません。 TCPメッセージの処理を実装する必要がないように、オーバーフローはSrvRqst、SrvRplyかのSrvRegメッセージで発生することはありません。属性がサポートされていませんので、最後に、すべてのAttrRqstメッセージは、SAによってドロップすることができます。
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.
アクティブDAディスカバリー、「：ディレクトリエージェントサービス」に設定し、そのサービスタイプフィールドとSrvRqstを使用します。スキームDAが「：ディレクトリエージェントサービス」とURLを含むDAAdvertで応答します。これは、このようなDAが未承諾DA通知にマルチキャストと同じDAAdvertです。
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]は、エンドシステムのセットによってサービスの登録と発見のために使用された場合、彼らは受動的に、この目的のために使用するLDAPサーバを発見するためのLDAP URL [16]を解釈することができます。この文書では、これがどのように行われるかを指定しません。さらにサポートなしSLPv2のエージェントは、単純にこのDAAdvertを捨てるでしょう。
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> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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は、要求されたサービスの種類（サービステンプレートによる）のために必要な属性を含めることができないSrvRqstかのSrvRegを受信した場合、そのメッセージに対応する応答に加えて、必要な属性拡張を返す場合があります。送信者は、返された必要な属性の拡張に記載されている属性を含む検索フィルタにメッセージを再発行すべきです。同様に、必須拡張は必須属性タグを含むSrvDeregメッセージに対して返信することができる属性。
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.'
テンプレートIDVer文字列は、必要に応じて特定の属性を定義するサービステンプレートの名前とバージョン番号の文字列です。これは含まれるべきではなく、与えられたSAまたはDAが個別に持つように構成されている場合は省略することができる「必要な属性を」。
The Required Attribute <tag-list> MUST NOT include wild cards.
必須属性<タグリスト>はワイルドカードを含めることはできません。
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を含むいくつかのディスカバリプロトコル、上の仕事からのアイデアを採用しています。私たちは、あなたがた区、ピーターフォードの貢献に感謝しています。ジョンVeizadesは、サービスロケーションプロトコルの標準化に尽力しました。ノベル、アクシスコミュニケーションズおよびSun Microsystemsの実装者は、このくらいのより明確かつ一貫性のある文書にするために大きく貢献してきました。
F. References
F.リファレンス
[1] Port numbers, July 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 / SC 21証明書の拡張を。 ISO / IEC 9594から2、1996年12月にドラフト改正DAM 4。
[3] ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment DAM 2 to ISO/IEC 9594-6, December 1996.
[3] ISO / IEC JTC1 / SC 21証明書の拡張を。 ISO / IEC 9594から6、1996年12月にドラフト改正DAM 2。
[4] ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment DAM 1 to ISO/IEC 9594-7, December 1996.
[4] ISO / IEC JTC1 / SC 21証明書の拡張を。 ISO / IEC 9594から7、1996年12月にドラフト改正DAM 1。
[5] ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment DAM 1 to ISO/IEC 9594-8, December 1996.
[5] ISO / IEC JTC1 / SC 21証明書の拡張を。 ISO / IEC 9594から8、1996年12月にドラフト改正DAM 1。
[6] Unicode Technical Report #8. The Unicode Standard, version 2.1. Technical report, The Unicode Consortium, 1998.
[6]のUnicodeテクニカルレポート＃8。 Unicode標準、バージョン2.1。技術レポート、ユニコードコンソーシアム、1998。
[7] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995.
[7] Alvestrand、H.、 "言語識別のためのタグ"、RFC 1766、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、 "統一資源識別子（URI）：一般的な構文"、RFC 2396、1998年8月。
[9] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[9]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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"、RFC 2234、1997年11月。
[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]ガットマン、E.、パーキンス、C.及びJ.ケンプ、 "サービステンプレートおよびサービス：スキーム"、RFC 2609、1999年6月。
[14] Howes, T., "The String Representation of LDAP Search Filters", RFC 2254, December 1997.
[14]ハウズ、T.、 "LDAP検索フィルタの文字列表現"、RFC 2254、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）"、RFC 2251、1997年12月。
[16] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255, December 1997.
[16]ハウズ、T.およびM.スミス、 "LDAPのURLの形式"、RFC 2255、1997年12月。
[17] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, July 1998.
[17]マイヤー、D.、 "管理スコープのIPマルチキャスト"、RFC 2365、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、「RFCsにIANA問題部に書くためのガイドライン、BCP 26、RFC 2434、1998年10月。
[19] Microsoft Networks. SMB File Sharing Protocol Extensions 3.0, Document Version 1.09, November 1989.
[19] Microsoftネットワーク。 SMBファイル共有プロトコル拡張3.0、ドキュメントバージョン1.09、1989年11月。
[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 PUBの186、コマース、1994年5月の米国部門。
[21] Perkins, C. and E. Guttman, "DHCP Options for Service Location Protocol", RFC 2610, June 1999.
[21]パーキンス、C.およびE.グットマン、 "サービスロケーションプロトコルのためのDHCPオプション"、RFC 2610、1999年6月。
[22] Veizades, J., Guttman, E., Perkins, C. and S. Kaplan, "Service Location Protocol", RFC 2165, July 1997.
[22] Veizades、J.、ガットマン、E.、パーキンス、C.及びS.カプラン、 "サービス・ロケーション・プロトコル"、RFC 2165、1997年7月。
[23] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[23] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、RFC 2279、1998年1月。
G. Authors' Addresses
G.の著者のアドレス
Erik Guttman Sun Microsystems Bahnstr. 2 74915 Waibstadt Germany
エリック・グットマンSun MicrosystemsのBahnstr。 2 74915ヴァイプシュタットドイツ
Phone: +49 7263 911 701 EMail: Erik.Guttman@sun.com
電話：+49 7263 911 701 Eメール：Erik.Guttman@sun.com
Charles Perkins Sun Microsystems 901 San Antonio Road Palo Alto, CA 94040 USA
チャールズ・パーキンスSun Microsystemsの901サンアントニオの道パロアルト、CA 94040 USA
Phone: +1 650 786 6464 EMail: cperkins@sun.com
電話：+1 650 786 6464 Eメール：cperkins@sun.com
John Veizades @Home Network 425 Broadway Redwood City, CA 94043 USA
ジョンVeizades @Homeネットワーク425ブロードウェイレッドウッドシティ、CA 94043 USA
Phone: +1 650 569 5243 EMail: veizades@home.net
電話：+1 650 569 5243 Eメール：veizades@home.net
Michael Day Vinca Corporation. 1201 North 800 East Orem, Utah 84097 USA
マイケル・デイビンカ株式会社。 1201北800東オレム、ユタ州84097 USA
Phone: +1 801 376-5083 EMail: mday@vinca.com
電話：+1 801 376-5083 Eメール：mday@vinca.com
H. Full Copyright Statement
H.完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています権利または特定の目的に対する商品性または適合性の黙示の保証を侵害し。」
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。