[要約] RFC 2608は、サービスの位置情報を提供するためのプロトコルであり、バージョン2です。このRFCの目的は、ネットワーク上のクライアントがサービスを見つけるための標準的な方法を提供することです。
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
サービスロケーションプロトコル、バージョン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.
Copyright（c）The Internet Society（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
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つの部分があります。最初は、プロトコルに必要な機能について説明します。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.
ユーザーエージェント（UA）ユーザーに代わって取り組んでいるプロセスは、サービスとの連絡を確立します。UAは、サービスエージェントまたはディレクトリエージェントからサービス情報を取得します。
Service Agent (SA) A process working on the behalf of one or more services to advertise the services.
サービスエージェント（SA）サービスを宣伝するための1つ以上のサービスに代わって作業するプロセス。
Directory Agent (DA) A process which collects service advertisements. There can only be one DA present per given host.
ディレクトリエージェント（DA）サービス広告を収集するプロセス。指定されたホストごとに存在するDAは1つしかありません。
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ユニバーサルリソースロケーター[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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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]変換を使用してエンコードされ、送信時にヌルが終了することはありません。文字列の前には、2バイトの長さフィールドがあります。
<string-list> A comma delimited list of strings with the following syntax:
<String-List>次の構文を備えた文字列のコンマ区切りリスト：
string-list = string / string `,' string-list
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.
形式図では、A \で終わるフィールドは、プロトコル内の以前の長さフィールドで与えられる可変長さフィールドを示します。
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).
ユーザーとサービスエージェントは、ディレクトリエージェントを2つの方法で発見します。まず、起動時に「ディレクトリエージェント」サービスのマルチキャストサービスリクエストを発行します。第二に、ディレクトリエージェントは、ユーザーとサービスエージェントが耳を傾ける未承諾の広告をまれに送信します。いずれの場合も、エージェントは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とYで構成されています。スコープXでサービスが求められている場合、リクエストはマルチキャストです。スコープYで求められている場合、リクエストはDAのユニキャストです。最後に、両方のスコープでリクエストを行う場合、リクエストはユニキャストとマルチキャストの両方でなければなりません。
Service Agents and User Agents may verify digital signatures provided with DAAdverts. User Agents and Directory Agents may verify service information registered by Service Agents. The keying material to use to verify digital signatures is identified using a SLP Security Parameter Index, or SLP SPI.
サービスエージェントとユーザーエージェントは、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.
SASは、マルチキャストサービスリクエストとユニキャストサービスリクエストを受け入れる必要があります。SASは、他のリクエスト（属性およびサービスタイプのリクエスト）を受け入れる場合があります。SASはマルチキャスト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を使用してネットワークに展開するためにオプションです。UASとSASは、これらのメッセージタイプをサポートする場合があります。これらの操作は、主にインタラクティブな使用（サービス登録をブラウジングまたは選択的に更新する）のためのものです。UASとSASは、使用される環境の要件と制約に応じて、それらをサポートするかどうかをサポートします。
Service Type Request A request for all types of service on the network. This allows generic service browsers to be built.
サービスタイプは、ネットワーク上のあらゆる種類のサービスのリクエストを要求します。これにより、一般的なサービスブラウザを構築できます。
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.
マルチキャストサポートがない場合、ブロードキャストを使用できます。DASの位置は、上記のようにSLPを使用して発見された、またはDHCPを使用して構成された静的に構成されている場合があります。メッセージが大きすぎる場合、TCPを使用してユニキャストである可能性があります。
A SLPv2 implementation SHOULD support SLPv1 [22]. This support includes:
SLPV2の実装は、SLPV1をサポートする必要があります[22]。このサポートには次のものが含まれます。
1. SLPv2 DAs are deployed, phasing out SLPv1 DAs.
1. SLPV2 DASが展開され、SLPV1 DASがフェージングされます。
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 UASは、可能であればスコープを持つように再構成する必要があります。
3. There is no way for an SLPv2 DA to behave as an unscoped SLPv1 DA. SLPv1 SAs MUST be reconfigured to have a scope if possible.
3. SLPV2 DAが非接続的なSLPV1 DAとして動作する方法はありません。SLPV1 SASは、可能であればスコープを持つように再構成する必要があります。
4. SLPv2 DAs answer SLPv1 requests with SLPv1 replies and SLPv2 requests with SLPv2 replies.
4. SLPV2 DAS応答SLPV1応答を使用してSLPV1要求とSLPV2リクエストをSLPV2応答で要求します。
5. SLPv2 DAs use registrations from SLPv1 and SLPv2 in the same way. That is, incoming requests from agents using either version of the protocol will be matched against this common set of registered services.
5. SLPV2 DASも同じ方法でSLPV1とSLPV2からの登録を使用します。つまり、いずれかのバージョンのプロトコルを使用したエージェントからの着信要求は、この一般的な登録サービスセットと一致します。
6. SLPv2 registrations which use Language Tags which are greater than 2 characters long will be inaccessible to SLPv1 UAs.
6. 2文字を超える言語タグを使用するSLPV2登録は、SLPV1 UASにはアクセスできません。
7. SLPv2 DAs MUST return only service type strings in SrvTypeRply messages which conform to SLPv1 service type string syntax, ie. they MUST NOT return Service Type strings for abstract service types.
7. SLPV2 DASは、SLPV1サービスタイプの文字列構文に準拠するSRVTyperPlyメッセージのサービスタイプの文字列のみを返す必要があります。抽象サービスタイプのサービスタイプの文字列を返してはなりません。
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 UASはSLPV2 SASから返信を受け取り、SLPV2 UASはSLPV1 SASから返信を受け取りません。さまざまなバージョンのUASとSASを相互操作するには、両方のプロトコルをサポートするネットワークにSLPV2 DAが存在する必要があります。
The use of abstract service types in SLPv2 presents a backward compatibility issue for SLPv1. It is possible that a SLPv1 UA will request a service type which is actually an abstract service type. Based on the rules above, the SLPv1 UA will never receive an abstract Service URL reply. For example, the service type 'service:x' in a SLPv1 AttrRqst will not return the attributes of 'service:x:y://orb'. If the request was made with SLPv2, it would return the attributes of this service.
SLPV2での抽象サービスタイプの使用は、SLPV1の後方互換性の問題を示しています。SLPV1 UAが実際に抽象サービスタイプであるサービスタイプを要求する可能性があります。上記のルールに基づいて、SLPV1 UAは抽象サービスのURL応答を受け取ることはありません。たとえば、slpv1 attrrqstのサービスタイプ 'service：x'は、「サービス：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は、Scheme [13]（セクション4.1でレビュー）、またはURI標準[8]に準拠したその他のURLスキームのサービスである場合があります。「ジェネリック」URLのサービスタイプは、そのスキーム名です。たとえば、「http://www.srvloc.org」のサービスタイプ文字列は「http」になります。
Reserved characters in URLs follow the rules in RFC 2396 [8].
URLの予約文字は、RFC 2396 [8]のルールに従います。
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>
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.
このサービスのサービスタイプ：URLは、<addrspec>の前の最終的な `： 'までの文字列であると定義されています。アドレス仕様。
<addrspec> is a hostname (which should be used if possible) or dotted decimal notation for a hostname, followed by an optional `:' and port number.
<addrspec>は、ホスト名（可能であれば使用する必要がある）またはホスト名の点線の小数表で、その後オプションの「：」とポート番号が続きます。
A service: scheme URL may be formed with any standard protocol name by concatenating "service:" and the reserved port [1] name. For example, "service:tftp://myhost" would indicate a tftp service. A tftp service on a nonstandard port could be "service:tftp://bad.glad.org:8080".
サービス：スキームURLは、「サービス：」と予約されたポート[1]名を連結することにより、標準プロトコル名で形成される場合があります。たとえば、「サービス：tftp：// myhost」はTFTPサービスを示します。非標準ポートのTFTPサービスは、「サービス：tftp：//bad.glad.org：8080」です。
Service Types SHOULD be defined by a "Service Template" [13], which provides expected attributes, values and protocol behavior. An abstract service type (also described in [13]) has the form
サービスタイプは、「サービステンプレート」[13]で定義する必要があります。これは、予想される属性、値、およびプロトコル動作を提供します。抽象サービスタイプ（[13]にも記載）にはフォームがあります
"service:<abstract-type>:<concrete-type>".
「サービス：<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.
サービスタイプの文字列「サービス：<Abstract-Type>」は、その抽象型のすべてのサービスと一致します。コンクリートタイプも含まれている場合、これらのサービスのみがリクエストと一致します。たとえば、「サービスタイプ」として「サービス：プリンター」を指定するSRVRQSTまたはATTRRQSTは、URLサービスと一致します。リクエストが「サービス：プリンター：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.
オプションのサブストリングは、最後の「。」に従うことができます。<srvtype>の文字（または<abstract-type>抽象サービスタイプのURLの場合）。このサブストリングは、セクション9.6で説明されているように、命名権限です。命名当局が異なるサービスタイプはまったく異なります。言い換えれば、サービス：X.ONEおよびSERVICE：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は、文字列が追加されていない場合、暗黙の命名当局です。「イアナ」自体を明示的に含めるべきではありません。
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.
命名当局は、実験的、所有権、または私的使用のためのサービスタイプを定義する場合があります。命名当局を使用すると、登録時に属性を無視するか、サイトの属性の局所的な属性セットを作成するだけです。使用する手順は、「一意の」ネーミング機関の文字列を作成し、上記のように標準属性定義を指定することです。この命名当局は、セクション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.
サービス広告には、多くの場合、サービス属性が伴うことがよくあります。これらの属性は、適切なサービスを選択するために、サービス要求でUASによって使用されます。
The allowable attributes which may be used are typically specified by a Service Template [13] for a particular service type. Services which are advertised according to a standard template MUST register all service attributes which the standard template requires. URLs with schemes other than "service:" MAY be registered with attributes.
使用できる許容属性は、通常、特定のサービスタイプのサービステンプレート[13]によって指定されます。標準テンプレートに従って宣伝されているサービスは、標準テンプレートに必要なすべてのサービス属性を登録する必要があります。「サービス：」以外のスキームを備えたURLは、属性に登録される場合があります。
Non-standard attribute names SHOULD begin with "x-", because no standard attribute name will ever have those initial characters.
非標準の属性名は「X-」で始まる必要があります。なぜなら、標準の属性名にそれらの初期文字がないため、「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 = `*'
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-list>は、存在する場合は、エスケープキャラクター「\」のすべての発生について評価する前にスキャンする必要があります。予約されたキャラクターを逃がす必要があります（他のキャラクターが逃げてはなりません）。すべての脱出されたキャラクターは、文字列のマッチングを試みる前に、価値に復元する必要があります。不透明な値の場合、脱出された文字は変換されません - それらはバイトとして解釈されます。
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*<digit>を取得し、範囲に落ちる整数文字列 "-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」で始まるため、文字列と区別されます。これは、Unescapedは違法な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-list>、<タグリスト>、または検索フィルターに含まれている場合、受信するSAまたはDAは、parse_errorをメッセージに返す必要があります。
A keyword has only an <attr-tag>, and no values. Attributes can have one or multiple values. All values are expressed as strings.
キーワードには<attr-tag>のみがあり、値はありません。属性には1つまたは複数の値を持つことができます。すべての値は文字列として表されます。
When values have been advertised by a SA or are registered in a DA, they can take on implicit typing rules for matching incoming requests.
値がSAによって宣伝されているか、DAに登録されている場合、着信要求を一致させるための暗黙のタイピングルールを引き受けることができます。
Stored values must be consistent, i.e., x=4,true,sue,\ff\00\00 is disallowed. A DA or SA receiving such an <attr-list> MUST return an INVALID_REGISTRATION error.
保存された値は一貫している必要があります。つまり、x = 4、true、sue、\ ff \ 00 \ 00は許可されていません。このような<attr-list>を受信するDAまたはSAは、無効な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.
このセクションでは、SASとUASの最小限の実装要件と、DASとの相互作用を定義します。SLPが機能するためにはDAは必要ありませんが、存在する場合、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は、発見されたDASにも登録する必要があります。
UAs perform discovery by issuing Service Request messages. SrvRqst messages are issued, using UDP, following these prioritized rules:
UASは、サービスリクエストメッセージを発行することにより発見を実行します。SRVRQSTメッセージは、これらの優先順位付けされたルールに従って、UDPを使用して発行されます。
1. A UA issues a request to a DA which it has been configured with by DHCP.
1. UAは、DHCPによって構成されているDAへのリクエストを発行します。
2. A UA issues requests to DAs which it has been statically configured with.
2. UAは、静的に構成されているDASへのリクエストを発行します。
3. UA uses multicast/convergence SrvRqsts to discover DAs, then uses that set of DAs. A UA that does not know of any DAs SHOULD retry DA discovery, increasing the waiting interval between subsequent attempts exponentially (doubling the wait interval each time.) The recommended minimum waiting interval is CONFIG_DA_FIND seconds.
3. UAはマルチキャスト/コンバージェンスSRVRQSTSを使用してDASを発見し、そのセットのDASを使用します。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.
4. DASの知らないUAは、マルチキャスト収束を使用してSASにリクエストを送信します。SASユニキャストは、マルチキャスト収束アルゴリズムに従ってUASに応答します。
UAs and SAs are configured with a list of scopes to use according to these prioritized rules:
UASとSAは、これらの優先順位付けされたルールに従って使用するスコープのリストで構成されています。
1. With DHCP.
1. DHCPで。
2. With static configuration. The static configuration may be explicitly set to NO SCOPE for UAs, if the User Selectable Scope model is used. See section 11.2.
2. 静的構成付き。ユーザー選択可能なスコープモデルを使用する場合、静的構成は、UASのスコープなしに明示的に設定される場合があります。セクション11.2を参照してください。
3. In the absence of configuration, the agent's scope is "DEFAULT".
3. 構成がない場合、エージェントのスコープは「デフォルト」です。
A UA MUST issue requests with one or more of the scopes it has been configured to use.
UAは、使用するように構成されている1つ以上のスコープでリクエストを発行する必要があります。
A UA which has been statically configured with NO SCOPE LIST will use DA or SA discovery to determine its scope list dynamically. In this case it uses an empty scope list to discover DAs and possibly SAs. Then it uses the scope list it obtains from DAAdverts and possibly SAAdverts in subsequent requests.
スコープリストなしで静的に構成されたUAは、DAまたはSAディスカバリーを使用してスコープリストを動的に決定します。この場合、空のスコープリストを使用してDASと場合によってはSASを発見します。次に、後続のリクエストでDAADVERTSとSAADVERTSから取得したスコープリストを使用します。
The SA MUST register all its services with any DA it discovers, if the DA advertises any of the scopes it has been configured with. A SA obtains information about DAs as a UA does. In addition, the SA MUST listen for multicast unsolicited DAAdverts. The SA registers by sending SrvReg messages to DAs, which reply with SrvReg messages to indicate success. SAs register in ALL the scopes they were configured to use.
DAが構成されているスコープのいずれかを宣伝する場合、SAは、すべてのサービスを発見する任意のDAに登録する必要があります。SAは、UAのようにDASに関する情報を取得します。さらに、SAはマルチキャストの未承諾のダアドバートを聴く必要があります。SAは、SRVREGメッセージをDASに送信することで登録します。DASは、SRVREGメッセージで成功を示すために返信します。SASは、使用するように構成されたすべてのスコープに登録します。
DAs MUST accept unicast requests and multicast directory agent discovery service requests (for the service type "service:directory-agent").
DASは、ユニキャストリクエストとマルチキャストディレクトリエージェントディスカバリーサービスリクエストを受け入れる必要があります（サービスタイプ「サービス：ディレクトリエージェント」）。
SAs MUST accept multicast requests and unicast requests both. The SA can distinguish between them by whether the REQUEST MCAST flag is set in the SLP Message header.
SASは、マルチキャストリクエストとユニキャストリクエストの両方を受け入れる必要があります。SAは、リクエストmcastフラグがSLPメッセージヘッダーに設定されているかどうかによって、それらを区別できます。
The Service Location Protocol uses multicast for discovering DAs and for issuing requests to SAs by default.
Service Location Protocolは、DASを発見し、デフォルトでSASへのリクエストを発行するためにマルチキャストを使用します。
The reserved listening port for SLP is 427. This is the destination port for all SLP messages. SLP messages MAY be transmitted on an ephemeral port. Replies and acknowledgements are sent to the port from which the request was issued. The default maximum transmission unit for UDP messages is 1400 bytes excluding UDP and other headers.
SLPのリスニングポートは427です。これは、すべてのSLPメッセージの宛先ポートです。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データグラムに収まらない場合、適合するように切り捨てられ、オーバーフローフラグが返信メッセージに設定されています。切り捨てられたメッセージを受信するUAは、DAまたはSAを使用してTCP接続（セクション6.2を参照）を開き、同じXIDを使用してリクエストを再送信する場合があります。また、切り捨てられた返信を利用したり、より制限的な要求を再定式化したりしようとする場合があります。これにより、返信が小さくなります。
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リクエストメッセージは、管理上スコープ付きSLPマルチキャスト[17]アドレス（239.255.255.253）のマルチキャストです。マルチキャストに使用するデフォルトのTTLは255です。
In isolated networks, broadcasts will work in place of multicast. To that end, SAs SHOULD and DAs MUST listen for broadcast Service Location messages at port 427. This allows UAs which do not support multicast the use of Service Location on isolated networks.
孤立したネットワークでは、放送はマルチキャストの代わりに機能します。そのために、SASはSHASが必要であり、DASはポート427でブロードキャストサービスのロケーションメッセージを聞く必要があります。これにより、マルチキャストをサポートしないUASが孤立したネットワークでのサービスロケーションの使用をサポートできます。
Setting multicast TTL to less than 255 (the default) limits the range of SLP discovery in a network, and localizes service information in the network.
マルチキャストTTLを255未満（デフォルト）に設定すると、ネットワーク内の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を実装する必要性を回避するには、次のことを保証する必要があります。
- UAs never issue requests larger than the Path MTU. SAs can omit TCP support only if they never have to receive unicast requests longer than the path MTU.
- UASは、Path MTUよりも大きいリクエストを発行することはありません。SASは、パスMTUよりも長くユニキャストリクエストを受信する必要がない場合にのみ、TCPサポートを省略できます。
- UAs can accept replies with the 'OVERFLOW' flag set, and make use of the first result included, or reformulate the request.
- UASは、「オーバーフロー」フラグセットで返信を受け入れることができ、最初の結果を使用したり、リクエストを再定式化したりできます。
- Ensure that a SA can send a SrvRply, SrvReg, or SrvDeReg in a single datagram. This means limiting the size of URLs, the number of attributes and the number of authenticators transmitted.
- SAが単一のデータグラムでSRVRPLY、SRVREG、またはSRVDEREGを送信できることを確認してください。これは、URLのサイズ、属性の数、および送信される認証機の数を制限することを意味します。
DAs MUST be able to respond to UDP and TCP requests, as well as multicast DA Discovery SrvRqsts. SAs MUST be able to respond to TCP unless the SA will NEVER receive a request or send a reply which will exceed a datagram in size (e.g., some embedded systems).
DASは、UDPおよびTCPリクエスト、およびマルチキャストDAディスカバリーSRVRQSTSに応答できる必要があります。SAがリクエストを受け取らない場合や、サイズのデータグラムを超える返信を送信しない限り、SASはTCPに応答できる必要があります（たとえば、埋め込まれたシステムなど）。
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エージェントは接続に沿って複数のリクエストを送信し、承認と返信のためにreturnストリームを読むことができます。
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とSASは、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待機期間後に発生します。再送信は、指数関数的に増加する待機間隔で行う必要があります（毎回待機を2倍にします）。これは、ユニキャストとマルチキャスト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秒でマルチキャストリクエストを再発行する必要があります。UASは、リクエストに一致する最初の返信を取得するまで待つだけです。つまり、要求エージェントが「限界時間間隔内でできるだけ多くの返信」ではなく「最初の返信」を使用する準備ができている場合、再送信は必要ありません。
When SLP SrvRqst, SrvTypeRqst, and AttrRqst messages are multicast, they contain a <PRList> of previous responders. Initially the <PRList> is empty. When these requests are unicast, the <PRList> is always empty.
SLP SRVRQST、SRVTYPERQST、およびATTRRQSTメッセージがマルチキャストの場合、以前のレスポンダーの<PRLIST>が含まれています。最初は<prlist>が空です。これらのリクエストがユニキャストの場合、<prlist>は常に空です。
Any DA or SA which sees its address in the <PRList> MUST NOT respond to the request.
<prlist>にそのアドレスを表示するDAまたはSAは、リクエストに応答してはなりません。
The message SHOULD be retransmitted until the <PRList> causes no further responses to be elicited or the previous responder list and the request will not fit into a single datagram or until CONFIG_MC_MAX seconds elapse.
メッセージは、<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.
リクエストを再送信するUASは、同じXIDを使用します。これにより、DAまたはSAが元のリクエストへの返信をキャッシュしてから、再度送信することができます。このキャッシュされた情報は、非常に短時間でのみ保持する必要があります。UASが頻繁に再起動する場合、XIDをリクエストで重複することを避けるために、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 0x5C）に続いて、エスケープされたキャラクターの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の順序と平等の文字列比較は、UTF-8の0x00-0x7Fサブレンジ内（ASCII文字エンコーディングに対応）内で症例不敏感でなければなりません。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".
文字列値の内部のホワイトスペース（スペース、CR、LF、タブ）は、文字列比較のために単一のスペース文字に折りたたまれます。文字列値の前後の空白は、文字列比較の目的で無視されます。たとえば、「いくつかの文字列」は「いくつかの文字列」と一致します。
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 Scopes which include any reserved characters must replace the escaped character with the escaped-val format.
scope-list = scope-val / scope-val `、 'scope-list scope-val = 1*safe safe =;予約済みを除くキャラクター。予約= `（ ' /`）' / `、 ' /` \' / `！ '/ `<' /` =' / `> ' /`〜' / ctl / `; '/ `*' /`' Escape-val = `\ 'hexdig hexdigスコープは、予約された文字を含むscopesを脱出した文字を脱出バル形式に置き換える必要があります。
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の構文に従うことができません。Invalid_Registration = 3：SRVREGには問題があります。たとえば、寿命ゼロまたは省略された言語タグ。scope_not_supported = 4：slpメッセージには、saまたはdaによってサポートされている<scope-list>にスコープが含まれていませんでした。Authentication_unknown = 5：DAまたはSAは、サポートされていないSLP SPIのリクエストを受け取ります。authentication_absent = 6：srvregでのDAが予想されるURLとattr認証を受け取りませんでした。Authentication_Failed = 7：DAは、認証ブロックで認証エラーを検出しました。ver_not_supported = 9：メッセージヘッダーのサポートされていないバージョン番号。internal_error = 10：DA（またはSA）は病気すぎて応答できません。da_busy_now = 11：uaまたはsaは、指数関数を使用して再試行する必要があります。option_not_understood = 12：DA（またはSA）は、必須範囲から未知のオプションを受け取りました（セクション9.1を参照）。Invalid_update = 13：DAは、未登録のサービス、または一貫性のないサービスタイプのために、新鮮なセットなしでSRVREGを受け取りました。MSG_NOT_SUPPORTED = 14：SAはATTRRQSTまたはSRVTYPERQSTを受け取り、サポートしていません。REFRESH_REJECTED = 15：SAは、DAのMin-Refresh-Intervalよりも頻繁にSRVREGまたは部分的なSRVDEREGをDAに送信しました。
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
メッセージタイプの略語function-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
SAs and UAs MUST support SrvRqst, SrvRply and DAAdvert. SAs MUST also support SrvReg, SAAdvert and SrvAck. For UAs and SAs, support for other messages are OPTIONAL.
SASとUASは、SRVRQST、SRVRPLY、およびDAADVERTをサポートする必要があります。SASは、SRVREG、Saadvert、Srvackもサポートする必要があります。UASとSASの場合、他のメッセージのサポートはオプションです。
- 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）は、メッセージの長さがデータグラムに収まるものを超えると設定されます。新鮮な（0x40）は、すべての新しいsrvregに設定されています。マルチリキャストまたはブロードキャストリクエストの場合、mcast（0x20）をリクエストすることが設定されます。予約ビットは0でなければなりません。-拡張機能が使用されない限り、次の拡張オフセットは0に設定されています。最初の拡張機能は、メッセージの開始から「オフセット」バイトから始まります。SLPメッセージデータの後に配置されます。認識されていないSLP拡張機能を解釈する方法については、セクション9.1を参照してください。-XIDは、一意の要求ごとに一意の値に設定されます。リクエストが再送信された場合、同じXIDが使用されます。返信リクエストのXIDをXIDと同じ値に設定します。XIDが0のXIDで送信される未承諾のDaAdvertのみが送信されます。 -Langタグの長さは、言語タグフィールドのバイトの長さです。 - 言語タグは[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に一致するためには、少なくとも1つの要求されたスコープに属し、要求されたサービスタイプをサポートし、述語と一致する必要があります。述語が存在する場合、リクエストの言語（言語タグの方言部分を無視）は、広告サービスと一致する必要があります。
<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>は、以前のレスポンダーリストです。この<string-list>には、点線の小数表記IP（v4）アドレスが含まれており、すべての可能な結果を得るために繰り返しマルチキャストです（セクション6.3を参照）。UASはこの発見アルゴリズムを実装する必要があります。SASは、他の手段でDAアドレスでまだ構成されていない場合、範囲内の利用可能なすべてのDASを発見するためにこれを使用する必要があります。
A SA silently drops all requests which include the SA's address in the <PRList>. An SA which has multiple network interfaces MUST check if any of the entries in the <PRList> equal any of its interfaces. An entry in the PRList which does not conform to an IPv4 dotted decimal address is ignored: The rest of the <PRList> is processed normally and an error is not returned.
SAは、<Prlist>のSAのアドレスを含むすべてのリクエストを静かにドロップします。複数のネットワークインターフェイスを備えたSAは、<PRLIST>のいずれかのエントリがそのインターフェイスのいずれかに等しいかどうかを確認する必要があります。IPv4点線の小数アドレスに準拠していないPRLISTのエントリは無視されます。<PRLIST>の残りは正常に処理され、エラーは返されません。
Once a <PRList> plus the request exceeds the path MTU, multicast convergence stops. This algorithm is not intended to find all instances; it finds 'enough' to provide useful results.
<prlist>プラスリクエストがパスMTUを超えると、マルチキャスト収束が停止します。このアルゴリズムは、すべてのインスタンスを見つけることを意図したものではありません。有用な結果を提供するのに「十分」を見つけます。
The <scope-list> is a <string-list> of configured scope names. SAs and DAs which have been configured with any of the scopes in this list will respond. DAs and SAs MUST reply to unicast requests with a 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-list>は、構成されたスコープ名の<string-list>です。このリストのいずれかのスコープで構成されているSASおよびDASが応答します。DASとSASは、<scope-list>が省略されているか、サポートされているスコープを含めない場合、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.
<Service-Type>文字列については、セクション4で説明します。通常、SRVRQSTはSRVRを誘発します。2つの例外があります。<service-type>が「service：directory-agent」に設定されている場合、dasは「service：service-agent」に設定されている場合、daadvertでsrvrqstに応答します（セクション8.5。を参照）、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=*)".
<Predicate>はLDAPV3検索フィルターです[14]。このフィールドはオプションです。サービスは、タイプと範囲によって単純に発見される場合があります。それ以外の場合、<Predicate>を満たすサービスが発見されます。存在する場合、各登録サービスと比較されます。フィルター内の属性が複数の値で登録されている場合、フィルターは各値と比較され、結果は一緒になります。つまり、「（x = 3）」は（x = 1,2,3）の登録と一致します。"（！（y = 0））" yはゼロではないため（y = 0,1）一致します。注マッチングは、症例の鈍感です。キーワード（つまり、値のない属性）は、「（キーワード=*）」のように、「存在」フィルターと一致します。
An incoming request term MUST have the same type as the attribute in a registration in order to match. Thus, "(x=33)" will not match ' x=true', etc. while "(y=foo)" will match 'y=FOO'. "(|(x=33)(y=foo))" will be satisfied, even though "(x=33)" cannot be satisfied, because of the `|' (boolean disjunction).
着信要求期間は、一致するために登録の属性と同じタイプを持っている必要があります。したがって、「（x = 33）」は「x = true」などと一致しません。"（|（x = 33）（y = foo））「"（x = 33）は「| 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 = 34foo」と一致しますが、最初の値は文字列であり、2番目の値は整数です。文字列は整数に一致しません。
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>は<scope-list>、<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>=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> = service：pop3 <s> = sales、default <p> =（user = wump）これは、ユーザーの「wump」にメールを提供する販売またはデフォルトの範囲で利用可能なすべての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> = service：backup <s> = bldg 32 <p> =（＆（q <= 3）（speed> = 1000））1000.これは、BLDG 32スコープに登録されているサービスに対してのみこれを返します。
<t>=service:directory-agent <s>=DEFAULT <p>= This returns DAAdverts for all DAs in the DEFAULT scope.
<t> = service：directory-agent <s> = default <p> =これにより、デフォルトの範囲内のすべてのDAのDAADVERTSが返されます。
DAs are discovered by sending a SrvRqst with the service type set to "service:directory-agent". If a predicate is included in the SrvRqst, the DA SHOULD respond only if the predicate can be satisfied with the DA's attributes. The <scope-list> MUST contain all scopes configured for the UA or SA which is discovering DAs.
DASは、SRVRQSTを「Service：Directory-Agent」に設定してSRVRQSTを送信することで発見されます。述語がSRVRQSTに含まれている場合、DAはDAの属性に満足できる場合にのみDAが応答する必要があります。<scope-list>には、DASを発見しているUAまたはSA用に構成されたすべてのスコープを含める必要があります。
The <SLP SPI> string indicates a SLP SPI that the requester has been configured with. If this string is omitted, the responder does not include any Authentication Blocks in its reply. If it is included, the responder MUST return a reply which has an associated authentication block with the SLP SPI in the SrvRqst. If no replies may be returned because the SLP SPI is not supported, the responder returns an AUTHENTICATION_UNKNOWN error.
<slp spi>文字列は、要求者が構成されているSLP SPIを示します。この文字列が省略されている場合、レスポンダーには応答に認証ブロックが含まれていません。含まれている場合、レスポンダーは、SRVRQSTのSLP SPIに関連する認証ブロックを持つ返信を返す必要があります。SLP SPIがサポートされていないために返信が返されない場合、Responderは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).
サービス返信には、ゼロ以上のURLエントリが含まれています（セクション4.3を参照）。一致するURLが存在しない場合は、UNACASTサービス要求に応じて、ゼロ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エントリを単に使用できます。SLPによって取得されたURLは、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.
<エントリ>はURLエントリです（セクション4.3を参照）。生涯は、DAが登録をキャッシュできる期間を定義します。SASは、この生涯になる前に再登録する必要があります（ただし、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).
<Service-Type>は、URLのスキームに関係なく、登録されるURLのサービスタイプを定義します。<scope-list>には、SA用に構成されたすべてのスコープの名前が含まれている必要があります。これは、サポートに登録されています。<scope-list>のデフォルト値は「デフォルト」です（セクション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は、すべてのDASに一貫して登録する必要があります。SAがスコープxとyで構成されており、スコープがそれぞれ「x」、「y」、「y」である3つのDASがある場合、SAはそれぞれのスコープに3つのDAすべてを登録します。サービスのすべての将来の更新と解雇は、サービスが最初に登録された同じスコープで同じDASのセットに送信する必要があります。
The <attr-list>, if present, specifies the attributes and values to be associated with the URL by the DA (see Section 5).
<attr-list>は、存在する場合、DAによってURLに関連付けられる属性と値を指定します（セクション5を参照）。
A SA configured with the ability to sign service registrations MUST sign each of the URLs and Attribute Lists using each of the keys it is configured to use, and the DA it is registering with accepts. (The SA MUST acquire DAAdverts for all DAs it will register with to obtain the DA's SLP SPI list and attributes, as described in Section 8.5). The SA supplies a SLP SPI in each authentication block indicating the SLP SPI configuration required to verify the digital signature. The format of the digital signatures used is defined in section 9.2.1.
サービス登録に署名する機能を備えたSAは、使用するように構成された各キーを使用して、各URLと属性リストに署名する必要があり、DAが登録している必要があります。（SAは、セクション8.5で説明されているように、DAのSLP SPIリストと属性を取得するために登録するすべてのDASの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のリストを含める必要があります。そうでなければ、DASはそれらを拒否し、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).
フレッシュフラグセットへの登録は、同じ言語で同じURLの以前の登録を *完全に *完全に *置き換えます。新鮮なフラグが設定されていない場合、登録は「増分」登録です（セクション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の後にsrvackをSAに戻します。2つのバイトエラーコードのみが搭載されています（セクション7を参照）。
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に設定されます。ユニキャストSRVRQST（つまり、リクエストMASTフラグセットなしのリクエスト）のためにDAADVERTが返されている場合、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の<Scope-List>は、省略するか、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.
SASが寿命が少なすぎる場合、SLPV2で潜在的なスケーリングの問題が発生します。この場合、より多くのサービスが展開されるにつれて、厄介な量の再登録が発生します。SLPV2を使用すると、DASはSAS登録頻度を制御できます。DAは、SASの再登録動作を変更するために、いつでも新しい属性セットを使用してDaAdvertを再発行する場合があります。これらは後続の登録にのみ適用されます。DAとの既存のサービス登録は、登録された寿命を維持します。
If the DAAdvert includes the attribute "min-refresh-interval" it MUST be set to a single Integer value indicating a number of seconds. If this attribute is present SAs MUST NOT refresh any particular service advertisement more frequently than this value. If SrvReg with the FRESH FLAG not set or SrvDereg with a non-empty tag list updating a 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に「min-refresh-interval」属性が含まれている場合、数秒を示す単一の整数値に設定する必要があります。この属性が存在する場合、SASはこの値よりも頻繁に特定のサービス広告を更新してはなりません。新鮮なフラグを持つSRVREGは、特定のサービスを更新する非空白のタグリストを備えたSRVDEREGを設定しない場合、DAの宣伝されている「Min-Refresh-Interval」属性の値よりも頻繁に受信された場合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.
URLは「service：directory-agent：// "<addr> daの「<addr>」です。ここで、<addr>はDAの点線数値アドレスです。daの<scope-list>はnullであってはなりません。
The SLP SPI List is the list of SPIs that the DA is capable of verifying. SAs MUST NOT register services with authentication blocks for those SLP SPIs which are not on the list. DAs will reject service registrations which they cannot verify, returning an AUTHENTICATION_UNKNOWN error.
SLP SPIリストは、DAが検証できるSPIのリストです。SASは、リストに載っていないSLP SPIの認証ブロックでサービスを登録してはなりません。DASは、検証できないサービス登録を拒否し、認証_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は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.
SRVRQSTに対応してDAADVERTが送信されている場合、DAADVERTは、DAがそのSLP SPIを使用してデジタル署名を生成できるように構成されている場合、SRVRQSTのSLP SPIの認証ブロックのみを含みます。SRVRQSTがDAのユニキャスト（ヘッダーのリクエストMCASTフラグが設定されていない）であり、サポートされていないSLP SPIが含まれている場合、DAはexepultication_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 SPISで構成され、それらのいずれかを使用して検証できない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.
ユーザーエージェントは、特定のDAを使用するように構成されている場合、<scope-list>で構成されている場合、またはDASが発見された場合、SA広告を募集してはなりません。UASは、SASがサポートするスコープを発見するために、ユーザー選択可能なスコープを使用するように明示的に構成されている場合にのみSA広告を求めます。これにより、スコープ構成のないUASが、パフォーマンスを除いて機能的な違いのないDASまたは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述語が満たされていない場合、SASは応答してはなりません。たとえば、「NFS」サービスを提供するSASのみが、SRVRQSTにSAADVERTで応答して、SRVRQSTに「サービス：Service-Agent」（Service-Type = nfs）を含む "Service-Agent"に応答する必要があります。
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は、NO <Scope-List>または使用するように構成されているスコープを含むマルチキャスト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がサイズのPath 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.
URLは「サービス：Service-Agent：//」SAの「service-agent：//」<addr>です。ここで、<addr>はSAの点線数値アドレスです。SAの<scope-list>はnullであってはなりません。
The SAAdvert contains one SAAdvert Authentication block for each SLP SPI the SA can produce Authentication Blocks for. If the UA can verify the Authentication Block of the SAAdvert, and the SAAdvert fails to be verified, the UA MUST discard it.
SAADVERTには、SAが認証ブロックを生成できる各SLP SPIごとに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標準化。実装するのに必須。このオプションを返信で受け取る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.
次の拡張機能への3バイトのオフセットは、SLPメッセージの先頭からオフセットとして次の拡張機能の位置を示します。
The offset value is 0 if there are no extensions following the current extension.
現在の拡張に続く拡張機能がない場合、オフセット値は0です。
If the offset is 0, the length of the current Extension Data is determined by subtracting total length of the SLP message as given in the SLP message header minus the offset of the current extension.
オフセットが0の場合、現在の拡張データの長さは、SLPメッセージヘッダーに与えられたSLPメッセージの総長さを差し引いて、現在の拡張のオフセットを差し引いて決定することによって決定されます。
Extensions defined in this document are in Section D. See section 15 for procedures that are required when specifying new SLP extensions.
このドキュメントで定義されている拡張機能は、セクションDにあります。新しいSLP拡張機能を指定するときに必要な手順については、セクション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登録データ（属性値など）は通常ケースに敏感ではありませんが、登録データの場合は、UASがデジタル署名データの計算に使用されるデータを検証できるように登録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）は、次の認証器の形式を識別します。BSDS 0x0000-0X7FFFはIANAによって維持されます。BSDS 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日に0Hに比べて32ビットの署名されていない固定点数です。署名は期限切れになります。このタイムスタンプは、2106年に0に戻ります。タイムスタンプの値がラップされると、タイムスタンプがリセットに関連する時間。たとえば、2106年2月5日06H28および16秒後、すべてのタイムスタンプの値はその時代に関連します。
The SLP Security Parameters Index (SPI) string identifies the key length, algorithm parameters and keying material to be used by agents to verify the signature data in the Structured Authentication Block. The SLP SPI string has the same grammar as the <scope-val> defined in Section 6.4.1.
SLPセキュリティパラメータインデックス（SPI）文字列は、構造化された認証ブロックの署名データを検証するためにエージェントが使用するキー長、アルゴリズムパラメーター、キーイング材料を識別します。SLP SPI文字列は、セクション6.4.1で定義されている<scope-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スピスは一意でなければなりません。BSD = 0x0002に使用されるSLP SPIは、他のBSDに使用されるものと同じでなければなりません。
All SLP agents MUST implement DSA [20] (BSD=0x0002). SAs MUST register services with DSA authentication blocks, and they MAY register them with other authentication blocks using other algorithms. SAs MUST use DSA authentication blocks in SrvDeReg messages and DAs MUST use DSA authentication blocks in unsolicited DAAdverts.
すべてのSLPエージェントは、DSA [20]（BSD = 0x0002）を実装する必要があります。SASは、DSA認証ブロックにサービスを登録する必要があり、他のアルゴリズムを使用して他の認証ブロックに登録する場合があります。SASは、SRVDEREGメッセージでDSA認証ブロックを使用する必要があり、DASは未承諾DAADVERTSでDSA認証ブロックを使用する必要があります。
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.
URL 16ビットの長さのSLP SPI文字列、SLP SPI文字列。URLの16ビット長、URL、32ビットタイムスタンプ。
Attribute List 16-bit Length of SLP SPI String, SLP SPI String, 16-bit length of <attr-list>, <attr-list>, 32-bit Timestamp.
属性リスト16ビットの長さのSLP SPI文字列、SLP SPI文字列、16ビットの長さ<attr-list>、<attr-list>、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.
daAdvert 16ビットの長さのSLP SPIストリング、SLP SPIストリング、32ビットDAステートレスブートタイムスタンプ、16ビットのURL、URL、16ビットの長さ<AttlSlist>、<Attl-List>、16-DAの<Scope-List>、DAの<Scope-List>、DAの<SLPSPIリスト>の16ビットの長さ、DAの<SLP SPIリスト>、32ビットタイムスタンプのビットの長さ。
The first SLP SPI is the SLP SPI in the Authentication Block. This SLP SPI indicates the keying material and other parameters to use to verify the DAAdvert. The SLP SPI List is the list of SLP SPIs the DA itself supports, and is able to verify.
最初のSLP SPIは、認証ブロックのSLP SPIです。このSLP SPIは、キーイング材料とDaAdvertの検証に使用するその他のパラメーターを示しています。SLP SPIリストは、DA自体がサポートするSLP SPIのリストであり、検証することができます。
SAAdvert 16-bit Length of SLP SPI String, SLP SPI String, 16-bit Length of URL, URL, 16-bit Length of <attr-list>, <attr-list>, 16-bit Length of <scope-list>, <scope-list>, 32-bit Timestamp.
SAADVERT 16ビットの長さのSLP SPIストリング、SLP SPIストリング、16ビットのURL、URL、16ビットの長さ<ATTRリスト>、<ATTRリスト>、16ビットの長さ<Scope-List>>、<scope-list>、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 = 0x0002は、SHA-1のDSAであると定義されています。署名計算は[20]で定義されます。署名形式は、X.509 V3証明書のそれに適合します：
1. The signature algorithm identifier (an OID) 2. The signature value (an octet string) 3. The certificate path.
1. 署名アルゴリズム識別子（OID）2。署名値（オクテット文字列）3。証明書パス。
All data is represented in ASN.1 encoding:
すべてのデータは、asn.1エンコードで表されます。
id-dsa-with-sha1 ID ::= {
iso(1) member-body(2) us(840) x9-57 (10040)
x9cm(4) 3 }
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].
すなわち、DSAおよびSHA-1を使用して計算されたRおよびSのバイナリASN.1エンコード。これに続いて、X.509 [10]、[2]、[3]、[4]、[5]で定義されている証明書パスが続きます。
Authentication Blocks for BSD=0x0002 have the following format. In the future, BSDs may be assigned which have different formats.
BSD = 0x0002の認証ブロックには、次の形式があります。将来的には、異なる形式を持つ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.
Incremental登録は、以前に登録されたサービスの属性値を更新します。たとえば、単一の属性のみが変更された場合、インクリメンタルサービス登録は役立ちます。増分登録では、SRVREGヘッダーの新鮮なフラグは設定されていません。
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に登録されているとします。属性C = 30、d = 40を備えたX：//a.orgのインクリメンタル登録がサービスに登録されている場合、更新後のサービスの属性はa = 1、b = 2、c = 30、d = 40です。。
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ヘッダーセットに新鮮なフラグがあるすべての属性を登録する必要があります。そのような登録メッセージを受信するDASは、authentication_failedエラーを返します。
If the FRESH flag is not set and the DA does not have a prior registration for the service, the incremental registration fails with error code INVALID_UPDATE.
新鮮なフラグが設定されておらず、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は、以前の登録で使用されていた更新メッセージで同じ<scope-list>を使用する必要があります。これが完了していない場合、DAはscope_not_supportedエラーを返します。サービス広告の範囲を変更するには、最初に登録し、新しい<scope-list>で再登録する必要があります。
The SA MUST use the same <service-type> in an update message as was used in a prior registration of the same URL. If this is not done, the DA returns an INVALID_UPDATE error.
SAは、同じURLの以前の登録で使用された更新メッセージで同じ<service-type>を使用する必要があります。これが完了していない場合、DAはnivalid_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).
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".
<タグリスト>アイテムのワイルドカード文字は、文字の任意のシーケンスと一致します。たとえば、「*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>リストと<scope-list>は、セクション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-list>で提供されています。これは<string-list>です。
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以外の命名機関がある場合、サービスタイプの文字列と「」に従って返品する必要があります。キャラクター。IANA Naming Authorityのサービスタイプには、命名権限の文字列は含まれていません。
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>、<scope-list>、<slp spi>文字列は、セクション8.1のように解釈されます。
The URL field can take two forms. It can simply be a Service Type (see Section 4.1), such as "http" or "service:tftp". In this case, all attributes and the full range of values for each attribute of all services of the given Service Type is returned.
URLフィールドは2つのフォームを取得できます。単に「HTTP」または「Service：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.
URLフィールドは、「サービス：プリンター：lpr：//igore.wco.ftp.com：515/draft」または「nfs：//max.net/znoo」などの完全なURLである場合があります。これでは、指定されたURLの登録属性のみが返されます。
The <tag-list> field is a <string-list> of attribute tags, as defined in Section 9.4 which indicates the attributes to return in the AttrRply. If <tag-list> is omitted, all attributes are returned. <tag-list> MUST be omitted and a full URL MUST be included when attributes when a SLP SPI List string is included, otherwise the DA will reply with an AUTHENTICATION_FAILED error.
<タグリスト>フィールドは、属性タグの<string-list>です。<タグリスト>が省略されている場合、すべての属性が返されます。<Tag-List>は省略し、属性の場合、slp SPIリスト文字列が含まれている場合は完全な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-list>と認証ブロックの形式は、SRVREGに指定されているとおりです（セクション9.2.1を参照）。
Attribute replies SHOULD be returned with the original case of the string registration intact, as they are likely to be human readable. In the case where the AttrRqst was by service type, all attributes defined for the service type, and all their values are returned.
属性の応答は、人間が読みやすい可能性が高いため、文字列登録の元のケースでそのまま返品する必要があります。attrrQSTがサービスタイプごとに行われた場合、すべての属性がサービスタイプに定義され、そのすべての値が返されます。
Although white space is folded for string matching, attribute tags and values MUST be returned with their original white space preserved.
ストリングマッチングのためにホワイトスペースは折りたたまれていますが、属性タグと値を保存して値を返す必要があります。
Only one copy of each attribute tag or String value should be returned, arbitrarily choosing one version (with respect to upper and lower case and white space internal to the strings): Duplicate attributes and values SHOULD be removed. An arbitrary version of the string value and tag name is chosen for the merge. For example: "(A=a a,b)" merged with "(a=A A,B)" may yield "(a=a a,B)".
各属性タグまたは文字列値の1つのコピーのみを返し、1つのバージョンを任意に選択する必要があります（文字列の内部の上限および小文字、および空白の重複と値を削除する必要があります。文字列値とタグ名の任意のバージョンがマージに選択されます。たとえば、 "（a = a a、b）"（a = a a、b） "と融合した"（a = 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 = service:printer:lpr://igore.wco.ftp.com/draft
scope-list = Development
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
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
Notice the first printer, "Igore" is registered in both English and German. The `<' and `>' characters in the Operator attribute value which are part of the Email address had to be escaped, as they are reserved characters for values.
最初のプリンター「igore」は英語とドイツ語の両方で登録されています。メールアドレスの一部であるOperator属性値の「 'および」文字は、値の予約文字であるため、逃げる必要がありました。
Attribute tags are not translated, though attribute values may be, see [13].
属性タグは翻訳されませんが、属性値は[13]を参照してください。
The attribute Request:
属性要求：
URL = service:printer:lpr://igore.wco.ftp.com/draft
scope-list = Development
Lang. Tag = de
tag-list = resolution,loc*
receives the Attribute Reply:
属性を受信します返信：
(location-description=13te Etage),(resolution=res-600)
The attribute Request:
属性要求：
URL = service:printer
scope-list = Development
Lang. Tag = en
tag-list = x-*,resolution,protocol
receives an Attribute Reply containing:
含む属性の返信を受信します：
(protocols=http,LPR),(resolution=res-600,other),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を搭載した認証ブロックを返すことができる場合、属性認証ブロックが返されます。認証ブロックを持つDAから返された<attr-list>は、認証検証の計算を可能にするために、SAによって登録された<attr-list>と同一でなければならないことに注意してください。
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がユニキャストリクエスト（ヘッダーのリクエストMCASTフラグが設定されていない）で指定され、SAまたはDAがそのSLP SPIで認証ブロックを返すことができない場合、authentication_unknownエラーが返されます。ATTR AUTHSフィールドの＃は、認証ブロックが含まれていない場合は0に設定されます。または、認証ブロックが続く場合は1です。
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).
<scope-list>は<string-list>です（セクション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 DEREGISTESは、以前に登録されていた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で定義されているように、属性タグの<string-list> noregisterの<string-list>です。<タグリスト>が存在する場合、srvderegは登録されているすべての言語のサービスをderegistersします。<タグリスト>が存在する場合、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つ以上のスコープを使用するように構成されています。ユーザーは、使用するように構成されているサービスのみを発見します。UASとSASをスコープで構成することにより、管理者はサービスを提供することができます。スコープ文字列は、症例の鈍感です。デフォルトのスコープ文字列は「デフォルト」です。
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が存在する場合、事前定義された非デフォルトスコープを持つようにUASとSASを構成することにより、さらに利益を得ることができます。これらのエージェントは、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エラーが返されます（リクエストがユニカストの場合）。すべてのSRVRQST（DAおよびSAディスカバリーリクエストを除く）、SRVREG、ATTRRQST、SRVTYPERQST、DAADVERT、およびSAADVERTメッセージには、A <Scope-List>を含める必要があります。
A UA MUST unicast its SLP messages to a DA which supports the desired scope, in preference to multicasting a request to SAs. A UA MAY multicast the request if no DA is available in the scope it is configured to use.
UAは、SASへのリクエストをマルチキャストすることを好むために、目的のスコープをサポートするDAにSLPメッセージをユニカストする必要があります。UAは、使用するように構成されているスコープにDAが利用できない場合、リクエストをマルチキャストする場合があります。
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です。ユーザーがスコープ選択を行うことができるようにするために使用すると、これらはゼロの長さの<scope-list>を持つ場合があります。この場合、UASはDaAdvertsからスコープリストを取得します（またはSaadvertsからDASが利用できない場合）。
Otherwise, if SAs and UAs are to use any scope other than the default (i.e., "DEFAULT"), the UAs and SAs are configured with lists of scopes to use by system administrators, perhaps automatically by way of DHCP option 78 or 79 [21]. Such administrative scoping allows services to be provisioned, so that users will only see services they are intended to see.
それ以外の場合、SASとUASがデフォルト以外のスコープ（つまり、「デフォルト」）を使用する場合、UASとSASは、おそらくDHCPオプション78または79で自動的に使用するシステム管理者が使用するスコープのリストで構成されています[21]。このような管理スコーピングにより、サービスをプロビジョニングできるため、ユーザーは目的のサービスのみを表示します。
User configurable scopes allow a user to discover any service, but require them to do their own selection of scope. This is similar to the way AppleTalk [12] and SMB [19] networking allow user selection of AppleTalk Zone or workgroups.
ユーザー構成可能なスコープにより、ユーザーはサービスを発見することができますが、独自の選択を行う必要があります。これは、AppleTalk [12]およびSMB [19]ネットワークにより、ユーザーがAppleTalkゾーンまたはワークグループの選択を可能にする方法に似ています。
Note that the two configuration choices are not compatible. One model allows administrators control over service provision. The other delegates this to users (who may not be prepared to do any configuration of their system).
2つの構成の選択肢は互換性がないことに注意してください。1つのモデルにより、管理者はサービス提供を制御できます。もう1つは、これをユーザー（システムの構成を実行する準備ができていない場合があります）に委任します。
DAs cache service location and attribute information. They exist to enhance the performance and scalability of SLP. Multiple DAs provide further scalability and robustness of operation, since they can each store service information for the same SAs, in case one of the DAs fails.
DASキャッシュサービスの場所と属性情報。それらは、SLPのパフォーマンスとスケーラビリティを向上させるために存在します。DASの1つが失敗した場合に備えて、同じSASのサービス情報を各サービス情報ができるため、複数のDASが動作のさらなるスケーラビリティと堅牢性を提供します。
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アドレスは、DHCPを使用してUASおよびSASで動的に構成するか、静的構成を使用して構成できます。
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がDHCPまたは静的構成でDASを使用するように構成されているSASは、SAが初期化されたときにSRVRQSTをDAにユニカストする必要があります。SRVRQSTはスコープリストを省略し、リクエストのサービスタイプを「サービス：ディレクトリエージェント」に設定します。DAは、適切なSAからDA通信に不可欠な属性、SLP SPIリスト、およびその他のパラメーターを備えたDAADVERTを返します。
Passive detection of DAs by SAs enables services to be advertised consistently among DAs of the same scope. Advertisements expire if not renewed, leaving only transient stale registrations in DAs, even in the case of a failure of a SA.
SASによるDASのパッシブ検出により、サービスは同じ範囲のDAS間で一貫して宣伝できます。広告は更新されていない場合は期限切れになり、SAが失敗した場合でも、DASに一時的な古い登録のみが残ります。
A single DA can support many UAs. UAs send the same requests to DAs that they would send to SAs and expect the same results. DAs reduce the load on SAs, making simpler implementations of SAs possible.
単一のDAは多くのUASをサポートできます。UASは、SASに送信し、同じ結果を期待する同じリクエストをDASに送信します。DASはSASの負荷を減らし、SASのより簡単な実装を可能にします。
UAs MUST be prepared for the possibility that the service information they obtain from DAs is stale.
UASは、DASから取得したサービス情報が古くなっている可能性について準備する必要があります。
When DAs are present, each SA MUST register its services with DAs that support one or more of its scope(s).
DASが存在する場合、各SAは、その範囲の1つ以上をサポートするDASにサービスを登録する必要があります。
UAs MUST unicast requests directly to a DA (when scoping rules allow), hence avoiding using the multicast convergence algorithm, to obtain service information. This decreases network utilization and increases the speed at which UAs can obtain service information.
UASは、Scopingルールが許可されている場合）に直接リクエストをユニキャストする必要があるため、サービス情報を取得するためにマルチキャストコンバージェンスアルゴリズムを使用して回避する必要があります。これにより、ネットワークの使用率が低下し、UASがサービス情報を取得できる速度が向上します。
DAs MUST flush service advertisements once their lifetime expires or their URL Authentication Block "Timestamp" of expiration is past.
DASは、寿命が切れる場合、またはURL認証ブロック「タイムスタンプ」の有効期限が過ぎばサービス広告をフラッシュする必要があります。
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には、認証ブロックと同じ形式でDA Stateless Boot Timestampを含める必要があります（セクション9.2を参照）。認証ブロックのタイムスタンプは、以前のすべての登録が失われた時間（つまり、最後のステートレスの再起動）を示します。タイムスタンプは、DAがダウンしていることをUASとSASに通知するために、DAADVERTで0に設定されています。DASは、サービス登録状態なしで下に戻って再起動した場合、以前のものに等しいまたはそれ以下のブートタイムスタンプを使用してはなりません。これは、SASをDAに再登録しないことを誤解させるでしょう。
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.
<scope-list>が（a）省略されておらず、（b）使用するように構成されているスコープを含めない場合、サービスタイプ「サービス：ディレクトリエージェント」のマルチキャストSRVRQSTを受信するDASは、黙って廃棄する必要があります。それ以外の場合、DAはDaAdvertで応答する必要があります。
DAs MUST respond to AttrRqst and SrvTypeRqst messages (these are OPTIONAL only for SAs, not DAs.)
DASは、attrrqstおよびsrvtyperqstメッセージに応答する必要があります（これらは、SASでのみ、DASではなくオプションです。）
UAs can discover DAs using static configuration, DHCP options 78 and 79, or by multicasting (or broadcasting) Service Requests using the convergence algorithm in Section 6.3.
UASは、セクション6.3の収束アルゴリズムを使用して、静的構成、DHCPオプション78および79、またはマルチリキャスト（またはブロードキャスト）サービス要求を使用してDASを発見できます。
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.
未承諾のダアドバートについては、セクション6を参照してください。セクション12.2.2では、SASが未承諾のDaAdvertに応じてDASで再登録しなければならない回数をどのように減らすかについて説明します。
DAs MUST send unsolicited DAAdverts once per CONFIG_DA_BEAT. An unsolicited DAAdvert has an XID of 0. SAs MUST listen for DAAdverts, passively, as described in Section 8.5. UAs MAY do this. If they do not listen for unsolicited DAAdverts, however, they will not discover DAs as they become available. UAs SHOULD, in this case, do periodic active DA discovery, see Section 6.
DASは、config_da_beatごとに1回未承諾のdaAdvertsを送信する必要があります。セクション8.5で説明されているように、SASは、0のXIDを0のXIDにしなければなりません。UASはこれを行う場合があります。しかし、彼らが未承諾のダアドバートを聞かない場合、彼らは利用可能になるとDASを発見しません。この場合、UASは定期的なアクティブなDA発見を行う必要があります。セクション6を参照してください。
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が再起動した後、0からCONFIG_START_WAIT秒に均一に配布されたランダムな時間の最初のDAディスカバリーリクエストを遅らせる必要があります。
The UA or SA sends the DA Discovery request using a SrvRqst, as described in Section 8.1. DA Discovery requests MUST include a Previous Responder List. SrvRqsts for Active DA Discovery SHOULD NOT be sent more than once per CONFIG_DA_FIND seconds.
UAまたはSAは、セクション8.1で説明されているように、SRVRQSTを使用してDAディスカバリーリクエストを送信します。DAディスカバリーリクエストには、以前のレスポンダーリストを含める必要があります。Active DA DiscoveryのSRVRQSTSは、config_da_find秒ごとに1回以上送信しないでください。
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は、config_da_beat秒ごとに未承諾のdaAdvertをマルチキャスト（またはブロードキャスト）する必要があります。config_da_beatは、利用可能な帯域幅の1％以上を使用するのを防ぐために指定する必要があります。
All UAs and SAs which receive the unsolicited DAAdvert SHOULD examine its DA stateless Boot Timestamp. If it is set to 0, the DA is going down and no further messages should be sent to it.
未承諾のDaAdvertを受け取るすべてのUASとSASは、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は登録する必要があります。SASは、SAが最後に登録されて以来、DAが無国籍の再起動を行ったかどうかを判断するために、DaAdvertのタイムスタンプを調べなければなりません。もしそうなら、それはDAに登録されます。SASは、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メッセージに応答できない場合、メッセージを再試行する必要があります。その後の各再送信の待機間隔は、毎回2倍になるように指数関数的に増加する必要があります。config_retry_maxの秒後にDAまたはSAが応答できない場合、送信者は受信機がダウンしたと考える必要があります。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:
デフォルトでは、DASは「デフォルト」スコープで構成されています。管理者は、非デフォルトスコープでUASとSASをサポートするために、他の構成されたスコープを追加する場合があります。次の場合を除き、デフォルトの構成をDAから削除しないでください。
- There are other DAs which support the "DEFAULT" scope, or
- 「デフォルト」スコープをサポートする他のDAS、または
- All UAs and SAs have been configured with non-default scopes.
- すべてのUASとSASは、非デフォルトスコープで構成されています。
Non-default scopes can be phased-in as the SLP deployment grows. Default scopes should be phased out only when the non-default scopes are universally configured.
SLPの展開が成長するにつれて、非デフォルトスコープは段階的に段階的になります。デフォルトのスコープは、非デフォルトスコープが普遍的に構成されている場合にのみ段階的に廃止する必要があります。
If a DA and SA are coresident on a host (quite possibly implemented by the same process), configuration of the host is considerably simplified if the SA supports only scopes also supported by the DA. That is, the SA SHOULD NOT advertise services in any scopes which are not supported by the coresident DA. This means that incoming requests can be answered by a single data store; the SA and DA registrations do not need to be kept separately.
DAとSAがホストのコアリデント（同じプロセスによって実装される可能性が非常に高い）の場合、SAがDAによってサポートされているスコープのみをサポートする場合、ホストの構成はかなり単純化されます。つまり、SAは、コアシデント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.
DASは、サービス登録または属性リストに署名するように構成されていません。サービスエージェントによって登録されたサービスをキャッシュするだけです。DASは、構成されていないSLP SPIの認証ブロックを含む登録を受け入れてはなりません。セクション8.5を参照してください。
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が登録されている場合、後続の登録（控えめに置き換える）または登録（それを削除します）が、対応する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"などの認証ブロックを使用してサービスを登録します。UAがSLP SPI文字列「X」を使用してサービスを要求する場合、DAはS（SRVRQSTマッチSのサービスタイプ、言語、スコープ、および述語の場合）を返すことができます。DAはSLP SPIで認証ブロックを返します。「x」に設定します。DAがSの後続のsrvdereg（広告を削除する）またはその後のsのsrvregを受信した場合、メッセージには2つのURL認証ブロックを含める必要があります。これらのいずれかが存在しない場合、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.
ブロードキャスト任意のSLPエージェントのみが、ブロードキャストのみを使用するように構成可能である必要があります。セクション6.1および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 DISCOVERY UAまたはSAは、事前定義されたDHCPで構成されたDASのみを使用し、アクティブまたはパッシブDA発見を実行しないように構成可能である必要があります。
Multicast TTL The default multicast TTL is 255. Agents SHOULD be configurable to use other values. A lower value will focus the multicast convergence algorithm on smaller subnetworks, decreasing the number of responses and increases the performance of service location. This may result in UAs obtaining different results for the identical requests depending on where they are connected to the network.
マルチキャストTTLデフォルトのマルチキャストTTLは255です。エージェントは、他の値を使用するように設定できる必要があります。値が低いと、マルチキャストコンバージェンスアルゴリズムが小規模なサブネットワークに集中し、応答の数を減らし、サービス場所のパフォーマンスを向上させます。これにより、UASがネットワークに接続されている場所に応じて、同一のリクエストに対して異なる結果を得る可能性があります。
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のデフォルト値は、それ以外の場合は設定されていない場合、スコープを「デフォルト」にすることです。
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を使用して構成されている場合、これらは積極的または受動的に発見されたDASを好みに使用する必要があります。DHCPを使用して構成された1つ以上のスコープをリクエストで使用する必要があります。構成された<scope-list>全体を登録および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.
サービステンプレートUASおよびSASは、サービステンプレートを使用して構成できます。属性値の仕様を簡素化することに加えて、これにより、SRVRQST、SRVREG、およびSRVDEREGメッセージに「必須」属性の包含を実施することもできます。DASは、これらの場合にUASとSASを警告できるように、テンプレートで構成できます。セクション10.4を参照してください。
SLP SPI for service discovery Agents SHOULD be configurable to support SLP SPIs using the following parameters: BSD=2 (DSA with SHA-1) and a public key identified by the SLP SPI String. In the future, when a Public Key Infrastructure exists, SLP Agents may be able to obtain public keys and cryptographic parameters corresponding to the names used in SLP SPI Strings.
サービス発見エージェント用のSLP SPIは、次のパラメーターを使用してSLP SPIをサポートするように構成可能である必要があります。BSD= 2（SHA-1を含むDSA）と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文字列がスコープ文字列と同一である場合、それは事実上SLPV1の保護されたスコープと同じであることに注意してください。つまり、その範囲内のすべてのSA広告は、同じ秘密鍵で構成されます。その範囲のすべてのDAおよびUAは、適切な公開キーで構成され、それらのSASによって生成された署名を検証します。これは、公開キーインフラストラクチャがない場合にSLP展開を構成する便利な方法です。現在、各SAに独自のキーがあれば、UASとDASのキーイングを管理することは難しすぎるでしょう。
SLP SPI for Directory Agent discovery Agents SHOULD be configurable to support SLP SPIs as above, to be used when discovering DAs. This SPI SHOULD be sent in SrvRqsts to discover DAs and be used to verify multicast DAAdvert messages.
ディレクトリエージェントのSLP SPIは、DASを発見するときに使用するために、上記のようにSLP SPIをサポートするように構成可能である必要があります。このSPIは、SRVRQSTSで送信してDASを発見し、マルチキャストDAADVERTメッセージを検証するために使用する必要があります。
SA and DA Private Key SAs and DAs which can generate digital signatures require a Private Key and a corresponding SLP SPI indentifier to include in the Authentication Block. The SLP SPI identifies the Public Key to use to verify the digital signature in the Authentication Block.
デジタル署名を生成できるSAおよびDAの秘密キーSASおよびDASには、秘密キーと対応するSLP SPIインデンティファイアが認証ブロックに含める必要があります。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）は、次の認証器の形式を識別します。BSDS 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:
さらに、範囲から0x0003-0x7fffの範囲から、さらにブロック構造化記述子（BSD）値は、以下を説明するドキュメントを送信することにより標準化される場合があります。
- 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.
- UAS、DAS、SASの事前構成に必要なキーイング素材の形式。また、重要な分布に関する考慮事項も含めます。
- Security considerations to alert others to the strengths and weaknesses of the approach.
- アプローチの長所と短所を他の人に警告するセキュリティ上の考慮事項。
The IANA will assign Cryptographic BSD numbers on the basis of IETF Consenus.
IANAは、IETFコンセンサスに基づいて暗号化BSD番号を割り当てます。
New function-IDs, in the range 12-255, may be standardized by the method of IETF Consensus.
12〜255の範囲の新しい機能IDは、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登録アクションも必要になる場合があります。SLPは、「サービス：」のURLおよびサービステンプレート[13]と組み合わせて使用されます。これらは、指定された専門家とメーリングリストのレビューによって標準化されています（[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とサービス属性の認証を提供します。これにより、UASとDASに、SLPメッセージに含まれるサービスURLと属性の整合性に関する知識を提供します。デジタル署名を生成できる唯一のシステムは、管理者によって事前に構成されたシステムです。署名されたデータを確認するエージェントは、管理者が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.
サービスの場所は機密性を提供しません。このプロトコルの目的はユーザーのコミュニティにサービスを宣伝することであるため、このプロトコルが非敏感な環境で使用される場合、機密性は一般に必要ではない場合があります。将来必要に応じて、専門的なスキームが機密性を提供できる場合があります。機密性を必要とするサイトは、セキュリティペイロード（ESP）[3]をカプセル化するIPを実装して、サービスロケーションメッセージの機密性を提供する必要があります。
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 SPIをSLPを使用する前にENDシステムで事前に設定できる場合、認証ブロックの使用に関連する利点を得ることができます。
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）が追加されました。これにより、UASは管理構成とDASがない場合にスコープ情報を発見できます。これはSLPV1では不可能でした。
SLPv2 is incompatible in some respects with SLPv1. If a DA which supports both SLPv1 and SLPv2 with the same scope is present, services advertised by SAs using either version of the protocol will be available to both SLPv1 and SLPv2 UAs. SLPv1 DAs SHOULD be phased out and replace with SLPv2 DAs which support both versions of the protocol.
SLPV2は、SLPV1とのいくつかの点で互換性がありません。同じスコープでSLPV1とSLPV2の両方をサポートするDAが存在する場合、いずれかのバージョンのプロトコルを使用してSASによって宣伝されているサービスは、SLPV1とSLPV2 UASの両方が利用できます。SLPV1 DASは段階的に廃止され、プロトコルの両方のバージョンをサポートするSLPV2 DASに置き換える必要があります。
SLPv1 allows services to be advertised and requested without a scope. Further, DAs can be configured without a scope. This is incompatible with SLPv2 and presents scalability problems. To facilitate this forward migration, SLPv1 agents MUST use scopes for all registrations and requests. SLPv1 DAs MUST be configured with a scope list. This constitutes a revision of RFC 2165 [22].
SLPV1を使用すると、サービスをスコープなしで宣伝およびリクエストすることができます。さらに、DASはスコープなしで構成できます。これはSLPV2と互換性がなく、スケーラビリティの問題を示します。この前方移行を促進するには、SLPV1エージェントはすべての登録とリクエストにスコープを使用する必要があります。SLPV1 DASは、スコープリストで構成する必要があります。これは、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]が定義されています。属性を指定するサービステンプレートに関連付けられたサービスタイプは、属性をサポートしていないSASによって宣伝されてはなりません。
While discovery of service by service type is a subset of the features possible using SLPv2 this form of discovery is consistent with the current generation of products that allow simple browsing of all services in a 'zone' or 'workgroup' by type. In some cases, attribute discovery, security and feature negotiation is handled by 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.
そのサービスタイプのサービスのみを要求するUASは、サービスリクエストのサービスタイプとスコープフィールドをサポートする必要があります。UASは、マルチリキャストの代わりに発見された後、DASにDASにDASに対してDA DiscoveryとUnicast 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.
SASはまた、DAディスカバリーを実行し、SLPV2 SRVREGを使用して、広告されたすべてのサービスを範囲内のSLPV2 DASで登録します。これらの広告は、言うまでもなく、属性文字列を含めません。
These minimal SAs could ignore the Language Tag in requests since SrvRqst messages would contain no attributes, hence no strings would be internationalized. Further, any non-null predicate string would fail to match a service advertisement with no attributes, so these SAs would not have to parse and interpret search filters. Overflow will never occur in SrvRqst, SrvRply or SrvReg messages so TCP message handling would not have to be implemented. Finally, all AttrRqst messages could be dropped by the SA, since no attributes are supported.
SRVRQSTメッセージには属性が含まれないため、これらの最小限のSASはリクエストの言語タグを無視できます。したがって、文字列は国際化されません。さらに、非ヌルの述語文字列は、サービス広告を属性なしで一致させることができないため、これらのSASは検索フィルターを解釈して解釈する必要はありません。オーバーフローは、srvrqst、srvrply、またはsrvregメッセージでは発生しないため、TCPメッセージ処理を実装する必要はありません。最後に、属性がサポートされていないため、すべての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.
Active DA Discoveryを使用して、SRVRQSTを「Service：Directory-Agent」に設定します。DASは、「service：directory-agent：」スキームを含む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は静かに廃棄されます。このドキュメントは、「service：directory-agent：」スキームで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 URL [16]を解釈して、この目的に使用するLDAPサーバーを受動的に発見できます。このドキュメントでは、これがどのように行われるかを指定しません。さらにサポートすることなくSLPV2エージェントは、このdaAdvertを単純に破棄します。
D. Appendix: SLP Protocol Extensions
D.付録：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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
このドキュメントには、PerkinsやHarjonoによるRDP、Michael DayのPDを含むいくつかの発見プロトコルの作業からのアイデアが組み込まれています。イェグアとピーターフォードによる貢献に感謝しています。John Veizadesは、サービスロケーションプロトコルの標準化に役立ちました。Novell、Axis Communications、およびSun Microsystemsの実装者は、これをより明確でより一貫したドキュメントにするために大きく貢献しています。
F. References
F.参照
[1] Port numbers, July 1997. ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers.
[1] ポート番号、1997年7月。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.証明書拡張。1996年12月、ISO/IEC 9594-2からISO/IEC 9594-2への草案。
[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.証明書拡張。1996年12月、ISO/IEC 9594-6からISO/IEC 9594-6の草案。
[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.証明書拡張。1996年12月、ISO/IEC 9594-7からISO/IEC 9594-7の草案。
[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.証明書拡張。1996年12月、ISO/IEC 9594-8からISO/IEC 9594-8の草案。
[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] Berners-Lee、T.、Fielding、R。and L. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、RFC 2396、1998年8月。
[9] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[9] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[10] CCITT. The Directory Authentication Framework. Recommendation X.509, 1988.
[10] ccitt。ディレクトリ認証フレームワーク。推奨X.509、1988。
[11] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[11] Crocker、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。Andrews、およびA. Oppenheimer。内部AppleTalk。Addison-Wesley、1990年。
[13] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and service: Schemes", RFC 2609, June 1999.
[13] Guttman、E.、Perkins、C。and J. Kempf、「サービステンプレートとサービス：スキーム」、RFC 2609、1999年6月。
[14] Howes, T., "The String Representation of LDAP Search Filters", RFC 2254, December 1997.
[14] Howes、T。、「LDAP検索フィルターの文字列表現」、RFC 2254、1997年12月。
[15] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[15] Wahl、M.、Howes、T。およびS. Killee、「Lightweight Directory Access Protocol（V3）」、RFC 2251、1997年12月。
[16] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255, December 1997.
[16] Howes、T。およびM. Smith、「LDAP URL形式」、RFC 2255、1997年12月。
[17] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, July 1998.
[17] Meyer、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、BCP 26、RFC 2434、1998年10月にIANA考慮事項セクションを作成するためのガイドライン。
[19] Microsoft Networks. SMB File Sharing Protocol Extensions 3.0, Document Version 1.09, November 1989.
[19] Microsoft Networks。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] Perkins、C。and E. Guttman、「サービスロケーションプロトコルの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.、Guttman、E.、Perkins、C。and S. Kaplan、「Service Location Protocol」、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
Erik Guttman Sun Microsystems Bahnstr。2 74915 Waibstadtドイツ
Phone: +49 7263 911 701
EMail: Erik.Guttman@sun.com
Charles Perkins Sun Microsystems 901 San Antonio Road Palo Alto, CA 94040 USA
チャールズパーキンスサンマイクロシステムズ901サンアントニオロードパロアルト、カリフォルニア94040 USA
Phone: +1 650 786 6464
EMail: cperkins@sun.com
John Veizades @Home Network 425 Broadway Redwood City, CA 94043 USA
John Veizades @home Network 425 Broadway Redwood City、CA 94043 USA
Phone: +1 650 569 5243
EMail: veizades@home.net
Michael Day Vinca Corporation. 1201 North 800 East Orem, Utah 84097 USA
マイケル・デイ・ヴィンカ・コーポレーション。1201 North 800 East Orem、Utah 84097 USA
Phone: +1 801 376-5083
EMail: mday@vinca.com
H. Full Copyright Statement
H.完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。