Network Working Group E. Guttman
Request for Comments: 3059 Sun Microsystems
Category: Standards Track February 2001
Network Working Group E. Guttman
Request for Comments: 3059 Sun Microsystems
Category: Standards Track February 2001
Attribute List Extension for the Service Location Protocol
服务位置协议的属性列表扩展
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 (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
The Service Location Protocol, Version 2 (SLPv2) provides a mechanism for a service to be discovered in a single exchange of messages. This exchange of messages does not presently include any of the service's attributes. This document specifies a SLPv2 extension which allows a User Agent (UA) to request a service's attributes be included as an extension to Service Reply messages. This will eliminate the need for multiple round trip messages for a UA to acquire all service information.
服务位置协议版本2（SLPv2）提供了一种在单个消息交换中发现服务的机制。此消息交换目前不包括服务的任何属性。本文档指定了一个SLPv2扩展，它允许用户代理（UA）请求将服务的属性作为服务回复消息的扩展包含在内。这将消除UA获取所有服务信息所需的多条往返消息。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Notation Conventions . . . . . . . . . . . . . . . . . . 3
2. Attribute List Extension . . . . . . . . . . . . . . . . . . . 3
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
4. Internationalization Considerations . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Notation Conventions . . . . . . . . . . . . . . . . . . 3
2. Attribute List Extension . . . . . . . . . . . . . . . . . . . 3
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
4. Internationalization Considerations . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 6
The Service Location Protocol, Version 2 [3] provides a mechanism for a service to be discovered in a single exchange of messages. The UA sends a Service Request message and the DA or SA (as appropriate) sends a Service Reply message.
服务位置协议（版本2[3]）提供了一种在单个消息交换中发现服务的机制。UA发送服务请求消息，DA或SA（视情况而定）发送服务回复消息。
It is clearly advantageous to be able to obtain all service information at once. The Service Location Protocol separates messages which obtain different classes of information. This extension enables an optimization to the basic exchange of messages, which currently does not include service attributes in Service Reply messages.
能够一次获得所有服务信息显然是有利的。服务位置协议将获取不同类别信息的消息分开。此扩展支持对消息的基本交换进行优化，该交换当前不包括服务回复消息中的服务属性。
This document specifies a SLPv2 extension which allows a UA to request that a service's attributes be included in Service Reply messages. This will eliminate the need for multiple round trip messages for a UA to acquire all service information.
本文档指定了一个SLPv2扩展，允许UA请求在服务回复消息中包含服务的属性。这将消除UA获取所有服务信息所需的多条往返消息。
If the DA or SA does not support the Attrlist extension, it will simply return a Service Reply (without the extension). Support of this extension is OPTIONAL. Existing implementations will ignore the Attrlist extension since it has been assigned a identifying number from the range which indicates that the receiver MUST ignore the extension if it is not recognized. See RFC 2608 [3].
如果DA或SA不支持Attrlist扩展，它将只返回一个服务应答（不带扩展）。支持此扩展是可选的。现有的实现将忽略Attrlist扩展，因为它被分配了一个范围内的标识号，该范围表示如果无法识别，接收方必须忽略扩展。参见RFC 2608[3]。
If the UA receives a Service Reply message without an Attrlist Extension it must assume the SA or DA does not support the extension. In this case, the UA must send an Attribute Request for each URL it obtains in the Service Reply message in order to obtain the attributes for these services.
如果UA收到没有Attrlist扩展的服务回复消息，则必须假定SA或DA不支持该扩展。在这种情况下，UA必须为其在服务回复消息中获得的每个URL发送属性请求，以便获得这些服务的属性。
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。
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 [2].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[2]中所述进行解释。
The format of the Attribute List Extension is as follows:
属性列表扩展的格式如下所示：
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 = 0x0002 | Next Extension Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset, contd.| Service URL Length | Service URL /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute List Length | Attribute 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension ID = 0x0002 | Next Extension Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset, contd.| Service URL Length | Service URL /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute List Length | Attribute List /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|# of AttrAuths |(if present) Attribute Authentication Blocks.../
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Extension ID is 0x0002.
扩展ID为0x0002。
The Next Extension Offset value indicates the position of the next extension as offset from the beginning of the SLP message. If the next extension offset value is 0, there are no more extensions in the message.
Next Extension Offset（下一个扩展偏移量）值表示下一个扩展的位置，即从SLP消息开始的偏移量。如果下一个扩展偏移量值为0，则消息中不再有扩展。
A UA sends an Attribute List Extension with a Service Request. The Service URL Length and Attribute List Length are set to 0 and the Service URL and Attribute List fields omitted in this case. The UA thereby requests that the SA or DA include an Attribute List Extension in its Service Reply by including such an 'empty' Attribute List Extension in the Service Request.
UA发送属性列表扩展和服务请求。服务URL长度和属性列表长度设置为0，在本例中省略服务URL和属性列表字段。UA因此通过在服务请求中包括这样的“空”属性列表扩展来请求SA或DA在其服务应答中包括属性列表扩展。
A SA or DA which supports the Attribute List Extension returns one Attribute List extension for every URL Entry in the Service Reply message. The order of the Attribute List Extensions SHOULD be the same as the URL Entries in the Service Reply.
支持属性列表扩展的SA或DA为服务回复消息中的每个URL条目返回一个属性列表扩展。属性列表扩展的顺序应与服务回复中的URL条目相同。
The Service URL [4] identifies the corresponding URL Entry.
服务URL[4]标识相应的URL条目。
The Attribute List field is the entire attribute list of the service. These attributes must be in the same language as that indicated in the Service Request message.
属性列表字段是服务的整个属性列表。这些属性的语言必须与服务请求消息中指示的语言相同。
If the Service Request message includes a SLP SPI string, then the attribute list extension MUST include an authentication block. If the SA or DA does not support or is unable to return an authentication block for the SLP SPI included in the Service Request, then the SA or DA MUST NOT return an Attribute List Extension. The format of the authentication block(s) is exactly the same as would be included in an Attribute Reply or Service Registration message.
如果服务请求消息包含SLP SPI字符串，则属性列表扩展必须包含身份验证块。如果SA或DA不支持或无法返回服务请求中包含的SLP SPI的身份验证块，则SA或DA不得返回属性列表扩展。身份验证块的格式与属性回复或服务注册消息中包含的格式完全相同。
IANA has assigned an extension ID number of 0x0002 for the Attribute List Extension.
IANA已为属性列表扩展分配了扩展ID号0x0002。
The Service Location Protocol, version 2 has mechanisms for allowing attributes to be transmitted with explicit language tagging [6]. The same mechanisms are used for this protocol extension.
服务位置协议版本2具有允许使用显式语言标记传输属性的机制[6]。此协议扩展使用相同的机制。
The Service Location Protocol, version 2 has mechanisms for allowing authenticators to be returned with attribute lists so that UAs are able to verify a digital signature over the attributes they obtain. This same mechanism is used for this protocol extension. The Attribute List Extension used in conjunction with SLPv2 is no less secure than SLPv2 without the extension.
服务位置协议（版本2）具有允许使用属性列表返回验证器的机制，以便UAs能够根据其获得的属性验证数字签名。此协议扩展使用相同的机制。与SLPv2一起使用的属性列表扩展的安全性不低于没有该扩展的SLPv2。
The author benefited from preliminary conversations about this extension with Charlie Perkins.
作者从与Charlie Perkins关于此扩展的初步对话中获益匪浅。
References
工具书类
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[1] Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[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] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
[3] Guttman，E.，Perkins，C.，Veizades，J.和M.Day，“服务位置协议，版本2”，RFC 26081999年6月。
[4] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and service: Schemes", RFC 2609, June 1999.
[4] Guttman，E.，Perkins，C.和J.Kempf，“服务模板和服务：方案”，RFC 26091999年6月。
[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] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
[6] Alvestrand，H.，“语言识别标签”，BCP 47，RFC 3066，2001年1月。
Author's Address
作者地址
Erik Guttman Sun Microsystems Eichhoelzelstr. 7 74915 Waibstadt Germany
埃里克·古特曼太阳微系统公司。74915德国威伯斯塔特
Phone: +49 6227 356 202
EMail: Erik.Guttman@sun.com
Phone: +49 6227 356 202
EMail: Erik.Guttman@sun.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
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编辑功能的资金目前由互联网协会提供。