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を、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.
正式な表記法を使用して、ネットワークサービスのためのネットワーク・アクセス情報を定義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:
テンプレートは以下の明確な目的のために使用されています。
The template is reviewed before it is standardized. Once it is standardized, all versions of the template are archived by IANA.
それが標準化される前に、テンプレートが見直されています。それが標準化されたら、テンプレートのすべてのバージョンは、IANAによってアーカイブされます。
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]を利用したサーバーは、自分自身とその属性を登録します。彼らは、サービス登録を生成するためのテンプレートを使用しています。登録するには、サービスは、その属性に指定された値を使用する必要があります。
Client applications may display service information. The template provides type information and explanatory text which may be helpful in producing user interfaces.
クライアントアプリケーションは、サービスの情報を表示することができます。テンプレートは、ユーザインタフェースを生成するのに有用であり得る情報と説明テキストを入力し提供します。
Entities with access to the template for a given service type in two different languages may translate between the two languages.
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.
すべての文法エンコーディング[8]構文仕様のための増大しているBNF（ABNF）に従います。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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: 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.
URLはまた、他のコンテキストで使用することができる：サービスものの、URLを登録して発見される：サービスロケーションプロトコルバージョン2 [10]は、サービスができます。
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ので使用するために変換する必要があります。代わりに、その後は「\ FF」の配列の「\」HEXDIG HEXDIGは、不透明な値の各バイトに対して、SLPv1のは基数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のは `＆ '`＃' 1 * DIGIT `HTMLの規則を使用しています;」。
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.
サービスの構文：[5]で定義されるようなURLは、「絶対URI」に従わなければなりません。サービスの構文：URLが提供されています：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-部分」に同じ構文を持つサービス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>フィールドには、サービスアクセスポイントで、サービスにアクセスする方法について説明します。加えて、両方の大文字と小文字の文字は、便宜上、<サービスタイプ>分野で認識されているが、名前は大文字折り畳ま下ケースにあります。サービスの種類は、例えば、したがって、例に基づいて区別されないので、「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
サービス：URL = "サービス：" サービス型 "：" SAPサービス型=抽象型 "：" "" URL-スキーム/コンクリート型抽象型=タイプ名[ 】コンクリート型=プロトコル[-AUTH命名 ""命名-AUTH]型名= resnameは命名-AUTH = resnameは、URLスキーム= resnameは、認識されたURLのスキーム名、標準化されました。一般的な慣行によるかのいずれかを介して、標準化団体の承認。 resnameは= ALPHA [1 *（ALPHA / DIGIT / "+" / " - "）]樹液=サイト[URL-一部]サイト= ipsite / atsite / ipxsite ipsite = "//" [[ユーザー "@"]ホスト側] HostPort =ホスト[ "：" ポート]ホスト=ホスト名/ hostnumberホスト名= *（ "" domainlabel）toplabel alphanum = ALPHA / DIGIT domainlabel = alphanum / alphanum * [alphanum / " - "] alphanum toplabel = ALPHA / ALPHA * [ alphanum / " - "] alphanum hostnumber = IPv4の番号のIPv4-数= 1 * 3DIGIT 3（1 * 3DIGIT ""）ポート= 1 * DIGIT。場合は、ポート番号が含まれている必要があります。プロトコルフィールドは、IANAはありません。割り当てられたポート番号。ユーザー= * [UCHAR / ";" / "+" / "＆" / "="] ipxsite = "/ IPX /" IPXネット：IPXノード "" "：" IPXソケットのIPXネット= 8 HEXDIGITのIPXノード= 12 HEXDIGITのIPXソケット= 4 HEXDIGIT atsite = "/ AT /" は、オブジェクト "：" で型 "" でゾーンにおける物体= 1 * 31apple-チャーで型= 1 * 31apple-チャーでゾーン= 1 * 31apple- char型のリンゴ-CHAR = ALPHA / DIGIT /安全/エスケープ=; AppleAscii [7]ない値=。制限された範囲から脱出しなければなりません。 =;注：エスケープ値は対応していません=。ここではUTF-8の値に：彼らはAppleAscii =です。バイト。 URLの一部= [URLパス] [ATTRリスト] URLパス= 1 *（ "/" * XCHAR）。各サービスの種類は、そのを定義する必要があります。独自の構文一貫。 [5]を有します。 ATTR-リスト= 1 *（ ";" のattr-ASGN）ATTR-ASGN = ATTR-ID / ATTR-ID "=" attrの値に安全= "$" / " - " / "_" / "" / "〜" 余分= "！" / "*" / " '" / "（" / "）" / "" / "+" UCHAR =予約されていない/エスケープXCHAR =未予約/予約/エスケープエスケープ= 1 *（ `\' HEXDIG HEXDIG）予約=" ;」 / "/" / "？" / "：" / "@" / "＆" / "=" / "+" 予約されていない= ALPHA / DIGIT /安全/エクストラ
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サブネットを意味する4バイトのネットワークのために数、16進数で表現されます。ノード要素は、ネットワーク・インターフェース・カードを表しています。それは、通常、インターフェースカードのノードIDと同じであり、進数で表現さ、6バイトの番号です。ソケット要素は、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の文法以外のケースでは、一部の文字は使用前にエスケープする必要があります。任意の文字をエスケープするには、「％」でそのASCII値を示す2桁の数字の前に。
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
サービス：URL =「サービス：」サービス型「：」サイトのURLパス
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.
ここで、<サイト>は、サービス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節で述べたように、<サービスタイプ>は、具体的なプロトコル名、または抽象型名のいずれかであることができます。
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またはサービス属性の他の情報は、サービスを利用するのに十分である場合は、<サイト>フィールドはnullにすることができます。
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パス>と<ATTRリスト>）サービスを一意に検索または<サイト>は、その目的のために十分でない場合、リソースができます。 IPアドレスの場合、<サイト>フィールドには、「//」で始まります。サポートされている他のアドレスファミリは、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パート>フィールドの最後に表示されますが、任意のサービスの位置登録に存在することが必要とされることはありません。
The <attr-list> field is composed of a list of semicolon (";") separated attribute assignments of the form:
<ATTRリスト>フィールドは（「;」）セミコロンのリストで構成されているフォームの属性割り当てを分離：
attr-id "=" attr-value
ATTR-ID "=" ATTR値
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:
属性が特定のサービスにアクセスするために必要とされるときのURL：属性は、サービスの一部です。例えば、ACAP [13]サービスは、クライアントがKerberosを通じてそれを使用して認証が必要になることがあります。サービス登録で属性を含めることはACAPクライアントが正しいSASL [11]認証機構を利用することができます。 ACAPサーバの登録は、次のようになります。
service:acap://some.where.net;authentication=KERBEROSV4
サービス：ACAP：//some.where.net;認証= 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.
URLに含めることが適切でないACAPサーバの他の属性があることに注意してください。たとえば、サーバーへのアクセス権を持つユーザーのリストは、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は、サービスのためのメカニズムを提供します：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が表示されるコンテキストは、それを明確にする必要があります。ユーザーは、ブランチオフィスにあるとき例えば、メールメッセージで、サービスが使用することは推奨される可能性があります。サービスはありませんし、誰がそれを使用することが許可されているものをテキストで記述し、サービスへのポインタとして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>
サービス：プリンタ：LPR：// <プリンタのアドレス> / <キュー名>
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パス>フィールドに対応：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」を識別するパス名、
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への最初の2つの項目を形成し、サービスにそれを埋め込むことです。避けるべき例として、
service:ftp:/x3.bean.org/drivers/diskdrivers.drv;driver=scsi
サービス：FTP：/x3.bean.org/drivers/diskdrivers.drv;ドライバー= 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
サービス：デバイス・ドライバー：FTP：//x3.bean.org/drivers/diskdrivers.drv。ドライバ= SCSI;プラットフォーム= 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
サービス：デバイス・ドライバー：TFTP：//x2.bean.org/vol3/disk/drivers.drv。ドライバ= SCSI;プラットフォーム= sys3.2-RS3000
service:device-drivers:http://www.bean.org/drivers/drivpak.drv; driver=scsi;platform=sys3.2-rs3000
サービス：デバイス・ドライバーます。http：//www.bean.org/drivers/drivpak.drv。ドライバ= SCSI;プラットフォーム= 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:
サービスの種類の指定サービス登録への重要な特性を定義する正式な構文に文書です。これらのプロパティは以下のとおりです。
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の0x00-0x7Fのサブレンジで符号化されなければならない[16]（ASCII文字コードに対応する）と英語であること。
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アクセントのaigueは「\ 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:
文字列値が空白で互いに分離潜在的に埋め込まれた空白と非空白トークンのシーケンスであると考えられます。カンマは文字列のリストを区切ります。 1つの空白に文字列に空白の内部の任意のシーケンスを低減するように文字列値がトリミングされています。先行または後続の空白を除去します。例えば：
" 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].
テンプレート= TEM-ATTRSのATTR-DEFS TEM-ATTRS = schemetype schemevers schemetext schemeurl schemetype = "テンプレート型=" スキーム用語schemeversは= "テンプレートバージョン=" バージョンなし用語schemetext = "テンプレート記述=" 改行DESC項schemeurl = "テンプレートのurl-構文=" 改行のurl-BNF用語のurl-BNF = * [COM-chars]は; <URLパス>の生産を説明ABNF。サービス中：セクション2.1のURL文法。スキーム=サービスタイプ[「」命名-AUTH]サービスタイプ=スキーム名の命名-AUTH =スキーム名スキーム名= ALPHA [1 * schemechar] [ "" 1 * schemechar] schemechar = ALPHA / DIGIT / " - " / "+" /バージョン-NO = 1 * DIGIT "" 1 * DIGIT langtag = 1 * 8ALPHAの[ " - " 1 * 8ALPHA]。 [3] DESC = * [COM-chars]は参照してください。によって読み取るための自由形式のテキストのブロック。 、短期的にサービスを記述した人。有益な方法。用語=改行改行ATTR-DEFS = *（ATTR-DEF / keydef）ATTR-DEF = ID "=" attrtail keydef = ID "=" "キーワード" 改行[ヘルプテキスト]改行attrtail =タイプフラグ改行[値リスト] [ヘルプテキスト] [値リスト]改行ID = 1 * attrcharタイプ= "文字列" / "整数" / "ブーリアン" / "不透明" フラグ= [ "M" / "M"] [ "L" / "L"] [ "O" / "O"] [ "X" / "X"]の値リスト=値改行/値 "" 値リスト/値 "" 改行値リストヘルプテキスト= 1 *（ "＃" ヘルプライン）;によって読み取るための自由形式のテキストのブロック。属性を記述した人や、その値。ヘルプライン= * [COM-chars]は改行attrchar = schemechar / "：" / "_" / "$" / "〜" / "@" / "" / "|" / = [ "+" "<" / ">" / "*" / "＆" 値=文字列/整数/ブール/不透明ストリング=安全するchar * [セーフチャー/ホワイト-SP]安全チャー整数| " - "] 1 * DIGITブール= "真" / "偽" 不透明= "\ FF" 1 *（ "\" HEXDIG HEXDIG）。不透明な値の各バイトはヘクスが符号化されています。 ;フォーマットは、[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 )
;改行は、不透明な復号化する際に無視されます。値。 COM-文字=安全-CHAR /白-SP / "" / ";" / "％" 安全-CHAR = attrchar /エスケープ/ "" / ""！ / '"' / "'"/ "|"/ "（"/ "）"/ "+"/ " - "/ ""/ "："/ "="/ ""/ "["/"。？ ] "/ "{"/ "/"/ "{"/ "$";すべてのUTF-8印刷可能な文字がされています。除い含まれる"、 "、 "％"、 ";"、および "＃" は* = 1を免れました（ `\」HEXDIG HEXDIG）白色-SP = SPACE / HT改行= 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-構文」すべての属性として定義されていることに注意してください。これらの属性は、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
- テンプレートの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から始まります。オプションの属性の追加は、マイナー番号に1を追加し、必要な属性は、定義の変更、または属性の除去の追加は、メジャー番号に1を追加します。その意図は、テンプレートだけでそのマイナーバージョンの登録と異なる場合、古いサービステンプレートは、まだ正確に、もし不完全、サービス登録の属性を定義することです。テンプレート-version属性の使用方法の詳細については、セクション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-構文」項目の値として、テンプレート文書で提供されています。 <URLパス>サービスの分野：URLは、フィールドが十分でない場合、<addrのスペック>サービスを見つけるために、追加情報を提供するように設計されています。 <URLパス>フィールドには、別のサービスタイプのものの中から特定のサービスタイプのURLを区別します。例えば、LPRサービスタイプの場合には、<URLパス>は、それがキュー名を含める必要があるように定義することができるが、他のサービスの種類は、この情報を必要としない場合があります。
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：URLスキームはすでに標準化とサービスではありませんされていない限り、<URLパス>フィールドの構文は、新しいサービスタイプの定義を添付しなければなりません。 ABNF [8] [5]に記載のURLの構文のルールを以下のような構文は、テンプレート文書に含まれています。 <URL-path>をサポートするためのサービススキームのための要件はありません。 <URLパス>フィールドは、非常に単純な、あるいは省略することができます。 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):
属性定義は、属性の識別子の仕様で始まり、単一の空行で終了します。 （定義で出現順に）定義は5つのコンポーネントを持っている属性：
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ビットで表現することができ、それらの符号付きの値に制限されます。文字列を表すために使用される文字セットは、テンプレートが定義されている時に指定されるのではなく、サービス登録により決定されます。ブール値は、標準の構文を持っています。 Opaquesには、任意の他の種類のデータを表現するために使用することができ、バイトエスケープ値です。キーワードは、彼らの存在以外の特性（そしておそらくその定義で説明文を）持っていない属性です。
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.
フラグは、属性の他の特性を決定します。任意のフラグを持っていない可能性があり、キーワードの属性を除いて、フラグが属性識別子と同じ行の属性タイプに従い、空白によって互いに分離されています。フラグは、属性タイプの後に任意の順序で表示されることがあります。その他の情報は、フラグに従ってはならない、と特定のフラグタイプの唯一の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:
デフォルト値またはリストは、サービスが登録されているときは値が属性に割り当てられていない場合は、属性が指定された値が何を示しています。オプションの属性の定義にはデフォルト値またはリストが含まれていない場合は、以下のデフォルト値が割り当てられています。
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:
MINORリビジョン番号は互換性の変化の導入を意味します。メジャーリビジョン番号は互換性のない変更を導入することを意味します。これは、次の規則によって形式化されています。
- 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.
ボランティア団体によって提供されるメールサーバーへの「svrloc-list@iana.org」のポイントとなるようIANAは、このリストの仕事のためのメール転送の別名を維持します。
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>
<サービスタイプ>「」 <バージョンなし>「」 <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".
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.
もう1つの言語からサービス登録を変換することができるプログラムは、登録のための言語のテンプレートと所望の目標言語のテンプレートの両方を有しました。すべての標準化された属性は、両方のテンプレートで同じ順序です。わかりやすいヘルプテキストを含むすべての非任意の文字列は、一つの言語から別の直接翻訳可能です。非リテラル属性定義、属性識別子、属性型名、属性フラグ、およびブール定数「真」と「偽」は翻訳されることはありません。したがって、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は配布され、それが通常使用したい以外のサービスの位置を示すことができました。 URLとサービス可能な認証メカニズムがあります：サービスロケーションプロトコル[10]は、サービスを配信登録されたサービスの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.
ネットトランスデューサの例は、抽象サービスタイプが定義され、どのように対応する具体的なインスタンスを定義する方法を示しています。システムは、いくつかの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.
抽象サービスタイプテンプレートは完全にコンクリートの型として使用することができます可能性どの値に明らかなように、そしてどのような彼らの解釈があるの場合は、抽象サービスタイプの具体的なテンプレートを登録する必要はありません。
A.1. FOO
A.1。 FOO
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@sun.com>サービステンプレートの言語：セキュリティの考慮EN：USERおよびグループ属性が含まれている場合は可能性がユーザーまたはグループのIDのリストを発見することができますが存在します。この情報は、そうでない場合は発見することは困難であろう。
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.
テンプレート記述= 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.
ユーザー=文字列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@sun.com>言語：セキュリティの考慮EN：ユーザーグループとプロパティが含まれている場合は、ユーザーまたはグループのIDのリストということにする可能性があるendecktことができます。この情報は、他の環境の中で、発見することは困難でした。
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.
テンプレート説明= FOOサービスURLはFooのサービスの位置を示します。
template-url-syntax= url-path= ; Es gibt keinen fuer den FOO URL definierten Pfad.
テンプレートのURL構文= URLパス=; FOO URL定義されたパスにはありません。
users= string M L O # Die Liste aller Users, die der FOO Server unterstuetzt.
ユーザー=文字列M、LのOの＃FOOサーバをサポートしているすべてのユーザーのリスト。
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.
属性タグが翻訳されていないことに注意してください。翻訳が必要な場合は、そうするための提案規則は、ローカライズされる各属性タグのlocalize-と呼ばれる別の属性<タグ>を定義することです。これは、ヒューマンインタフェースに属性タグを表示するのに役立つだろう。
For example, in this case above, the following two attributes could be defined:
例えば、上記のこのケースでは、次の2つの属性を定義することができます。
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)
（ユーザー=ハンス、フリッツ）、（グループ=管理、財務会計）（テンプレート型= FOO）（テンプレートバージョン= 0.0）（テンプレート記述= FOOサービスURLはFooのサービスの位置を示します。 ）（テンプレートのurl-構文= \ ODのURL-path =;ありFOOのURL定義されたパスの\ ODのための）、（ローカライズユーザー=ユーザー）（ローカライズ-グループ=グループ）。ありません
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 =ハンス、フリッツ」を表示することができます。テンプレート属性は、この登録に含まれていることに注意してください。これはオプションですが、サービスを登録するために使用されたテンプレートを発見することが可能となります。
A.2. Abstract Service Type: Net-Transducer
A.2。抽象サービスタイプ：ネットトランスデューサ
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@sun.com>言語：セキュリティの考慮EN：具体的なサービスの種類のセキュリティの考慮事項を参照してください。
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-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.
サンプル単位=変換器は、インスタンス＃1 C（摂氏）、V（ボルト）、キログラム（キログラム）、等のために、提供することでサンプルの文字列L位ユニット
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------------------------
A.3. Concrete Service Type: Net-Transducer:Thermometer
A.3。コンクリートサービスタイプ：ネットトランスデューサ：温度計
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@sun.com>言語：セキュリティの考慮EN：トランスデューサ出力のない認証はありません。このように、温度計の出力を簡単に詐称することができます。
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内のポートの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.
テンプレートのurl-構文=のURL-path = "ポート=" ポートリストのポートリスト=ポート/ポート "" ポートポート= 1 * DIGIT。サービスURL <ポート>生成規則を参照してください。 ;これらの接続は上行うことができるポートです。
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------------------------
A.4. service: URLs and SLP
A.4。サービス：URLおよびSLP
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サーバのアドレスを知っていると気にするべきではありません。カレンダークライアントプログラムは、FOOサービスを取得するためにSLPを使用することができますURLを自動的に、言う「サービス：FOO：//server1.nosuch.org」を、サービスリクエストを発行することによって。このFOOサーバに障害が発生した場合には、カレンダクライアントは、「：FOO：//server2.nosuch.orgサービス」と言うと、バックアップFOOサーバを見つけるために、再度同じサービス要求を発行することができます。どちらの場合も、サービス：関連する属性そうであるように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 =サービス：ネット変換器：温度計：=（位置記述=ミサイルベイ32）、（演算子=ジョー・エージェント）、（サンプル単位= C）、（サンプル解像度属性//v33.test/ports=3211 = 10 ^ -1）、（サンプルレート= 10）、（テンプレートタイプ=サービス：ネット変換器：温度計）、（テンプレートバージョン= 0.0）、（テンプレート記述=温度計が可能なネットトランスデューサでありますデータは、サービスURL内のポートの1へのTCP接続を開き、NULL文字に遭遇するまでのASCII文字列をリードされた温度を読み取る。。クライアントは、サンプル・レートよりも何より高速でデータを読み続けていない、または可能。接続を閉じる）、（テンプレートのurl-構文= 0D \ "ポート=" ポート・リストの\ ODポートリスト=ポート/ポート "" ポートを\ ODポート= 1 * DIGITの\のOD;サービスURLを参照してください<ポート>生成規則\ OD;。これらは、接続がオンに行うことができるポートです\ 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.
テンプレートの属性が宣伝されていることに注意してください。 ABNFの構文が正しくなるように、テンプレートのurl-構文値は、明示的なエスケープ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のアドレス構文部分を支援するためのマイケル・デイとリーランドウォレスに感謝します。ライアン・モーツは、この文書の執筆を通じて、貴重なフィードバックを提供します。
C. References
C.リファレンス
[1] Protocol and service names, October 1994.
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]バーナーズ=リー、T.、フィールディング、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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[7] Apple Computer. Inside Macintosh. Addison-Wesley, 1993.
[7]アップルコンピュータ。 Macintoshの内部。アディソン・ウェズリー、1993。
[8] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[8]クロッカー、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.アンドリュース、およびA.オッペンハイマー。 AppleTalkの内部。アディソン・ウェズリー、1990。
[10] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol Version 2", RFC 2608, June 1999.
[10]ガットマン、E.、パーキンス、C.、Veizades、J.とM.日、 "サービスロケーションプロトコルバージョン2"、RFC 2608、1999年6月。
[11] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[11]マイヤーズ、J.、 "簡易認証セキュリティー層（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にIANA問題部に書くためのガイドライン、BCP 26、RFC 2434、1998年10月
[13] Newman C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[13]ニューマンC.及びJ.マイヤーズ、 "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.、ガットマン、E.、パーキンス、C.及びS.カプラン、 "サービス・ロケーション・プロトコル"、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
エリック・グットマンSun MicrosystemsのBahnstr。 2 74915ヴァイプシュタットドイツ
Phone: +49 7263 911484 Fax: +1 650 786 5992 EMail: erik.guttman@sun.com
電話：+49 7263 911484ファックス：+1 650 786 5992 Eメール：erik.guttman@sun.com
Charles E. Perkins Sun Microsystems 15 Network Circle Menlo Park, CA 94303 USA
チャールズE.パーキンスSun Microsystemsの15ネットワークサークルメンロパーク、CA 94303 USA
Phone: +1 650 786 6464 Fas: +1 650 786 6445 EMail: cperkins@sun.com
電話：+1 650 786 6464のFas：+1 650 786 6445 Eメール：cperkins@sun.com
James Kempf Sun Microsystems 15 Network Circle Menlo Park, CA 94303 USA
ジェームズ・ケンプSun Microsystemsの15ネットワークサークルメンロパーク、CA 94303 USA
Phone: +1 650 786 5890 Fax: +1 650 786 6445 EMail: james.kempf@sun.com
電話：+1 650 786 5890ファックス：+1 650 786 6445 Eメール：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 Editor機能のための基金は現在、インターネット協会によって提供されます。