RFC2609 日本語訳
2609 Service Templates and Service: Schemes. E. Guttman, C. Perkins,J. Kempf. June 1999. (Format: TXT=72842 bytes) (Updates RFC2165) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group E. Guttman
Request for Comments: 2609 C. Perkins
Updates: 2165 J. Kempf
Category: Standards Track Sun Microsystems
June 1999
Guttmanがコメントのために要求するワーキンググループE.をネットワークでつないでください: 2609のC.パーキンスアップデート: 2165年のJ.ケンフカテゴリ: 標準化過程サン・マイクロシステムズ1999年6月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
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体系名は、サービスアクセス情報を分配するのにService Locationプロトコルによって使用されることを主として意図するURL(本書では「サービス: URL」と呼ばれる)を定義するのに使用されます。 クライアントベースのネットワークソフトウェアがネットワーク・サービスを利用するのに必要である設定情報を得るように、これらの体系は広げることができるフレームワークを提供します。 サービスを登録するとき: URL、URLはサービスを定義する1セットの明確な属性によって伴われます。 これらの属性はエンドユーザにとって、重要なクライアントソフトウェア、またはサービスの特性に設定情報を伝えます。
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.
このドキュメントが使用のために新しいサービスタイプと属性を定義して、標準化するための正式手順について説明する、「サービス:」 計画してください。 サービスタイプと属性の形式的記述は人間であってマシン理解できるテンプレートです。 それら、管理ツールによって使用されて、サービスレジスト情報を分析して、サービスの翻訳であると提供するクライアント利用でローカライズされたSHOULDはストリングを結果と考えます。
Guttman, et al. Standards Track [Page 1] RFC 2609 Service Templates and URLs June 1999
Guttman、他 標準化過程[1ページ]RFC2609サービステンプレートとURL1999年6月
Table of Contents
目次
1. Introduction 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3
1.2. Service Location Protocol . . . . . . . . . . . . . . 5
1.2.1. Compatibility with SLPv1 . . . . . . . . . . . 5
2. Service URL Syntax and Semantics 5
2.1. Service URL Syntax . . . . . . . . . . . . . . . . . 5
2.2. Service URL Semantics . . . . . . . . . . . . . . . . 8
2.3. Use of service: URLs . . . . . . . . . . . . . . . . 9
2.4. Specifying the Service Type-Specific URL Syntax. . . . 10
2.5. Accommodating Abstract Service Types . . . . . . . . 10
2.5.1. Advertising Abstract Service Types . . . . . . 11
3. Syntax and Semantics of Service Type Specifications 12
3.1. Syntax of Service Type Templates . . . . . . . . . . 12
3.2. Semantics of Service Type Templates. . . . . . . . . . 15
3.2.1. Definition of a Service Template . . . . . . . 15
3.2.2. Service Type . . . . . . . . . . . . . . . . . 16
3.2.3. Version Number . . . . . . . . . . . . . . . . 16
3.2.4. Description . . . . . . . . . . . . . . . . . 16
3.2.5. Syntax of the Service Type-specific URL Part . 17
3.2.6. Attribute Definition . . . . . . . . . . . . 17
4. A Process For Standardizing New Service Types 21
5. IANA Considerations 22
6. Internationalization Considerations 24
6.1. Language Identification and Translation. . . . . . . . 24
7. Security Considerations 25
A. Service Template Examples 26
A.1. FOO . . . . . . . . . . . . . . . . . .. . . . . . . . 26
A.2. Abstract Service Type: Net-Transducer . . . . . . . . 28
A.3. Concrete Service Type: Net-Transducer:Thermometer . . 29
A.4. service: URLs and SLP . . . . . . . . . . . . . . . . 30
B. Acknowledgments 30
C. References 31
D. Authors' Addresses 32
E. Full Copyright Statement 33
1. 序論2 1.1。 用語. . . . . . . . . . . . . . . . . . . . . 3 1.2。 位置のプロトコル. . . . . . . . . . . . . . 5 1.2.1を修理してください。 SLPv1. . . . . . . . . . . 5 2との互換性。 URL構文と意味論5 2.1を修理してください。 URL構文. . . . . . . . . . . . . . . . . 5 2.2を修理してください。 URL意味論. . . . . . . . . . . . . . . . 8 2.3を修理してください。 サービスの使用: URL. . . . . . . . . . . . . . . . 9 2.4。 サービスのタイプ特有のURL構文を指定します。 . . . 10 2.5. 親切な抽象的なサービスは.1に.102.5をタイプします。 抽象的なサービスの広告を出すと、.113はタイプされます。 サービスの構文と意味論は仕様12 3.1をタイプします。 サービスタイプテンプレート. . . . . . . . . . 12 3.2の構文。 サービスタイプテンプレートの意味論。 . . . . . . . . . 15 3.2.1. サービステンプレート. . . . . . . 15 3.2.2の定義。 タイプ. . . . . . . . . . . . . . . . . 16 3.2.3を修理してください。 バージョンNo.. . . . . . . . . . . . . . . . 16 3.2.4。 記述. . . . . . . . . . . . . . . . . 16 3.2.5。 サービスのタイプ特有のURLパート. 17 3.2.6のものの構文。 定義. . . . . . . . . . . . 17 4を結果と考えてください。 新しいサービスを標準化するためのプロセスは5に21をタイプします。 IANA問題22 6。 国際化問題24 6.1。 言語識別と翻訳。 . . . . . . . 24 7. セキュリティ問題25A.サービステンプレートの例26のA.1。 FOO………………。 . . . . . . . 26 A.2。 抽象的なサービスタイプ: ネットの振動子.28A.3。 具体的なサービスタイプ: ネットの振動子: 温度計. . 29A.4サービス: URLとSLP. . . . . . . . . . . . . . . . 30B.承認30C.参照31D.作者のアドレス32のE.の完全な著作権宣言文33
1. Introduction
1. 序論
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は、正式な記法を使用することでネットワーク・サービスのためのネットワークアクセス情報を定義します)。 さらに、サービスと交際するために1セットの属性を定義する方法を説明します: URL。 これらの属性はエンドユーザを許容するでしょう、そして、同じタイプのネットワーク・サービスの間でそれを選択するプログラムには、異なる機能があります。 属性は人々とマシンで読み込み可能なテンプレートドキュメントで定義されます。
Guttman, et al. Standards Track [Page 2] RFC 2609 Service Templates and URLs June 1999
Guttman、他 標準化過程[2ページ]RFC2609サービステンプレートとURL1999年6月
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.
Service Locationプロトコル[10]を利用するサーバが自分たちとそれらの属性を示します。 彼らは、サービスが登録証明書であると生成するのにテンプレートを使用します。 登録では、サービスは属性に規定値を使用しなければなりません。
3. Client presentation of Service Information
3. Service情報のクライアントプレゼンテーション
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.
サービスはテンプレートを使用しながら、1つ以上の言語でそれ自体を登録するかもしれません、だれがただ一つの言語のサービス属性を示したかがオペレータによって構成されましたが。
All grammar encoding follows the Augmented BNF (ABNF) [8] for syntax specifications.
すべての文法コード化が構文仕様のためのAugmented BNF(ABNF)[8]に続きます。
1.1. Terminology
1.1. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[6]で説明されるように本書では解釈されることであるべきですか?
Guttman, et al. Standards Track [Page 3] RFC 2609 Service Templates and URLs June 1999
Guttman、他 標準化過程[3ページ]RFC2609サービステンプレートとURL1999年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 Locationプロトコルによって使用されて、登録して、発見します。 それは他のプロトコルの近くと、そして、また、ドキュメントで使用されるかもしれません。
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は理解されることです。 それはさまざまなプロトコルに関連している特定のネットワーク・プロトコルか抽象的なサービスのどちらかを指示するかもしれません。 サービスタイプが特定のプロトコルを指示するなら、サービスは名前SHOULDをタイプします。特定のよく知られているポート[2]の名前はコンベンションによって割り当てられなさいか、サービス[1]のためのAssigned民数記名になってください。
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、任意に、1セットの属性はサービス登録を包括します。 サービスか与えられたサービスを代表してこの登録をします。 URL構文と属性は登録されたサービスのためのサービステンプレートに従わなければなりません。
service template
サービステンプレート
A formal description of the service attributes and service
scheme associated with a particular service type.
サービス属性とサービス体系の形式的記述は特定のサービスタイプと交際しました。
Guttman, et al. Standards Track [Page 4] RFC 2609 Service Templates and URLs June 1999
Guttman、他 標準化過程[4ページ]RFC2609サービステンプレートとURL1999年6月
1.2. Service Location Protocol
1.2. サービス位置のプロトコル
The Service Location Protocol version 2 [10] allows service: URLs to be registered and discovered, though service: URLs may be also used in other contexts.
Service Locationプロトコルバージョン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。 クライアントはサービスを供給することによって、特定にサービスの属性を検索します: 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、ことによると属性、およびデジタル署名。
1.2.1. Compatibility with SLPv1
1.2.1. SLPv1との互換性
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は抽象的なサービスタイプでService 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はHTMLコンベンション'&''#'1*DIGIT';'を使用します。
2. Service URL Syntax and Semantics
2. サービスURL構文と意味論
This section describes the syntax and semantics of service: URLs.
このセクションはサービスの構文と意味論について説明します: URL。
2.1. Service URL Syntax
2.1. サービス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としてそれを扱うほど異なる、サービスのための特定のパーサ: URLは利用可能です。
Guttman, et al. Standards Track [Page 5] RFC 2609 Service Templates and URLs June 1999
Guttman、他 標準化過程[5ページ]RFC2609サービステンプレートとURL1999年6月
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].
<体液>分野への構文はサービス型定義によります。 <体液>分野は、サービスアクセスポイントであり、サービスにアクセスする方法を説明します。 さらに、大文字と小文字キャラクタの両方がサービスタイプ>が便宜のためにさばく<で見分けられますが、名前はケースによって小文字に折り重ねられます。 したがって、サービスタイプがケースに基づいて区別されないので、例えば、"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
サービス: URL= 「以下を修理してください」 「サービスタイプ」:、」 「体液サービスタイプは抽象型と等しい」:、」 具体的なurl-体系/タイプ抽象型=型名、[「. 」 命名-auth] 具体的なタイプがプロトコルと等しい、[「. 」 命名-auth] resname url-体系=型名=resname命名-auth=resname。 認識されたURL体系名であって、標準化される。 一般的な習慣か突き抜けることを通して。 承認..標準化団体..アルファー..体液..サイト..部分..サイト..等しい..ユーザ..等しい..ホスト..ポート..ホスト..ホスト名..ホスト名..アルファ..ケタ..アルファ..アルファ..数..数..等しい..ポート..ケタ ポートナンバーを含まなければならない、。 プロトコル分野には、IANAがありません。 「ポートナンバーユーザ=*を割り当てる、[uchar/、」 ; 」 /「+ 」 /“&"/「=」] ipxsite="/ipx/"ipxネット」:、」 「ipx-ノード」:、」 「ipx-ソケットipx-ネットは=4 12HEXDIGIT ipx-ソケット=HEXDIGIT atsite="/at/"という8HEXDIGIT ipx-ノードとオブジェクトであることで等しい」:、」 タイプ、「「ゾーン」
Guttman, et al. Standards Track [Page 6] RFC 2609 Service Templates and URLs June 1999
Guttman、他 標準化過程[6ページ]RFC2609サービステンプレートとURL1999年6月
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
アルファー/ DIGIT /ゾーンの=1*31apple-炭がりんごで炭にするオブジェクトの=1*31apple炭タイプの=1*31apple-炭=金庫/は=から逃げました。 =でないAppleAscii[7]値。 制限を範囲から逃げなければなりません。 = ; 以下に注意してください。 逃げられた値が対応していない、=。 ここのUTF-8値に: それらはAppleAscii=です。 バイトurl-部分はurl-経路=1*(「/」*xchar)と等しいです[url-経路][attr-リスト]。 それぞれのサービスタイプが定義しなければならない、それ、。 一貫していた状態で構文を所有してください。 「[5] attr-リスト=で、1*(「;」attr-asgn)attr-asgn=attr attr-イド/イドは「」 attr-値安全な=「$」/「-」/"_"/と等しいです」。」 /「~」付加的な=“!" 「/「*」/、「'「無遠慮であるか予約されたか逃げられた逃げられた=1/無遠慮であるか逃げられた「+」 「」 (「/」)/」、」 /uchar=xchar=*('\'HEXDIG HEXDIG)は=を予約」」でした'。 / "/" / "?" / ":" /"@"/“&"/「=」/「+」無遠慮な=アルファー/ケタ/金庫/エキストラ
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サブネットを意味します。 ノード要素はネットワーク・インターフェース・カードを表します。 通常、インタフェースカードのノードIDと同じであるのは、16進で表された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 Zone名を示します。(また、それも、読み込み可能な状態で人間です)。 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ケタに先行してください。
Guttman, et al. Standards Track [Page 7] RFC 2609 Service Templates and URLs June 1999
Guttman、他 標準化過程[7ページ]RFC2609サービステンプレートとURL1999年6月
2.2. Service URL Semantics
2.2. サービスURL意味論
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.
<サイト>が以下のフォームの1つを持っているところと、サービス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>分野は、サービスのためのIPネットワーク・プロトコルアドレスと、ドメイン名(DNS)かことによるとポートナンバーのどちらかです。 DNSホスト名の使用が番号を付け替えることの容易さのために好まれることに注意してください。 サービスURLかサービス属性における他の情報がサービスを利用するために十分であるなら、<サイト>分野はヌルである場合があります。
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].
<体液>分野は、詳しい情報が<サイト>がそのために十分でないなら(<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.
>分野がしかし>がさばく<url-部分の端で見える<attr-リストは、どんなサービス位置登録でも存在するのに決して必要ではありません。
The <attr-list> field is composed of a list of semicolon (";")
separated attribute assignments of the form:
<のattrリストの>分野がセミコロンのリストで構成される、(「」、)、形式の切り離された属性課題:
attr-id "=" attr-value
attr-イド「=」attr-価値
or for keyword attributes:
キーワードは以下を結果と考えます。
attr-id
attr-イド
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]サービスは、クライアントが終わっていてケルベロスを認証するのを必要とするかもしれません。 サービス登録に属性を含んでいるのに、ACAPクライアントは正しいSASL[11]認証機構を利用できます。 ACAPサーバの登録に似るかもしれません:
service:acap://some.where.net;authentication=KERBEROSV4
サービス: acap://some.where.net; 認証=KERBEROSV4
Guttman, et al. Standards Track [Page 8] RFC 2609 Service Templates and URLs June 1999
Guttman、他 標準化過程[8ページ]RFC2609サービステンプレートとURL1999年6月
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は、唯一特定のサービスエージェントかリソースと同一視されていて、属性情報を登録するか、または要求するとき、使用されています。 Service Locationプロトコルはどうそのような情報をネットワーク・サービスで登録して、クライアントソフトウェアで得るかを指定します。
2.3. Use of service: URLs
2.3. サービスの使用: 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登録は属性を含んでいます、また、登録しているエージェントSHOULDがサービスを特徴付ける属性の動向をおさえます。
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.
テンプレートでクライアントの代理をするクライアントかエージェントによって定義された正式な属性仕様に対して登録証明書をチェックできます。 サービス登録はService Locationプロトコル[10](SLP)を使用し通常終わっています。 SLPはメカニズムをサービスに提供します: サービスの属性に応じてダイナミックに得られるべきURL。
It is also possible to obtain service: URLs from documents and using other protocols. In this case, the URL may not be accompanied by the service attributes. The context in which the URL appears should make it clear, if possible, when the service is appropriate to use. For example, in a mail message, a service might be recommended for use when the user is in a branch office. Or, an HTML document might include a service: URL as a pointer to a service, describing in text what the service does and who is authorized to use it.
また、サービスを得るのも可能です: ドキュメントからのURLと他のプロトコルを使用すること。 この場合、URLはサービス属性によって伴われないかもしれません。 できれば、URLが現れる文脈は、サービスは使用するのがいつ適切であるかを断言するべきです。 ユーザが支店にいるとき、例えば、メール・メッセージでは、サービスは使用のために推薦されるかもしれません。 または、HTMLドキュメントはサービスを含むかもしれません: テキストでサービスが何をするか、そして、だれがそれを使用するのに権限を与えられるかを説明するサービスへの指針としてのURL。
Guttman, et al. Standards Track [Page 9] RFC 2609 Service Templates and URLs June 1999
Guttman、他 標準化過程[9ページ]RFC2609サービステンプレートとURL1999年6月
2.4. Specifying the Service Type-Specific URL Syntax
2.4. サービスのタイプ特有のURL構文を指定します。
When a service type is specified, the specification includes the definition of the syntax for all URLs that are registered by services of that particular type. For instance, the "lpr" service type may be defined with service: URLs in the following form:
サービスタイプが指定されるとき、仕様はその特定のタイプのサービスで登録されるすべてのURLのための構文の定義を含んでいます。 例えば、"lpr"サービスタイプはサービスで定義されるかもしれません: 以下の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サービスタイプが指定されると、この部分は指定されています。
2.5. Accommodating Abstract Service Types
2.5. 抽象的なサービスを収容するのはタイプされます。
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.
aを登録するには、以下を修理してください。 '抽象型'文法規則がセクション3.1で説明した抽象的なサービスタイプのためのURLは使用されています。 これはすなわち、サービスを利用できるくらいの情報、プロトコル、アドレス、および経路情報を含んでいる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で説明されます。
Guttman, et al. Standards Track [Page 10] RFC 2609 Service Templates and URLs June 1999
Guttman、他 標準化過程[10ページ]RFC2609サービステンプレートとURL1999年6月
2.5.1. Advertising Abstract Service Types
2.5.1. 抽象的なサービスの広告を出すのはタイプされます。
Some services may make use of several protocols that are in common use and are distinct services in their own right. In these cases an abstract service type is appropriate. What is essential is that all the required information for the service is clearly defined.
いくつかのサービスがそのものとして共用であり、異なったサービスであるいくつかのプロトコルを利用するかもしれません。 これらの場合では、抽象的なサービスタイプは適切です。 不可欠のことはサービスのためのすべての必須情報が明確に定義されるということです。
For example, suppose a network service is being developed for dynamically loading device drivers. The client requires the following three pieces of information before it can successfully load and instantiate the driver:
例えば、ネットワーク・サービスがダイナミックにデバイスドライバをロードするために開発されていると仮定してください。 首尾よくドライバーをロードして、例示できる前にクライアントは以下のスリーピースの情報を必要とします:
1. The protocol used to load the driver code, for example, "ftp",
"http" or "tftp"
1. プロトコルは以前はよく例えば、ドライバーコード、"ftp"、"http"または"tftp"をロードしていました。
2. A pathname identifying where the driver code is located, for
example "/systemhost/drivers/diskdrivers.drv",
2. ドライバーコードがどこに位置しているかを特定するパス名、例えば、"/systemhost/drivers/diskdrivers.drv"
3. The name of the driver, for example, "scsi".
3. ドライバーの名前、例えば、"scsi"。
The temptation is to form the first two items into a URL and embed that into a service: URL. As an example which should be avoided,
誘惑は、最初の2つの項目でURLを作って、それをサービスに埋め込むことです: URL。 例として、どれが避けられるべきであるか。
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:
むしろ、要約はSHOULDをサービスしてタイプします。使用されます。 例が示すようにサービスタイプは"ftp"ではありません。 むしろ、それは「デバイスドライバ」です。 サービス: 使用されるべきであるセクション[6]で規則と一致したURLは以下です:
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/ディスク/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のすべてを返すかもしれません。 クライアントは必要なリソースのために最も適切なアクセス・プロトコルを選択します。
Guttman, et al. Standards Track [Page 11] RFC 2609 Service Templates and URLs June 1999
Guttman、他 標準化過程[11ページ]RFC2609サービステンプレートとURL1999年6月
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つの属性が、ドライバーについて描写するために含まれています。
3. Syntax and Semantics of Service Type Specifications
3. サービスの構文と意味論は仕様をタイプします。
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.
以下の小区分はサービスタイプテンプレートの構文と意味論について説明します。
3.1. Syntax of Service Type Templates
3.1. サービスタイプテンプレートの構文
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文字符号化に対応します)の0×00 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.
1ブロックのテキストが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]で説明されるのと同じです。
Guttman, et al. Standards Track [Page 12] RFC 2609 Service Templates and URLs June 1999
Guttman、他 標準化過程[12ページ]RFC2609サービステンプレートとURL1999年6月
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文字でコード化されます)。 '\'HEXDIG HEXDIG構文を使用して、ASCII範囲の外にあるすべてのキャラクタから逃げなければなりません。 「例えば、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.
属性識別子、属性タイプ名、および旗はすべて大文字と小文字を区別しないです。 プレゼンテーションの容易さにおいて、テンプレートドキュメントにこれらを表すのに大文字と小文字キャラクタを使用できます。 ニューラインは文法で重要です。内部的に項目の部分を切り離すことと同様にそれらは別のものから1つの項目を区切ります。
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.
属性タグと値はディレクトリルックアップの役に立ちます。 この場合、ストリングマッチングの前にキャラクタエスケープを解読して、余白を整えるのを実行しなければなりません。 追加、SHOULDに合っているストリングでは、大文字と小文字を区別しなくいてください。
Guttman, et al. Standards Track [Page 13] RFC 2609 Service Templates and URLs June 1999
Guttman、他 標準化過程[13ページ]RFC2609サービステンプレートとURL1999年6月
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=「テンプレートバージョン=」schemeurl=「テンプレート-url構文=」ニューラインのurl-bnfの用語のurl-bnfのバージョンノー用語schemetext=「テンプレート記述=」ニューラインdesc用語=*[com-雑用]を計画します。 <のurl経路の>生産について説明するABNF。 サービスで: 「セクション2.1体系==バージョンサービスタイプサービスタイプ体系名の体系=体系名命名-auth=名=アルファー[1*schemechar][「.」 1*schemechar]がschemecharする[「.」 命名-auth]=アルファ/ケタ/「-」/「+」/ノー1*ケタのURL文法」、」 1*DIGIT langtagは1*8ALPHA[「-」1*8ALPHA]と等しいです。 [3] descが*[com-雑用]と等しいのを見てください。 読書するための1ブロックの自由形式テキスト。 aでサービスについて説明する人々がショートします。 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 ) ; 読書するための1ブロックの自由形式テキスト。 そして、属性について説明する人々、。 「値. ヘルプライン=*[comに、焦げます]ニューラインattrcharはschemechar/と等しい」:、」 / "_" / "$" / "~" / "@" / "." / "|値..ストリング..整数..ブール..不透明..ストリング..安全..炭..安全..炭..白..安全..炭..整数..等しい..ケタ..論理演算子..本当..誤る..不透明なもの..ff 各バイトの不透明な価値はコード化された十六進法です。 ; 形式は[10]に対応しています。
Guttman, et al. Standards Track [Page 14] RFC 2609 Service Templates and URLs June 1999
Guttman、他 標準化過程[14ページ]RFC2609サービステンプレートとURL1999年6月
; 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-雑用は白く安全な炭/spな/と等しいです」、/、」、;、」 /「%」安全な炭の=が/からattrcharしたか、または逃げた 「「/“!"」 / '"' / "'" / "|" / "(" / ")" / "+" / "-" / "." / ":" / "=" / "?" 「「[「/」]」という//、「「/」/、」 /、「「すべてのUTF-8の印刷可能なキャラクタがそうであるという/「$」を含んでいて、除いてください」、」、「%」、」、;」 「#」 逃げられた=1*('\'HEXDIG HEXDIG)白くspな=スペース/HTニューラインがCR/と等しい (CR LF)
3.2. Semantics of Service Type Templates
3.2. サービスタイプテンプレートの意味論
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を使用して、これらの属性はどんなサービス登録にも伴うかもしれません。
3.2.1. Definition of a Service Template
3.2.1. サービステンプレートの定義
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.
サービス体系の体系名。 体系名は期間までにサービス型名と切り離されたサービス型名と任意の命名権威名から成ります。 コンベンションのための.2がサービス型名を支配しているのを3.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.
テキストでの包含に適したサービスの記述は人々で読みました。
Guttman, et al. Standards Track [Page 15] RFC 2609 Service Templates and URLs June 1999
Guttman、他 標準化過程[15ページ]RFC2609サービステンプレートとURL1999年6月
- 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.
それぞれの以下の小区分はこれらの項目の1つに対処します。
3.2.2. Service Type
3.2.2. サービスタイプ
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であると思われます。
3.2.3. Version Number
3.2.3. バージョン番号
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つを加えます、そして、必要な属性の追加、定義の変化、または属性の取り外しが主要な数に1つを加えます。 意図は不完全にならテンプレートが小さい方のバージョンにおける登録と異なっているだけであるなら古いサービステンプレートがまだ正確にサービス登録の属性を定義しているということです。 どうテンプレートバージョン属性を使用するかに関するその他の詳細に関してセクション4を見てください。
3.2.4. Description
3.2.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.
サービスタイプが特定のプロトコルに文通しているなら、ここでプロトコル仕様を引用しなければなりません。 プロトコルは標準化されたプロトコルである必要はありません。 テンプレートは、詳細について連絡窓口にメーカー独自仕様を呼んで、テンプレートの読者を差し向けるかもしれません。
Guttman, et al. Standards Track [Page 16] RFC 2609 Service Templates and URLs June 1999
Guttman、他 標準化過程[16ページ]RFC2609サービステンプレートとURL1999年6月
3.2.5. Syntax of the Service Type-specific URL Part
3.2.5. サービスのタイプ特有のURL部分の構文
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。 構文は[5]で説明されたURL構文のために約束を守るABNF[8]としてテンプレートドキュメントに含まれています。 サービス体系が<url-経路が>であるとサポートするという要件が全くありません。 >がさばく<url-経路は、非常に簡単であるか、または省略さえできます。 URL体系が既に標準化されたなら、「テンプレートurl構文」項目SHOULDは適切な標準化ドキュメントの指示するものを含んでいます。 抽象的なサービスタイプはそれらの具体的なインスタンスについて説明するテンプレートドキュメントにこの分野を延期するかもしれません。
3.2.6. Attribute Definition
3.2.6. 属性定義
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] 何らかのプロトコルが意味するService Locationを使用することで質問における属性の反登録と使用を実行できて、この議論はドキュメントの範囲を超えています。
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
属性定義は、属性の識別子の仕様で始まって、ただ一つの空の系列で終わります。 aの外観の順に属性定義には5つのコンポーネントがある、(。
Guttman, et al. Standards Track [Page 17] RFC 2609 Service Templates and URLs June 1999
Guttman、他 標準化過程[17ページ]RFC2609サービステンプレートとURL1999年6月
definition):
定義)、:
1. An attribute identifier which acts as the name of the attribute,
1. 属性の名前として機能する属性識別子
2. Attribute descriptors (type and flags),
2. 記述子(タイプと旗)を結果と考えてください。
3. An optional list of values which are assigned to the attribute by
default,
3. デフォルトで属性に割り当てられる値の任意のリスト
4. An optional block of text readable by people providing a short,
informative description of the attribute,
4. 属性の短くて、有益な記述を提供する人々で読み込み可能なテキストの任意のブロック
5. An optional list of allowed values which restrict the value or
values the attribute can take on.
5. 値を制限する許容値か属性が呈することができる値の任意のリスト。
3.2.6.1. The Attribute Identifier
3.2.6.1. 属性識別子
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登録証明書。 それぞれの属性識別子はテンプレートでユニークであるに違いありません。 識別子が折り重ねられたケースであるので、大文字と小文字キャラクタは同じです。
3.2.6.2. The Attribute Type
3.2.6.2. 属性タイプ
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.
キーワードと論理演算子属性は属性定義の以下の部分に制限を課します。 型定義、およびどんなデフォルトにも従って、キーワード属性定義には旗の情報が全くあってはいけない、さもなければ、許容値は記載します。 ブール属性がただ一つの値専用である、すなわち、マルチ評価された論理演算子属性は許容されていません。
Guttman, et al. Standards Track [Page 18] RFC 2609 Service Templates and URLs June 1999
Guttman、他 標準化過程[18ページ]RFC2609サービステンプレートとURL1999年6月
3.2.6.3. Attribute Flags
3.2.6.3. 属性旗
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.
クライアントSHOULDがサービスを求める要求に示された属性を含んでいるのを示します。 この属性を含んでいるのを忘れるのがサービスを十分差別化しないでしょう。 この属性を選択しないでサービスを得ると、それらはおそらくクライアントにはかなり役に立たなくなるでしょう。
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.
多値の属性のための値は順不同のセットです。 多値の属性からの個人価値の削除はサポートされません、そして、属性の削除で、全体の値を取り除きます。
Guttman, et al. Standards Track [Page 19] RFC 2609 Service Templates and URLs June 1999
Guttman、他 標準化過程[19ページ]RFC2609サービステンプレートとURL1999年6月
3.2.6.4. Default Value or List
3.2.6.4. デフォルト値かリスト
If the attribute definition includes a default value or, in the case of multivalued attributes, a default values list, it begins on the second line of the attribute definition and continues over the following lines until a line ends without a comma. As a consequence, newlines cannot be embedded in values unless escaped. See Section 2.1.
属性定義がデフォルト値か多値の属性の場合におけるデフォルト値リストを含んでいるなら、それは、属性定義のセカンドラインの上で始まって、系列がコンマなしで終わるまで、以下の系列の上で続きます。 結果として、逃げられない場合、ニューラインを値に埋め込むことができません。 セクション2.1を見てください。
Particular attribute types and definitions restrict the default values list. Keyword attributes must not have a list of defaults. If an optional attribute's definition has an allowed values list, then a default value or list is not optional but required. The motivation for this is that defining an attribute with an allowed values list is meant to restrict the values the attribute can take on, and requiring a default value or list assures that the default value is a member of the given set of allowed values.
特定の属性タイプと定義はデフォルト値リストを制限します。 キーワード属性に、デフォルトのリストがあってはいけません。 許容値が任意の属性の定義で記載するなら、デフォルト値かリストが任意であるのではなく、必要です。 これに関する動機は許容値で属性を定義して、リストが属性が呈することができる値を制限することになっているということです、そして、デフォルト値かリストを必要とするのはデフォルト値が与えられたセットの許容値のメンバーであることを保証します。
The default value or list indicates what values the attribute is given if no values are assigned to the attribute when a service is registered. If an optional attribute's definition includes no default value or list, the following defaults are assigned:
サービスが登録されているとき、値が全く属性に割り当てられないなら、デフォルト値かリストが、属性がどんな値に与えられているかを示します。 任意の属性の定義がどんなデフォルト値もリストも含んでいないなら、以下のデフォルトは割り当てられます:
1. String values are assigned the empty string,
1. 空のストリングはストリング値に割り当てられます。
2. Integer values are assigned zero,
2. 整数値が割り当てられる、ゼロ
3. Boolean values are assigned false,
3. ブール値は虚偽で割り当てられます。
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.
「非-リテラル」属性を翻訳する目的において、順序集合になるようにデフォルト値リストを取ります、そして、翻訳はそのオーダーを維持しなければなりません。
3.2.6.5. Descriptive Text
3.2.6.5. 説明文
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
デフォルト値がもしあれば説明文SHOULDの1ブロックをリストアップする直後、属性定義で含められてください。 本稿は、人々で読み込み可能であることが意味されて、属性の短くて、有益な記述を含むべきです。 また、それは許容値の記述などの追加情報を提供するかもしれません。 本稿はディスプレイのために対話的なブラウジングツールによって主として設計されます。 系列の始めの網状線キャラクタ(「#」)は周囲の定義から説明文を引きたたせます。 しかしながら、コメントとしてテキストを扱うべきではありません。
Guttman, et al. Standards Track [Page 20] RFC 2609 Service Templates and URLs June 1999
Guttman、他 標準化過程[20ページ]RFC2609サービステンプレートとURL1999年6月
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.
それが属性定義の不可欠の部分である時から分析していて他のツール。 説明文のブロックの中では、テキストを逐語的に移します、刻み目とラインブレイクを含んでいてどんな形式も保存されて。
3.2.6.6. Allowed Values List
3.2.6.6. 値が許容されて、記載してください。
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.
デフォルトのように、値は記載します、またリストが翻訳の目的のための順序集合であると考えられる許容値。
3.2.6.7. Conclusion of An Attribute Definition
3.2.6.7. 属性定義の結論
An attribute definition concludes with a single empty line.
属性定義はただ一つの空の系列で締めくくります。
4. A Process For Standardizing New Service Types
4. 新しいサービスを標準化するためのプロセスはタイプされます。
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 '.'.
'メージャー改訂番号が前に来る、'、'MINOR改訂番号が後に来る、'.'
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
- テンプレートのために定義されたどんな新しい任意の属性もマイナーバージョン番号を1つ増強します。 バージョンのための他のすべての属性が、従来と同様サポートされ続けなければなりません。 クライアント、どれ
Guttman, et al. Standards Track [Page 21] RFC 2609 Service Templates and URLs June 1999
Guttman、他 標準化過程[21ページ]RFC2609サービステンプレートとURL1999年6月
supports 1.x can still use later versions of 1.y (where x<y) as
it ignores attributes it doesn't know about.
知らない属性を無視するとき、サポート1.xはまだ1.y(どこx<y)の後のバージョンを使用できるか。
- Adding a required attribute, removing support for an attribute
or changing definition of an attribute requires changing the
major version number of a service template. A client application
may be unable to make use of this information, or it may need
to obtain the most recent service template to help the user
interpret the service information.
- 必要な属性を加えて、属性か属性の定義を変えるサポートを取り除くと、サービステンプレートはメジャーバージョン番号を変えるのが要求されます。 クライアントアプリケーションがこの情報を利用できないかもしれませんか、またはそれは、ユーザがサービス情報を解釈するのを助けるために最新のサービステンプレートを入手する必要があるかもしれません。
The template is submitted to a special mailing list, see section 5. This document must include a 'template begins here' and 'template ends here' marking, in text, so that it is trivial to cut and paste the template from the submission.
セクション5は、特別なメーリングリストにテンプレートを提出するのを見ます。 このドキュメントは'テンプレートはここで始まっ'て'ここのテンプレートエンド'マークを含まなければなりません、テキストで、服従からテンプレートを切って、貼るのが些細であるように。
The list will be available at svrloc-list@iana.org. Ideally, experts in the implementation and deployment of the particular protocol are consulted so as to add or delete attributes or change their definition to make the template as useful as possible. The mailing list will be maintained even when the SVRLOC WG goes dormant for the purpose of discussing service templates.
リストは svrloc-list@iana.org で利用可能になるでしょう。 理想的に、特定のプロトコルの実装と展開の専門家は、テンプレートをできるだけ役に立つようにするように加えるか、属性を削除するか、または彼らの定義を変えるために相談されます。 SVRLOC 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に設定させて、テンプレートは可能な修正で再発行されるべきです。 バージョンNo.1.0があるテンプレートをIANAに提出しません。 そのポイントから、前方へ、テンプレートを提出します。 どうテンプレートのIANA登録にテンプレートを提出するかに関する詳細に関してセクション5を見てください。
5. IANA Considerations
5. IANA問題
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.
Designated Expertを任命するのは、IESG(例えば、Applications Areaディレクター)の責任([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にテンプレートを提出するでしょう。 メーリングリスト関係者は、入力をプロセスに供給しますが、サービステンプレートを受け入れるかどうかという決定をしません。
Guttman, et al. Standards Track [Page 22] RFC 2609 Service Templates and URLs June 1999
Guttman、他 標準化過程[22ページ]RFC2609サービステンプレートとURL1999年6月
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手順によると、その件はStandards Trackプロセスのために説明されるように上告されるかもしれません。
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------------------------
submitterの名前: サービステンプレートの言語: セキュリティ問題: テンプレートテキスト: ----------------------テンプレートはここで始まります。----------------------- . . . -----------------------ここのテンプレートエンド------------------------
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".
"foo.0.0.en"、「ネットの振動子.0.0.en」、「ネットの振動子: 温度計.0.0.de」、および「ネットの振動子: 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は、登録に評論家からのメールでサービステンプレートを含むように通知を受け取るでしょう。 このメッセージはサービステンプレート自体を含むでしょう。(それは、登録されていることになっています)。
Guttman, et al. Standards Track [Page 23] RFC 2609 Service Templates and URLs June 1999
Guttman、他 標準化過程[23ページ]RFC2609サービステンプレートとURL1999年6月
Neither the reviewer nor the IANA will take any position on claims of copyright or trademark issues with regard to templates.
評論家もIANAも著作権か商標問題のクレームのときにテンプレートに関して少しの立場も取らないでしょう。
6. Internationalization Considerations
6. 国際化問題
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をコード化しなければなりません。 文字集合コード化は米国-ASCII文字の組[4]の中の特定の範囲に制限されます。
The template is encoded in UTF-8 characters.
テンプレートはUTF-8キャラクタでコード化されます。
6.1. Language Identification and Translation
6.1. 言語識別と翻訳
The language used in attribute strings should be identified supplying a Language Tag [3] in the Service Template submission (see Section 5).
属性ストリングで使用される言語は、Service Template服従でLanguage Tag[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つの言語から別の言語までのサービス登録を翻訳できます。 同次にはすべての標準化された属性が両方のテンプレートにあります。 すべての非任意のストリングであり、描写的である助けテキストを含んでいるのは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.
翻訳に取り組む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つのサービス型記述がマスターとして承認されます、1つの言語でサービスタイプテンプレートをアップデートするとき、すべての翻訳(少なくとも結局)が同じ意味論を反映するように。
Guttman, et al. Standards Track [Page 24] RFC 2609 Service Templates and URLs June 1999
Guttman、他 標準化過程[24ページ]RFC2609サービステンプレートとURL1999年6月
If no document exists describing the standard translation of the service type, a 'best effort' translation for strings should be done.
ドキュメントが全くサービスタイプの標準の翻訳について説明しながら存在していないなら、ストリングのための'ベストエフォート型'の翻訳をするべきです。
7. Security Considerations
7. セキュリティ問題
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.
サービスタイプテンプレートはService Locationプロトコルによって得られた情報を解釈するのに使用される情報を提供します。 これらのテンプレートが変更されているか、または偽のテンプレートが分配されているなら、サービスは正しく自分たちを登録しないことができないかもしれませんか、クライアントがサービス情報を解釈できないかもしれません。
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プロトコル[10]はサービスを広げます: URL、それが許容する認証機構に以下を修理させます。 署名されて、署名がクライアントによって確かめられる登録されたサービスのURL。
Each Service Template will include a security considerations section which will describe security issues with using the service scheme for the specific Service Type.
各Service Templateは特定のService Typeにサービス体系を使用する安全保障問題について説明するセキュリティ問題部を含むでしょう。
Guttman, et al. Standards Track [Page 25] RFC 2609 Service Templates and URLs June 1999
Guttman、他 標準化過程[25ページ]RFC2609サービステンプレートとURL1999年6月
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).
テンプレート例の部分のテキストは一列でであるとして取ることです。 それらは完全に架空です(ie例は本当のサービスを表しません)。
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サービスのいずれもサポートするかもしれません。 ここに、私たちは抽象型の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.
抽象的なサービスタイプテンプレートが具体的なタイプとしてどんな可能な値を使用できるか、そして、彼らの解釈が何であるかに関して完全に明確であるなら、抽象的なサービスタイプのためにコンクリートのテンプレートを登録するのは必要ではありません。
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.
submitterの名前: 「エリックGuttman、「 <Erik.Guttman@sun.com 、gt;、サービステンプレートの言語:、」 アンSecurity Considerations: USERとGROUPS属性が含まれているなら、ユーザかグループのためのアイデンティティのリストを発見できる可能性は存在しています。 そうでなければ、この情報は発見するのが難しいでしょう。
Template Text: -------------------------template begins here----------------------- template-type=FOO
テンプレートテキスト: -------------------------テンプレートはここで始まります。----------------------- テンプレートタイプは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サーバがサポートするすべてのユーザのリスト。
Guttman, et al. Standards Track [Page 26] RFC 2609 Service Templates and URLs June 1999
Guttman、他 標準化過程[26ページ]RFC2609サービステンプレートとURL1999年6月
groups= string M L O # The list of all groups which the FOO server supports. --------------------------template ends here------------------------
グループ=はM L O#を結びます。FOOサーバがサポートするすべてのグループのリスト。 --------------------------ここのテンプレートエンド------------------------
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.
submitterの名前: 「エリックGuttman、「 <Erik.Guttman@sun.com 、gt;、サービステンプレートの言語:、」 de Security Considerations: WennはUSER und GROUPS Eigenschaften inbegriffen sindで死んで、bestehtはMoeglichkeitで死んで、dassはListe der IdentitaetenフォンBenutzern oder Gruppen endeckt werden kannで死にます。 Diese情報wurde unter anderen Umstaenden schwierig zu entdecken sein。
Template Text: -------------------------template begins here----------------------- template-type=FOO
テンプレートテキスト: -------------------------テンプレートはここで始まります。----------------------- テンプレートタイプはFOOと等しいです。
template-version=0.0
テンプレートバージョン= 0.0
template-description=
Der FOO Service URL zeigt die Stelle von einem Foo Service an.
Der FOO Serviceテンプレート記述=URL zeigtはStelleフォンeinem Foo Serviceで死にます。
template-url-syntax=
url-path= ; Es gibt keinen fuer den FOO URL definierten Pfad.
テンプレート-url構文はurl経路=と等しいです。 Es gibt keinen fuerはFOO URL definierten Pfadを穴に追い込みます。
users= string M L O # Die Liste aller Users, die der FOO Server unterstuetzt.
ユーザ=ストリングM L O#Die Liste aller Users、der FOO Server unterstuetztで、死んでください。
groups= string M L O # Die Liste aller Gruppen, die der FOO Server unterstuetzt. --------------------------template ends here------------------------
グループ=ストリングM L O#Die Liste aller Gruppen、der FOO Server unterstuetztで、死んでください。 --------------------------ここのテンプレートエンド------------------------
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.
属性タグが翻訳されないことに注意してください。 翻訳が望まれているなら、そうするための提案されたコンベンションはローカライズされることになっているそれぞれの属性タグのために<をローカライズしているタグ>と呼ばれる別々の属性を定義することになっています。 これはヒューマンインターフェースで属性タグを表示する際に支援されるでしょう。
For example, in this case above, the following two attributes could be defined:
例えば、この場合、上では、以下の2つの属性が定義されるかもしれません:
localize-users= string Benutzer
ユーザ=を配属しているストリングBenutzer
localize-groups= string
グループをローカライズしている=ストリング
Guttman, et al. Standards Track [Page 27] RFC 2609 Service Templates and URLs June 1999
Guttman、他 標準化過程[27ページ]RFC2609サービステンプレートとURL1999年6月
Gruppen
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)
(ハンス、ユーザ=フリッツ)、(Verwaltung、グループ=Finanzbuchhaltung)、(テンプレートタイプ=FOO)、(テンプレートバージョン=0.0)、(Der FOO Serviceテンプレート記述=URL zeigtがStelleフォンeinem Foo Serviceで死ぬ、)。(テンプレート-url構文は\過量url経路=と等しいです。 Es gibt kein fuerはFOO URL definiert Pfadを穴に追い込みます。 \過量)(ユーザ=Benutzerをローカライズします)です。(グループ=をローカライズしている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=フリッツ」を表示できました。 テンプレート属性がこの登録に含まれていることに注意してください。 これで、OPTIONALですが、どのテンプレートがサービスを登録するのに使用されたかを発見するのが可能になります。
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.
submitterの名前: 「エリックGuttman、「 <Erik.Guttman@sun.com 、gt;、サービステンプレートの言語:、」 アンSecurity Considerations: 具体的なサービスタイプのセキュリティ問題を見てください。
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.
テンプレート記述=これは抽象的なサービスタイプです。 サービスタイプがすべてがネットワークでつなぐただ一つのカテゴリに組織化することになっているネット振動子の目的はある特性を持っているTransducersを有効にしました。
template-url-syntax=
url-path= ; Depends on the concrete service type.
; See these templates.
テンプレート-url構文はurl経路=と等しいです。 具体的なサービスタイプに頼っています。 ; これらのテンプレートを見てください。
sample-units= string L # The units of sample that the Transducer provides, for instance # C (degrees Celsius), V (Volts), kg (Kilograms), etc.
サンプルユニットがストリングL#、と等しい、Transducerが提供するサンプルのユニット、例えば、#、C(度合い、摂氏)、V(ボルト)、kg(キログラム)など
sample-resolution= string L
サンプル解決はストリングLと等しいです。
Guttman, et al. Standards Track [Page 28] RFC 2609 Service Templates and URLs June 1999
Guttman、他 標準化過程[28ページ]RFC2609サービステンプレートとURL1999年6月
# The resolution of the Transducer. For instance, 10^-3 means # that the Transducer has resolution to 0.001 unit.
# Transducerの解決。 例えば、10^-3は、#Transducerには解決が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#、がサンプルが1秒単位で入手される速度であるとサンプルで評定してください。 #、に関しては、インスタンス1000は、1個のサンプルがミリセカンド毎に入手されることを意味します。
--------------------------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.
submitterの名前: 「エリックGuttman、「 <Erik.Guttman@sun.com 、gt;、サービステンプレートの言語:、」 アンSecurity Considerations: Transducer出力の認証が全くありません。 したがって、容易にThermometer出力を偽造することができました。
Template Text: -------------------------template begins here----------------------- template-type=service:Net-Transducer:Thermometer
テンプレートテキスト: -------------------------テンプレートはここで始まります。----------------------- テンプレートタイプ=サービス: ネットの振動子: 温度計
template-version=0.0
テンプレートバージョン= 0.0
template-description=
The Thermometer is a Net-Transducer capable of reading temperature.
The data is read by opening a TCP connection to one of the ports
in the service URL and reading an ASCII string until an NULL
character is encountered. The client may continue reading data at
no faster than the sample-rate, or close the connection.
テンプレート記述=Thermometerは温度を読み取ることができるネット振動子です。 サービス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-経路=「」 リストを移植しているポート=左舷傾斜はポート/ポートと等しいこと」と等しいこと」はポートが移植する1*ケタと等しいです。 Service URL<ポート>プロダクションルールを見てください。 ; これらは接続を作ることができるポートです。
location-description=string # The location where the Thermometer is located.
位置記述はストリング#と等しいです。Thermometerが位置している位置。
operator=string O # The operator to contact to have the Thermometer serviced.
オペレータ=はThermometerを調整させるために連絡するオペレータのO#を結びます。
--------------------------template ends here------------------------
--------------------------ここのテンプレートエンド------------------------
Guttman, et al. Standards Track [Page 29] RFC 2609 Service Templates and URLs June 1999
Guttman、他 標準化過程[29ページ]RFC2609サービステンプレートとURL1999年6月
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は、Service Requestを発行することによって、': foo://server1.nosuch.orgを調整します'。 Calendarクライアントは、バックアップFOOサーバを見つけるためにこのFOOサーバが失敗したなら'サービス: 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= %%BODY%%D "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=サービス: ネットの振動子: 3211Attributes=(位置記述はミサイルベイ32と等しい)、(オペレータ=ジョーエージェント)、(サンプルユニット=C)(サンプル解決は10^-1と等しい)、(見本郵送料率=10)、(テンプレートタイプ=サービス: ネットの振動子: 温度計)と温度計://v33.test/ポートは等しいです(テンプレートバージョンは0.0と等しいです)。(テンプレート記述=Thermometerは温度を読み取ることができるネット振動子です。 サービスURLのポートの1つにTCP接続を開いて、NULLキャラクタまでASCIIストリングを読み込むことによって、遭遇しますデータが読まれる。 クライアントは、見本郵送料率より速いノー、または閉鎖におけるデータに接続を読み込み続けるかもしれません。), (「テンプレート-url構文=%%BODY%%Dは「」 左舷傾斜\過量左舷傾斜=が移植するか、または移植する=を移植」」は\過量ポート=1*ケタ\過量を移植します。 Service URL<ポート>プロダクションルールを見てください。 \過量。 これらは. \過量のときに接続を作ることができるポートです。)
This might be very useful for a technician who wanted to find a Thermometers in Missile bay 32, for example.
これは非常に例えば、Missileベイ32でThermometersを見つけたがっていた技術者の役に立つかもしれません。
Note that the template attributes are advertised. The template-url-syntax value requires explicit escaped CR characters so that the ABNF syntax is correct.
テンプレート属性が広告を出すことに注意してください。 テンプレートurl構文値が明白な逃げられたCRキャラクタを必要とするので、ABNF構文は正しいです。
B. Acknowledgments
B。 承認
Thanks to Michael Day and Leland Wallace for assisting with the IPX and AppleTalk address syntax portions. Ryan Moats provided valuable feedback throughout the writing of this document.
おかげに、IPXとAppleTalkを助けるためのマイケル・デーとリーランド・ウォレスは構文部分を扱います。 ライアン・モウツはこのドキュメントの書くことに有益なフィードバックを提供しました。
Guttman, et al. Standards Track [Page 30] RFC 2609 Service Templates and URLs June 1999
Guttman、他 標準化過程[30ページ]RFC2609サービステンプレートとURL1999年6月
C. References
C。 参照
[1] Protocol and service names, October 1994.
ftp://ftp.isi.edu/in-notes/iana/assignments/service-names.
[1] 名前、10月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] 数、7月1997日の ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers を移植してください。
[3] Alvestrand, H., "Tags for the Identification of Languages",
RFC 1766, March 1995.
Alvestrand(H.)が「言語の識別のためにタグ付けをする」[3]、RFC1766、1995年3月。
[4] ANSI. Coded Character Set -- 7-bit American Standard code for
Information Interchange. X3.4-1986, 1986.
[4] ANSI。 コード化された文字コード--情報Interchangeのための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、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、RFC2396、1998年8月。
[6] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[6] ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、BCP14、RFC2119、1997年3月。
[7] Apple Computer. Inside Macintosh. Addison-Wesley, 1993.
[7] アップル・コンピューター。 マッキントッシュの中で。 アディソン-ウエスリー、1993。
[8] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[8] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[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] Guttman(E.、パーキンス、C.、Veizades、J.、およびM.日)は「1999年6月に位置のプロトコルバージョン2インチ、RFC2608を調整します」。
[11] Myers, J., "Simple Authentication and Security Layer (SASL)",
RFC 2222, October 1997.
[11] マイアーズ、J.、「簡易認証とセキュリティは(SASL)を層にする」RFC2222、1997年10月。
[12] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs, BCP 26, RFC 2434,
October 1998
[12]NartenとT.とH.Alvestrand、「1998年10月にRFCs、BCP26、RFC2434にIANA問題部に書くためのガイドライン」
[13] Newman C. and J. Myers, "ACAP -- Application Configuration
Access Protocol", RFC 2244, November 1997.
[13] ニューマンC.とJ.マイアーズ、「ACAP--アプリケーション構成アクセスは議定書を作る」、RFC2244、11月1997日
[14] Inc Novell. IPX RIP and SAP Router Specification. Part Number
107-000029-001, Version 1.30, May 1996.
[14] Incノベル。 IPXはルータ仕様を裂いて、徐々に破壊します。 部品番号107-000029-001(バージョン1.30)は1996がそうするかもしれません。
[15] Veizades, J., Guttman, E., Perkins, C. and S. Kaplan, "Service
Location Protocol", RFC 2165, July 1997.
[15]VeizadesとJ.とGuttmanとE.とパーキンスとC.とS.キャプラン、「サービス位置のプロトコル」、RFC2165、1997年7月。
Guttman, et al. Standards Track [Page 31] RFC 2609 Service Templates and URLs June 1999
Guttman、他 標準化過程[31ページ]RFC2609サービステンプレートとURL1999年6月
[16] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 2279, January 1998.
[16]Yergeau、1998年1月のF.、「UTF-8、ISO10646の変換形式」RFC2279。
D. Authors' Addresses
D。 作者のアドレス
Questions about this memo can be directed to:
このメモに関する質問による以下のことよう指示できます。
Erik Guttman Sun Microsystems Bahnstr. 2 74915 Waibstadt Germany
エリックGuttmanサン・マイクロシステムズBahnstr。 2 74915Waibstadtドイツ
Phone: +49 7263 911484 Fax: +1 650 786 5992 EMail: erik.guttman@sun.com
以下に電話をしてください。 +49 7263 911484、Fax: +1 5992年の650 786メール: erik.guttman@sun.com
Charles E. Perkins Sun Microsystems 15 Network Circle Menlo Park, CA 94303 USA
チャールズE.パーキンスサン・マイクロシステムズ15ネットワーク円のカリフォルニア94303メンローパーク(米国)
Phone: +1 650 786 6464 Fas: +1 650 786 6445 EMail: cperkins@sun.com
以下に電話をしてください。 +1 650 786の6464ファ: +1 6445年の650 786メール: cperkins@sun.com
James Kempf Sun Microsystems 15 Network Circle Menlo Park, CA 94303 USA
ジェームスケンフサン・マイクロシステムズ15ネットワーク円のカリフォルニア94303メンローパーク(米国)
Phone: +1 650 786 5890 Fax: +1 650 786 6445 EMail: james.kempf@sun.com
以下に電話をしてください。 +1 650 786、5890Fax: +1 6445年の650 786メール: james.kempf@sun.com
Guttman, et al. Standards Track [Page 32] RFC 2609 Service Templates and URLs June 1999
Guttman、他 標準化過程[32ページ]RFC2609サービステンプレートとURL1999年6月
E. Full Copyright Statement
E。 完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Guttman, et al. Standards Track [Page 33]
Guttman、他 標準化過程[33ページ]
一覧
スポンサーリンク
