Network Working Group E. Guttman
Request for Comments: 3224 Sun Microsystems
Updates: 2608 January 2002
Category: Standards Track
Network Working Group E. Guttman
Request for Comments: 3224 Sun Microsystems
Updates: 2608 January 2002
Category: Standards Track
Vendor Extensions for 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 (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document specifies how the features of the Service Location Protocol, Version 2 allow for vendor extensibility safely, with no possibility of collisions. The specification introduces a new SLPv2 extension: The Vendor Opaque Extension. While proprietary protocol extensions are not encouraged by IETF standards, it is important that they not hinder interoperability of compliant implementations when they are undertaken. This document udpates RFC 2608, "The Service Location Protocol."
本文档指定了服务位置协议（版本2）的功能如何安全地允许供应商扩展，而不会发生冲突。该规范引入了一个新的SLPv2扩展：供应商不透明扩展。虽然IETF标准不鼓励专有协议扩展，但重要的是，在进行这些扩展时，它们不会妨碍兼容实现的互操作性。本文档介绍RFC 2608“服务位置协议”
Table of Contents
目录
1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . 2
2.0 Enterprise Numbers . . . . . . . . . . . . . . . . . . . . . 3
3.0 Naming Authorities . . . . . . . . . . . . . . . . . . . . . 3
4.0 Vendor Defined Attributes . . . . . . . . . . . . . . . . . 4
5.0 Vendor Opaque Extension . . . . . . . . . . . . . . . . . . 5
5.1 Vendor Opaque Extension Format . . . . . . . . . . . . . . 6
5.2 Example: Acme Extension for UA Authentication . . . . . . . 6
6.0 Extensions Requiring IETF Action . . . . . . . . . . . . . . 7
7.0 IANA Considerations . . . . . . . . . . . . . . . . . . . . 7
8.0 Security Considerations . . . . . . . . . . . . . . . . . . 8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 8
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 10
1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . 2
2.0 Enterprise Numbers . . . . . . . . . . . . . . . . . . . . . 3
3.0 Naming Authorities . . . . . . . . . . . . . . . . . . . . . 3
4.0 Vendor Defined Attributes . . . . . . . . . . . . . . . . . 4
5.0 Vendor Opaque Extension . . . . . . . . . . . . . . . . . . 5
5.1 Vendor Opaque Extension Format . . . . . . . . . . . . . . 6
5.2 Example: Acme Extension for UA Authentication . . . . . . . 6
6.0 Extensions Requiring IETF Action . . . . . . . . . . . . . . 7
7.0 IANA Considerations . . . . . . . . . . . . . . . . . . . . 7
8.0 Security Considerations . . . . . . . . . . . . . . . . . . 8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 8
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 10
The Service Location Protocol, Version 2 [1] defines a number of features which are extensible. This document clarifies exactly which mechanisms can be used to that end (Sections 3-5) and which cannot (Section 6). This document updates [1], specifying conventions that ensure the protocol extension mechanisms in the SLPv2 specification will not possibly have ambiguous interpretations.
服务位置协议版本2[1]定义了许多可扩展的功能。本文件明确说明了哪些机制可用于此目的（第3-5节），哪些机制不能用于此目的（第6节）。本文档更新了[1]，指定了确保SLPv2规范中的协议扩展机制不可能有模糊解释的约定。
This specification introduces only one new protocol element, the Vendor Opaque Extension. This Extension makes it possible for a vendor to extend SLP independently, once the vendor has registered itself with IANA and obtained an Enterprise Number. This is useful for vendor-specific applications.
本规范只引入了一个新的协议元素，即供应商不透明扩展。一旦供应商在IANA注册并获得企业编号，此扩展使供应商可以独立扩展SLP。这对于特定于供应商的应用程序非常有用。
Vendor extensions to standard protocols come at a cost.
供应商对标准协议的扩展是有代价的。
- Vendor extensions occur without review from the community. They may not make good engineering sense in the context of the protocol they extend, and the engineers responsible may discover this too late.
- 供应商扩展未经社区审查。在他们扩展的协议的上下文中，他们可能没有很好的工程意义，而负责的工程师可能发现这一点太晚了。
- Vendor extensions preclude interoperation with compliant but non-extended implementations. There is a real danger of incompatibility if different implementations support different feature sets.
- 供应商扩展排除了与兼容但未扩展的实现的互操作。如果不同的实现支持不同的功能集，则存在不兼容的真正危险。
- By extending SLPv2 privately, ubiquitous automatic configuration is impossible, which is the primary benefit of a standard service discovery framework.
- 通过私下扩展SLPv2，不可能实现无处不在的自动配置，这是标准服务发现框架的主要优点。
For these reasons, registration of service templates with IANA is strongly encouraged! This process is easy and has proved to be rapid (taking less than 2 weeks in most cases).
出于这些原因，强烈建议向IANA注册服务模板！这一过程很简单，而且被证明是快速的（在大多数情况下不到2周）。
In this document, the key words "MAY", "MUST", "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [2].
在本文件中，关键词“可能”、“必须”、“不得”、“可选”、“建议”、“应该”和“不应该”的解释如[2]所述。
Service Location Protocol terminology is defined in [1]. IANA registration terminology is defined in [5].
[1]中定义了服务位置协议术语。IANA注册术语定义见[5]。
Enterprise Numbers are used to distinguish different vendors in IETF protocols. Vendor Extensions to SLPv2 SHOULD use these values to avoid any possibility of a name space collision. Each vendor is responsible for ensuring that vendor extensions under their own authority are non-conflicting.
企业编号用于区分IETF协议中的不同供应商。SLPv2的供应商扩展应使用这些值，以避免名称空间冲突的任何可能性。每个供应商负责确保其自身权限下的供应商扩展不冲突。
IANA maintains a repository of all 'SMI Network Management Private Enterprise Codes,' whose prefix is iso.org.dod.internet.private.enterprise (1.3.6.1.4.1). The number which follows is unique and may be registered by an on-line form [3].
IANA维护着所有“SMI网络管理私有企业代码”的存储库，其前缀为iso.org.dod.internet.Private.Enterprise（1.3.6.1.4.1）。下面的号码是唯一的，可以通过在线表格注册[3]。
The complete up-to-date list of Enterprise Numbers is maintained by IANA [3].
IANA维护完整的最新企业编号列表[3]。
Naming Authorities are defined by SLPv2 [1] as an agency or group which catalogues Service Types and attributes.
命名机构由SLPv2[1]定义为对服务类型和属性进行编目的机构或组。
A Service Type is a string representing a service which can be discovered by SLPv2. Attributes may be associated with a particular Service Type which is advertised by SLPv2.
服务类型是表示SLPv2可以发现的服务的字符串。属性可以与SLPv2公布的特定服务类型相关联。
Service Type strings and service attributes may be registered with IANA by creating a Service Template [4]. The template is included in an internet draft and an email message is sent to srvloc-list@iana.org requesting that the template be included in the Service Template registry. In this case, the naming authority for the service type is IANA.
可以通过创建服务模板向IANA注册服务类型字符串和服务属性[4]。该模板包含在互联网草案中，并向srvloc发送电子邮件-list@iana.org请求将模板包括在服务模板注册表中。在这种情况下，服务类型的命名机构是IANA。
It is also possible for a Vendor to create their own naming authority. In this case, any service type or attribute may be used. SLPv2 allows arbitrary naming authorities to coexist. To use an explicit naming authority, a vendor simply employs their Enterprise Number as a naming authority. For example, for the following (fictitious) Enterprise Number
供应商也可以创建自己的命名机构。在这种情况下，可以使用任何服务类型或属性。SLPv2允许任意命名权限共存。要使用明确的命名机构，供应商只需使用其企业编号作为命名机构。例如，对于以下（虚构的）企业编号
9999 Acme, Inc. Erik Guttman femur@example.com
9999 Acme公司Erik Guttmanfemur@example.com
the Naming Authority string to use would be "9999". A service: URL which used this Naming Authority to advertise a Roadrunner Detector service could look like
要使用的命名机构字符串为“9999”。一个服务：使用此命名权限发布Roadrunner Detector服务的URL可能看起来像
service:roadrunner-detector.9999://example.com:9341
service:roadrunner-detector.9999://example.com:9341
Service types which are defined under a naming authority based on an Enterprise Number are guaranteed not to conflict with other service type strings which mean something entirely different. That is also true of attributes defined for service types defined under a naming authority.
在基于企业编号的命名机构下定义的服务类型保证不会与表示完全不同的内容的其他服务类型字符串冲突。为命名机构下定义的服务类型定义的属性也是如此。
To create a safe naming authority with no possibility of name collisions, a vendor SHOULD use their Enterprise Number as a naming authority.
要创建一个安全的命名机构，而不存在名称冲突的可能性，供应商应使用其企业编号作为命名机构。
SLPv2 [1] suggests that
SLPv2[1]表明
Non-standard attribute names SHOULD begin with "x-", because no standard attribute name will ever have those initial characters.
Non-standard attribute names SHOULD begin with "x-", because no standard attribute name will ever have those initial characters.translate error, please retry
It is possible that two non-standard attributes will conflict that both use the "x-" prefix notation. For that reason, vendors SHOULD use "x-" followed by their Enterprise Number followed by a "-" to guarantee that the non-standard attribute name's interpretation is not ambiguous.
两个非标准属性可能会冲突，因为它们都使用“x-”前缀表示法。因此，供应商应使用“x-”后跟其企业编号，后跟一个“-”，以确保非标准属性名称的解释不会模棱两可。
For example, Acme, Inc.'s Enterprise Number is 9999. Say the Service Template for NetHive (a fictitious game) was:
例如，Acme，Inc.的企业编号是9999。假设NetHive（虚拟游戏）的服务模板是：
------------------------------------------------------------
template-type=NetHive
------------------------------------------------------------
template-type=NetHive
template-version=1.0
模板版本=1.0
template-description= The popular NetHive game.
模板说明=流行的NetHive游戏。
template-url-syntax= url-path = ; There is no path for a NetHive service URL.
模板url语法=url路径=；没有NetHive服务URL的路径。
features= string M O # The list of optional features the NetHive server supports. secure session, fast mode
features=string M O#NetHive服务器支持的可选功能列表。安全会话，快速模式
current-users= string M
# The list of users currently playing
------------------------------------------------------------
current-users= string M
# The list of users currently playing
------------------------------------------------------------
Acme's server advertises a feature which is not on the list of standard features, "x-9999-cheat-mode". Only an Acme client would request this attribute to discover servers, since it is not standard.
Acme的服务器宣传一项不在标准功能列表中的功能，“x-9999-cheat-mode”。只有Acme客户端会请求此属性来发现服务器，因为它不是标准的。
SLPv2 [1] defines a protocol extensibility mechanism. SLPv2 Extensions are added at the end of a message and have the following format:
SLPv2[1]定义了一种协议扩展机制。SLPv2扩展名添加在消息末尾，格式如下：
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 /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the Extension Data depends on the Extension ID. Refer to [4] for a full description of different mechanisms available for registration of values with IANA.
扩展数据的格式取决于扩展ID。有关可用于向IANA注册值的不同机制的完整说明，请参阅[4]。
SLPv2 may be extended in any of three ways.
SLPv2可通过三种方式中的任何一种进行扩展。
(1) Anyone may request the designated expert for SLP to register a new extension ID with IANA. Send requests to the svrloc-list@iana.org.
(1) 任何人都可以要求SLP的指定专家向IANA注册新的扩展ID。向svrloc发送请求-list@iana.org.
It is recommended that an internet draft specifying this extension be published, with the intention of publishing the document as an Informational RFC. This way others can use the extension as well. This is not a 'vendor extension' - rather this is the preferred way of extending the protocol in a vendor neutral manner.
建议发布指定此扩展的互联网草案，目的是将文档作为信息RFC发布。这样其他人也可以使用扩展。这不是“供应商扩展”-而是以供应商中立的方式扩展协议的首选方式。
If no specification is published and the extension is intended for vendor specific use only - the 'Vendor Extension' option below probably makes more sense than assigning an extension ID.
如果未发布规范，且扩展仅用于供应商特定用途，则下面的“供应商扩展”选项可能比分配扩展ID更有意义。
(2) An experimental extension may be done using the range 0x8000 to 0x8FFF. There is always the risk, however, that another vendor will use the same ID, since these IDs are not registered.
(2) 可以使用0x8000到0x8FFF范围进行实验扩展。但是，始终存在另一个供应商使用相同ID的风险，因为这些ID未注册。
(3) A Vendor Extension may be used. This extension allows a Vendor to define their own extensions which are guaranteed to have a unique interpretation. It is OPTIONAL to implement.
(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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension ID = 0x0003 | Next Extension Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset, contd.| Enterprise Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ent. #, 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 = 0x0003 | Next Extension Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset, contd.| Enterprise Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ent. #, contd.| Extension Data /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Enterprise Number is included in the Extension as a 4 byte unsigned integer value. The Extension Data following is guaranteed to have an unambiguous interpretation determined by the vendor.
企业编号作为4字节无符号整数值包含在扩展名中。以下扩展数据保证具有由供应商确定的明确解释。
The Acme Corporation, whose Enterprise Number is 9999, can define an extension to SLP. In this example, Acme creates one such extension to create an application level access control to service information. This would allow replies to be sent only to clients who could authenticate themselves.
Acme Corporation（其企业编号为9999）可以定义SLP的扩展。在本例中，Acme创建了一个这样的扩展来创建对服务信息的应用程序级访问控制。这将允许只将回复发送给能够对自己进行身份验证的客户端。
The engineers at Acme give the Extension Data the following form:
Acme的工程师以以下形式提供扩展数据：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ACME Ext ID = 1| Client ID Length | Client ID ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authenticator ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ACME Ext ID = 1| Client ID Length | Client ID ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authenticator ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ACME Ext ID: The ACME engineers decided to define the first byte of their extension data as an extension ID field. In the future, ACME may decide to define more than this extension. Since there is 8 bits in the ID field, ACME can define up to 256 different extensions. If ACME were to omit this field and begin directly with their 'Extension for UA Authentication', they would only be able to define one ACME specific SLP extension. For the 'Extension for UA Authentication,' the ACME Extension ID is set to 1. This ID has to be managed within ACME, to make sure that each new extension they invent has a unique ID assigned to it.
acmeextid：ACME工程师决定将扩展数据的第一个字节定义为扩展ID字段。将来，ACME可能会决定定义更多的扩展。由于ID字段中有8位，ACME最多可以定义256个不同的扩展名。如果ACME省略此字段并直接以其“UA认证扩展”开始，则他们将只能定义一个特定于ACME的SLP扩展。对于“UA身份验证扩展”，ACME扩展ID设置为1。必须在ACME中管理此ID，以确保他们发明的每个新扩展都有一个唯一的ID分配给它。
Client ID Length: This declares how many bytes of Client ID data follow.
客户机ID长度：声明客户机ID数据的字节数。
Client ID: The Acme application user ID.
客户端ID：Acme应用程序用户ID。
Timestamp: # of seconds since January 1, 2000, 0:00 GMT.
时间戳：自2000年1月1日0:00 GMT以来的秒数。
Authenticator: a 16 byte MD5 digest [6] calculated on the following data fields, concatenated together
验证器：一个16字节的MD5摘要[6]，在下列数据字段上计算，并连接在一起
- UA request bytes, including the header, but not any extensions. - UA SECRET PASS PHRASE - Acme UA Authentication Extension - Client ID - Acme UA Authentication Extension - Timestamp
- UA请求字节，包括标头，但不包括任何扩展。-UA密码短语-Acme UA身份验证扩展-客户端ID-Acme UA身份验证扩展-时间戳
The SA or DA which receives this extension and supports this extension will check if it (1) recognizes the Client ID, (2) has an associated SECRET PASS PHRASE for it, (3) whether upon calculating an MD5 digest over the same data as listed above it arrives at the same Authenticator value as included in the extension. If all 3 of these steps succeed, the UA has been authenticated.
接收此扩展并支持此扩展的SA或DA将检查它（1）是否识别客户端ID，（2）是否具有相关的密码短语，（3）在对上面列出的相同数据计算MD5摘要时，它是否达到扩展中包含的相同验证器值。如果上述三个步骤全部成功，则UA已通过身份验证。
Note this example is for explanatory purposes only. It would not work well in practice. It requires a shared secret be configured in SAs and DAs, for every UA. Furthermore, the UA secret pass phrase would be susceptible to a dictionary attack.
注：此示例仅用于解释目的。它在实践中不会很好地起作用。它要求在SAs和DAs中为每个UA配置一个共享密钥。此外，UA密码短语容易受到字典攻击。
Modification or extension of any feature of SLPv2 whatsoever, aside from those listed in Sections 3-5 of this document, requires a standards action as defined in [1].
除本文件第3-5节中列出的功能外，SLPv2任何功能的修改或扩展都需要[1]中定义的标准行动。
Terminology and procedures for IETF Actions related to registration of IDs with IANA are defined in [5]. Existing SLPv2 extensions assignments are registered with IANA [3].
[5]中定义了与向IANA注册IDs相关的IETF行动的术语和程序。现有的SLPv2扩展分配已向IANA注册[3]。
This document clarifies procedures described in other documents [1] [4]. The Vendor Opaque Extension ID has already been registered [3]. No additional IANA action is required for publication of this document.
本文件澄清了其他文件[1][4]中描述的程序。供应商不透明扩展ID已注册[3]。出版本文件不需要IANA采取其他行动。
Vendor extensions may introduce additional security considerations into SLP.
供应商扩展可能会在SLP中引入额外的安全注意事项。
This memo describes mechanisms which are standardized elsewhere [1] [4]. The only protocol mechanism described in this document (see Section 5 above) is no less secure than 'private use' extensions defined in SLPv2 [1].
本备忘录描述了其他地方标准化的机制[1][4]。本文档中描述的唯一协议机制（见上文第5节）的安全性不低于SLPv2[1]中定义的“专用”扩展。
The example in Section 5.2 above shows how Vendor Opaque Extensions can be used to include an access control mechanism to SLP so that SAs can enforce an access control policy using an authentication mechanism. This is merely an example and protocol details were intentionally not provided. A vendor could, however, create a mechanism similar to this one and provide additional security services to SLPv2 in the manner indicated in the example.
上面第5.2节中的示例显示了如何使用供应商不透明扩展将访问控制机制包括到SLP中，以便SAs可以使用身份验证机制强制执行访问控制策略。这只是一个示例，故意不提供协议细节。但是，供应商可以创建类似于此机制的机制，并以示例中所示的方式向SLPv2提供额外的安全服务。
Acknowledgements
致谢
I thank the IESG, for their usual persistence and attention to detail.
我感谢IESG，感谢他们一贯的坚持和对细节的关注。
References
工具书类
[1] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2", RFC 2608, July 1999.
[1] Guttman，E.，Perkins，C.，Veizades，J.和M.Day，“服务位置协议，版本2”，RFC 26081999年7月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] http://www.iana.org/numbers.html
[3] http://www.iana.org/numbers.html
[4] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and URLs", RFC 2609, July 1999.
[4] Guttman，E.，Perkins，C.和J.Kempf，“服务模板和URL”，RFC 26091999年7月。
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[5] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[6] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[6] Rivest，R.，“MD5消息摘要算法”，RFC1321，1992年4月。
Author's Address
作者地址
Erik Guttman Sun Microsystems Eichhoelzelstr. 7 74915 Waibstadt Germany
埃里克·古特曼太阳微系统公司。74915德国威伯斯塔特
Phone: +49 7263 911 701
Messages: +49 6221 356 202
EMail: erik.guttman@sun.com
Phone: +49 7263 911 701
Messages: +49 6221 356 202
EMail: erik.guttman@sun.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
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编辑功能的资金目前由互联网协会提供。