Network Working Group E. Guttman
Request for Comments: 2609 C. Perkins
Updates: 2165 J. Kempf
Category: Standards Track Sun Microsystems
June 1999
Network Working Group E. Guttman
Request for Comments: 2609 C. Perkins
Updates: 2165 J. Kempf
Category: Standards Track Sun Microsystems
June 1999
Service Templates and Service: Schemes
服务模板和服务：方案
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:" URL scheme name is used to define URLs (called "service: URLs" in this document) that are primarily intended to be used by the Service Location Protocol in order to distribute service access information. These schemes provide an extensible framework for client-based network software to obtain configuration information required to make use of network services. When registering a service: URL, the URL is accompanied by a set of well-defined attributes which define the service. These attributes convey configuration information to client software, or service characteristics meaningful to end users.
“服务：”URL方案名称用于定义URL（在本文档中称为“服务：URL”），这些URL主要由服务位置协议使用，以便分发服务访问信息。这些方案为基于客户端的网络软件提供了一个可扩展的框架，以获取使用网络服务所需的配置信息。注册service:URL时，URL附带一组定义服务的定义良好的属性。这些属性将配置信息传递给客户端软件，或传递给最终用户有意义的服务特征。
This document describes a formal procedure for defining and standardizing new service types and attributes for use with the "service:" scheme. The formal descriptions of service types and attributes are templates that are human and machine understandable. They SHOULD be used by administrative tools to parse service registration information and by client applications to provide localized translations of service attribute strings.
本文档描述了定义和标准化新服务类型和属性以用于“服务：”方案的正式过程。服务类型和属性的形式化描述是人类和机器可以理解的模板。管理工具应该使用它们来解析服务注册信息，客户端应用程序应该使用它们来提供服务属性字符串的本地化翻译。
Table of Contents
目录
1. Introduction 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3
1.2. Service Location Protocol . . . . . . . . . . . . . . 5
1.2.1. Compatibility with SLPv1 . . . . . . . . . . . 5
2. Service URL Syntax and Semantics 5
2.1. Service URL Syntax . . . . . . . . . . . . . . . . . 5
2.2. Service URL Semantics . . . . . . . . . . . . . . . . 8
2.3. Use of service: URLs . . . . . . . . . . . . . . . . 9
2.4. Specifying the Service Type-Specific URL Syntax. . . . 10
2.5. Accommodating Abstract Service Types . . . . . . . . 10
2.5.1. Advertising Abstract Service Types . . . . . . 11
3. Syntax and Semantics of Service Type Specifications 12
3.1. Syntax of Service Type Templates . . . . . . . . . . 12
3.2. Semantics of Service Type Templates. . . . . . . . . . 15
3.2.1. Definition of a Service Template . . . . . . . 15
3.2.2. Service Type . . . . . . . . . . . . . . . . . 16
3.2.3. Version Number . . . . . . . . . . . . . . . . 16
3.2.4. Description . . . . . . . . . . . . . . . . . 16
3.2.5. Syntax of the Service Type-specific URL Part . 17
3.2.6. Attribute Definition . . . . . . . . . . . . 17
4. A Process For Standardizing New Service Types 21
5. IANA Considerations 22
6. Internationalization Considerations 24
6.1. Language Identification and Translation. . . . . . . . 24
7. Security Considerations 25
A. Service Template Examples 26
A.1. FOO . . . . . . . . . . . . . . . . . .. . . . . . . . 26
A.2. Abstract Service Type: Net-Transducer . . . . . . . . 28
A.3. Concrete Service Type: Net-Transducer:Thermometer . . 29
A.4. service: URLs and SLP . . . . . . . . . . . . . . . . 30
B. Acknowledgments 30
C. References 31
D. Authors' Addresses 32
E. Full Copyright Statement 33
1. Introduction 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3
1.2. Service Location Protocol . . . . . . . . . . . . . . 5
1.2.1. Compatibility with SLPv1 . . . . . . . . . . . 5
2. Service URL Syntax and Semantics 5
2.1. Service URL Syntax . . . . . . . . . . . . . . . . . 5
2.2. Service URL Semantics . . . . . . . . . . . . . . . . 8
2.3. Use of service: URLs . . . . . . . . . . . . . . . . 9
2.4. Specifying the Service Type-Specific URL Syntax. . . . 10
2.5. Accommodating Abstract Service Types . . . . . . . . 10
2.5.1. Advertising Abstract Service Types . . . . . . 11
3. Syntax and Semantics of Service Type Specifications 12
3.1. Syntax of Service Type Templates . . . . . . . . . . 12
3.2. Semantics of Service Type Templates. . . . . . . . . . 15
3.2.1. Definition of a Service Template . . . . . . . 15
3.2.2. Service Type . . . . . . . . . . . . . . . . . 16
3.2.3. Version Number . . . . . . . . . . . . . . . . 16
3.2.4. Description . . . . . . . . . . . . . . . . . 16
3.2.5. Syntax of the Service Type-specific URL Part . 17
3.2.6. Attribute Definition . . . . . . . . . . . . 17
4. A Process For Standardizing New Service Types 21
5. IANA Considerations 22
6. Internationalization Considerations 24
6.1. Language Identification and Translation. . . . . . . . 24
7. Security Considerations 25
A. Service Template Examples 26
A.1. FOO . . . . . . . . . . . . . . . . . .. . . . . . . . 26
A.2. Abstract Service Type: Net-Transducer . . . . . . . . 28
A.3. Concrete Service Type: Net-Transducer:Thermometer . . 29
A.4. service: URLs and SLP . . . . . . . . . . . . . . . . 30
B. Acknowledgments 30
C. References 31
D. Authors' Addresses 32
E. Full Copyright Statement 33
This document describes a URL scheme, called service: URL, which defines network access information for network services using a formal notation. In addition it describes how to define a set of attributes to associate with a service: URL. These attributes will allow end users and programs to select between network services of the same type that have different capabilities. The attributes are defined in a template document that is readable by people and machines.
本文档描述了一个名为service:URL的URL方案，它使用正式的表示法定义网络服务的网络访问信息。此外，它还描述了如何定义一组与服务关联的属性：URL。这些属性将允许最终用户和程序在具有不同功能的相同类型的网络服务之间进行选择。这些属性在人和机器可读的模板文档中定义。
A client uses attributes to select a particular service. Service selection occurs by obtaining the service: URL that offers the right configuration for the client. Service type templates define the syntax of service: URLs for a particular service type, as well as the attributes which accompany a service: URL in a service registration.
客户端使用属性来选择特定的服务。通过获取为客户端提供正确配置的Service:URL来选择服务。服务类型模板定义特定服务类型的Service:URL的语法，以及服务注册中伴随Service:URL的属性。
Templates are used for the following distinct purposes:
模板用于以下不同目的：
1. Standardization
1. 标准化
The template is reviewed before it is standardized. Once it is standardized, all versions of the template are archived by IANA.
模板在标准化之前经过审核。一旦标准化，IANA将归档模板的所有版本。
2. Service Registration
2. 服务注册
Servers making use of the Service Location Protocol [10] register themselves and their attributes. They use the templates to generate the service registrations. In registering, the service must use the specified values for its attributes.
使用服务位置协议[10]的服务器注册自身及其属性。他们使用模板生成服务注册。在注册时，服务必须为其属性使用指定的值。
3. Client presentation of Service Information
3. 客户提供服务信息
Client applications may display service information. The template provides type information and explanatory text which may be helpful in producing user interfaces.
客户端应用程序可以显示服务信息。模板提供类型信息和解释性文本，这可能有助于生成用户界面。
4. Internationalization
4. 国际化
Entities with access to the template for a given service type in two different languages may translate between the two languages.
可以访问两种不同语言的给定服务类型模板的实体可以在两种语言之间进行翻译。
A service may register itself in more than one language using templates, though it has been configured by an operator who registered service attributes in a single language.
一个服务可以使用模板以多种语言注册自身，尽管它是由使用单一语言注册服务属性的操作员配置的。
All grammar encoding follows the Augmented BNF (ABNF) [8] for syntax specifications.
所有语法编码都遵循语法规范的增广BNF（ABNF）[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 [6].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[6]中所述进行解释。
The following terminology is used for describing service: URLs.
以下术语用于描述服务：URL。
service scheme
服务计划
A URL scheme whose name starts with the string "service:" and is followed by the service type name, constructed according to the rules in this document.
一个URL方案，其名称以字符串“service:”开头，后跟根据本文档中的规则构造的服务类型名称。
service: URL
服务：网址
A URL constructed according to the service scheme definition. It typically provides at least the following: The name of an access protocol, and an address locating this service. The service: URL may include url path information specific to the type of service, as well as attribute information encoded according to the URL grammar. The service: URL is used by the Service Location Protocol to register and discover the location of services. It may be used by other protocols and in documents as well.
根据服务方案定义构造的URL。它通常至少提供以下内容：访问协议的名称和定位此服务的地址。服务：URL可能包括特定于服务类型的URL路径信息，以及根据URL语法编码的属性信息。服务：URL由服务位置协议用于注册和发现服务的位置。它也可以被其他协议和文档使用。
service type
服务类型
A name identifying the semantics by which the remainder of the service: URL is to be understood. It may denote either a particular network protocol, or an abstract service associated with a variety of protocols. If the service type denotes a particular protocol, then the service type name SHOULD either be assigned the name of a particular well known port [2] by convention or be the Assigned Numbers name for the service [1].
标识语义的名称，通过该名称可以理解服务的其余部分：URL。它可以表示特定的网络协议，也可以表示与各种协议相关联的抽象服务。如果服务类型表示特定协议，则服务类型名称应按照约定分配给特定已知端口的名称[2]，或分配给服务的编号名称[1]。
abstract service type
抽象服务类型
A service type name which is associated with a variety of different protocols. An example is given in Section A. Section 2 discusses various ways that abstract types can be accommodated.
与各种不同协议关联的服务类型名称。第2节讨论了容纳抽象类型的各种方法。
service registration
服务注册
A service: URL and optionally a set of attributes comprise a service registration. This registration is made by or on behalf of a given service. The URL syntax and attributes must conform to the service template for the registered service.
服务：URL和可选的一组属性组成服务注册。此注册由给定服务或其代表进行。URL语法和属性必须符合已注册服务的服务模板。
service template
服务模板
A formal description of the service attributes and service scheme associated with a particular service type.
与特定服务类型关联的服务属性和服务方案的形式化描述。
The Service Location Protocol version 2 [10] allows service: URLs to be registered and discovered, though service: URLs may be also used in other contexts.
Service Location Protocol version 2[10]允许注册和查找Service:URL，尽管Service:URL也可以在其他上下文中使用。
Client applications discover service registrations by issuing queries for services of a particular type, specifying the attributes of the service: URLs to return. Clients retrieve the attributes of a particular service by supplying its service: URL. Attributes for all service registrations of a particular type can also be retrieved.
客户端应用程序通过对特定类型的服务发出查询来发现服务注册，并指定服务的属性：要返回的URL。客户端通过提供服务URL来检索特定服务的属性。还可以检索特定类型的所有服务注册的属性。
Services may register themselves, or registrations may be made on their behalf. These registrations contain a service: URL, and possibly attributes and digital signatures.
服务可以自行注册，也可以代表其进行注册。这些注册包含一个服务：URL，可能还有属性和数字签名。
This document adopts the encoding conventions of SLPv2.
本文件采用SLPv2的编码约定。
Compatibility with SLPv1 [[15]] is possible, if the following conventions are observed:
如果遵守以下约定，则可以与SLPv1[[15]]兼容：
1. Abstract service types must not be used. SLPv2 specifies the use of Service URLs with abstract service types. SLPv1 does not support them. Thus, a service template which is to serve both SLPv1 and SLPv2 must not use abstract service types.
1. 不能使用抽象服务类型。SLPv2指定使用抽象服务类型的服务URL。SLPv1不支持它们。因此，同时为SLPv1和SLPv2提供服务的服务模板不得使用抽象服务类型。
2. The syntax for representing opaque values in this document is consistent with SLPv2. The syntax must be converted for use with SLPv1. Instead of a sequence of "\FF" then "\" HEXDIG HEXDIG for each byte in the opaque value, SLPv1 uses radix-64 notation.
2. 本文档中表示不透明值的语法与SLPv2一致。必须转换语法才能与SLPv1一起使用。SLPv1不使用不透明值中每个字节的“\FF”和“\”HEXDIG-HEXDIG序列，而是使用基数64表示法。
3. Escape characters are significantly differently in SLPv1 and SLPv2. Instead of using escaped byte notation for escaped characters, SLPv1 uses the HTML convention `&' `#' 1*DIGIT `;'.
3. SLPv1和SLPv2中的转义字符显著不同。SLPv1没有对转义字符使用转义字节表示法，而是使用HTML约定`&``1*位`。
This section describes the syntax and semantics of service: URLs.
本节介绍service:url的语法和语义。
The syntax of the service: URL MUST conform to an 'absolute URI' as defined by [5]. The syntax of a service: URL differs enough from a 'generic URI' that it is best to treat it as an opaque URI unless a specific parser for the service: URL is available.
service:URL的语法必须符合[5]定义的“绝对URI”。service:URL的语法与“generic URI”差异很大，因此最好将其视为不透明URI，除非service:URL的特定解析器可用。
All service: URLs have the same syntax up to the 'url-part' The syntax for a service URL depends on the service type following the service scheme. All service: URLs have a service access point portion, indicating the address of the service to access.
所有服务：url在“url部分”之前具有相同的语法。服务url的语法取决于服务方案后面的服务类型。所有服务：URL都有一个服务访问点部分，指示要访问的服务的地址。
The syntax for the <sap> field depends upon the service type definition. The <sap> field is the service access point, and describes how to access the service. In addition, although both upper case and lower case characters are recognized in the <service-type> field for convenience, the name is case-folded into lower case. Service types are therefore not distinguished on the basis of case, so, for example, "http" and "HTTP" designate the same service type. This is consistent with general URL practice, as outlined in [5].
<sap>字段的语法取决于服务类型定义。<sap>字段是服务访问点，描述如何访问服务。此外，尽管为了方便起见，<service type>字段中可以识别大写和小写字符，但名称是大小写折叠成小写的。因此，服务类型不会根据大小写进行区分，因此，例如，“http”和“http”指定相同的服务类型。这与[5]中概述的一般URL实践是一致的。
The ABNF for a service: URL is:
服务URL的ABNF为：
service: URL = "service:" service-type ":" sap
service-type = abstract-type ":" url-scheme / concrete-type
abstract-type = type-name [ "." naming-auth ]
concrete-type = protocol [ "." naming-auth ]
type-name = resname
naming-auth = resname
url-scheme = resname
; A recognized URL scheme name, standardized
; either through common practice or through
; approval of a standards body.
resname = ALPHA [ 1*(ALPHA / DIGIT / "+" / "-") ]
sap = site [url-part]
site = ipsite / atsite / ipxsite
ipsite = "//" [ [ user "@" ] hostport ]
hostport = host [ ":" port ]
host = hostname / hostnumber
hostname = *( domainlabel "." ) toplabel
alphanum = ALPHA / DIGIT
domainlabel = alphanum / alphanum *[alphanum / "-"] alphanum
toplabel = ALPHA / ALPHA *[ alphanum / "-" ] alphanum
hostnumber = ipv4-number
ipv4-number = 1*3DIGIT 3("." 1*3DIGIT)
port = 1*DIGIT
; A port number must be included if the
; protocol field does not have an IANA
; assigned port number.
user = *[ uchar / ";" / "+" / "&" / "=" ]
ipxsite = "/ipx/" ipx-net ":" ipx-node ":" ipx-socket
ipx-net = 8 HEXDIGIT
ipx-node = 12 HEXDIGIT
ipx-socket = 4 HEXDIGIT
atsite = "/at/" at-object ":" at-type "" at-zone
service: URL = "service:" service-type ":" sap
service-type = abstract-type ":" url-scheme / concrete-type
abstract-type = type-name [ "." naming-auth ]
concrete-type = protocol [ "." naming-auth ]
type-name = resname
naming-auth = resname
url-scheme = resname
; A recognized URL scheme name, standardized
; either through common practice or through
; approval of a standards body.
resname = ALPHA [ 1*(ALPHA / DIGIT / "+" / "-") ]
sap = site [url-part]
site = ipsite / atsite / ipxsite
ipsite = "//" [ [ user "@" ] hostport ]
hostport = host [ ":" port ]
host = hostname / hostnumber
hostname = *( domainlabel "." ) toplabel
alphanum = ALPHA / DIGIT
domainlabel = alphanum / alphanum *[alphanum / "-"] alphanum
toplabel = ALPHA / ALPHA *[ alphanum / "-" ] alphanum
hostnumber = ipv4-number
ipv4-number = 1*3DIGIT 3("." 1*3DIGIT)
port = 1*DIGIT
; A port number must be included if the
; protocol field does not have an IANA
; assigned port number.
user = *[ uchar / ";" / "+" / "&" / "=" ]
ipxsite = "/ipx/" ipx-net ":" ipx-node ":" ipx-socket
ipx-net = 8 HEXDIGIT
ipx-node = 12 HEXDIGIT
ipx-socket = 4 HEXDIGIT
atsite = "/at/" at-object ":" at-type "" at-zone
at-object = 1*31apple-char
at-type = 1*31apple-char
at-zone = 1*31apple-char
apple-char = ALPHA / DIGIT / safe / escaped
= ; AppleAscii [7] values that are not
= ; from the restricted range must be escaped.
= ; NOTE: The escaped values do NOT correspond
= ; to UTF-8 values here: They are AppleAscii
= ; bytes.
url-part = [ url-path ] [ attr-list ]
url-path = 1 * ( "/" *xchar )
; Each service type must define its
; own syntax consistent
; with [5].
attr-list = 1 * ( ";" attr-asgn )
attr-asgn = attr-id / attr-id "=" attr-value
safe = "$" / "-" / "_" / "." / "~"
extra = "!" / "*" / "'" / "(" / ")" / "," / "+"
uchar = unreserved / escaped
xchar = unreserved / reserved / escaped
escaped = 1*(`\' HEXDIG HEXDIG)
reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" / "+"
unreserved = ALPHA / DIGIT / safe / extra
at-object = 1*31apple-char
at-type = 1*31apple-char
at-zone = 1*31apple-char
apple-char = ALPHA / DIGIT / safe / escaped
= ; AppleAscii [7] values that are not
= ; from the restricted range must be escaped.
= ; NOTE: The escaped values do NOT correspond
= ; to UTF-8 values here: They are AppleAscii
= ; bytes.
url-part = [ url-path ] [ attr-list ]
url-path = 1 * ( "/" *xchar )
; Each service type must define its
; own syntax consistent
; with [5].
attr-list = 1 * ( ";" attr-asgn )
attr-asgn = attr-id / attr-id "=" attr-value
safe = "$" / "-" / "_" / "." / "~"
extra = "!" / "*" / "'" / "(" / ")" / "," / "+"
uchar = unreserved / escaped
xchar = unreserved / reserved / escaped
escaped = 1*(`\' HEXDIG HEXDIG)
reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" / "+"
unreserved = ALPHA / DIGIT / safe / extra
IPX addresses [14] are composed of a network, node and socket number. The IPX network number is a four-byte number, in network order and expressed in hexadecimal, that signifies an IPX subnet. The node element represents a network interface card. It is a six-byte number, expressed in hexadecimal, that is usually the same as the node ID of the interface card. The socket element represents a specific service access point, given an IPX network and node. IPX sockets are analogous to TCP/IP ports, and are not to be confused with Berkeley sockets.
IPX地址[14]由网络、节点和套接字编号组成。IPX网络号是一个四字节的数字，按网络顺序并以十六进制表示，表示IPX子网。节点元素表示网络接口卡。它是一个六字节的数字，用十六进制表示，通常与接口卡的节点ID相同。套接字元素表示给定IPX网络和节点的特定服务访问点。IPX套接字类似于TCP/IP端口，不要与Berkeley套接字混淆。
AppleTalk addresses [9] are composed of an object, type and zone. The object is a human readable string. The type is an identifier, not intended for human readability. The zone refers to the AppleTalk Zone name, which is also human readable. The characters composing these names are drawn from the AppleAscii character set [7]. Thus, they do not equate to escaped ASCII or UTF-8 characters. The characters "=" and "*" are reserved and may not be included in the names even in binary form.
AppleTalk地址[9]由对象、类型和区域组成。对象是人类可读的字符串。类型是一个标识符，不用于人类可读性。区域指的是AppleTalk区域名称，也是人类可读的。构成这些名称的字符来自AppleAscii字符集[7]。因此，它们并不等同于转义的ASCII或UTF-8字符。字符“=”和“*”是保留的，即使以二进制形式也不能包含在名称中。
In cases besides the AppleTalk grammar, some characters must be escaped before use. To escape any character, precede the two digits indicating its ASCII value by '%'.
在除AppleTalk语法之外的情况下，某些字符在使用前必须转义。若要转义任何字符，请在指示其ASCII值的两位数字前面加“%”。
The service scheme-specific information following the "service:" URL scheme identifier provides information necessary to access the service. As described in the previous subsection, the form of a service: URL is as follows:
“服务：”URL方案标识符后面的服务方案特定信息提供访问服务所需的信息。如前一小节所述，service:URL的形式如下：
service: URL = "service:" service-type ":" site url-path
service: URL = "service:" service-type ":" site url-path
where <site> has one of the following forms could refer to an <ipsite>, <ipxsite> or <atsite> if the service URL locates to an IP, IPX or AppleTalk service access point, respectively.
其中，<site>具有以下形式之一，如果服务URL分别位于IP、IPX或AppleTalk服务接入点，则可以引用<ipsite>、<ipxsite>或<atsite>。
As discussed in Section 1, the <service-type> can be either a concrete protocol name, or an abstract type name.
如第1节所述，<service type>可以是具体的协议名，也可以是抽象的类型名。
The <ipsite> field is typically either a domain name (DNS) or an IP network protocol address for the service, and possibly a port number. Note that use of DNS hostnames is preferred for ease of renumbering. The <site> field can be null if other information in the service URL or service attributes is sufficient to use the service.
<ipsite>字段通常是服务的域名（DNS）或IP网络协议地址，也可能是端口号。请注意，为了便于重新编号，最好使用DNS主机名。如果服务URL或服务属性中的其他信息足以使用该服务，<site>字段可以为空。
The <sap> field allows more information to be provided (by way of <url-path> and <attr-list>) that can uniquely locate the service or resource if the <site> is not sufficient for that purpose. For IP addresses, the <site> field begins with "//". Other address families supported are IPX [14] and AppleTalk [9].
<sap>字段允许提供更多信息（通过<url path>和<attr list>），如果<site>不足以定位服务或资源，则这些信息可以唯一定位服务或资源。对于IP地址，<site>字段以“/”开头。支持的其他地址系列有IPX[14]和AppleTalk[9]。
An <attr-list> field appears at the end of the <url-part> field, but is never required to exist in any service location registration.
一个<attr list>字段出现在<url part>字段的末尾，但在任何服务位置注册中都不需要存在该字段。
The <attr-list> field is composed of a list of semicolon (";") separated attribute assignments of the form:
<attr list>字段由以下形式的分号（；）分隔属性赋值列表组成：
attr-id "=" attr-value
属性id“=”属性值
or for keyword attributes:
或对于关键字属性：
attr-id
属性id
Attributes are part of service: URLs when the attributes are required to access a particular service. For instance, an ACAP [13] service might require that the client authenticate with it through Kerberos. Including an attribute in the service registration allows the ACAP client to make use of the correct SASL [11] authentication mechanism. The ACAP server's registration might look like:
属性是服务的一部分：当访问特定服务需要属性时，URL。例如，ACAP[13]服务可能要求客户端通过Kerberos对其进行身份验证。在服务注册中包含属性允许ACAP客户端使用正确的SASL[11]身份验证机制。ACAP服务器的注册可能如下所示：
service:acap://some.where.net;authentication=KERBEROSV4
service:acap://some.where.net;authentication=KERBEROSV4
Note that there can be other attributes of an ACAP server which are not appropriate to include in the URL. For instance, the list of users who have access to the server is useful for selecting an ACAP server, but is not required for a client to use the registered service.
请注意，ACAP服务器的其他属性可能不适合包含在URL中。例如，有权访问服务器的用户列表对于选择ACAP服务器很有用，但客户端使用已注册的服务并不需要这些用户列表。
Attributes associated with the service: URL are not typically included in the service: URL. They are stored and retrieved using other mechanisms. The service: URL is uniquely identified with a particular service agent or resource, and is used when registering or requesting the attribute information. The Service Location Protocol specifies how such information is registered by network services and obtained by client software.
与service:URL关联的属性通常不包括在service:URL中。它们是使用其他机制存储和检索的。service:URL由特定的服务代理或资源唯一标识，并在注册或请求属性信息时使用。服务位置协议指定网络服务如何注册此类信息，以及客户端软件如何获取此类信息。
The service: URL is intended to allow arbitrary client/server and peer to peer systems to make use of a standardized dynamic service access point discovery mechanism.
服务：URL旨在允许任意客户端/服务器和对等系统使用标准化的动态服务访问点发现机制。
It is intended that service: URLs be selected according to the suitability of associated attributes. A client application can obtain the URLs of several services of the same type and distinguish the most preferable among them by means of their attributes. The client uses the service: URL to communicate directly to a service.
其目的是根据相关属性的适用性选择服务：URL。客户端应用程序可以获取相同类型的多个服务的URL，并通过它们的属性来区分它们中最可取的服务。客户端使用service:URL直接与服务通信。
Attributes are specified with a formal service template syntax described in Section 3. If a service: URL registration includes attributes, the registering agent SHOULD also keep track of the attributes which characterize the service.
属性是使用第3节中描述的正式服务模板语法指定的。如果service:URL注册包含属性，那么注册代理还应该跟踪描述服务的属性。
Registrations can be checked against the formal attribute specification defined in the template by the client or agent representing the client. Service registration are typically done using the Service Location Protocol [10] (SLP). SLP provides a mechanism for service: URLs to be obtained dynamically, according to the service's attributes.
客户机或代表客户机的代理可以根据模板中定义的正式属性规范检查注册。服务注册通常使用服务位置协议[10]（SLP）完成。SLP为服务提供了一种机制：根据服务的属性动态获取URL。
It is also possible to obtain service: URLs from documents and using other protocols. In this case, the URL may not be accompanied by the service attributes. The context in which the URL appears should make it clear, if possible, when the service is appropriate to use. For example, in a mail message, a service might be recommended for use when the user is in a branch office. Or, an HTML document might include a service: URL as a pointer to a service, describing in text what the service does and who is authorized to use it.
还可以从文档和使用其他协议获取服务：URL。在这种情况下，URL可能不附带服务属性。如果可能的话，URL出现的上下文应该清楚地表明服务何时适合使用。例如，在邮件消息中，当用户在分支办公室时，可能会建议使用服务。或者，HTML文档可能包含一个service:URL作为指向服务的指针，用文本描述服务的功能以及授权使用它的人。
When a service type is specified, the specification includes the definition of the syntax for all URLs that are registered by services of that particular type. For instance, the "lpr" service type may be defined with service: URLs in the following form:
当指定服务类型时，规范包括该特定类型的服务注册的所有URL的语法定义。例如，“lpr”服务类型可以用以下形式的service:url定义：
service:printer:lpr://<address of printer>/<queue name>
service:printer:lpr://<address of printer>/<queue name>
The section of the URL after the address of the printer:
打印机地址后的URL部分：
"/" <queue name>
"/" <queue name>
is specific to the lpr service type and corresponds to the <url-path> field of the general service: URL syntax. This part is specified when the lpr service type is specified.
特定于lpr服务类型，并对应于general service:url语法的<url path>字段。指定lpr服务类型时指定此部分。
An abstract service type is a service type that can be implemented by a variety of different service agents.
抽象服务类型是可以由各种不同的服务代理实现的服务类型。
In order to register a service: URL for an abstract service type the 'abstract-type' grammar rule described in section 3.1 is used. This will result in a URL which includes enough information to use the service, namely, the protocol, address and path information. Unlike 'concrete' service: URLs, however, the service type is not enough to determine the service access. Rather, an abstract service type denotes a class of service types. The following subsection discusses this point in more detail.
为了注册抽象服务类型的service:URL，使用第3.1节中描述的“abstract type”语法规则。这将产生一个URL，其中包含足够的信息来使用该服务，即协议、地址和路径信息。然而，与“具体”服务不同的是：URL，服务类型不足以确定服务访问。相反，抽象服务类型表示一类服务类型。以下小节将更详细地讨论这一点。
Concrete service templates inherit all attributes defined in the abstract service template from which the concrete service template was derived. Attribute defined in the abstract service template MUST not be defined in the concrete service template as well. This simplifies interpretation of templates.
具体服务模板继承从中派生具体服务模板的抽象服务模板中定义的所有属性。抽象服务模板中定义的属性也不能在具体服务模板中定义。这简化了模板的解释。
For example, if an abstract service template for service type ' Abstract' defines an attribute FOO, all concrete service templates derived from the abstract service template, such as ' Abstract:Concrete' will implicitly include the definition of attribute FOO. This derived template MUST NOT redefine FOO, according to the rule above.
例如，如果服务类型“abstract”的抽象服务模板定义了一个属性FOO，那么从抽象服务模板派生的所有具体服务模板（例如“abstract:concrete”）都将隐式包含属性FOO的定义。根据上述规则，此派生模板不得重新定义FOO。
A further example is described in Section A.
第A节中描述了另一个示例。
Some services may make use of several protocols that are in common use and are distinct services in their own right. In these cases an abstract service type is appropriate. What is essential is that all the required information for the service is clearly defined.
有些服务可能使用几种常用的协议，它们本身就是不同的服务。在这些情况下，抽象服务类型是合适的。重要的是，明确定义了服务所需的所有信息。
For example, suppose a network service is being developed for dynamically loading device drivers. The client requires the following three pieces of information before it can successfully load and instantiate the driver:
例如，假设正在开发用于动态加载设备驱动程序的网络服务。客户端需要以下三条信息才能成功加载和实例化驱动程序：
1. The protocol used to load the driver code, for example, "ftp", "http" or "tftp"
1. 用于加载驱动程序代码的协议，例如，“ftp”、“http”或“tftp”
2. A pathname identifying where the driver code is located, for example "/systemhost/drivers/diskdrivers.drv",
2. 标识驱动程序代码所在位置的路径名，例如“/systemhost/drivers/diskdrivers.drv”，
3. The name of the driver, for example, "scsi".
3. 驱动程序的名称，例如“scsi”。
The temptation is to form the first two items into a URL and embed that into a service: URL. As an example which should be avoided,
诱惑是将前两项形成一个URL，并将其嵌入一个服务：URL。作为一个应该避免的例子，
service:ftp:/x3.bean.org/drivers/diskdrivers.drv;driver=scsi
service:ftp:/x3.bean.org/drivers/diskdrivers.drv;driver=scsi
is a service: URL which seems to indicate where to obtain the driver.
是一个服务：URL，它似乎指示从何处获取驱动程序。
Rather, an abstract service-type SHOULD be used. The service type is not "ftp", as the example indicates. Rather, it is "device-drivers". The service: URL that should be used, consistent with the rules in section [6], is the following:
相反，应该使用抽象服务类型。如示例所示，服务类型不是“ftp”。相反，它是“设备驱动程序”。与第[6]节中的规则一致，应使用的服务：URL如下：
service:device-drivers:ftp://x3.bean.org/drivers/diskdrivers.drv;
driver=scsi;platform=sys3.2-rs3000
service:device-drivers:ftp://x3.bean.org/drivers/diskdrivers.drv;
driver=scsi;platform=sys3.2-rs3000
Other URLs for the same service using other protocols are also supported, as in:
还支持使用其他协议的同一服务的其他URL，如：
service:device-drivers:tftp://x2.bean.org/vol3/disk/drivers.drv;
driver=scsi;platform=sys3.2-rs3000
service:device-drivers:tftp://x2.bean.org/vol3/disk/drivers.drv;
driver=scsi;platform=sys3.2-rs3000
service:device-drivers:http://www.bean.org/drivers/drivpak.drv;
driver=scsi;platform=sys3.2-rs3000
service:device-drivers:http://www.bean.org/drivers/drivpak.drv;
driver=scsi;platform=sys3.2-rs3000
Using SLP, a search for the service type "device-drivers" may return all of the three URLs listed above. The client selects the most appropriate access protocol for the desired resource.
使用SLP，搜索服务类型“设备驱动程序”可能会返回上面列出的所有三个URL。客户端为所需资源选择最合适的访问协议。
The fundamental requirement is that the abstract service type MUST be well specified. This requirement is imposed so that program code or human users have enough information to access the service. In every case, a well-specified abstract type will include either an access protocol and a network address where the service is available, or an embedded URL for a standardized URL scheme that describes how to access the service. In the example above, there are three further requirements: A URL path is included for access protocols indicating the document to download, and two attributes are included to characterize the driver.
基本要求是必须很好地指定抽象服务类型。这一要求是为了使程序代码或人类用户有足够的信息来访问服务。在每种情况下，一个明确指定的抽象类型将包括访问协议和服务可用的网络地址，或者一个用于描述如何访问服务的标准化URL方案的嵌入式URL。在上面的示例中，还有三个进一步的要求：URL路径用于访问协议，指示要下载的文档，并且包含两个属性来描述驱动程序。
Service type specifications are documents in a formal syntax defining properties important to service registration. These properties are:
服务类型规范是以正式语法定义对服务注册非常重要的属性的文档。这些属性是：
1. General information on the service type specification itself,
1. 服务类型规范本身的一般信息，
2. The syntax of the service type-specific part of the service URL,
2. 服务URL的服务类型特定部分的语法，
3. The definition of attributes associated with a service.
3. 与服务关联的属性的定义。
The service type specification document is the service type template.
服务类型规范文档是服务类型模板。
The following subsections describe the syntax and semantics of service type templates.
以下小节描述服务类型模板的语法和语义。
Service template documents are encoded in a simple form. They may be translated into any language or character set, but the template used for standardization MUST be encoded in the 0x00-0x7F subrange of UTF-8 [16] (which corresponds to ASCII character encoding) and be in English.
服务模板文档以简单的形式编码。它们可以翻译成任何语言或字符集，但用于标准化的模板必须在UTF-8[16]（对应于ASCII字符编码）的0x00-0x7F子范围内编码，并且必须使用英语。
A template document begins with a block of text assigning values to five document identification items. The five identification items can appear in any order within the block, but conventionally the "template-type" item, which assigns the service type name, occurs at the very top of the document in order to provide context for the rest of the document. The attribute definition item occurs after the document identification items.
模板文档以一个文本块开始，该文本块将值分配给五个文档标识项。这五个标识项可以以任何顺序出现在块中，但按照惯例，分配服务类型名称的“模板类型”项出现在文档的最顶端，以便为文档的其余部分提供上下文。属性定义项出现在文档标识项之后。
All items end with a blank line. The reserved characters are ";", "%", "=", ",", "#", LF, and CR. Reserved characters MUST be escaped. The escape sequence is the same as described in [5].
所有项目都以一个空行结束。保留字符为“；”、“%”、“=”、“、”、“#”、LF和CR。保留字符必须转义。逃逸序列与[5]中描述的相同。
The service template is encoded in a UTF-8 character set, but submitted as a part of an work in progress, which is encoded in ASCII characters. All characters which are outside of the ASCII range MUST be escaped using the `\' HEXDIG HEXDIG syntax. For example, the letter e accent aigue would be represented as "\c3\a9". Unfortunately, this will detract from the readability of the service template in the service template submission. Hopefully some public domain tools will emerge for translating escaped UTF-8 characters into humanly readable ones.
服务模板以UTF-8字符集编码，但作为正在进行的工作的一部分提交，该工作以ASCII字符编码。所有超出ASCII范围的字符都必须使用“\”HEXDIG HEXDIG语法进行转义。例如，字母e将表示为“\c3\a9”。不幸的是，这会降低服务模板提交中服务模板的可读性。希望出现一些公共领域工具，将转义的UTF-8字符翻译成人类可读的字符。
Values in value lists are separated by commas. A value list is terminated by a newline not preceded by a comma. If the newline is preceded by a comma, the value list is interpreted to continue onto the next line.
值列表中的值用逗号分隔。值列表以不带逗号的换行符结尾。如果换行符前面有逗号，则值列表将被解释为继续到下一行。
Attribute identifiers, attribute type names, and flags are all case insensitive. For ease of presentation, upper and lower case characters can be used to represent these in the template document. Newlines are significant in the grammar. They delimit one item from another, as well as separating parts of items internally.
属性标识符、属性类型名称和标志都不区分大小写。为了便于演示，可以在模板文档中使用大写和小写字符来表示这些内容。新行在语法中很重要。它们将一个项目与另一个项目区分开来，并在内部分隔项目的各个部分。
String values are considered to be a sequence of non-whitespace tokens potentially with embedded whitespace, separated from each other by whitespace. Commas delimit lists of strings. String values are trimmed so as to reduce any sequence of white space interior to a string to a single white space. Preceding or trailing white space is removed. For example:
字符串值被认为是一系列可能带有嵌入空格的非空格标记，它们之间用空格隔开。逗号分隔字符串列表。字符串值将被修剪，以便将字符串内部的任何空格序列减少为单个空格。删除前面或后面的空白。例如：
" some value , another example "
“一些价值，另一个例子”
is trimmed to
修剪为
"some value" and "another example".
“一些价值”和“另一个例子”。
Note that there can be no ambiguity in string tokenization because values in value lists are separated by a comma. String tokens are not delimited by double quotes (") as is usually the case with programming languages.
请注意，字符串标记化中不会出现歧义，因为值列表中的值用逗号分隔。字符串标记不是像编程语言那样用双引号（“）分隔的。
Attribute tags and values are useful for directory look-up. In this case, decoding of character escapes and trimming white space MUST be performed before string matching. In addition, string matching SHOULD be case insensitive.
属性标记和值对于目录查找很有用。在这种情况下，必须在字符串匹配之前执行字符转义的解码和空格的修剪。此外，字符串匹配应该不区分大小写。
Templates obey the following ABNF [8] grammar:
模板遵循以下ABNF[8]语法：
template = tem-attrs attr-defs
tem-attrs = schemetype schemevers schemetext schemeurl
schemetype = "template-type=" scheme term
schemevers = "template-version=" version-no term
schemetext = "template-description=" newline desc term
schemeurl = "template-url-syntax=" newline url-bnf term
url-bnf = *[ com-chars ]
; An ABNF describing the <url-path> production
; in the service: URL grammar of Section 2.1.
scheme = service-type [ "." naming-auth ]
service-type = scheme-name
naming-auth = scheme-name
scheme-name = ALPHA [1*schemechar] [ "." 1*schemechar ]
schemechar = ALPHA / DIGIT / "-" / "+" /
version-no = 1*DIGIT "." 1*DIGIT
langtag = 1*8ALPHA ["-" 1*8ALPHA]
; See [3]
desc = *[ com-chars ]
; A block of free-form text for reading by
; people describing the service in a short,
; informative manner.
term = newline newline
attr-defs = *( attr-def / keydef )
attr-def = id "=" attrtail
keydef = id "=" "keyword" newline [help-text] newline
attrtail = type flags newline [value-list] [help-text]
[value-list] newline
id = 1*attrchar
type = "string" / "integer" / "boolean" / "opaque"
flags = ["m"/"M"] ["l"/"L"] ["o"/"O"] ["x"/"X"]
value-list = value newline / value "," value-list /
value "," newline value-list
help-text = 1*( "#" help-line )
; A block of free-form text for reading by
; people describing the attribute and
; its values.
help-line = *[ com-chars ] newline
attrchar = schemechar / ":" / "_" / "$" / "~" / "@" / "." /
"|" / "<" / ">" / "*" / "&"
value = string / integer / boolean / opaque
string = safe-char *[safe-char / white-sp] safe-char
integer = [ "+" | "-" ] 1*DIGIT
boolean = "true" / "false"
opaque = "\FF" 1*( "\" HEXDIG HEXDIG)
; Each byte of opaque value is hex encoded.
; The format corresponds to [10].
template = tem-attrs attr-defs
tem-attrs = schemetype schemevers schemetext schemeurl
schemetype = "template-type=" scheme term
schemevers = "template-version=" version-no term
schemetext = "template-description=" newline desc term
schemeurl = "template-url-syntax=" newline url-bnf term
url-bnf = *[ com-chars ]
; An ABNF describing the <url-path> production
; in the service: URL grammar of Section 2.1.
scheme = service-type [ "." naming-auth ]
service-type = scheme-name
naming-auth = scheme-name
scheme-name = ALPHA [1*schemechar] [ "." 1*schemechar ]
schemechar = ALPHA / DIGIT / "-" / "+" /
version-no = 1*DIGIT "." 1*DIGIT
langtag = 1*8ALPHA ["-" 1*8ALPHA]
; See [3]
desc = *[ com-chars ]
; A block of free-form text for reading by
; people describing the service in a short,
; informative manner.
term = newline newline
attr-defs = *( attr-def / keydef )
attr-def = id "=" attrtail
keydef = id "=" "keyword" newline [help-text] newline
attrtail = type flags newline [value-list] [help-text]
[value-list] newline
id = 1*attrchar
type = "string" / "integer" / "boolean" / "opaque"
flags = ["m"/"M"] ["l"/"L"] ["o"/"O"] ["x"/"X"]
value-list = value newline / value "," value-list /
value "," newline value-list
help-text = 1*( "#" help-line )
; A block of free-form text for reading by
; people describing the attribute and
; its values.
help-line = *[ com-chars ] newline
attrchar = schemechar / ":" / "_" / "$" / "~" / "@" / "." /
"|" / "<" / ">" / "*" / "&"
value = string / integer / boolean / opaque
string = safe-char *[safe-char / white-sp] safe-char
integer = [ "+" | "-" ] 1*DIGIT
boolean = "true" / "false"
opaque = "\FF" 1*( "\" HEXDIG HEXDIG)
; Each byte of opaque value is hex encoded.
; The format corresponds to [10].
; Newlines are ignored in decoding opaque
; values.
com-chars = safe-char / white-sp / "," / ";"/ "%"
safe-char = attrchar / escaped / " " / "!" / '"' / "'" /
"|" / "(" / ")" / "+" / "-" / "." / ":" /
"=" / "?" / "[" / "]" / "{" / "/" / "{" /
"$"
; All UTF-8 printable characters are
; included except ",", "%", ";", and "#".
escaped = 1*(`\' HEXDIG HEXDIG)
white-sp = SPACE / HT
newline = CR / ( CR LF )
; Newlines are ignored in decoding opaque
; values.
com-chars = safe-char / white-sp / "," / ";"/ "%"
safe-char = attrchar / escaped / " " / "!" / '"' / "'" /
"|" / "(" / ")" / "+" / "-" / "." / ":" /
"=" / "?" / "[" / "]" / "{" / "/" / "{" /
"$"
; All UTF-8 printable characters are
; included except ",", "%", ";", and "#".
escaped = 1*(`\' HEXDIG HEXDIG)
white-sp = SPACE / HT
newline = CR / ( CR LF )
The service type template defines the service attributes and service: URL syntax for a particular service type. The attribute definition includes the attribute type, default values, allowed values and other information.
服务类型模板定义特定服务类型的服务属性和service:URL语法。属性定义包括属性类型、默认值、允许值和其他信息。
Note that the 'template-type', 'template-version', 'template-description' and 'template-url-syntax' have all been defined as attributes. These attributes MAY accompany any service registration using SLPv2.
请注意，“模板类型”、“模板版本”、“模板描述”和“模板url语法”都已定义为属性。这些属性可能伴随使用SLPv2的任何服务注册。
There are four items included in the service template. The semantics of each item is summarized below.
服务模板中包括四个项目。每个项目的语义总结如下。
- template-type
- 模板类型
The scheme name of the service scheme. The scheme name consists of the service type name and an optional naming authority name, separated from the service type name by a period. See 3.2.2 for the conventions governing service type names.
服务方案的方案名称。方案名称由服务类型名称和可选命名机构名称组成，与服务类型名称之间用句点分隔。有关管理服务类型名称的约定，请参见3.2.2。
- template-version
- 模板版本
The version number of the service type specification.
服务类型规范的版本号。
- template-description
- 模板描述
A description of the service suitable for inclusion in text read by people.
适合包含在人们阅读的文本中的服务说明。
- template-url-syntax
- 模板url语法
The syntax of the service type-specific URL part of the service: URL.
服务的特定于服务类型的URL部分的语法：URL。
- attribute definitions
- 属性定义
A collection of zero or more definitions for attributes associated with the service in service registrations.
服务注册中与服务关联的属性的零个或多个定义的集合。
Each of the following subsections deals with one of these items.
以下每一小节都涉及其中一项。
The service scheme consists of the service type name and an optional naming authority name separated from the service type name by a period. The service scheme is a string that is appended to the ' service:' URL scheme identifier, and is the value of the "template-type" item in the template document. If the naming authority name is absent it is assumed to be IANA.
服务方案由服务类型名称和可选的命名机构名称组成，命名机构名称与服务类型名称之间以句点分隔。服务方案是附加到“服务：”URL方案标识符的字符串，是模板文档中“模板类型”项的值。如果没有命名机构名称，则假定为IANA。
The version number of the service type template is the value of the "template-version" item. A draft proposal starts at 0.0, and the minor number increments once per revision. A standardized template starts at 1.0. Additions of optional attributes add one to the minor number, and additions of required attributes, changes of definition, or removal of attributes add one to the major number. The intent is that an old service template still accurately, if incompletely, defines the attributes of a service registration if the template only differs from the registration in its minor version. See Section 4 for more detail on how to use the template-version attribute.
服务类型模板的版本号是“模板版本”项的值。提案草案从0.0开始，每修订一次，次要数字递增一次。标准化模板从1.0开始。添加可选属性会将一个添加到次要编号，添加必需属性、更改定义或删除属性会将一个添加到主要编号。其目的是，如果旧服务模板仅在次要版本中与注册不同，则该模板仍然准确（如果不完全）定义服务注册的属性。有关如何使用“模板版本”属性的更多详细信息，请参见第4节。
The description is a block of text readable by people in the language of the template and is the value of the "template-description" item. It should be sufficient to identify the service to human readers and provide a short, informative description of what the service does.
描述是人们可以用模板语言阅读的文本块，是“模板描述”项的值。它应该足以向人类读者识别服务，并提供服务功能的简短、信息性描述。
If the service type corresponds to a particular protocol, the protocol specification must be cited here. The protocol need not be a standardized protocol. The template might refer to a proprietary specification, and refer the reader of the template to a contact person for further information.
如果服务类型对应于特定协议，则必须在此处引用协议规范。该协议不必是标准化协议。模板可能引用专有规范，并将模板的读者提交给联系人以获取更多信息。
The syntax of the service type-specific part of the service: URL is provided in the template document as the value of the "template-url-syntax" item. The <url-path> field of the service: URL is designed to provide additional information to locate a service when the <addr-spec> field is not sufficient. The <url-path> field distinguishes URLs of a particular service type from those of another service type. For instance, in the case of the lpr service type, the <url-path> may be defined so that it must include the queue name, but other service types may not require this information.
服务的服务类型特定部分的语法：URL在模板文档中作为“模板URL语法”项的值提供。service:url的<url path>字段用于在<addr spec>字段不足时提供定位服务的附加信息。<url path>字段将特定服务类型的url与其他服务类型的url区分开来。例如，对于lpr服务类型，可以定义<url path>，以便它必须包含队列名称，但其他服务类型可能不需要此信息。
The syntax for the <url-path> field MUST accompany the definition of a new service type, unless the URL scheme has already been standardized and is not a service: URL. The syntax is included in the template document as an ABNF [8] following the rules for URL syntax described in [5]. There is no requirement for a service scheme to support a <url-path>. The <url-path> field can be very simple, or even omitted. If the URL scheme has already been standardized, the "template-url-syntax" item SHOULD include a reference to the appropriate standardization documents. Abstract service types may defer this field to the template documents describing their concrete instances.
<url path>字段的语法必须随新服务类型的定义一起提供，除非url方案已经标准化并且不是服务：url。该语法作为ABNF[8]包含在模板文档中，遵循[5]中描述的URL语法规则。服务方案不需要支持<url路径>。<url path>字段可以非常简单，甚至可以省略。如果URL方案已经标准化，“模板URL语法”项应包括对适当标准化文档的引用。抽象服务类型可以将此字段推迟到描述其具体实例的模板文档。
The bulk of the template is typically devoted to defining service type-specific attributes. An attribute definition precisely specifies the attribute's type, other restrictions on the attribute (whether it is multi-valued, optional, etc), some text readable by people describing the attribute, and lists of default and allowed values. The only required information is the attribute's type, the rest are optional. Registration, deregistration and the use of attributes in queries can be accomplished using the Service Location Protocol [10] or other means, and discussion of this is beyond the scope of the document.
模板的大部分通常用于定义特定于服务类型的属性。属性定义精确地指定了属性的类型、对属性的其他限制（是否为多值、可选等）、描述属性的人可读的一些文本，以及默认值和允许值的列表。唯一需要的信息是属性的类型，其余信息是可选的。可以使用服务位置协议[10]或其他方式完成注册、注销和查询中属性的使用，对此的讨论超出了本文档的范围。
Attributes are used to convey information about a given service for purposes of differentiating different services of the same type. They convey information to be used in the selection of a particular service to establish communicate with, either through a program offering a human interface or programmatically. Attributes can be encoded in different character sets and in different languages. The procedure for doing this is described in Section 6.
属性用于传递有关给定服务的信息，以便区分相同类型的不同服务。它们通过提供人机界面的程序或以编程方式传递信息，用于选择要建立通信的特定服务。属性可以用不同的字符集和语言编码。第6节介绍了执行此操作的步骤。
An attribute definition begins with the specification of the attribute's identifier and ends with a single empty line. Attributes definitions have five components (in order of appearance in a
属性定义从属性标识符的指定开始，以一个空行结束。属性定义有五个组件（按外观顺序排列）
definition):
定义）：
1. An attribute identifier which acts as the name of the attribute,
1. 作为属性名称的属性标识符，
2. Attribute descriptors (type and flags),
2. 属性描述符（类型和标志），
3. An optional list of values which are assigned to the attribute by default,
3. 默认情况下指定给属性的可选值列表，
4. An optional block of text readable by people providing a short, informative description of the attribute,
4. 可供人们阅读的可选文本块，提供属性的简短信息描述，
5. An optional list of allowed values which restrict the value or values the attribute can take on.
5. 允许值的可选列表，用于限制属性可以采用的一个或多个值。
An attribute definition starts with the specification of the attribute's identifier. The attribute's identifier functions as the name of the attribute. Note that the characters used to compose an attribute identifier are restricted to those characters considered unrestricted for inclusion in a URL according to [5]. The reason is that services can display prominent attributes in their service: URL registrations. Each attribute identifier must be unique in the template. Since identifiers are case folded, upper case and lower case characters are the same.
属性定义从属性标识符的指定开始。属性的标识符用作属性的名称。请注意，根据[5]，用于组成属性标识符的字符仅限于那些被认为不受限制地包含在URL中的字符。原因是服务可以在其服务中显示突出的属性：URL注册。每个属性标识符在模板中都必须是唯一的。因为标识符是大小写折叠的，所以大写和小写字符是相同的。
Attributes can have one of five different types: string, integer, boolean, opaque, or keyword. The attribute's type specification is separated from the attribute's identifier by an equal sign ("=") and follows the equal sign on the same line. The string, signed integer, and boolean types have the standard programming language or database semantics. Integers are restricted to those signed values that can be represented in 32 bits. The character set used to represent strings is not specified at the time the template is defined, but rather is determined by the service registration. Booleans have the standard syntax. Opaques are byte escaped values that can be used to represent any other kind of data. Keywords are attributes that have no characteristics other than their existence (and possibly the descriptive text in their definition).
属性可以有五种不同类型之一：字符串、整数、布尔值、不透明或关键字。属性的类型规范与属性的标识符之间用等号（“=”）分隔，并在同一行上跟随等号。字符串、带符号整数和布尔类型具有标准编程语言或数据库语义。整数仅限于那些可以用32位表示的有符号值。用于表示字符串的字符集在定义模板时未指定，而是由服务注册确定。布尔语有标准语法。opaque是字节转义值，可用于表示任何其他类型的数据。关键字是除了其存在（可能还有其定义中的描述性文本）之外没有其他特征的属性。
Keyword and boolean attributes impose restrictions on the following parts of the attribute definition. Keyword attribute definitions MUST have no flag information following the type definition, nor any default or allowed values list. Boolean attributes are single value only, i.e., multi-valued boolean attributes are not allowed.
关键字和布尔属性对属性定义的以下部分施加限制。关键字属性定义在类型定义之后不能有标志信息，也不能有任何默认值或允许值列表。布尔属性仅为单值，即不允许使用多值布尔属性。
Flags determine other characteristics of an attribute. With the exception of keyword attributes, which may not have any flags, flags follow the attribute type on the same line as the attribute identifier, and are separated from each other by whitespace. Flags may appear in any order after the attribute type. Other information must not follow the flags, and only one flag identifier of a particular flag type is allowed per attribute definition.
标志确定属性的其他特征。除了关键字属性（可能没有任何标志）之外，标志与属性标识符位于同一行上的属性类型之后，并通过空格相互分隔。标志可以在属性类型之后以任何顺序出现。其他信息不能跟在标志后面，每个属性定义只允许一个特定标志类型的标志标识符。
The semantics of the flags are as follows:
这些标志的语义如下所示：
- o or O
- o或o
Indicates that the attribute is optional. If this flag is missing, the attribute is required in every service registration.
指示该属性是可选的。如果缺少此标志，则每个服务注册中都需要该属性。
- m or M
- m还是m
Indicates that the attribute can take on multiple values. If this flag is present, every value in a multi-valued attribute has the same type as the type specified in the type part of the attribute definition. Boolean attributes must not include this flag.
指示属性可以具有多个值。如果存在此标志，则多值属性中的每个值的类型都与属性定义的类型部分中指定的类型相同。布尔属性不能包含此标志。
- l or L
- 我还是我
Indicates that attribute is literal, i.e. is not meant to be translated into other languages. If this flag is present, the attribute is not considered to be readable by people and should not be translated when the template is translated. See Section 6 for more information about translation.
指示属性为文本，即不应翻译为其他语言。如果存在此标志，则认为该属性不可读，并且在翻译模板时不应翻译该属性。有关翻译的更多信息，请参见第6节。
- x or X
- x或x
Indicates that clients SHOULD include the indicated attribute in requests for services. Neglecting to include this attribute will not sufficiently differentiate the service. If services are obtained without selecting this attribute they will quite likely be useless to the client.
指示客户端应在服务请求中包含指示的属性。忽略包含此属性将不会充分区分服务。如果在未选择此属性的情况下获得服务，则这些服务很可能对客户端没有用处。
The values for multivalued attributes are an unordered set. Deletions of individual values from a multivalued attribute are not supported, and deletion of the attribute causes the entire set of values to be removed.
多值属性的值是无序集。不支持从多值属性中删除单个值，删除该属性会导致删除整个值集。
If the attribute definition includes a default value or, in the case of multivalued attributes, a default values list, it begins on the second line of the attribute definition and continues over the following lines until a line ends without a comma. As a consequence, newlines cannot be embedded in values unless escaped. See Section 2.1.
如果属性定义包含一个默认值，或者在多值属性的情况下包含一个默认值列表，则它从属性定义的第二行开始，并在以下行上继续，直到一行结束时没有逗号。因此，除非转义，否则新行不能嵌入到值中。见第2.1节。
Particular attribute types and definitions restrict the default values list. Keyword attributes must not have a list of defaults. If an optional attribute's definition has an allowed values list, then a default value or list is not optional but required. The motivation for this is that defining an attribute with an allowed values list is meant to restrict the values the attribute can take on, and requiring a default value or list assures that the default value is a member of the given set of allowed values.
特定的属性类型和定义限制默认值列表。关键字属性不能有默认值列表。如果可选属性的定义具有允许的值列表，则默认值或列表不是可选的，而是必需的。这样做的动机是，定义具有允许值列表的属性意味着限制属性可以采用的值，并且需要默认值或列表可以确保默认值是给定允许值集的成员。
The default value or list indicates what values the attribute is given if no values are assigned to the attribute when a service is registered. If an optional attribute's definition includes no default value or list, the following defaults are assigned:
默认值或列表指示在注册服务时，如果没有为属性分配值，则该属性将给出哪些值。如果可选属性的定义不包含默认值或列表，则会指定以下默认值：
1. String values are assigned the empty string,
1. 字符串值被指定为空字符串，
2. Integer values are assigned zero,
2. 整数值被赋值为零，
3. Boolean values are assigned false,
3. 布尔值被指定为false，
4. Opaque values are assigned a byte array containing no values,
4. 不透明值被分配一个不包含任何值的字节数组，
5. Multi-valued attributes are initialized with a single value.
5. 多值属性使用单个值初始化。
For purposes of translating nonliteral attributes, the default values list is taken to be an ordered set, and translations MUST maintain that order.
为了转换非文字属性，默认值列表被视为有序集，并且转换必须保持该顺序。
Immediately after the default values list, if any, a block of descriptive text SHOULD be included in the attribute definition. This text is meant to be readable by people, and should include a short, informative description of the attribute. It may also provide additional information, such as a description of the allowed values. This text is primarily designed for display by interactive browsing tools. The descriptive text is set off from the surrounding definition by a crosshatch character ("#") at the beginning of the line. The text should not, however, be treated as a comment by
在默认值列表（如果有）之后，属性定义中应立即包含一块描述性文本。此文本旨在供人们阅读，并应包括对属性的简短、信息性描述。它还可以提供附加信息，例如允许值的描述。此文本主要用于通过交互式浏览工具显示。描述性文本由行首的交叉线字符（#）与周围定义隔开。但是，该案文不应被视为缔约国的评论
parsing and other tools, since it is an integral part of the attribute definition. Within the block of descriptive text, the text is transferred verbatim, including indentation and line breaks, so any formatting is preserved.
解析和其他工具，因为它是属性定义的一个组成部分。在描述性文本块中，文本逐字传输，包括缩进和换行，因此保留任何格式。
Finally, the attribute definition concludes with an optional allowed values list. The allowed values list, if any, follows the descriptive text, or, if the descriptive text is absent, the initial values list. The syntax of the allowed values list is identical to that of the initial values list. The allowed values list is also terminated by a line that does not end in a comma. If the allowed values list is present, assignment to attributes is restricted to members of the list.
最后，属性定义以可选的允许值列表结束。“允许值”列表（如果有）位于描述性文本之后，如果没有描述性文本，则位于“初始值”列表之后。“允许值”列表的语法与“初始值”列表的语法相同。“允许值”列表也以不以逗号结尾的行终止。如果存在“允许的值”列表，则对属性的指定仅限于列表中的成员。
As with the default values list, the allowed values list is also considered to be an ordered set for purposes of translation.
与默认值列表一样，出于转换的目的，允许值列表也被视为有序集。
An attribute definition concludes with a single empty line.
属性定义以一个空行结束。
New service types can be suggested simply by providing a service type template and a short description about how to use the service. The template MUST have its "template-version" template attribute set to 0.0.
只需提供服务类型模板和关于如何使用服务的简短描述，就可以建议新的服务类型。模板的“模板版本”模板属性必须设置为0.0。
MAJOR revision numbers come before the '.', MINOR revision numbers come after the '.'.
主要修订号在“.”之前，次要修订号在“.”之后。
The minor version number increments once with each change until it achieves 1.0. There is no guarantee any version of the service template is backward compatible before it reaches 1.0.
次要版本号随每次更改增加一次，直到达到1.0。无法保证任何版本的服务模板在达到1.0之前都是向后兼容的。
Once a service template has reached 1.0, the definition is "frozen" for that version. New templates must be defined, of course, to refine that definition, but the following rules must be followed:
一旦服务模板达到1.0，该版本的定义将“冻结”。当然，必须定义新模板以细化该定义，但必须遵循以下规则：
A MINOR revision number signifies the introduction of a compatible change. A MAJOR revision number signifies the introduction of an incompatible change. This is formalized by the following rules:
次要修订号表示引入了兼容的变更。主要修订号表示引入了不兼容的变更。这由以下规则正式规定：
- Any new optional attribute defined for the template increases the minor version number by one. All other attributes for the version must continue to be supported as before. A client which
- 为模板定义的任何新可选属性都会将次要版本号增加1。版本的所有其他属性必须像以前一样继续受支持。客户
supports 1.x can still use later versions of 1.y (where x<y) as it ignores attributes it doesn't know about.
支持1.x仍然可以使用1.y的更高版本（其中x<y），因为它忽略了它不知道的属性。
- Adding a required attribute, removing support for an attribute or changing definition of an attribute requires changing the major version number of a service template. A client application may be unable to make use of this information, or it may need to obtain the most recent service template to help the user interpret the service information.
- 添加必需的属性、删除对属性的支持或更改属性的定义需要更改服务模板的主要版本号。客户端应用程序可能无法使用此信息，或者可能需要获取最新的服务模板以帮助用户解释服务信息。
The template is submitted to a special mailing list, see section 5. This document must include a 'template begins here' and 'template ends here' marking, in text, so that it is trivial to cut and paste the template from the submission.
模板被提交到一个特殊的邮件列表中，见第5节。此文档必须包含文本中的“模板从此处开始”和“模板到此结束”标记，以便从提交内容中剪切和粘贴模板非常简单。
The list will be available at svrloc-list@iana.org. Ideally, experts in the implementation and deployment of the particular protocol are consulted so as to add or delete attributes or change their definition to make the template as useful as possible. The mailing list will be maintained even when the SVRLOC WG goes dormant for the purpose of discussing service templates.
该列表将在svrloc上提供-list@iana.org. 理想情况下，咨询特定协议实施和部署方面的专家，以便添加或删除属性或更改其定义，使模板尽可能有用。即使SVRLOC工作组为了讨论服务模板而处于休眠状态，邮件列表也将得到维护。
All published versions of the template must be available on-line, including obsolete ones.
模板的所有发布版本必须在线可用，包括过时版本。
Once consensus is achieved, the template should be reissued with possible corrections, having its Version number set to 1.0. Templates with version numbers below 1.0 are not submitted to the IANA. From that point onwards, templates are submitted. See Section 5 for details on how templates are submitted to an IANA registry of templates.
一旦达成共识，应重新发布模板，并进行可能的更正，将其版本号设置为1.0。版本号低于1.0的模板不会提交给IANA。从那时起，将提交模板。有关如何将模板提交到IANA模板注册表的详细信息，请参见第5节。
It is the responsibility of the IESG (e.g., Applications Area director) to appoint a Designated Expert (see [12].) Anyone may ask for clarification of a service template. This is to solicit input from the concerned community. It is up to the appointed reviewer to determine whether clarification requests are satisfied. It is the reviewer's responsibility to see that all reasonable clarification requests are met before the template is submitted for inclusion in the IANA registry.
IESG（例如，应用领域总监）负责任命指定专家（见[12]）。任何人都可以要求澄清服务模板。这是为了征求有关社区的意见。是否满足澄清要求由指定审查人决定。审核人有责任确保在提交模板以纳入IANA注册之前满足所有合理的澄清要求。
When the reviewer has determined that the template submission is ready, he or she will submit the template to the IANA for inclusion in a registry. Mailing list participants supply input to the process but do not make the decision whether to accept a service template.
当审核人确定模板提交已准备就绪时，他或她将向IANA提交模板，以便将其包含在注册表中。邮件列表参与者向流程提供输入，但不决定是否接受服务模板。
If a dispute arises over the decisions made by the reviewer, the matter may be appealed according to normal IETF procedure as described for the Standards Track process.
如果对评审员做出的决定产生争议，可根据标准跟踪过程中所述的正常IETF程序对该事项提出上诉。
The IANA will maintain a mail forwarding alias for the work of this list, so that "svrloc-list@iana.org" points to a mail server supplied by a volunteer organization.
IANA将为此列表的工作维护一个邮件转发别名，以便“svrloc”-list@iana.org指向志愿者组织提供的邮件服务器。
The service template submission MUST be of the form:
服务模板提交必须采用以下格式：
Name of submitter:
Language of service template:
Security Considerations:
Template Text:
----------------------template begins here-----------------------
. . .
-----------------------template ends here------------------------
Name of submitter:
Language of service template:
Security Considerations:
Template Text:
----------------------template begins here-----------------------
. . .
-----------------------template ends here------------------------
The service template file has a naming convention:
服务模板文件具有命名约定：
<service-type> "." <version-no> "." <langtag>
<service-type> "." <version-no> "." <langtag>
Each of these fields are defined in Section 2. They correspond to the values of the template fields "type", "template-version". The files for the example templates in this document (see Section A) are called:
这些字段中的每一个都在第2节中定义。它们对应于模板字段“类型”、“模板版本”的值。本文档中示例模板的文件（见A节）称为：
"foo.0.0.en", "Net-Transducer.0.0.en", "Net-Transducer:Thermometer.0.0.de" and "Net-Transducer:Thermomoter.0.0.en".
“foo.0.0.en”、“网络传感器.0.0.en”、“网络传感器：温度计.0.0.de”和“网络传感器：温度计.0.0.en”。
The reviewer will ensure that the template submission to IANA has the correct form and required fields.
审核人将确保提交给IANA的模板具有正确的格式和必填字段。
No service type template will be accepted for inclusion in the service template registry unless the submission includes a security considerations section and contact information for the template document author.
除非提交内容包含安全注意事项部分和模板文档作者的联系信息，否则不接受服务类型模板包含在服务模板注册表中。
The IANA will maintain a registry containing both the service type templates, and the template description document containing the service type template, including all previous versions. The IANA will receive notice to include a service template in the registry by email from the reviewer. This message will include the service template itself, which is to be registered.
IANA将维护一个包含服务类型模板和包含服务类型模板的模板描述文档（包括所有以前的版本）的注册表。IANA将收到审核人通过电子邮件发出的在注册表中包含服务模板的通知。此消息将包括要注册的服务模板本身。
Neither the reviewer nor the IANA will take any position on claims of copyright or trademark issues with regard to templates.
评审员和IANA都不会就模板的版权或商标问题采取任何立场。
The service: URL must be encoded using the rules set forth in [5]. The character set encoding is limited to specific ranges within the US-ASCII character set [4].
服务：URL必须使用[5]中规定的规则进行编码。字符集编码仅限于US-ASCII字符集中的特定范围[4]。
The template is encoded in UTF-8 characters.
模板以UTF-8字符编码。
The language used in attribute strings should be identified supplying a Language Tag [3] in the Service Template submission (see Section 5).
属性字符串中使用的语言应该通过在服务模板提交中提供语言标记[3]来标识（参见第5节）。
A program can translate a service registration from one language to another provided it has both the template of the language for the registration and the template of the desired target language. All standardized attributes are in the same order in both templates. All non-arbitrary strings, including the descriptive help text, is directly translatable from one language to another. Non-literal attribute definitions, attribute identifiers, attribute type names, attribute flags, and the boolean constants "true" and "false" are never translated. Translation of attribute identifiers is prohibited because, as with domain names, they can potentially be part of a service: URL and therefore their character set is restricted. In addition, as with variable identifiers in programming languages, they could become embedded into program code.
程序可以将服务注册从一种语言转换为另一种语言，前提是它同时具有注册语言的模板和所需目标语言的模板。所有标准化属性在两个模板中的顺序相同。所有非任意字符串，包括描述性帮助文本，都可以从一种语言直接翻译到另一种语言。非文字属性定义、属性标识符、属性类型名称、属性标志以及布尔常量“true”和“false”永远不会被转换。禁止翻译属性标识符，因为与域名一样，它们可能是服务URL的一部分，因此它们的字符集受到限制。此外，与编程语言中的变量标识符一样，它们可以嵌入到程序代码中。
All strings used in attribute values are assumed translatable unless explicitly defined as being literal, so that best effort translation (see below) does not modify strings which are meant to be interpreted by a program, not a person.
除非明确定义为文字，否则属性值中使用的所有字符串都假定为可翻译的，以便尽力而为的翻译（见下文）不会修改拟由程序而非人员解释的字符串。
An example of a translated service template is included in Section A.
翻译后的服务模板示例包含在第a节中。
There are two ways to go about translation: standardization and best effort.
翻译有两种方法：标准化和尽力而为。
When the service type is standardized, more than one document can be submitted for review. One service type description is approved as a master, so that when a service type template is updated in one language, all the translations (at least eventually) reflect the same semantics.
当服务类型标准化时，可以提交多个文档进行审查。一个服务类型描述被批准为主描述，因此当一个服务类型模板以一种语言更新时，所有翻译（至少最终）都反映相同的语义。
If no document exists describing the standard translation of the service type, a 'best effort' translation for strings should be done.
如果不存在描述服务类型的标准翻译的文档，则应对字符串进行“尽力”翻译。
Service type templates provide information that is used to interpret information obtained by the Service Location Protocol. If these templates are modified or false templates are distributed, services may not correctly register themselves, or clients might not be able to interpret service information.
服务类型模板提供用于解释服务位置协议获得的信息的信息。如果修改了这些模板或分发了错误的模板，则服务可能无法正确注册自身，或者客户端可能无法解释服务信息。
The service: URLs themselves specify the service access point and protocol for a particular service type. These service: URLs could be distributed and indicate the location of a service other than that normally want to used. The Service Location Protocol [10] distributes service: URLs and has an authentication mechanism that allows service: URLs of registered services to be signed and for the signatures to be verified by clients.
服务：URL本身为特定服务类型指定服务访问点和协议。这些服务：URL可以是分布式的，并指示服务的位置，而不是通常想要使用的位置。服务位置协议[10]分发服务：URL，并具有一种身份验证机制，允许对已注册服务的服务：URL进行签名，并允许客户端验证签名。
Each Service Template will include a security considerations section which will describe security issues with using the service scheme for the specific Service Type.
每个服务模板将包括一个安全注意事项部分，该部分将描述使用特定服务类型的服务方案时的安全问题。
A. Service Template Examples
A.服务模板示例
The text in the template example sections is to be taken as being a single file. They are completely fictitious (ie. the examples do not represent real services).
模板示例部分中的文本将被视为单个文件。它们完全是虚构的（即示例并不代表真实的服务）。
The FOO example shows how to use service templates for an application that has very few attributes. Clients request the FOO server where their user data is located by including their user name as the value of the user attribute.
FOO示例展示了如何为属性很少的应用程序使用服务模板。客户端通过将其用户名作为用户属性的值来请求其用户数据所在的FOO服务器。
The Net-Transducer example shows how abstract service types are defined and how a corresponding concrete instance is defined. A system might support any of several NetTransducer services. Here we give only one concrete instance of the abstract type.
Net Transformer示例显示如何定义抽象服务类型以及如何定义相应的具体实例。系统可能支持多个NetTransducer服务中的任何一个。这里我们只给出抽象类型的一个具体实例。
It is not necessary to register concrete templates for an abstract service type if the abstract service type template is completely clear as to what possible values can be used as a concrete type, and what their interpretation is.
如果抽象服务类型模板完全清楚哪些可能的值可以用作具体类型，以及它们的解释是什么，则无需为抽象服务类型注册具体模板。
The FOO service template submission example follows:
FOO服务模板提交示例如下：
Name of submitter: "Erik Guttman" <Erik.Guttman@sun.com> Language of service template: en Security Considerations: If the USER and GROUPS attributes are included a possibility exists that the list of identities for users or groups can be discovered. This information would otherwise be difficult to discover.
提交人姓名：“Erik Guttman”<Erik。Guttman@sun.com>服务语言模板：en安全注意事项：如果包含用户和组属性，则可能会发现用户或组的身份列表。否则很难发现这些信息。
Template Text:
-------------------------template begins here-----------------------
template-type=FOO
Template Text:
-------------------------template begins here-----------------------
template-type=FOO
template-version=0.0
模板版本=0.0
template-description= The FOO service URL provides the location of an FOO service.
template description=FOO服务URL提供FOO服务的位置。
template-url-syntax= url-path= ; There is no URL path defined for a FOO URL.
模板url语法=url路径=；没有为FOO URL定义URL路径。
users= string M L O # The list of all users which the FOO server supports.
users=string M L O#FOO服务器支持的所有用户的列表。
groups= string M L O
# The list of all groups which the FOO server supports.
--------------------------template ends here------------------------
groups= string M L O
# The list of all groups which the FOO server supports.
--------------------------template ends here------------------------
This template could be internationalized by registering another version, say in German:
该模板可以通过注册另一个版本（如德语版）进行国际化：
Name of submitter: "Erik Guttman" <Erik.Guttman@sun.com> Language of service template: de Security Considerations: Wenn die USER und GROUPS Eigenschaften inbegriffen sind, besteht die Moeglichkeit, dass die Liste der Identitaeten von Benutzern oder Gruppen endeckt werden kann. Diese Information wurde unter anderen Umstaenden schwierig zu entdecken sein.
提交人姓名：“Erik Guttman”<Erik。Guttman@sun.com>服务模板语言：反安全注意事项：用户和组的特征值在EGRIFFEN sind、besteht die Moeglichkeit、dass die Liste der IDENTITATETEN von Benutzern oder Gruppen endeckt werden kann中。他们的信息来源于他们的生活。
Template Text:
-------------------------template begins here-----------------------
template-type=FOO
Template Text:
-------------------------template begins here-----------------------
template-type=FOO
template-version=0.0
模板版本=0.0
template-description= Der FOO Service URL zeigt die Stelle von einem Foo Service an.
模板描述=Der FOO服务URL zeigt die Stelle von einem FOO服务。
template-url-syntax= url-path= ; Es gibt keinen fuer den FOO URL definierten Pfad.
模板url语法=url路径=；这是一个很好的URL定义程序。
users= string M L O # Die Liste aller Users, die der FOO Server unterstuetzt.
users=字符串M L O#Die Liste aller users，Die der FOO Server unterstuetzt。
groups= string M L O
# Die Liste aller Gruppen, die der FOO Server unterstuetzt.
--------------------------template ends here------------------------
groups= string M L O
# Die Liste aller Gruppen, die der FOO Server unterstuetzt.
--------------------------template ends here------------------------
Note that the attribute tags are not translated. If translations are desired, the suggested convention for doing so is to define a separate attribute called localize-<tag> for each attribute tag which is to be localized. This will aid in displaying the attribute tags in a human interface.
请注意，属性标记不会被转换。如果需要翻译，建议的惯例是为每个要本地化的属性标记定义一个称为本地化-<tag>的单独属性。这将有助于在人机界面中显示属性标记。
For example, in this case above, the following two attributes could be defined:
例如，在上述情况下，可以定义以下两个属性：
localize-users= string Benutzer
本地化用户=字符串Benutzer
localize-groups= string
本地化组=字符串
Gruppen
格鲁本
The attributes (in SLPv2 attribute list format) for a service registration of a FOO service based on this template, in German, could be:
基于此模板（德语）的FOO服务注册的属性（SLPv2属性列表格式）可以是：
(users=Hans,Fritz),(groups=Verwaltung,Finanzbuchhaltung),
(template-type=FOO),(template-version=0.0),(template-description=
Der FOO Service URL zeigt die Stelle von einem Foo Service an.),
(template-url-syntax= \OD url-path= ; Es gibt kein fuer den FOO
URL definiert Pfad. \OD),(localize-users=Benutzer),
(localize-groups=Gruppen)
(users=Hans,Fritz),(groups=Verwaltung,Finanzbuchhaltung),
(template-type=FOO),(template-version=0.0),(template-description=
Der FOO Service URL zeigt die Stelle von einem Foo Service an.),
(template-url-syntax= \OD url-path= ; Es gibt kein fuer den FOO
URL definiert Pfad. \OD),(localize-users=Benutzer),
(localize-groups=Gruppen)
Anyone obtaining these attributes could display "Benutzer=Hans,Fritz" in a human interface using the included information. Note that the template attributes have been included in this registration. This is OPTIONAL, but makes it possible to discover which template was used to register the service.
任何获得这些属性的人都可以使用包含的信息在人机界面中显示“Benutzer=Hans，Fritz”。请注意，模板属性已包含在此注册中。这是可选的，但可以发现用于注册服务的模板。
An example submission of an abstract service type template is:
抽象服务类型模板的提交示例如下：
Name of submitter: "Erik Guttman" <Erik.Guttman@sun.com> Language of service template: en Security Considerations: See the security considerations of the concrete service types.
提交人姓名：“Erik Guttman”<Erik。Guttman@sun.com>服务模板语言：en安全注意事项：请参阅具体服务类型的安全注意事项。
Template Text:
-------------------------template begins here-----------------------
template-type=Net-Transducer
Template Text:
-------------------------template begins here-----------------------
template-type=Net-Transducer
template-version=0.0
模板版本=0.0
template-description= This is an abstract service type. The purpose of the Net-Transducer service type is to organize into a single category all network enabled Transducers which have certain properties.
template description=这是一种抽象服务类型。网络传感器服务类型的目的是将具有特定属性的所有网络启用传感器组织为一个类别。
template-url-syntax= url-path= ; Depends on the concrete service type. ; See these templates.
模板url语法=url路径=；取决于具体的服务类型；查看这些模板。
sample-units= string L # The units of sample that the Transducer provides, for instance # C (degrees Celsius), V (Volts), kg (Kilograms), etc.
样本单位=字符串L#传感器提供的样本单位，例如#C（摄氏度）、V（伏特）、kg（千克）等。
sample-resolution= string L
样本分辨率=字符串L
# The resolution of the Transducer. For instance, 10^-3 means # that the Transducer has resolution to 0.001 unit.
#传感器的分辨率。例如，10^-3表示传感器的分辨率为0.001单位。
sample-rate= integer L # The speed at which samples are obtained per second. For # instance 1000 means that one sample is obtained every millisecond.
采样率=整数L#每秒获取采样的速度。例如，1000意味着每毫秒获得一个样本。
--------------------------template ends here------------------------
--------------------------template ends here------------------------
This is another service template submission example, supplying a concrete service type corresponding to the abstract template above.
这是另一个服务模板提交示例，提供了与上述抽象模板对应的具体服务类型。
Name of submitter: "Erik Guttman" <Erik.Guttman@sun.com> Language of service template: en Security Considerations: There is no authentication of the Transducer output. Thus, the Thermometer output could easily be spoofed.
提交人姓名：“Erik Guttman”<Erik。Guttman@sun.com>服务模板语言：en安全注意事项：传感器输出无认证。因此，温度计输出很容易被欺骗。
Template Text:
-------------------------template begins here-----------------------
template-type=service:Net-Transducer:Thermometer
Template Text:
-------------------------template begins here-----------------------
template-type=service:Net-Transducer:Thermometer
template-version=0.0
模板版本=0.0
template-description= The Thermometer is a Net-Transducer capable of reading temperature. The data is read by opening a TCP connection to one of the ports in the service URL and reading an ASCII string until an NULL character is encountered. The client may continue reading data at no faster than the sample-rate, or close the connection.
模板说明=温度计是一个能够读取温度的净传感器。通过打开到服务URL中的一个端口的TCP连接并读取ASCII字符串直到遇到空字符来读取数据。客户端可以不超过采样速率继续读取数据，或者关闭连接。
template-url-syntax= url-path = "ports=" ports-list port-list = port / port "," ports port = 1*DIGIT ; See the Service URL <port> production rule. ; These are the ports connections can be made on.
模板url语法=url path=“ports=”端口列表端口列表=端口/端口”，“端口=1*位；请参阅服务URL<port>生产规则；这些是可以在上进行连接的端口。
location-description=string # The location where the Thermometer is located.
位置描述=字符串#温度计的位置。
operator=string O # The operator to contact to have the Thermometer serviced.
操作员=字符串O#联系操作员维修温度计。
--------------------------template ends here------------------------
--------------------------template ends here------------------------
A user with an FOO enabled calendar application should not be bothered with knowing the address of their FOO server. The calendar client program can use SLP to obtain the FOO service: URL automatically, say 'service:foo://server1.nosuch.org', by issuing a Service Request. In the event that this FOO server failed, the Calendar client can issue the same service request again to find the backup FOO server, say 'service:foo://server2.nosuch.org'. In both cases, the service: URL conforms to the FOO service template as do the associated attributes (user and group.)
具有启用FOO的日历应用程序的用户不应该为知道其FOO服务器的地址而烦恼。日历客户端程序可以使用SLP自动获取FOO服务：URL，例如“服务：foo://server1.nosuch.org，通过发出服务请求。如果此FOO服务器出现故障，日历客户端可以再次发出相同的服务请求以查找备份FOO服务器，例如“服务：foo://server2.nosuch.org'. 在这两种情况下，service:URL和相关属性（用户和组）都符合FOO服务模板
A network thermometer based on the above template could be advertised with the SLPv2 attribute list:
基于上述模板的网络温度计可通过SLPv2属性列表发布：
URL = service:net-transducer:thermometer://v33.test/ports=3211
Attributes = (location-description=Missile bay 32),
(operator=Joe Agent), (sample-units=C),
(sample-resolution=10^-1),(sample-rate=10),
(template-type=service:net-transducer:thermometer),
(template-version=0.0),(template-description=
The Thermometer is a Net-Transducer capable of reading temperature.
The data is read by opening a TCP connection to one of the ports
in the service URL and reading an ASCII string until an NULL
character is encountered. The client may continue reading data at
no faster than the sample-rate, or close the connection.),
(template-url-syntax= \0D "ports=" port-list \OD
port-list = port / port "," ports \OD
port = 1*DIGIT \OD
; See the Service URL <port> production rule. \OD
; These are the ports connections can be made on.\OD)
URL = service:net-transducer:thermometer://v33.test/ports=3211
Attributes = (location-description=Missile bay 32),
(operator=Joe Agent), (sample-units=C),
(sample-resolution=10^-1),(sample-rate=10),
(template-type=service:net-transducer:thermometer),
(template-version=0.0),(template-description=
The Thermometer is a Net-Transducer capable of reading temperature.
The data is read by opening a TCP connection to one of the ports
in the service URL and reading an ASCII string until an NULL
character is encountered. The client may continue reading data at
no faster than the sample-rate, or close the connection.),
(template-url-syntax= \0D "ports=" port-list \OD
port-list = port / port "," ports \OD
port = 1*DIGIT \OD
; See the Service URL <port> production rule. \OD
; These are the ports connections can be made on.\OD)
This might be very useful for a technician who wanted to find a Thermometers in Missile bay 32, for example.
例如，对于想在导弹舱32中找到温度计的技术人员来说，这可能非常有用。
Note that the template attributes are advertised. The template-url-syntax value requires explicit escaped CR characters so that the ABNF syntax is correct.
请注意，模板属性是公开的。模板url语法值需要显式转义CR字符，以便ABNF语法正确。
B. Acknowledgments
B.致谢
Thanks to Michael Day and Leland Wallace for assisting with the IPX and AppleTalk address syntax portions. Ryan Moats provided valuable feedback throughout the writing of this document.
感谢Michael Day和Leland Wallace对IPX和AppleTalk地址语法部分的帮助。Ryan Moats在本文件的整个编写过程中提供了宝贵的反馈。
C. References
C.参考资料
[1] Protocol and service names, October 1994. ftp://ftp.isi.edu/in-notes/iana/assignments/service-names.
[1] 协议和服务名称，1994年10月。ftp://ftp.isi.edu/in-notes/iana/assignments/service-names.
[2] Port numbers, July 1997. ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers.
[2] 港口编号，1997年7月。ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers.
[3] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995.
[3] Alvestrand，H.，“语言识别标签”，RFC1766，1995年3月。
[4] ANSI. Coded Character Set -- 7-bit American Standard code for Information Interchange. X3.4-1986, 1986.
[4] ANSI。编码字符集——信息交换用7位美国标准代码。X3.4-1986，1986年。
[5] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[5] Berners Lee，T.，Fielding，R.和L.Masinter，“统一资源标识符（URI）：通用语法”，RFC 2396，1998年8月。
[6] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[6] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[7] Apple Computer. Inside Macintosh. Addison-Wesley, 1993.
[7] 苹果电脑。麦金塔内部。艾迪生·韦斯利，1993年。
[8] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[8] Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[9] S. Gursharan, R. Andrews, and A. Oppenheimer. Inside AppleTalk. Addison-Wesley, 1990.
[9] S.Gursharan、R.Andrews和A.Oppenheimer。在AppleTalk内部。艾迪生·韦斯利，1990年。
[10] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol Version 2", RFC 2608, June 1999.
[10] Guttman，E.，Perkins，C.，Veizades，J.和M.Day，“服务位置协议版本2”，RFC 26081999年6月。
[11] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[11] 迈尔斯，J.，“简单认证和安全层（SASL）”，RFC2222，1997年10月。
[12] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs, BCP 26, RFC 2434, October 1998
[12] Narten，T.和H.Alvestrand，“在RFCs中编写IANA考虑事项部分的指南，BCP 26，RFC 2434，1998年10月
[13] Newman C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[13] Newman C.和J.Myers，“ACAP——应用程序配置访问协议”，RFC 2244，1997年11月。
[14] Inc Novell. IPX RIP and SAP Router Specification. Part Number 107-000029-001, Version 1.30, May 1996.
[14] 诺维尔公司。IPX RIP和SAP路由器规范。零件号107-000029-001，版本1.30，1996年5月。
[15] Veizades, J., Guttman, E., Perkins, C. and S. Kaplan, "Service Location Protocol", RFC 2165, July 1997.
[15] Veizades，J.，Guttman，E.，Perkins，C.和S.Kaplan，“服务位置协议”，RFC 21651997年7月。
[16] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[16] “UTF-8，ISO 10646的转换格式”，RFC 2279，1998年1月。
D. Authors' Addresses
D.作者地址
Questions about this memo can be directed to:
有关本备忘录的问题，请联系：
Erik Guttman Sun Microsystems Bahnstr. 2 74915 Waibstadt Germany
埃里克·古特曼太阳微系统公司。274915德国威伯斯塔特
Phone: +49 7263 911484
Fax: +1 650 786 5992
EMail: erik.guttman@sun.com
Phone: +49 7263 911484
Fax: +1 650 786 5992
EMail: erik.guttman@sun.com
Charles E. Perkins Sun Microsystems 15 Network Circle Menlo Park, CA 94303 USA
Charles E.Perkins Sun Microsystems 15 Network Circle Menlo Park，加利福尼亚州，美国94303
Phone: +1 650 786 6464
Fas: +1 650 786 6445
EMail: cperkins@sun.com
Phone: +1 650 786 6464
Fas: +1 650 786 6445
EMail: cperkins@sun.com
James Kempf Sun Microsystems 15 Network Circle Menlo Park, CA 94303 USA
James Kempf Sun Microsystems 15 Network Circle Menlo Park，加利福尼亚州，美国94303
Phone: +1 650 786 5890
Fax: +1 650 786 6445
EMail: james.kempf@sun.com
Phone: +1 650 786 5890
Fax: +1 650 786 6445
EMail: james.kempf@sun.com
E. Full Copyright Statement
E.完整的版权声明
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编辑功能的资金目前由互联网协会提供。