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
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.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
The Service Location Protocol provides a scalable framework for the discovery and selection of network services. Using this protocol, computers using the Internet need little or no static configuration of network services for network based applications. This is especially important as computers become more portable, and users less tolerant or able to fulfill the demands of network system administration.
服务位置协议为网络服务的发现和选择提供了一个可扩展的框架。使用此协议，使用Internet的计算机对于基于网络的应用程序几乎不需要或不需要静态配置网络服务。这一点尤其重要，因为计算机越来越便携，用户的容忍度越来越低，或者无法满足网络系统管理的要求。
Table of Contents
目录
1. Introduction 3
1.1. Applicability Statement . . . . . . . . . . . . . . . 3
2. Terminology 4
2.1. Notation Conventions . . . . . . . . . . . . . . . . . 4
3. Protocol Overview 5
4. URLs used with Service Location 8
4.1. Service: URLs . . . . . . . . . . . . . . . . . . . . 9
4.2. Naming Authorities . . . . . . . . . . . . . . . . . 10
4.3. URL Entries . . . . . . . . . . . . . . . . . . . . . 10
5. Service Attributes 10
6. Required Features 12
6.1. Use of Ports, UDP, and Multicast . . . . . . . . . . 13
1. 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
6.2. Use of TCP . . . . . . . . . . . . . . . . . . . . . 14
6.3. Retransmission of SLP messages . . . . . . . . . . . 15
6.4. Strings in SLP messages . . . . . . . . . . . . . . . 16
6.4.1. Scope Lists in SLP . . . . . . . . . . . . . . 16
7. Errors 17
8. Required SLP Messages 17
8.1. Service Request . . . . . . . . . . . . . . . . . . . 19
8.2. Service Reply . . . . . . . . . . . . . . . . . . . . 21
8.3. Service Registration . . . . . . . . . . . . . . . . . 22
8.4. Service Acknowledgment . . . . . . . . . . . . . . . . 23
8.5. Directory Agent Advertisement. . . . . . . . . . . . . 24
8.6. Service Agent Advertisement. . . . . . . . . . . . . . 25
9. Optional Features 26
9.1. Service Location Protocol Extensions . . . . . . . . . 27
9.2. Authentication Blocks . . . . . . . . . . . . . . . . 28
9.2.1. SLP Message Authentication Rules . . . . . . . 29
9.2.2. DSA with SHA-1 in Authentication Blocks . . . 30
9.3. Incremental Service Registration . . . . . . . . . . 30
9.4. Tag Lists . . . . . . . . . . . . . . . . . . . . . . 31
10. Optional SLP Messages 32
10.1. Service Type Request . . . . . . . . . . . . . . . . 32
10.2. Service Type Reply . . . . . . . . . . . . . . . . . 32
10.3. Attribute Request . . . . . . . . . . . . . . . . . . 33
10.4. Attribute Reply . . . . . . . . . . . . . . . . . . . 34
10.5. Attribute Request/Reply Examples . . . . . . . . . . . 34
10.6. Service Deregistration . . . . . . . . . . . . . . . 36
11. Scopes 37
11.1. Scope Rules . . . . . . . . . . . . . . . . . . . . . 37
11.2. Administrative and User Selectable Scopes. . . . . . . 38
12. Directory Agents 38
12.1. Directory Agent Rules . . . . . . . . . . . . . . . . 39
12.2. Directory Agent Discovery . . . . . . . . . . . . . . 39
12.2.1. Active DA Discovery . . . . . . . . . . . . . 40
12.2.2. Passive DA Advertising . . . . . . . . . . . . 40
12.3. Reliable Unicast to DAs and SAs. . . . . . . . . . . . 41
12.4. DA Scope Configuration . . . . . . . . . . . . . . . 41
12.5. DAs and Authentication Blocks. . . . . . . . . . . . . 41
13. Protocol Timing Defaults 42
14. Optional Configuration 43
15. IANA Considerations 44
16. Internationalization Considerations 45
17. Security Considerations 46
A. Appendix: Changes to the Service Location Protocol from
v1 to v2 48
B. Appendix: Service Discovery by Type: Minimal SLPv2 Features 48
C. Appendix: DAAdverts with arbitrary URLs 49
D. Appendix: SLP Protocol Extensions 50
D.1. Required Attribute Missing Option . . . . . . . . . . 50
E. Acknowledgments 50 F. References 51 G. Authors' Addresses 53 H. Full Copyright Statement 54
E.确认50 F.参考文献51 G.作者地址53 H.版权声明全文54
The Service Location Protocol (SLP) provides a flexible and scalable framework for providing hosts with access to information about the existence, location, and configuration of networked services. Traditionally, users have had to find services by knowing the name of a network host (a human readable text string) which is an alias for a network address. SLP eliminates the need for a user to know the name of a network host supporting a service. Rather, the user supplies the desired type of service and a set of attributes which describe the service. Based on that description, the Service Location Protocol resolves the network address of the service for the user.
服务位置协议（SLP）为主机提供了一个灵活且可扩展的框架，使其能够访问有关网络服务的存在、位置和配置的信息。传统上，用户必须通过知道网络主机的名称（人类可读的文本字符串）来查找服务，该名称是网络地址的别名。SLP不需要用户知道支持服务的网络主机的名称。相反，用户提供所需的服务类型和一组描述服务的属性。基于该描述，服务位置协议为用户解析服务的网络地址。
SLP provides a dynamic configuration mechanism for applications in local area networks. Applications are modeled as clients that need to find servers attached to any of the available networks within an enterprise. For cases where there are many different clients and/or services available, the protocol is adapted to make use of nearby Directory Agents that offer a centralized repository for advertised services.
SLP为局域网中的应用程序提供了一种动态配置机制。应用程序被建模为需要查找连接到企业内任何可用网络的服务器的客户端。对于有许多不同客户机和/或服务可用的情况，该协议适用于使用附近的目录代理，这些代理为广告服务提供集中的存储库。
This document updates SLPv1 [RFC 2165], correcting protocol errors, adding some enhancements and removing some requirements. This specification has two parts. The first describes the required features of the protocol. The second describes the extended features of the protocol which are optional, and allow greater scalability.
本文档更新了SLPv1[RFC 2165]，纠正了协议错误，添加了一些增强功能并删除了一些要求。本规范分为两部分。第一部分描述了协议所需的功能。第二个描述了协议的扩展特性，这些特性是可选的，并允许更大的可伸缩性。
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）代表一个或多个服务发布服务的过程。
Directory Agent (DA) A process which collects service advertisements. There can only be one DA present per given host.
目录代理（DA）收集服务广告的进程。每个给定主机只能有一个DA。
Service Type Each type of service has a unique Service Type string.
服务类型每种类型的服务都有一个唯一的服务类型字符串。
Naming Authority The agency or group which catalogues given Service Types and Attributes. The default Naming Authority is IANA.
命名机构对给定服务类型和属性进行编目的机构或团体。默认命名机构是IANA。
Scope A set of services, typically making up a logical administrative group.
作用域一组服务，通常构成一个逻辑管理组。
URL A Universal Resource Locator [8].
URL是通用资源定位器[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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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]转换进行编码，传输时不以空结尾。字符串前面有一个两字节长度的字段。
<string-list> A comma delimited list of strings with the following syntax:
<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.
在格式图中，任何以\结尾的字段都表示一个可变长度字段，由协议中的前一个长度字段给出。
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.
服务位置协议支持一个框架，通过该框架，客户端应用程序被建模为“用户代理”，服务由“服务代理”发布。第三个实体称为“目录代理”，提供了协议的可伸缩性。
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------ +---------------+
+------------+ ----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.
在较大的网络中，使用一个或多个目录代理。目录代理充当缓存。服务代理向目录代理发送包含其播发的所有服务的注册消息（SrvReg），并接收应答确认（SrvAck）。必须使用目录代理刷新这些播发，否则它们将过期。如果已知任何目录代理，则用户代理将单播请求发送到目录代理，而不是服务代理。
+-------+ -Unicast SrvRqst-> +-----------+ <-Unicast SrvReg- +--------+
| User | | Directory | |Service |
| Agent | | Agent | | Agent |
+-------+ <-Unicast SrvRply- +-----------+ -Unicast SrvAck-> +--------+
+-------+ -Unicast SrvRqst-> +-----------+ <-Unicast SrvReg- +--------+
| User | | Directory | |Service |
| Agent | | Agent | | Agent |
+-------+ <-Unicast SrvRply- +-----------+ -Unicast SrvAck-> +--------+
User and Service Agents discover Directory Agents two ways. First, they issue a multicast Service Request for the 'Directory Agent' service when they start up. Second, the Directory Agent sends an unsolicited advertisement infrequently, which the User and Service Agents listen for. In either case the Agents receive a DA Advertisement (DAAdvert).
用户和服务代理通过两种方式发现目录代理。首先，它们在启动时为“目录代理”服务发出多播服务请求。其次，目录代理不经常发送未经请求的广告，用户和服务代理会监听该广告。在任何一种情况下，代理都会收到DA广告（DAADERD）。
+---------------+ --Multicast SrvRqst-> +-----------+
| User or | <--Unicast DAAdvert-- | Directory |
| Service Agent | | Agent |
+---------------+ <-Multicast 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-- +-----------+
+---------+ 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.
服务代理和用户代理可以验证随广告提供的数字签名。用户代理和目录代理可以验证服务代理注册的服务信息。使用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
协议中有几个可选功能。请注意，DAs必须支持所有这些消息类型，但DA支持本身是有限的
optional to deploy on networks using SLP. UAs and SAs MAY support these message types. These operations are primarily for interactive use (browsing or selectively updating service registrations.) UAs and SAs either support them or not depending on the requirements and constraints of the environment where they will be used.
可选择在使用SLP的网络上部署。UAs和SAs可能支持这些消息类型。这些操作主要用于交互使用（浏览或有选择地更新服务注册）。UAs和SAs支持或不支持这些操作，具体取决于使用它们的环境的要求和约束。
Service Type Request A request for all types of service on the network. This allows generic service browsers to be built.
服务类型请求对网络上所有类型服务的请求。这允许构建通用服务浏览器。
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. SLPv1 UAs将无法访问使用长度超过2个字符的语言标记的SLPv2注册。
7. SLPv2 DAs MUST return only service type strings in SrvTypeRply messages which conform to SLPv1 service type string syntax, ie. they MUST NOT return Service Type strings for abstract service types.
7. SLPv2 DAs必须仅返回SrvTypeRply消息中符合SLPv1服务类型字符串语法的服务类型字符串，即，它们不得返回抽象服务类型的服务类型字符串。
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 SRVRQST和ATTRQST与抽象服务类型的服务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”将不会返回“service:x:y://orb”的属性。如果请求是使用SLPv2发出的，它将返回此服务的属性。
A Service URL indicates the location of a service. This URL may be of the service: scheme [13] (reviewed in section 4.1), or any other URL scheme conforming to the URI standard [8], except that URLs without address specifications SHOULD NOT be advertised by SLP. The service type for an 'generic' URL is its scheme name. For example, the service type string for "http://www.srvloc.org" would be "http".
服务URL表示服务的位置。此URL可能是服务方案[13]（在第4.1节中审查）或符合URI标准[8]的任何其他URL方案，但SLP不应公布没有地址规范的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.
[13]中定义了服务URL语法和语义。任何网络服务都可以在服务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>
"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".
服务：通过连接“服务：”和保留端口[1]名称，可以使用任何标准协议名称形成方案URL。例如，“服务：tftp://myhost“表示tftp服务。非标准端口上的tftp服务可以是“服务：tftp://bad.glad.org:8080".
Service Types SHOULD be defined by a "Service Template" [13], which provides expected attributes, values and protocol behavior. An abstract service type (also described in [13]) has the form
服务类型应由“服务模板”[13]定义，该模板提供预期的属性、值和协议行为。抽象服务类型（也在[13]中描述）的形式为
"service:<abstract-type>:<concrete-type>".
“服务：<抽象类型>：<具体类型>”。
The service type string "service:<abstract-type>" matches all services of that abstract type. If the concrete type is included also, only these services match the request. For example: a SrvRqst or AttrRqst which specifies "service:printer" as the Service Type will match the URL service:printer:lpr://hostname and service:printer:http://hostname. If the requests specified "service:printer:http" they would match only the latter URL.
服务类型字符串“service:<abstract type>”匹配该抽象类型的所有服务。如果还包括具体类型，则只有这些服务与请求匹配。例如：指定“服务：打印机”作为服务类型的SrvRqst或ATTRQST将匹配URL服务：打印机：lpr://hostname 和服务：打印机：http://hostname. 如果请求指定“service:printer: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>中的最后一个`.'字符后面（或者在抽象服务类型URL的情况下是<abstract type>）。该子字符串是命名机构，如第9.6节所述。具有不同命名权限的服务类型非常不同。换句话说，service:x.one和service:x.two是不同的服务类型，service:abstract.one:y和service:abstract.two:y也是不同的服务类型。
A Naming Authority MAY optionally be included as part of the Service Type string. The Naming Authority of a service defines the meaning of the Service Types and attributes registered with and provided by Service Location. The Naming Authority itself is typically a string which uniquely identifies an organization. IANA is the implied Naming Authority when no string is appended. "IANA" itself MUST NOT be included explicitly.
可以选择将命名机构作为服务类型字符串的一部分。服务的命名机构定义了向服务位置注册并由服务位置提供的服务类型和属性的含义。命名机构本身通常是唯一标识组织的字符串。当没有附加字符串时，IANA是隐含的命名机构。“IANA”本身不得明确包括在内。
Naming Authorities may define Service Types which are experimental, proprietary or for private use. Using a Naming Authority, one may either simply ignore attributes upon registration or create a local-use only set of attributes for one's site. The procedure to use is to create a 'unique' Naming Authority string and then specify the Standard Attribute Definitions as described above. This Naming Authority will accompany registration and queries, as described in Sections 8.1 and 8.3. Service Types SHOULD be registered with IANA to allow for Internet-wide interoperability.
命名机构可以定义实验性、专有或私人使用的服务类型。使用命名机构，用户可以在注册时忽略属性，也可以为自己的站点创建一组仅限本地使用的属性。要使用的过程是创建“唯一”命名机构字符串，然后如上所述指定标准属性定义。如第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) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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相关联。如上所示定义的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-”开头，因为任何标准属性名称都不会有这些初始字符。
An attribute list is a string encoding of the attributes of a service. The following ABNF [11] grammar defines attribute lists:
属性列表是服务属性的字符串编码。以下ABNF[11]语法定义了属性列表：
attr-list = attribute / attribute `,' attr-list
attribute = `(' attr-tag `=' attr-val-list `)' / attr-tag
attr-val-list = attr-val / attr-val `,' attr-val-list
attr-tag = 1*safe-tag
attr-val = intval / strval / boolval / opaque
intval = [-]1*DIGIT
strval = 1*safe-val
boolval = "true" / "false"
opaque = "\FF" 1*escape-val
safe-val = ; Any character except reserved.
safe-tag = ; Any character except reserved, star and bad-tag.
reserved = `(' / `)' / `,' / `\' / `!' / `<' / `=' / `>' / `~' / CTL
escape-val = `\' HEXDIG HEXDIG
bad-tag = CR / LF / HTAB / `_'
star = `*'
attr-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”的布尔字符串只能接受一个值，并且只能与“=”进行比较。布尔值在比较时不区分大小写。
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”开头。这是一种非法的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>、<tag list>或搜索筛选器中，则接收该字符串的SA或DA必须向消息返回PARSE_错误。
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>，没有值。属性可以有一个或多个值。所有值都表示为字符串。
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必须返回无效的\u注册错误。
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，但如果存在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唯一需要的功能是，它可以根据以下规则发布SRVRQST，并解释DAADS、SAAdverts和SrvRply消息。UA必须在发现请求时向DAs发出请求。SA必须使用SrvRply或SAAdvert消息回复相应的SRVRQST。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使用多播/聚合SRVRQST发现DAs，然后使用该DAs集。不知道任何DAs的UA应重试DA发现，以指数方式增加后续尝试之间的等待间隔（每次将等待间隔增加一倍）。建议的最小等待间隔为CONFIG_DA_FIND seconds。
4. A UA with no knowledge of DAs sends requests using multicast convergence to SAs. SAs unicast replies to UAs according to the multicast convergence algorithm.
4. 不知道DAs的UA使用多播聚合向SAs发送请求。SAs单播根据多播收敛算法回复UAs。
UAs and SAs are configured with a list of scopes to use according to these prioritized rules:
UAs和SAs配置有一个范围列表，根据这些优先规则使用：
1. With DHCP.
1. 使用DHCP。
2. With static configuration. The static configuration may be explicitly set to NO SCOPE for UAs, if the User Selectable Scope model is used. See section 11.2.
2. 具有静态配置。如果使用用户可选择的作用域模型，静态配置可以显式设置为无UAs作用域。见第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必须发出具有一个或多个已配置为使用的作用域的请求。
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.
SA必须向其发现的任何DA注册其所有服务，如果DA播发其已配置的任何作用域。SA像UA一样获得有关DAs的信息。此外，SA必须侦听多播未经请求的DAAD。SA通过向DAs发送SrvReg消息进行注册，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可以通过是否在SLP消息头中设置请求MCAST标志来区分它们。
The Service Location Protocol uses multicast for discovering DAs and for issuing requests to SAs by default.
默认情况下，服务位置协议使用多播来发现DAs和向SAs发出请求。
The reserved listening port for SLP is 427. This is the destination port for all SLP messages. SLP messages MAY be transmitted on an ephemeral port. Replies and acknowledgements are sent to the port
SLP的预留监听端口为427。这是所有SLP消息的目标端口。SLP消息可以在临时端口上传输。回复和确认被发送到端口
from which the request was issued. The default maximum transmission unit for UDP messages is 1400 bytes excluding UDP and other headers.
从中发出请求。UDP消息的默认最大传输单位为1400字节，不包括UDP和其他标头。
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和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从不发出大于路径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发现SRVRQST。SA必须能够响应TCP，除非SA永远不会收到超过数据报大小的请求或发送回复（例如，某些嵌入式系统）。
A TCP connection MAY be used for a single SLP transaction, or for multiple transactions. Since there are length fields in the message headers, SLP Agents can send multiple requests along a connection and read the return stream for acknowledgments and replies.
TCP连接可以用于单个SLP事务，也可以用于多个事务。由于消息头中有长度字段，SLP代理可以沿连接发送多个请求，并读取返回流以获得确认和回复。
The initiating agent SHOULD close the TCP connection. The DA SHOULD wait at least CONFIG_CLOSE_CONN seconds before closing an idle connection. DAs and SAs SHOULD close an idle TCP connection after CONFIG_CLOSE_CONN seconds to ensure robust operation, even when the initiating agent neglects to close it. See Section 13 for timing rules.
启动代理应关闭TCP连接。DA应在关闭空闲连接之前至少等待CONFIG_CLOSE_CONN秒。DAs和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.
无法引发响应的请求将被重新传输。初始重新传输发生在配置重试等待期之后。必须以指数增长的等待间隔（每次等待时间加倍）进行重新传输。这适用于单播和多播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的单播请求应重新传输，直到获得响应（可能是错误）为止，或者对于配置\重试\最大秒数。
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 seconds上重新发出多播请求，直到获得结果。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和ATTRQST消息是多播消息时，它们包含以前响应者的<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 seconds过去。
UAs which retransmit a request use the same XID. This allows a DA or SA to cache its reply to the original request and then send it again, should a duplicate request arrive. This cached information should only be held very briefly. XIDs SHOULD be randomly chosen to avoid
重新传输请求的UAs使用相同的XID。这允许DA或SA缓存其对原始请求的回复，然后在重复请求到达时再次发送。这些缓存的信息应该只保留很短的时间。应随机选择XID，以避免
duplicate XIDs in requests if UAs restart frequently.
如果UAs频繁重启，则在请求中复制XIDs。
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），后跟转义字符的两个十六进制数字。仅转义保留字符。例如，逗号（UTF-8 0x29）转义为“\29”，反斜杠“\”转义为“\5c”。SLP中使用的字符串列表将逗号定义为列表元素之间的分隔符，因此数据字符串中的逗号必须以这种方式转义。反斜杠是转义字符，因此当包含在字符串中时，它们也必须始终转义。
String comparison for order and equality in SLP MUST be case insensitive inside the 0x00-0x7F subrange of UTF-8 (which corresponds to ASCII character encoding). Case insensitivity SHOULD be supported throughout the entire UTF-8 encoded Unicode [6] character set.
在UTF-8的0x00-0x7F子范围内（对应于ASCII字符编码），SLP中顺序和相等的字符串比较必须不区分大小写。应在整个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.
不区分大小写规则适用于SLPv2中的所有字符串匹配，包括范围字符串、SLP SPI字符串、服务类型、查询处理中的属性标记和值、语言标记、以前的响应程序列表。然而，URL字符串的比较是区分大小写的。
White space (SPACE, CR, LF, TAB) internal to a string value is folded to a single SPACE character for the sake of string comparisons. White space preceding or following a string value is ignored for the purposes of string comparison. For example, " Some String " matches "SOME STRING".
为了进行字符串比较，字符串值内部的空白（空格、CR、LF、制表符）被折叠为单个空格字符。为了进行字符串比较，将忽略字符串值前面或后面的空白。例如，“Some String”匹配“Some String”。
String comparisons (using comparison operators such as `<=' or `>=') are done using lexical ordering in UTF-8 encoded characters, not using any language specific rules.
字符串比较（使用比较运算符，如“<=”或“>=”）是使用UTF-8编码字符中的词法排序完成的，而不是使用任何特定于语言的规则。
The reserved character `*' may precede, follow or be internal to a string value in order to indicate substring matching. The query including this character matches any character sequence which conforms to the letters which are not wildcarded.
保留字符“*”可以位于字符串值的前面、后面或内部，以指示子字符串匹配。包含此字符的查询匹配符合未通配符字母的任何字符序列。
Scope Lists in SLPv2 have the following grammar:
SLPv2中的作用域列表具有以下语法：
scope-list = scope-val / scope-val `,' scope-list
scope-val = 1*safe
safe = ; Any character except reserved.
reserved = `(' / `)' / `,' / `\' / `!' / `<' / `=' / `>' / `~' / CTL
/ `;' / `*' / `+'
escape-val = `\' HEXDIG HEXDIG
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.
包含任何保留字符的作用域必须用转义val格式替换转义字符。
If the Error Code in a SLP reply message is nonzero, the rest of the message MAY be truncated. No data is necessarily transmitted or should be expected after the header and the error code, except possibly for some optional extensions to clarify the error, for example as in section D.1.
如果SLP回复消息中的错误代码为非零，则消息的其余部分可能会被截断。在报头和错误代码之后不需要传输数据，也不应期望传输任何数据，但可能需要一些可选的扩展来澄清错误，如第D.1节中所述。
Errors are only returned for unicast requests. Multicast requests are silently discarded if they result in an error.
仅针对单播请求返回错误。如果多播请求导致错误，则会自动丢弃这些请求。
LANGUAGE_NOT_SUPPORTED = 1: There is data for the service type in the scope in the AttrRqst or SrvRqst, but not in the requested language. PARSE_ERROR = 2: The message fails to obey SLP syntax. INVALID_REGISTRATION = 3: The SrvReg has problems -- e.g., a zero lifetime or an omitted Language Tag. SCOPE_NOT_SUPPORTED = 4: The SLP message did not include a scope in its <scope-list> supported by the SA or DA. AUTHENTICATION_UNKNOWN = 5: The DA or SA receives a request for an unsupported SLP SPI. AUTHENTICATION_ABSENT = 6: The DA expected URL and ATTR authentication in the SrvReg and did not receive it. AUTHENTICATION_FAILED = 7: The DA detected an authentication error in an Authentication block. VER_NOT_SUPPORTED = 9: Unsupported version number in message header. INTERNAL_ERROR = 10: The DA (or SA) is too sick to respond. DA_BUSY_NOW = 11: UA or SA SHOULD retry, using exponential back off. OPTION_NOT_UNDERSTOOD = 12: The DA (or SA) received an unknown option from the mandatory range (see section 9.1). INVALID_UPDATE = 13: The DA received a SrvReg without FRESH set, for an unregistered service or with inconsistent Service Types. MSG_NOT_SUPPORTED = 14: The SA received an AttrRqst or SrvTypeRqst and does not support it. REFRESH_REJECTED = 15: The SA sent a SrvReg or partial SrvDereg to a DA more frequently than the DA's min-refresh-interval.
LANGUAGE_NOT_SUPPORTED=1:AttrRqst或SrvRqst中的作用域中存在服务类型的数据，但不是请求的语言。PARSE_ERROR=2：消息未能遵守SLP语法。无效的_注册=3：SrvReg存在问题——例如，零生存期或省略的语言标记。SCOPE_NOT_SUPPORTED=4:SLP消息在SA或DA支持的<SCOPE list>中未包含作用域。AUTHENTICATION_UNKNOWN=5：DA或SA接收到对不受支持的SLP SPI的请求。AUTHENTICATION_缺席=6:DA在SrvReg中需要URL和ATTR身份验证，但未收到。身份验证_FAILED=7:DA在身份验证块中检测到身份验证错误。VER_NOT_SUPPORTED=9：消息头中的版本号不受支持。内部_错误=10：DA（或SA）病得太重，无法响应。DA_BUSY_NOW=11:UA或SA应使用指数退避重试。选项_未_理解=12：DA（或SA）收到来自强制范围的未知选项（见第9.1节）。无效的_UPDATE=13：DA收到了一个SrvReg，该SrvReg没有新设置，用于未注册的服务或服务类型不一致。MSG_NOT_SUPPORTED=14:SA收到ATTRQST或SrvTypeRqst，不支持它。REFRESH_REJECTED=15：SA向DA发送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 \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Function-ID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length, contd.|O|F|R| reserved |Next Ext Offset|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Extension Offset, contd.| XID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Language Tag Length | Language Tag \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message Type Abbreviation Function-ID
消息类型缩写函数ID
Service Request SrvRqst 1 Service Reply SrvRply 2 Service Registration SrvReg 3 Service Deregister SrvDeReg 4 Service Acknowledge SrvAck 5 Attribute Request AttrRqst 6 Attribute Reply AttrRply 7 DA Advertisement DAAdvert 8 Service Type Request SrvTypeRqst 9 Service Type Reply SrvTypeRply 10 SA Advertisement SAAdvert 11
服务请求SrvRqst 1服务回复SrvRply 2服务注册SrvReg 3服务注销SrvDeReg 4服务确认SrvAck 5属性请求属性SRQST 6属性回复属性7 DA广告数据广告8服务类型请求SrvTypeRqst 9服务类型回复SrvTypeRply 10 SA广告SAAdvert 11
SAs and UAs MUST support SrvRqst, SrvRply and DAAdvert. SAs MUST also support SrvReg, SAAdvert and SrvAck. For UAs and SAs, support for other messages are OPTIONAL.
SAs和UAs必须支持SrvRqst、SrvRply和DAAD。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).
- Length是整个SLP消息的长度，包括标头。-标志为：当消息长度超过数据报中可以容纳的长度时，将设置溢出（0x80）。每个新SrvReg上都设置了FRESH（0x40）。在多播或广播请求时设置请求MCAST（0x20）。保留位必须为0。-除非使用扩展，否则“下一个扩展偏移”设置为0。第一个扩展从消息开头的“offset”字节开始。它放在SLP消息数据之后。有关如何解释无法识别的SLP扩展，请参见第9.1节。-对于每个唯一请求，XID都设置为唯一值。如果请求被重新传输，则使用相同的XID。回复将XID设置为与请求中的XID相同的值。仅发送未经请求的DAAD，XID为0。-Lang Tag Length是语言标记字段的字节长度。-语言标记符合[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_错误进行响应。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = SrvRqst = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <PRList> | <PRList> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <service-type> | <service-type> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <scope-list> | <scope-list> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of predicate string | Service Request <predicate> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <SLP SPI> string | <SLP SPI> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = SrvRqst = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <PRList> | <PRList> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <service-type> | <service-type> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <scope-list> | <scope-list> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of predicate string | Service Request <predicate> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <SLP SPI> string | <SLP SPI> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In order for a Service to match a SrvRqst, it must belong to at least one requested scope, support the requested service type, and match the predicate. If the predicate is present, the language of the request (ignoring the dialect part of the Language Tag) must match the advertised service.
为了使服务与SrvRqst匹配，它必须至少属于一个请求的作用域，支持请求的服务类型，并与谓词匹配。如果存在谓词，则请求的语言（忽略语言标记的方言部分）必须与播发的服务匹配。
<PRList> is the Previous Responder List. This <string-list> contains dotted decimal notation IP (v4) addresses, and is iteratively multicast to obtain all possible results (see Section 6.3). UAs SHOULD implement this discovery algorithm. SAs MUST use this to discover all available DAs in their scope, if they are not already configured with DA addresses by some other means.
<PRList>是以前的响应者列表。该<string list>包含点十进制表示法IP（v4）地址，并通过迭代多播获得所有可能的结果（见第6.3节）。UAs应该实现这个发现算法。如果SAs尚未通过其他方式配置DA地址，则必须使用此功能来发现其作用域中的所有可用DA。
A SA silently drops all requests which include the SA's address in the <PRList>. An SA which has multiple network interfaces MUST check if any of the entries in the <PRList> equal any of its interfaces. An entry in the PRList which does not conform to an IPv4 dotted decimal address is ignored: The rest of the <PRList> is processed normally and an error is not returned.
SA会自动删除<PRList>中包含SA地址的所有请求。具有多个网络接口的SA必须检查<PRList>中的任何条目是否等于其任何接口。PRList中不符合IPv4点十进制地址的条目将被忽略：<PRList>的其余部分将正常处理，不会返回错误。
Once a <PRList> plus the request exceeds the path MTU, multicast convergence stops. This algorithm is not intended to find all instances; it finds 'enough' to provide useful results.
一旦<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 list>是配置的作用域名称的<string list>。使用此列表中的任何作用域配置的SAs和DAs将响应。DAs和SAs必须使用
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>或未能包含其支持的范围，则出现SCOPE\u NOT\u 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.
第4节讨论了<service type>字符串。通常，SrvRqst会引发SrvRply。有两种例外情况：如果<service type>设置为“service:directory agent”，则DAs使用DAAdvert响应SrvRqst（参见第8.5节）。如果设置为“service:service agent”，则SAs使用SAAdvert响应（参见第8.6节）。如果省略此字段，则返回PARSE_错误-因为此字段是必需的。
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>的服务。如果存在，则将其与每个注册服务进行比较。如果过滤器中的属性已使用多个值注册，则将过滤器与每个值进行比较，并将结果一起进行OR运算，即，“x=3”匹配（x=1,2,3）的注册；“（！（Y=0））”匹配（Y=0,1），因为Y可以非零。注意，匹配不区分大小写。关键字（即没有值的属性）与“存在”过滤器匹配，如“（关键字=*）”。
An incoming request term MUST have the same type as the attribute in a registration in order to match. Thus, "(x=33)" will not match ' x=true', etc. while "(y=foo)" will match 'y=FOO'. "(|(x=33)(y=foo))" will be satisfied, even though "(x=33)" cannot be satisfied, because of the `|' (boolean disjunction).
传入请求术语必须与注册中的属性具有相同的类型才能匹配。因此，“（x=33）”将不匹配“x=true”，等等，而“（y=foo）”将匹配“y=foo”。“（|（x=33）（y=foo））”将得到满足，即使由于“|”（布尔析取）而无法满足“（x=33）”。
Wildcard matching MUST be done with the '=' filter. In any other case, a PARSE_ERROR is returned. Request terms which include wildcards are interpreted to be Strings. That is, (x=34*) would match 'x=34foo', but not 'x=3432' since the first value is a String while the second value is an Integer; Strings don't match Integers.
必须使用“=”筛选器进行通配符匹配。在任何其他情况下，都会返回PARSE_错误。包含通配符的请求术语被解释为字符串。也就是说，（x=34*）将匹配“x=34foo”，但不会匹配“x=3432”，因为第一个值是字符串，而第二个值是整数；字符串与整数不匹配。
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: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> =服务：pop3<s>=销售，默认值<p>=（用户=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）（速度>=1000））这将返回队列长度小于3且速度大于1000的备份服务。它将仅返回在BLDG 32范围内注册的服务。
<t>=service:directory-agent <s>=DEFAULT <p>= This returns DAAdverts for all DAs in the DEFAULT scope.
<t> =服务：目录代理<s>=默认值<p>=返回默认范围内所有DA的DAAD。
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.
通过发送服务类型设置为“服务：目录代理”的SrvRqst来发现DAs。如果SrvRqst中包含谓词，则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而无法返回任何答复，则响应程序将返回身份验证未知错误。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = SrvRply = 2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | URL Entry count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| <URL Entry 1> ... <URL Entry N> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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，则必须返回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.
URL条目中返回身份验证块，包括SrvRqst中的SLP SPI。如果请求中未包含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...\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = SrvReg = 3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| <URL-Entry> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of service type string | <service-type> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <scope-list> | <scope-list> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of attr-list string | <attr-list> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|# of AttrAuths |(if present) Attribute Authentication Blocks...\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The <entry> is a URL Entry (see section 4.3). The Lifetime defines how long a DA can cache the registration. SAs SHOULD reregister before this lifetime expires (but SHOULD NOT more often than once per second). The Lifetime MAY be set to any value between 0 and 0xffff (maximum, around 18 hours). Long-lived registrations remain stale longer if the service fails and the SA does not deregister the service.
<entry>是一个URL条目（参见第4.3节）。生存期定义DA可以缓存注册的时间。SAs应在此生存期到期之前重新注册（但频率不应超过每秒一次）。寿命可以设置为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配置的所有作用域的名称，它正在注册的DA支持这些作用域。<scope list>的默认值为“default”（参见第11节）。
The SA MUST register consistently with all DAs. If a SA is configured with scopes X and Y and there are three DAs, whose scopes are "X", "Y" and "X,Y" respectively, the SA will register the with all three DAs in their respective scopes. All future updates and deregistrations of the service must be sent to the same set of DAs in
SA必须与所有DAs一致注册。如果SA配置了作用域X和Y，并且有三个DAs，其作用域分别为“X”、“Y”和“X，Y”，SA将在各自的作用域中向所有三个DAs注册。将来对服务的所有更新和注销都必须发送到中的同一组DAs
the same scopes the service was initially registered in.
服务最初注册的作用域相同。
The <attr-list>, if present, specifies the attributes and values to be associated with the URL by the DA (see Section 5).
如果存在<attr 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。（如第8.5节所述，SA必须为其注册的所有DA获取DAAD，以获取DA的SLP SPI列表和属性）。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将拒绝这些SLP SPI，并回复一个没有身份验证的错误。
A registration with the FRESH flag set will replace *entirely* any previous registration for the same URL in the same language. If the FRESH flag is not set, the registration is an "incremental" registration (see Section 9.3).
使用FRESH标志集的注册将*完全*替换以前使用相同语言对相同URL的任何注册。如果未设置FRESH标志，则注册为“增量”注册（见第9.3节）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = SrvAck = 5) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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。它只携带一个两字节的错误代码（参见第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) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
当DAAD为多播时，错误代码设置为0。如果由于单播SrvRqst（即未设置请求MCAST标志的请求）而返回DAAD，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可以在DAAD中包括其属性的列表。此列表应保持简短，因为DAAD必须适合数据报才能进行多播。
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可随时使用一组新属性重新发布DAAD，以更改SA的重新注册行为。这些仅适用于后续注册；向DA注册的现有服务保留其注册寿命。
If the DAAdvert includes the attribute "min-refresh-interval" it MUST be set to a single Integer value indicating a number of seconds. If this attribute is present SAs MUST NOT refresh any particular service advertisement more frequently than this value. If SrvReg with the FRESH FLAG not set or SrvDereg with a non-empty tag list updating a
如果DAAdvert包含属性“min refresh interval”，则必须将其设置为指示秒数的单个整数值。如果存在此属性，SAs刷新任何特定服务公告的频率不得超过此值。如果未设置带有FRESH标志的SrvReg或带有非空标记列表的SrvDereg，则更新
particular service are received more often than the value for the DA's advertised "min-refresh-interval" attribute the DA SHOULD reject the message and return a REFRESH_REJECTED error in the SrvAck.
接收特定服务的频率高于DA公布的“最小刷新间隔”属性的值DA应拒绝消息并在SrvAck中返回refresh_REJECTED错误。
The URL is "service:directory-agent://"<addr> of the DA, where <addr> is the dotted decimal numeric address of the DA. The <scope-list> of the DA MUST NOT be NULL.
URL是DA的“服务：目录代理：/”<addr>，其中<addr>是DA的点状十进制数字地址。DA的<scope list>不能为空。
The SLP SPI List is the list of SPIs that the DA is capable of verifying. SAs MUST NOT register services with authentication blocks for those SLP SPIs which are not on the list. DAs will reject service registrations which they cannot verify, returning an AUTHENTICATION_UNKNOWN error.
SLP SPI列表是DA能够验证的SPI列表。SA不得向不在列表中的SLP SPI的身份验证块注册服务。DAs将拒绝无法验证的服务注册，并返回身份验证未知错误。
The format of DAAdvert signatures is defined in Section 9.2.1.
第9.2.1节定义了DAAD签名的格式。
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.
用于验证DAAD的SLP SPI包含在身份验证块中。当DAAD是多播时，它们可能必须传输多个DAAD身份验证块。如果DA配置为能够为多个SPI生成签名，则DA必须为每个SPI包含一个身份验证块。如果所有这些身份验证块不适合单个数据报（多播或广播），DA必须发送单独的DAAD，以便发送DA能够生成的所有SPI的身份验证块。
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.
如果DAAD是响应SrvRqst发送的，则如果DA配置为能够使用该SLP SPI生成数字签名，则DAAD仅包含SrvRqst中具有SLP SPI的身份验证块。如果SrvRqst单播到DA（未设置报头中的请求MCAST标志），并且包含不受支持的SLP SPI，DA将使用DAAD进行回复，错误代码设置为身份验证未知错误。
UAs SHOULD be configured with SLP SPIs that will allow them to verify DA Advertisements. If the UA is configured with SLP SPIs and receives a DAAdvert which fails to be verified using one of them, the UA MUST discard it.
UAs应配置SLP SPI，以允许其验证DA播发。如果UA配置了SLP SPI，并且接收到无法使用其中一个进行验证的DAAD，则UA必须放弃该DAAD。
User Agents MUST NOT solicit SA Advertisements if they have been configured to use a particular DA, if they have been configured with a <scope-list> or if DAs have been discovered. UAs solicit SA Advertisements only when they are explicitly configured to use User Selectable scopes (see Section 11.2) in order to discover the scopes that SAs support. This allows UAs without scope configuration to make use of either DAs or SAs without any functional difference
如果用户代理已配置为使用特定DA、已配置了<范围列表>或已发现DA，则不得请求SA播发。UAs仅在明确配置为使用用户可选择的作用域（参见第11.2节）以发现SAs支持的作用域时才会请求SA播发。这使得无范围配置的UAs可以在没有任何功能差异的情况下使用DAs或SAs
except performance.
除了表演。
A SA MAY be configured with attributes, and SHOULD support the attribute 'service-type' whose value is all the service types of services represented by the SA. SAs MUST NOT respond if the SrvRqst predicate is not satisfied. For example, only SAs offering 'nfs' services SHOULD respond with a SAAdvert to a SrvRqst for service type "service:service-agent" which includes a predicate "(service-type=nfs)".
SA可以配置属性，并且应该支持“服务类型”属性，该属性的值是SA表示的所有服务类型。如果SrvRqst谓词不满足，SA不得响应。例如，只有提供“nfs”服务的SAs才应使用SAAdvert对服务类型“service:service agent”的SrvRqst作出响应，该服务类型包括一个谓词（service type=nfs）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = SAAdvert = 11) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of URL | URL \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of <scope-list> | <scope-list> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of <attr-list> | <attr-list> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # auth blocks | authentication block (if any) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = SAAdvert = 11) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of URL | URL \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of <scope-list> | <scope-list> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of <attr-list> | <attr-list> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # auth blocks | authentication block (if any) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The SA responds only to multicast SA discovery requests which either include no <scope-list> or a scope which they are configured to use.
SA只响应多播SA发现请求，这些请求要么不包含<scope list>，要么包含配置为使用的作用域。
The SAAdvert MAY include a list of attributes the SA supports. This attribute list SHOULD be kept short so that the SAAdvert will not exceed the path MTU in size.
SAAdvert可能包括SA支持的属性列表。此属性列表应保持简短，以便SAAdvert的大小不会超过路径MTU。
The URL is "service:service-agent://"<addr> of the SA, where <addr> is the dotted decimal numeric address of the SA. The <scope-list> of the SA MUST NOT be null.
URL是SA的“service:service agent://”<addr>，其中<addr>是SA的点状十进制数字地址。SA的<scope list>不能为空。
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包含一个SAAdvert身份验证块，用于SA可以为其生成身份验证块的每个SLP SPI。如果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 \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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在回复中收到此选项，但不理解该选项，必须以静默方式放弃该回复。DA或SA在请求中收到此选项但不理解它必须返回一个选项未理解错误。0x8000-0x8FFF供私人使用（未标准化）。可选项来实现。如果无法识别，则忽略。0x9000-0xFFFF保留。
The three byte offset to next extension indicates the position of the next extension as offset from the beginning of the SLP message.
下一个扩展的三字节偏移量表示下一个扩展的位置与SLP消息开头的偏移量。
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 ... \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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注册数据（例如，属性值）通常不区分大小写，注册DA也必须保留注册数据的大小写，以便UAs能够验证用于计算数字签名数据的数据。
The Block Structure Descriptor (BSD) identifies the format of the Authenticator which follows. BSDs 0x0000-0x7FFF will be maintained by IANA. BSDs 0x8000-0x8FFF are for private use.
块结构描述符（BSD）标识后面的身份验证器的格式。BSD 0x0000-0x7FFF将由IANA维护。BSD 0x8000-0x8FFF仅供私人使用。
The Authentication Block Length is the length of the entire block, starting with the BSD.
身份验证块长度是整个块的长度，从BSD开始。
The Timestamp is the time that the authenticator expires (to prevent replay attacks.) The Timestamp is a 32-bit unsigned fixed-point number of seconds relative to 0h on 1 January 1970. SAs use this value to indicate when the validity of the digital signature expires. This Timestamp will wrap back to 0 in the year 2106. Once the value of the Timestamp wraps, the time at which the Timestamp is relative to resets. For example, after 06h28 and 16 seconds 5 February 2106, all Timestamp values will be relative to that epoch date.
时间戳是验证器过期的时间（以防止重播攻击）。时间戳是相对于1970年1月1日0h的32位无符号定点秒数。SAs使用此值指示数字签名的有效期何时到期。这个时间戳将在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 SPI必须是唯一的。用于BSD=0x0002的SLP SPI不得与用于其他某些BSD的SLP SPI相同。
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必须在未经请求的DAAD中使用DSA身份验证块。
The sections below define how to calculate the value to apply to the algorithm identified by the BSD value. The components listed are used as if they were a contiguous single byte aligned buffer in the order given.
以下各节定义了如何计算应用于由BSD值标识的算法的值。所列组件的使用就像它们是按给定顺序排列的连续单字节对齐缓冲区一样。
URL 16-bit Length of SLP SPI String, SLP SPI String. 16-bit Length of URL, URL, 32-bit Timestamp.
SLP SPI字符串的URL 16位长度，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.
属性列表SLP SPI字符串的16位长度，SLP SPI字符串，<attr List>的16位长度，<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.
DAAD SLP SPI字符串的16位长度、SLP SPI字符串、32位DA无状态启动时间戳、URL的16位长度、URL的16位长度<attr list>、<attr list>、DA的16位长度<scope list>、DA的<scope list>、DA的16位长度<SLP SPI list>、DA的<SLP SPI list>、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指示用于验证DAAD的键控材料和其他参数。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 list>，<attr list>，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 }
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:
i、 例如，ASN.1编码为1.2.840.10040.4.3，紧接着是：
Dss-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
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].
i、 例如，使用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 \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASN.1 encoded DSA signature \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Incremental registrations update attribute values for a previously registered service. Incremental service registrations are useful when only a single attribute has changed, for instance. In an incremental registration, the FRESH flag in the SrvReg header is NOT set.
增量注册更新以前注册的服务的属性值。例如，当只有单个属性发生更改时，增量服务注册非常有用。在增量注册中，未设置SrvReg头中的FRESH标志。
The new registration's attributes replace the previous registration's, but do not affect attributes which were included previously and are not present in the update.
新注册的属性将替换以前注册的属性，但不会影响以前包含且不在更新中的属性。
For example, suppose service:x://a.org has been registered with attributes A=1, B=2, C=3. If an incremental registration comes for service:x://a.org with attributes C=30, D=40, then the attributes for the service after the update are A=1, B=2, C=30, D=40.
例如，假设服务：x://a.org已经注册了属性a=1、B=2、C=3。如果服务：x://a.org的增量注册带有属性C=30，D=40，则更新后服务的属性为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头集中设置FRESH标志。接收此类注册消息的DAs返回身份验证失败错误。
If the FRESH flag is not set and the DA does not have a prior registration for the service, the incremental registration fails with error code INVALID_UPDATE.
如果未设置FRESH标志，且DA未事先注册服务，则增量注册将失败，错误代码为INVALID\ U 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\u not\u 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将返回无效的_更新错误。
Tag lists are used in SrvDeReg and AttrReq messages. The syntax of a <tag-list> item is:
标记列表用于SrvDeReg和AttrReq消息。<tag list>项的语法为：
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).
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".
<tag list>项中的通配符匹配任意字符序列。例如，“*bob*”匹配“我认识的一些bob”、“大bob”、“bobby”和“bob”。
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 \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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命名权限的服务类型不包括命名权限字符串。
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 \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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字段可以采用两种形式。它可以只是一种服务类型（参见第4.1节），例如“http”或“服务：tftp”。在这种情况下，将返回给定服务类型的所有服务的所有属性和每个属性的完整值范围。
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字段也可以是完整的URL，例如“服务：打印机：lpr://igore.wco.ftp.com:515/draft“或”nfs://max.net/znoo". 在这种情况下，只返回指定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.
<tag list>字段是属性标记的<string list>，如第9.4节所定义，它指示属性列表中要返回的属性。如果省略<tag list>，则返回所有属性<当包含SLP SPI列表字符串时，必须省略标记列表>，并且必须在属性中包含完整的URL，否则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 = AttrRply = 7) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | length of <attr-list> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| <attr-list> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|# of AttrAuths | Attribute Authentication Block (if present) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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)".
应仅返回每个属性标记或字符串值的一个副本，任意选择一个版本（相对于字符串内部的大小写和空白）：应删除重复的属性和值。为合并选择任意版本的字符串值和标记名。例如：“（A=aa，b）”与“（A=aa，b）”合并可能产生“（A=aa，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
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
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
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
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”以英语和德语注册。操作员属性值中的“<”和“>”字符是电子邮件地址的一部分，必须转义，因为它们是值的保留字符。
Attribute tags are not translated, though attribute values may be, see [13].
属性标记不会被转换，尽管属性值可能会被转换，请参见[13]。
The attribute Request:
属性请求：
URL = service:printer:lpr://igore.wco.ftp.com/draft
scope-list = Development
Lang. Tag = de
tag-list = resolution,loc*
URL = 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)
(location-description=13te Etage),(resolution=res-600)
The attribute Request:
属性请求：
URL = service:printer
scope-list = Development
Lang. Tag = en
tag-list = x-*,resolution,protocol
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
(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".
第一个请求由服务实例发出，并以德语返回请求的值。第二个请求是按抽象服务类型（参见第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.
如果可以返回ATTRQST中具有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.
如果ATTRQST在请求中包含完整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返回身份验证块，则会返回身份验证未知错误。如果未包含任何身份验证块，则将#of 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> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
如果DA没有响应，SA必须重试，请参阅第12.3节。DA用SrvAck确认SrvDeReg。SA收到指示成功的确认后，DA将不再播发服务和/或属性。DA从以前注册的SrvDeReg中指定的每个作用域中注销服务或服务属性。
The SA MUST deregister all services with the same scope list used to register the service with a DA. If this is not done in the SrvDeReg message, the DA returns a SCOPE_NOT_SUPPORTED error. The Lifetime field in the URL Entry is ignored for the purposes of the SrvDeReg.
SA必须注销与DA注册服务所用作用域列表相同的所有服务。如果在SrvDeReg消息中未执行此操作，DA将返回一个SCOPE_not_SUPPORTED错误。出于SrvDeReg的目的，URL条目中的生存期字段被忽略。
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.
<tag list>是第9.4节中定义的要注销的属性标签的<string list>。如果不存在<tag list>，SrvDeReg将以其已注册的所有语言注销该服务。如果存在<tag list>，则SrvDeReg将取消注册其标签在标签规范中列出的属性。使用身份验证块注册的服务不得在SrvDeReg消息中包含<tag list>：在这种情况下，DA将响应身份验证失败错误。
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.
如果要注销的服务已使用一个或多个身份验证块注册，则SrvDeReg中必须包含每个已注册SLP SPI的URL身份验证块。否则，DA将返回一个身份验证错误。如果DA未能验证消息，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".
作用域是一组服务。作用域的主要用途是提供创建服务管理分组的能力。网络管理员可以为一组服务分配一个作用域。查找服务的客户端配置为使用一个或多个作用域。用户将只发现那些已配置供其使用的服务。通过使用作用域配置UAs和SAs，管理员可以提供服务。作用域字符串不区分大小写。默认范围字符串为“default”。
Scopes are the primary means an administrator has to scale SLP deployments to larger networks. When DAs with NON-DEFAULT scopes are present on the network, further gains can be had by configuring UAs and SAs to have a predefined non-default scope. These agents can then perform DA discovery and make requests using their scope. This will limit the number of replies.
作用域是管理员将SLP部署扩展到更大网络的主要手段。当网络上存在具有非默认作用域的DAs时，通过将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消息将被丢弃（如果请求是多播的）或返回不支持作用域的错误（如果请求是单播的）。每个SrvRqst（DA和SA发现请求除外）、SrvReg、ATTRQST、SrvTypeRqst、DAAdvert和SAAdvert消息必须包含一个<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必须将其SLP消息单播到支持所需范围的DA，而不是将请求多播到SAs。如果UA配置使用的作用域中没有可用的DA，则UA可以多播该请求。
All requests and services are scoped. The two exceptions are SrvRqsts for "service:directory-agent" and "service:service-agent". These MAY have a zero-length <scope-list> when used to enable the user to make scope selections. In this case UAs obtain their scope list from DAAdverts (or if DAs are not available, from SAAdverts.)
所有请求和服务都有作用域。这两个例外是“服务：目录代理”和“服务：服务代理”的SRVRQST。当用于使用户能够进行范围选择时，它们的长度可能为零。在这种情况下，UAs从DAAdverts获取其范围列表（如果DAs不可用，则从SAAdverts获取）
Otherwise, if SAs and UAs are to use any scope other than the default (i.e., "DEFAULT"), the UAs and SAs are configured with lists of scopes to use by system administrators, perhaps automatically by way of DHCP option 78 or 79 [21]. Such administrative scoping allows services to be provisioned, so that users will only see services they are intended to see.
否则，如果SAs和UAs要使用默认（即“默认”）以外的任何作用域，则UAs和SAs将配置系统管理员使用的作用域列表，可能会通过DHCP选项78或79自动配置[21]。这样的管理范围允许配置服务，以便用户只能看到他们想要看到的服务。
User configurable scopes allow a user to discover any service, but require them to do their own selection of scope. This is similar to the way AppleTalk [12] and SMB [19] networking allow user selection of AppleTalk Zone or workgroups.
用户可配置的作用域允许用户发现任何服务，但要求他们自己选择作用域。这类似于AppleTalk[12]和SMB[19]网络允许用户选择AppleTalk区域或工作组的方式。
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).
请注意，这两个配置选项不兼容。一种模型允许管理员控制服务提供。其他人将此委托给用户（用户可能不准备对其系统进行任何配置）。
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提供了进一步的可扩展性和操作的健壮性，因为它们可以在其中一个DAs出现故障时存储同一SAs的服务信息。
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的SA必须单播SrvRqst到DA。SrvRqst省略作用域列表，并将请求的服务类型设置为“服务：目录代理”。DA将返回一个DAAD及其属性、SLP SPI列表和其他参数，这些参数对于SA到DA的正确通信至关重要。
Passive detection of DAs by SAs enables services to be advertised consistently among DAs of the same scope. Advertisements expire if not renewed, leaving only transient stale registrations in DAs, even
SAs对DAs的被动检测使服务能够在同一范围内的DAs之间一致地发布。广告如果不更新就会过期，甚至在DAs中只留下短暂的过期注册
in the case of a failure of a SA.
如果SA出现故障。
A single DA can support many UAs. UAs send the same requests to DAs that they would send to SAs and expect the same results. DAs reduce the load on SAs, making simpler implementations of SAs possible.
一个DA可以支持多个UAs。UAs向DAs发送与向SAs发送相同的请求，并期望得到相同的结果。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必须向支持其一个或多个作用域的DAs注册其服务。
UAs MUST unicast requests directly to a DA (when scoping rules allow), hence avoiding using the multicast convergence algorithm, to obtain service information. This decreases network utilization and increases the speed at which UAs can obtain service information.
UAs必须将请求直接单播到DA（在范围规则允许的情况下），从而避免使用多播聚合算法来获取服务信息。这降低了网络利用率，提高了UAs获取服务信息的速度。
DAs MUST flush service advertisements once their lifetime expires or their URL Authentication Block "Timestamp" of expiration is past.
DAs必须在其生命周期到期或其URL身份验证块“时间戳”过期后刷新服务广告。
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.
DAAD必须包括DA无状态启动时间戳，格式与身份验证块相同（见第9.2节）。身份验证块中的时间戳表示以前所有注册丢失的时间（即最后一次无状态重新启动）。DAAD中的时间戳设置为0，以通知UAs和SAs DA正在关闭。如果DAs在没有服务注册状态的情况下关闭并重新启动，则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>未被省略且（b）未包含配置为使用的作用域，则接收服务类型“service:directory agent”的多播SrvRqst的DAs必须以静默方式放弃它。否则，DA必须以DAAD响应。
DAs MUST respond to AttrRqst and SrvTypeRqst messages (these are OPTIONAL only for SAs, not DAs.)
DAs必须响应ATTRQST和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可以使用静态配置、DHCP选项78和79或使用第6.3节中的收敛算法通过多播（或广播）服务请求发现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节描述了SA如何减少其必须向DAs重新注册以响应未经请求的DAAD的次数。
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必须在每个配置节拍中发送一次未经请求的DAAD。未经请求的DAAD的XID为0。SA必须按照第8.5节所述被动监听DAAD。UAs可能会这样做。但是，如果他们不收听未经请求的DAs广告，他们将无法在DAs可用时发现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的位置。例如：“服务：目录”-agent://foobawooba.org".
The following sections suggest timing algorithms which enhance the scalability of SLP.
以下各节介绍了增强SLP可扩展性的定时算法。
After a UA or SA restarts, its initial DA discovery request SHOULD be delayed for some random time uniformly distributed from 0 to CONFIG_START_WAIT seconds.
UA或SA重新启动后，其初始DA发现请求应延迟一段随机时间，从0到CONFIG_START_WAIT秒均匀分布。
The UA or SA sends the DA Discovery request using a SrvRqst, as described in Section 8.1. DA Discovery requests MUST include a Previous Responder List. SrvRqsts for Active DA Discovery SHOULD NOT be sent more than once per CONFIG_DA_FIND seconds.
UA或SA使用SrvRqst发送DA发现请求，如第8.1节所述。DA发现请求必须包括以前的响应者列表。用于活动DA查找的SRVRQST不应每配置DA查找秒发送一次以上。
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必须每隔几秒钟多播（或广播）一个未经请求的DAAD。应指定CONFIG_DA_BEAT，以防止DAAD使用超过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.
所有接收未经请求的DAAD的UAs和SA都应检查其DA无状态启动时间戳。如果设置为0，则DA将关闭，不应再向其发送任何消息。
If a SA detects a DA it has never encountered (with a nonzero timestamp,) the SA must register with it. SAs MUST examine the DAAdvert's timestamp to determine if the DA has had a stateless reboot since the SA last registered with it. If so it registers with the DA. SAs MUST wait a random interval between 0 and CONFIG_REG_PASSIVE before beginning DA registration.
如果SA检测到从未遇到过的DA（时间戳为非零），则SA必须向其注册。SAs必须检查DAAD的时间戳，以确定自SA上次向其注册以来，DA是否已无状态重新启动。如果是这样，则向DA注册。在开始DA注册之前，SAs必须等待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 seconds中响应单播UDP消息，则应重试该消息。每次后续重传的等待间隔必须以指数形式增加，每次增加一倍。如果DA或SA在CONTIGRESYLYXMAX秒之后没有响应，发送方应该考虑接收器已经下降。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不应在coresident 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保护通过身份验证块进行的注册。如果服务已注册，则后续注册（将替换adertisement）或注销（将删除它）必须包括具有相应SLP SPI的身份验证块，请参见第8.3节和第10.6节。
Example:
例子：
A DA is configured to be able to verify Authentication Blocks with SLP SPIs "X,Y", that is X and Y.
DA被配置为能够使用SLP SPI“X，Y”，即X和Y来验证认证块。
An SA registers a service with an Authentication Block with SPI "Z". The DA stores the registration, but discards the Authentication Block. If a UA requests a service with an SLP SPI string "Z", the DA will respond with an AUTHENTICATION_UNKNOWN error.
SA使用SPI“Z”向身份验证块注册服务。DA存储注册，但丢弃身份验证块。如果UA使用SLP SPI字符串“Z”请求服务，DA将以身份验证未知错误进行响应。
An SA registers a service S with Authentication Blocks including SLP SPIs "X" and "Y". If a UA requests a service with an SLP SPI string "X" the DA will be able to return S (if the service type, language, scope and predicate of the SrvRqst match S) The DA will also return the Authentication Block with SLP SPI set to "X". If the DA receives a subsequent SrvDeReg for S (which will remove the advertisement) or a subsequent SrvReg for S (which will replace it), the message must include two URL Authentication Blocks, one each for SPIs "X" and "Y". If either of these were absent, the DA would return an AUTHENTICATION_ABSENT error.
SA使用包括SLP SPIs“X”和“Y”的认证块注册服务S。如果UA请求具有SLP SPI字符串“X”的服务，DA将能够返回S（如果SrvRqst的服务类型、语言、范围和谓词与S匹配），DA还将返回SLP SPI设置为“X”的身份验证块。如果DA收到S的后续SrvDeReg（将删除广告）或S的后续SrvReg（将替换它），则消息必须包括两个URL身份验证块，SPI“X”和“Y”各一个。如果其中任何一个不存在，DA将返回一个身份验证不存在错误。
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.
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 UA或SA应可配置为使用预定义DA。
No DA Discovery The UA or SA SHOULD be configurable to ONLY use predefined and DHCP-configured DAs and perform no active or passive DA discovery.
无DA发现UA或SA应可配置为仅使用预定义和DHCP配置的DA，而不执行主动或被动DA发现。
Multicast TTL The default multicast TTL is 255. Agents SHOULD be configurable to use other values. A lower value will focus the multicast convergence algorithm on smaller subnetworks, decreasing the number of responses and increases the performance of service location. This may result in UAs obtaining different results for the identical requests depending on where they are connected to the network.
多播TTL默认多播TTL为255。代理应可配置为使用其他值。较低的值将使多播收敛算法集中在较小的子网上，从而减少响应数量并提高服务位置的性能。这可能导致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.
作用域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。如果使用DHCP配置DA位置，则应优先使用这些位置，而不是主动或被动查找DAs。请求中必须使用使用DHCP配置的一个或多个作用域。注册和DA配置消息中必须使用整个配置的<scope list>。
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都将配置适当的公钥，以验证这些SA生成的签名。这是在没有公钥基础结构的情况下配置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应可配置为支持上述SLP SPI，以便在发现DAs时使用。此SPI应在SRVRQST中发送以发现DAs，并用于验证多播DAAD消息。
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注册的标识符。在每种情况下都注明了这些注册的政策（见[18]）。
The Block Structure Descriptor (BSD) identifies the format of the Authenticator which follows. BSDs 0x8000-0x8FFF are for Private Use.
块结构描述符（BSD）标识后面的身份验证器的格式。BSD 0x8000-0x8FFF仅供私人使用。
Further Block Structured Descriptor (BSD) values, from the range 0x0003-0x7FFF may be standardized in the future by submitting a document which describes:
将来，可以通过提交描述以下内容的文档，对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 Consenus分配加密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或ATTRQST的语言用于满足请求。如果请求的语言不受支持，则返回“语言不受支持”错误。SrvRply和ATTRPLY消息始终使用请求的相同语言。
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.
服务位置不提供机密性。由于此协议的目标是向用户社区公布服务，因此在非敏感环境中使用此协议时，通常不需要保密。如果将来需要，专门计划可能能够提供保密性。需要保密的站点应实施IP封装安全有效负载（ESP）[3]，为服务位置消息提供保密性。
If Agents are not configured to generate Authentication Blocks and Agents are not configured to verify them, an adversary might easily use this protocol to advertise services on servers controlled by the adversary and thereby gain access to users' private information. Further, an adversary using this protocol will find it much easier to engage in selective denial of service attacks. Sites that are in potentially hostile environments (e.g., are directly connected to the Internet) should consider the advantages of distributing keys associated with SLP SPIs prior to deploying the sensitive directory agents or service agents.
如果代理未配置为生成身份验证块，并且代理未配置为验证身份验证块，则对手可能很容易使用此协议在对手控制的服务器上公布服务，从而获得对用户私有信息的访问。此外，使用此协议的对手将发现更容易进行选择性拒绝服务攻击。在潜在的敌对环境中（例如，直接连接到Internet）的站点应该考虑在部署敏感目录代理或服务代理之前分发与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之前与终端系统预配置时，才有可能获得与使用身份验证块相关的好处。
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]，该模板明确指定没有与服务公告关联的属性。与指定属性的服务模板关联的服务类型不得由不支持属性的SA播发。
While discovery of service by service type is a subset of the features possible using SLPv2 this form of discovery is consistent with the current generation of products that allow simple browsing of all services in a 'zone' or 'workgroup' by type. In some cases, attribute discovery, security and feature negotiation is handled by
虽然按服务类型发现服务是使用SLPv2可能的功能的子集，但这种发现形式与当前一代产品一致，允许按类型简单浏览“区域”或“工作组”中的所有服务。在某些情况下，属性发现、安全性和功能协商由
application layer protocols - all that is required is the basic discovery of services that support a certain service.
应用层协议—所需的只是基本发现支持特定服务的服务。
UAs requesting only service of that service type would only need to support service type and scope fields of the Service Request. UAs would still perform DA discovery and unicast SLPv2 SrvRqst messages to DAs in their scope once they were discovered instead of multicasting them.
仅请求该服务类型的服务的UAs只需要支持服务请求的服务类型和范围字段。一旦发现DA发现和单播SLPv2 SrvRqst消息，UAs将在其作用域内执行DA发现和单播，而不是多播。
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.
这些最小SA可以忽略请求中的语言标记，因为SrvRqst消息将不包含属性，因此不会国际化任何字符串。此外，任何非null谓词字符串都无法匹配没有属性的服务广告，因此这些SA不必解析和解释搜索过滤器。SrvRqst、SrvRply或SrvReg消息中永远不会发生溢出，因此不必实现TCP消息处理。最后，SA可以删除所有ATTRQST消息，因为不支持任何属性。
C. Appendix: DAAdverts with arbitrary URLs
C.附录：带有任意URL的DAAD广告
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的服务类型字段设置为“服务：目录代理”。DAs将用一个包含“服务：目录代理：”方案的URL的DAAD进行响应。这与此类DA将在未经请求的DA广告中多播的DA广告相同。
A UA or SA which receives an unsolicited DAAdvert MUST examine the URL to determine if it has a recognized scheme. If the UA or SA does not recognize the DAAdvert's URL scheme, the DAAdvert is silently discarded. This document specifies only how to use URLs with the "service:directory-agent:" scheme.
收到未经请求的DAAD的UA或SA必须检查URL，以确定其是否具有可识别的方案。如果UA或SA不识别DAAdvert的URL方案，DAAdvert将被自动丢弃。本文档仅指定如何将URL与“服务：目录代理：”方案一起使用。
This provides the possibility for forward compatibility with future versions of SLP and enables other services to advertise their ability to serve as a clearinghouse for service location information.
这提供了与未来版本的SLP向前兼容的可能性，并使其他服务能够宣传其作为服务位置信息交换所的能力。
For example, if LDAPv3 [15] is used for service registration and discovery by a set of end systems, they could interpret a LDAP URL [16] to passively discover the LDAP server to use for this purpose. This document does not specify how this is done: SLPv2 agents without further support would simply discard this DAAdvert.
例如，如果一组终端系统将LDAPv3[15]用于服务注册和发现，则它们可以解释LDAP URL[16]以被动地发现用于此目的的LDAP服务器。本文档未指定如何执行此操作：没有进一步支持的SLPv2代理只会丢弃此DAAD。
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> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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，但该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.'
Template IDVer字符串是服务模板的名称和版本号字符串，它根据需要定义给定属性。它应该包括在内，但如果给定的SA或DA已单独配置为具有“必需属性”，则可以省略
The Required Attribute <tag-list> MUST NOT include wild cards.
所需属性<tag list>不得包含通配符。
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的PDS。我们感谢叶谷和彼得·福特的贡献。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。证书扩展。ISO/IEC 9594-2的DAM 4修正草案，1996年12月。
[3] ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment DAM 2 to ISO/IEC 9594-6, December 1996.
[3] ISO/IEC JTC1/SC 21。证书扩展。ISO/IEC 9594-6 DAM 2修订草案，1996年12月。
[4] ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment DAM 1 to ISO/IEC 9594-7, December 1996.
[4] ISO/IEC JTC1/SC 21。证书扩展。ISO/IEC 9594-7 DAM 1修订草案，1996年12月。
[5] ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment DAM 1 to ISO/IEC 9594-8, December 1996.
[5] ISO/IEC JTC1/SC 21。证书扩展。ISO/IEC 9594-8的DAM 1修订草案，1996年12月。
[6] Unicode Technical Report #8. The Unicode Standard, version 2.1. Technical report, The Unicode Consortium, 1998.
[6] Unicode技术报告#8。Unicode标准，版本2.1。技术报告，Unicode联合会，1998年。
[7] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995.
[7] Alvestrand，H.，“语言识别标签”，RFC1766，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.和L.Masinter，“统一资源标识符（URI）：通用语法”，RFC 2396，1998年8月。
[9] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[9] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[10] CCITT. The Directory Authentication Framework. Recommendation X.509, 1988.
[10] 赛特。目录身份验证框架。建议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内部。艾迪生·韦斯利，1990年。
[13] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and service: Schemes", RFC 2609, June 1999.
[13] Guttman，E.，Perkins，C.和J.Kempf，“服务模板和服务：方案”，RFC 26091999年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.Kille，“轻量级目录访问协议（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中编写IANA注意事项部分的指南，BCP 26，RFC 2434，1998年10月。
[19] Microsoft Networks. SMB File Sharing Protocol Extensions 3.0, Document Version 1.09, November 1989.
[19] 微软网络公司。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.和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.和S.Kaplan，“服务位置协议”，RFC 21651997年7月。
[23] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[23] “UTF-8，ISO 10646的转换格式”，RFC 2279，1998年1月。
G. Authors' Addresses
G.作者地址
Erik Guttman Sun Microsystems Bahnstr. 2 74915 Waibstadt Germany
埃里克·古特曼太阳微系统公司。274915德国威伯斯塔特
Phone: +49 7263 911 701
EMail: Erik.Guttman@sun.com
Phone: +49 7263 911 701
EMail: Erik.Guttman@sun.com
Charles Perkins Sun Microsystems 901 San Antonio Road Palo Alto, CA 94040 USA
美国加利福尼亚州帕洛阿尔托市圣安东尼奥路901号Charles Perkins Sun Microsystems 94040
Phone: +1 650 786 6464
EMail: cperkins@sun.com
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号，邮编94043
Phone: +1 650 569 5243
EMail: veizades@home.net
Phone: +1 650 569 5243
EMail: veizades@home.net
Michael Day Vinca Corporation. 1201 North 800 East Orem, Utah 84097 USA
迈克尔·戴文卡公司。美国犹他州东奥勒姆北800号1201 84097
Phone: +1 801 376-5083
EMail: mday@vinca.com
Phone: +1 801 376-5083
EMail: mday@vinca.com
H. Full Copyright Statement
H.完整的版权声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。”
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。