[要約] RFC 2609は、サービステンプレートとサービススキームに関する情報を提供するものであり、インターネットサービスの設計と実装を支援することを目的としています。
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.
Copyright（c）The Internet Society（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には、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
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.
クライアントは属性を使用して特定のサービスを選択します。サービスの選択は、クライアントに適切な構成を提供するサービス：URLを取得することにより発生します。サービスタイプテンプレートサービスの構文：特定のサービスタイプのURL、およびサービスに伴う属性：サービス登録の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.
2つの異なる言語の特定のサービスタイプのテンプレートにアクセスできるエンティティは、2つの言語間で翻訳される場合があります。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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.
名前が文字列「service：」で始まり、このドキュメントのルールに従って構築されたサービスタイプ名が続きます。
service: URL
サービス：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.
さまざまな異なるプロトコルに関連付けられているサービスタイプ名。セクションAに例を示します。セクション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.
サービスロケーションプロトコルバージョン2 [10]では、サービス：URLを登録および検出できますが、サービス：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。特定のタイプのすべてのサービス登録の属性も取得できます。
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で使用するために変換する必要があります。不透明な値でバイトごとに「\ ff」then "\" hexdig hexdigのシーケンスの代わりに、SLPV1はRADIX-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. Escape文字は、SLPV1とSLPV2で大幅に異なります。Escaped文字に逃げたバイト表記を使用する代わりに、SLPV1はHTMLコンベンション `＆ '`＃' 1*digit `; 'を使用します。
This section describes the syntax and semantics of service: URLs.
このセクションでは、サービスの構文とセマンティクス：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.
サービスの構文：URLは[5]で定義されている「絶対URI」に適合する必要があります。サービスの構文：URLは、「ジェネリックURI」とは十分に異なり、サービスの特定のパーサーが利用可能でない限り、不透明なURIとして扱うことが最善です。
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-PART」まで同じ構文があり、サービスの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:
サービスのABNF：URLは次のとおりです。
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
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ネットワーク番号は、ネットワークの順序で4バイトの番号であり、16進数で表され、IPXサブネットを意味します。ノード要素は、ネットワークインターフェイスカードを表します。これは、16進数で表される6バイトの数字で、通常はインターフェイスカードのノードIDと同じです。ソケット要素は、IPXネットワークとノードを考慮して、特定のサービスアクセスポイントを表します。IPXソケットはTCP/IPポートに類似しており、バークレーソケットと混同しないでください。
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文法以外に、使用前に一部のキャラクターを逃れる必要があります。任意のキャラクターを逃れるために、2桁の先行して、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スキーム識別子に続くサービススキーム固有の情報」は、サービスにアクセスするために必要な情報を提供します。前のサブセクションで説明されているように、サービスの形式：URLは次のとおりです。
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>には、次のフォームのいずれかが<ipsite>、<ipxsite>、または<atsite>を参照できます。サービスURLがそれぞれIP、IPX、またはAppleTalk Serviceアクセスポイントに位置する場合。
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>フィールドを使用すると、<Site>がその目的のために十分でない場合にサービスまたはリソースを一意に見つけることができる、より多くの情報を（<url-path>および<attr-list>を使用して）提供できます。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
attr-id "=" attr-value
or for keyword attributes:
またはキーワード属性の場合：
attr-id
attr-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:
属性はサービスの一部です。属性が特定のサービスにアクセスするために必要な場合。たとえば、ACAP [13]サービスでは、クライアントがKerberosを介してそれを認証する必要がある場合があります。サービス登録に属性を含めることで、ACAPクライアントは正しいSASL [11]認証メカニズムを使用することができます。ACAPサーバーの登録は次のようになります。
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.
サービスに関連付けられた属性：URLは通常、サービスに含まれていません：URL。それらは他のメカニズムを使用して保存および取得されます。サービス：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を取得し、それらの属性によってそれらの中で最も好ましいものを区別できます。クライアントはサービスを使用して、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で説明されている正式なサービステンプレート構文で指定されます。サービス：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は、サービスの属性に従って、サービスのメカニズムを動的に取得するためのメカニズムを提供します。
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ドキュメントには、サービスへのポインターとしてのサービスを含む場合があります。これは、サービスが何をし、誰がそれを使用することを許可されているかをテキストで説明します。
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」サービスタイプは、次の形式のURLを使用して定義できます。
service:printer:lpr://<address of printer>/<queue name>
The section of the URL after the address of the printer:
プリンターのアドレス後のURLのセクション：
"/" <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サービスタイプに固有であり、一般サービスの<url-path>フィールドに対応しています：url構文。このパートは、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.
サービスを登録するために：抽象サービスタイプのURLは、セクション3.1で説明されている「抽象型」文法ルールを使用します。これにより、サービスを使用するのに十分な情報、つまりプロトコル、アドレス、パス情報が含まれる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.
たとえば、サービスタイプの「要約」の抽象サービステンプレートが属性FOOを定義する場合、「抽象：コンクリート」などの抽象サービステンプレートから派生したすべての具体的なサービステンプレートには、属性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:
たとえば、デバイスドライバーを動的にロードするためのネットワークサービスが開発されているとします。クライアントは、ドライバーを正常にロードしてインスタンス化する前に、次の3つの情報を必要とします。
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,
誘惑は、最初の2つのアイテムをURLに形成し、それをサービスに埋め込むことです：URL。避けるべき例として、
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」ではありません。むしろ、それは「デバイスドライバー」です。サービス：使用する必要があるURLは、セクション[6]のルールと一致して、次のとおりです。
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: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を使用して、サービスタイプの「デバイスドライバー」の検索では、上記の3つの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が含まれます。上記の例には、さらに3つの要件があります。ダウンロードするドキュメントを示すアクセスプロトコルにはURLパスが含まれており、ドライバーを特徴付けるために2つの属性が含まれています。
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.
テンプレートドキュメントは、5つのドキュメント識別項目に値を割り当てるテキストブロックから始まります。5つの識別項目はブロック内の任意の順序で表示できますが、従来はサービスタイプ名を割り当てる「テンプレートタイプ」アイテムがドキュメントの最上部で発生し、文書の残りの部分にコンテキストを提供します。属性定義項目は、ドキュメント識別項目の後に発生します。
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アクセントAigeは「\ 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.
値リストの値はコンマで区切られています。値リストは、コンマが先行しない新しいラインによって終了します。Newlineの前にコンマの前にある場合、値リストは次の行に続くと解釈されます。
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].
; 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.
サービスタイプテンプレートは、特定のサービスタイプのサービス属性とサービス：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-syntax」はすべて属性として定義されていることに注意してください。これらの属性は、SLPV2を使用してサービス登録を伴う場合があります。
There are four items included in the service template. The semantics of each item is summarized below.
サービステンプレートには4つのアイテムが含まれています。各アイテムのセマンティクスを以下に要約します。
- 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
- Template-url-syntax
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回開始されます。標準化されたテンプレートは1.0から始まります。オプションの属性を追加すると、マイナー数に1つ追加され、必要な属性の追加、定義の変更、または属性の削除が主要な数字に追加されます。目的は、古いサービステンプレートが不完全である場合、テンプレートがマイナーバージョンの登録とのみ異なる場合、サービス登録の属性を定義することです。テンプレートバージョン属性の使用方法の詳細については、セクション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-Syntax」アイテムの値として提供されます。サービスの<URL-PATH>フィールド：URLは、<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スキームがすでに標準化されており、サービスではない場合を除き、新しいサービスタイプの定義に付随する必要があります。構文は、[5]で説明されているURL構文のルールに従って、ABNF [8]としてテンプレートドキュメントに含まれています。<url-path>をサポートするサービススキームの要件はありません。<url-path>フィールドは非常にシンプルであるか、省略することもできます。URLスキームが既に標準化されている場合、「テンプレート-RURL-SYNTAX」項目には、適切な標準化ドキュメントへの参照を含める必要があります。抽象サービスタイプは、具体的なインスタンスを説明するテンプレートドキュメントにこのフィールドを延期する場合があります。
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):
属性定義は、属性の識別子の仕様から始まり、単一の空の行で終わります。属性定義には5つのコンポーネントがあります（定義の外観の順に）：
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).
属性は、文字列、整数、ブール、不透明、またはキーワードの5つの異なるタイプのいずれかを持つことができます。属性のタイプ仕様は、等号（ "="）によって属性の識別子から分離され、同じ行の等記号に従います。文字列、署名された整数、ブール型には、標準のプログラミング言語またはデータベースセマンティクスがあります。整数は、32ビットで表すことができる署名された値に制限されています。文字列を表すために使用される文字セットは、テンプレートが定義されている時点では指定されていませんが、サービス登録によって決定されます。ブール人には標準的な構文があります。オパークは、他の種類のデータを表すために使用できるバイトエスケープ値です。キーワードは、存在以外の特性（および定義の記述テキスト）以外の特性を持たない属性です。
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.
フラグは、属性の他の特性を決定します。フラグがない可能性のあるキーワード属性を除き、フラグは属性識別子と同じ行の属性タイプに従い、Whitespaceによって互いに分離されます。フラグは、属性タイプの後に任意の順序で表示される場合があります。他の情報はフラグに従ってはならず、属性定義ごとに特定のフラグタイプの1つのフラグ識別子のみが許可されます。
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
- lまたは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行目で開始され、ラインがコンマなしで終了するまで次の行で継続します。結果として、ニューラインを逃げない限り、値に埋め込むことはできません。セクション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回増加します。サービステンプレートのバージョンは、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 supports 1.x can still use later versions of 1.y (where x<y) as it ignores attributes it doesn't know about.
- テンプレートに対して定義された新しいオプションの属性は、マイナーバージョン数を1つ増やします。バージョンの他のすべての属性は、以前のように引き続きサポートされている必要があります。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 WGがサービステンプレートについて議論する目的で休眠状態になった場合でも維持されます。
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------------------------
The service template file has a naming convention:
サービステンプレートファイルには命名規則があります。
<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"、 "net-transducer.0.0.en"、 "net-transducer：termomer.0.0.de"および "net-transducer：thermomoter.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].
サービス：[5]に記載されているルールを使用して、URLをエンコードする必要があります。キャラクターセットエンコーディングは、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.
プログラムは、登録用の言語のテンプレートと目的のターゲット言語のテンプレートの両方を備えている場合、ある言語から別の言語にサービス登録を翻訳できます。すべての標準化された属性は、両方のテンプレートで同じ順序であります。説明的なヘルプテキストを含むすべての非arbitrary意的な文字列は、ある言語から別の言語に直接翻訳可能です。非文字属性定義、属性識別子、属性タイプ名、属性フラグ、およびブール定数「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.
翻訳を進めるには、標準化と最善の努力という2つの方法があります。
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.
サービスタイプが標準化されている場合、レビューのために複数のドキュメントを提出できます。1つのサービスタイプの説明はマスターとして承認されているため、サービスタイプテンプレートが1つの言語で更新されると、すべての翻訳が（最終的には）同じセマンティクスを反映します。
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を配布し、通常使用する以外のサービスの場所を示すことができます。Service Location Protocol [10]はサービス：URLSを分散し、サービス：登録サービスの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-Transducerの例は、抽象的なサービスタイプの定義方法と、対応するコンクリートインスタンスの定義方法を示しています。システムは、いくつかのNetTransducerサービスのいずれかをサポートする場合があります。ここでは、抽象型の具体的なインスタンスは1つだけです。
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-version=0.0
テンプレートversion = 0.0
template-description= The FOO service URL provides the location of an FOO service.
Template-description = Foo Service URLは、FOOサービスの場所を提供します。
template-url-syntax= url-path= ; There is no URL path defined for a FOO URL.
Template-url-syntax = url-path =;FOO URLに対して定義されたURLパスはありません。
users= string M L O # The list of all users which the FOO server supports.
ユーザー=文字列M l o＃FOOサーバーがサポートするすべてのユーザーのリスト。
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>サービステンプレートの言語：DEセキュリティに関する考慮事項：Wenn Die die uss uns undグループeigenschaften inbegriffen sind、besteht die moeglichkeit、dass die liste liste der der identaeten von benutzern gruppen endecktwerdenカン。情報Wurde Unter Anderen Umstaenden Schwierig Zu Entdecken Sein。
Template Text:
-------------------------template begins here-----------------------
template-type=FOO
template-version=0.0
テンプレートversion = 0.0
template-description= Der FOO Service URL zeigt die Stelle von einem Foo Service an.
Template-description = der foo service url zeigt die stelle von einem foo service an。
template-url-syntax= url-path= ; Es gibt keinen fuer den FOO URL definierten Pfad.
Template-url-syntax = url-path =;es gibt keinen fuer den foo url definierten pfad。
users= string M L O # Die Liste aller Users, die der FOO Server unterstuetzt.
users = string m l o＃die liste allerユーザー、die der foo server unterstuetzt。
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.
属性タグは翻訳されていないことに注意してください。翻訳が必要な場合、そうするための提案された条約は、ローカライズされる各属性タグのlocialize- <ag>と呼ばれる個別の属性を定義することです。これにより、人間のインターフェイスに属性タグを表示するのに役立ちます。
For example, in this case above, the following two attributes could be defined:
たとえば、上記のこの場合、次の2つの属性を定義できます。
localize-users= string Benutzer
locialize-users = string benutzer
localize-groups= string Gruppen
locialize-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)
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-version=0.0
テンプレートversion = 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.
Template-url-syntax = url-path =;コンクリートサービスの種類に依存します。;これらのテンプレートを参照してください。
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の場合、1つのサンプルがミリ秒ごとに取得されることを意味します。
--------------------------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-version=0.0
テンプレート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-description =温度計は、温度を読むことができるネットトランスドゥーサーです。データは、サービスURL内のポートの1つにTCP接続を開き、null文字が発生するまで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.
Template-url-syntax = url-path = "ports =" ports-list port-list = port / port "、" ports port = 1*digit;Service URL <port>生産ルールを参照してください。;これらは、オンにできるポートです。
location-description=string # The location where the Thermometer is located.
場所description =文字列＃温度計がある場所。
operator=string O # The operator to contact to have the Thermometer serviced.
オペレーター=文字列o＃オペレーターは、温度計を使用するために連絡します。
--------------------------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サーバーが失敗した場合、カレンダークライアントは同じサービス要求を再度発行して、「サービス：//server2.nosuch.org」と言います。どちらの場合も、サービス：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)
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.
テンプレート属性が宣伝されていることに注意してください。Template-url-syntax値には、ABNF構文が正しいように、明示的な脱出CR文字が必要です。
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.
IPXおよびAppleTalkアドレスの構文部分を支援してくれたMichael DayとLeland Wallaceに感謝します。ライアン・モートは、この文書の執筆を通して貴重なフィードバックを提供しました。
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。、「言語の識別のためのタグ」、RFC 1766、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。and L. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、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] Appleコンピューター。Macintoshの中。Addison-Wesley、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。Addison-Wesley、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。and M. Day、「Service Location Protocolバージョン2」、RFC 2608、1999年6月。
[11] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[11] Myers、J。、「Simple Authentication and Security Layer（SASL）」、RFC 2222、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、BCP 26、RFC 2434、1998年10月にIANA考慮事項セクションを作成するためのガイドライン
[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] Inc Novell。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。and S. Kaplan、「Service Location Protocol」、RFC 2165、1997年7月。
[16] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[16] Yergeau、F。、「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
Erik Guttman Sun Microsystems Bahnstr。2 74915 Waibstadtドイツ
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、CA 94303 USA
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、CA 94303 USA
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.
Copyright（c）The Internet Society（1999）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性またはフィットネスの権利または黙示的な保証を侵害します。」
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。