[要約] RFC 2926は、LDAPスキーマとSLPテンプレートの相互変換に関する標準仕様です。このRFCの目的は、LDAPとSLPの間でのデータの互換性を確保し、システム間の統合を容易にすることです。
Network Working Group J. Kempf
Request for Comments: 2926 Sun Microsystems, Inc.
Category: Informational R. Moats
Coreon, Inc.
P. St. Pierre
Sun Microsystems, Inc.
September 2000
Conversion of LDAP Schemas to and from SLP Templates
LDAPスキーマからSLPテンプレートへの変換
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
Abstract
概要
This document describes a procedure for mapping between Service Location Protocol (SLP) service advertisements and lightweight directory access protocol (LDAP) descriptions of services. The document covers two aspects of the mapping. One aspect is mapping between SLP service type templates and LDAP directory schema. Because the SLP service type template grammar is relatively simple, mapping from service type templates to LDAP types is straightforward. Mapping in the other direction is straightforward if the attributes are restricted to use just a few of the syntaxes defined in RFC 2252. If arbitrary ASN.1 types occur in the schema, then the mapping is more complex and may even be impossible. The second aspect is representation of service information in an LDAP directory. The recommended representation simplifies interoperability with SLP by allowing SLP directory agents to backend into LDAP directory servers. The resulting system allows service advertisements to propagate easily between SLP and LDAP.
このドキュメントでは、サービスの配信プロトコル（SLP）サービス広告とLightweight Directory Access Protocol（LDAP）のサービスのマッピングの手順について説明します。ドキュメントは、マッピングの2つの側面をカバーしています。1つの側面は、SLPサービスタイプテンプレートとLDAPディレクトリスキーマのマッピングです。SLPサービスタイプのテンプレート文法は比較的簡単であるため、サービスタイプテンプレートからLDAPタイプへのマッピングは簡単です。属性がRFC 2252で定義されているいくつかの構文のみを使用するように制限されている場合、反対方向にマッピングするのは簡単です。任意のASN.1タイプがスキーマで発生する場合、マッピングはより複雑であり、不可能である可能性があります。2番目の側面は、LDAPディレクトリ内のサービス情報の表現です。推奨される表現は、SLPディレクトリエージェントがLDAPディレクトリサーバーにバックエンドできるようにすることにより、SLPとの相互運用性を簡素化します。結果のシステムにより、サービス広告はSLPとLDAPの間に簡単に伝播できます。
Table of Contents
目次
1.0 Introduction ................................................ 2
2.0 Mapping SLP Templates to LDAP Schema ........................ 3
2.1 Mapping from SLP Attribute Types to LDAP Attribute Types .. 8
2.1.1 Integer ............................................... 8
2.1.2 String ................................................ 8
2.1.3 Boolean ............................................... 9
2.1.4 Opaque ................................................ 9
2.2 Keyword Attributes ........................................ 9
2.3 Template Flags ............................................ 9
2.3.1 Multi-valued .......................................... 9
2.3.2 Optional .............................................. 10
2.3.3 Literal ............................................... 10
2.3.4 Explicit Matching ..................................... 10
2.4 Default and Allowed Value Lists ........................... 10
2.5 Descriptive Text .......................................... 11
2.6 Generating LDAP Attribute OIDs ............................ 11
2.7 Example ................................................... 11
3.0 Attribute Name Conflicts .................................... 15
4.0 Mapping from Schema to Templates ............................ 15
4.1 Mapping LDAP Attribute Types to SLP Attribute Types ....... 16
4.2 Mapping ASN.1 Types to SLP Types .......................... 17
4.2.1 Integer ............................................... 18
4.2.2 Boolean ............................................... 18
4.2.3 Enumerated ............................................ 18
4.2.4 Object Identifier ..................................... 19
4.2.5 Octet String .......................................... 19
4.2.6 Real .................................................. 19
4.3 Example ASN.1 Schema ...................................... 19
5.0 Representing SLP Service Advertisements in an LDAP DIT ...... 22
6.0 Internationalization Considerations ......................... 24
7.0 Security Considerations ..................................... 24
8.0 References .................................................. 25
9.0 Authors' Addresses .......................................... 26
10.0 Full Copyright Statement ................................... 27
SLP templates [1] are intended to create a simple encoding of the syntactic and semantic conventions for individual service types, their attributes, and conventions. They can easily be generated, transmitted, read by humans and parsed by programs, as it is a string based syntax with required comments. Directory schemas serve to formalize directory entry structures for use with LDAP [2] These directories serve to store information about many types of entities. Network services are an example of one such entity.
SLPテンプレート[1]は、個々のサービスタイプ、属性、および規則の構文およびセマンティックコンベンションの簡単なエンコードを作成することを目的としています。それらは、必要なコメントを備えた文字列ベースの構文であるため、簡単に生成、送信、人間によって読み、プログラムによって解析されます。ディレクトリスキーマは、LDAP [2]で使用するためのディレクトリエントリ構造を正式化するのに役立ちます[2]これらのディレクトリは、多くのタイプのエンティティに関する情報を保存するのに役立ちます。ネットワークサービスは、そのようなエンティティの1つの例です。
Interoperability between SLP and LDAP is important so clients using one protocol derive benefit from services registered through the other. In addition, LDAP directory servers can serve as the backend for SLP directory agents (DAs) if interoperability is possible In order to facilitate interoperability, this document creates mappings between the SLP template grammar and LDAP directory schema, and establishes some conventions for representing service advertisements in LDAP directories. The goal of the translation is to allow SLPv2 queries (which are syntactically and semantically equivalent to LDAPv3 string queries [7]) to be submitted to an LDAP directory server by an SLP DA backended into LDAP without extensive processing by the DA.
SLPとLDAPの間の相互運用性は重要であるため、1つのプロトコルを使用してクライアントは、他のプロトコルを介して登録されているサービスから利益を導き出します。さらに、LDAPディレクトリサーバーは、相互運用性を促進するために相互運用性が可能な場合、SLPディレクトリエージェント（DAS）のバックエンドとして機能することができます。LDAPディレクトリで。翻訳の目標は、SLPV2クエリ（LDAPV3文字列クエリ[7]と構文的および意味的に同等である）を、DAによる広範な処理なしにLDAPにバックインしたSLP DAによってLDAPディレクトリサーバーに提出できるようにすることです。
The simple notation and syntactic/semantic attribute capabilities of SLP templates map easily into directory schemas, and are easily converted into directory schemas, even by automated means. The reverse may not be true. If the LDAP schema contains attributes with unrecognized or complex syntaxes, the translation may be difficult or impossible. If, however, the LDAP schema only uses a few of the common syntaxes defined in RFC 2252 [8], then the translation is more straightforward. In addition, to foster complete bidirectionality, the mapping must follow a very specific representation in its DESC attributes.
SLPテンプレートの単純な表記法と構文/セマンティック属性機能は、自動化された手段であっても、ディレクトリスキーマに簡単にマッピングされ、ディレクトリスキーマに簡単に変換されます。逆は真実ではないかもしれません。LDAPスキーマに、認識されていないまたは複雑な構文を持つ属性が含まれている場合、翻訳は困難または不可能かもしれません。ただし、LDAPスキーマがRFC 2252 [8]で定義されているいくつかの一般的な構文のみを使用している場合、翻訳はより簡単です。さらに、完全な双方向性を促進するには、マッピングはDESC属性の非常に具体的な表現に従う必要があります。
This document outlines the correct mappings for SLP templates into the syntactic representation specified for LDAP directory schema by RFC 2252 [8]. This syntax is a subset of the ASN.1/BER described in the X.209 specification [9], and is used by the LDAPv3 [2] directory schema. Likewise, rules and guidelines are proposed to facilitate consistent mapping of ASN.1 based schemas to be translated in the SLP template grammar. Finally, a proposal for a representation of service advertisements in LDAP directory services is made that facilitates SLP interoperability.
このドキュメントでは、RFC 2252 [8]によってLDAPディレクトリスキーマに指定された構文表現へのSLPテンプレートの正しいマッピングの概要を示しています。この構文は、X.209仕様[9]で説明されているASN.1/BERのサブセットであり、LDAPV3 [2]ディレクトリスキーマで使用されています。同様に、SLPテンプレート文法で翻訳されるASN.1ベースのスキーマの一貫したマッピングを促進するために、ルールとガイドラインが提案されています。最後に、SLPの相互運用性を促進するLDAPディレクトリサービスのサービス広告を表現する提案が作成されます。
Except when used as elements in the definition of LDAP schemas, 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 [16].
LDAPスキーマの定義の要素として使用される場合を除き、キーワードは「必須」、「必須」、「必須」、「shall」、「suff」、 "nove"、 "buld"、 "becommended"、このドキュメントの「5月」と「オプション」は、RFC 2119 [16]に記載されているように解釈されます。
We define the following abstract object class as the parent class for all services. Any specific service type is a subclass of this, with its own attributes:
次の抽象オブジェクトクラスをすべてのサービスの親クラスとして定義します。特定のサービスタイプは、これのサブクラスであり、独自の属性を備えています。
( 1.3.6.1.4.1.6252.2.27.6.2.1 NAME 'slpService' DESC 'parent superclass for SLP services' ABSTRACT SUP top MUST ( template-major-version-number $ template-minor-version-number $ description $ template-url-syntax $ service-advert-service-type $ service-advert-scopes ) MAY ( service-advert-url-authenticator $ service-advert-attribute-authenticator ) )
（1.3.6.1.4.1.6252.2.27.6.2.1名「SLPサービス用のslpservice」desc '親スーパークラス' abstract sup top（テンプレート - マジョールバージョン番号$ Template-minor-minor-version-number $ description $ template-urll-syntax $ service-advert-service-type $ service-advert-scopes）5月（service-advert-url-authenticator $ service-advert-aTtribute-authenticator）））
The attributes correspond to various parts of the SLP service template and SLP service advertisement.
属性は、SLPサービステンプレートのさまざまな部分とSLPサービス広告に対応しています。
SLP service type templates begin with four definitions that set the context of the template:
SLPサービスタイプテンプレートは、テンプレートのコンテキストを設定する4つの定義で始まります。
template-type - This defines the service type of the template. The service type can be a simple service type, like "service:ftp", an abstract service type, like "service:printer" or a concrete service type, like "service:printer:lpr". The type name can additionally include a naming authority, for example "service:printer.sun:local". The name that appears in this field omits the "service:" prefix.
テンプレートタイプ - これにより、テンプレートのサービスタイプが定義されます。サービスタイプは、「サービス：FTP」、「サービス：プリンター」などの抽象サービスタイプ、または「サービス：プリンター：LPR」などの具体的なサービスタイプのようなシンプルなサービスタイプにすることができます。タイプ名には、「Service：Printer.sun：Local」など、命名権限を含めることができます。このフィールドに表示される名前は、「サービス：」プレフィックスを省略します。
template-version - A string containing a major and minor version number, separated by a period.
テンプレートバージョン - 期間で区切られた、主要なバージョンとマイナーバージョン番号を含む文字列。
template-description - A block of human readable text describing what the service type does.
テンプレート説明 - サービスタイプが何をするかを説明する人間の読み取り可能なテキストのブロック。
template-url-syntax - An ABNF [6] grammar describing the service type specific part of the service URL.
Template-url-syntax-ABNF [6]サービスURLの特定の部分を説明するABNF [6]文法。
The SLP template-type definition is used as the name of the LDAP object class for the template, a subclass of the "slpService" class, together with the "service" prefix to indicate that the name is for a service. In the translating service type name, colons and the period separating the naming authority are converted into hyphens. If the template defines an SLP concrete type, the concrete type name is used; the abstract type name is never used. For example, the template for "service:printer:lpr" is translated into an LDAP object class called "service-printer-lpr". Furthermore, if the type name contains a naming authority, the naming authority name must be included. For example, the service type name "service:printer.sun:local" becomes "service-printer-sun-local". The LDAP object class is always "STRUCTURAL".
SLPテンプレートタイプの定義は、「Slpservice」クラスのサブクラスであるテンプレートのLDAPオブジェクトクラスの名前として使用され、「サービス」プレフィックスとともに、名前がサービス用であることを示します。翻訳サービスタイプ名では、コロンと命名権限を分離する期間がハイフンに変換されます。テンプレートがSLPコンクリートタイプを定義する場合、コンクリートタイプ名が使用されます。要約タイプ名は使用されません。たとえば、「サービス：プリンター：LPR」のテンプレートは、「Service-Printer-LPR」と呼ばれるLDAPオブジェクトクラスに翻訳されます。さらに、タイプ名に命名権限が含まれている場合、命名権限名を含める必要があります。たとえば、サービスタイプ名「サービス：printer.sun：local」は「Service-Printer-Sun-Local」になります。LDAPオブジェクトクラスは常に「構造」です。
The template-version definition is partitioned into two attributes, template-major-version-number and template-minor-version-number. The LDAP definition for these attributes is:
テンプレートバージョン定義は、テンプレートマジョールバージョン番号とテンプレートマイノールバージョン番号の2つの属性に分割されます。これらの属性のLDAP定義は次のとおりです。
( 1.3.6.1.4.1.6252.2.27.6.1.1 NAME 'template-major-version-number' DESC 'The major version number of the service type template' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
（1.3.6.1.4.1.6252.2.27.6.1.1名 'Template-major-version-number' desc ''サービスタイプテンプレートの主要バージョン番号equality Integermatch Syntax 1.3.6.1.4.1.1466.115.121.1.27単一 - 価値 ）
( 1.3.6.1.4.1.6252.2.27.6.1.2 NAME 'template-minor-version-number' DESC 'The minor version number of the service type template' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
（1.3.6.1.4.1.6252.2.27.6.1.2名 'Template-Minor-version-number' desc ''サービスタイプテンプレートのマイナーバージョン番号equality Integermatch Syntax 1.3.6.1.4.1.1466.115.121.1.27単一 - 価値 ）
The template-url-syntax definition in the SLP template is described by the following attribute:
SLPテンプレートのテンプレート-URL-SYNTAX定義は、次の属性で説明されています。
( 1.3.6.1.4.1.6252.2.27.6.1.3 NAME 'template-url-syntax' DESC 'An ABNF grammar describing the service type specific part of the service URL' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
（1.3.6.1.4.1.6252.2.27.6.1.3名 'Template-url-syntax' desc '' abnf caseexactia5match Syntax 1.3.6.1.4.1.14666.115.121.1.26単一価値）
The template-description attribute is translated into the X.520 standard attribute "description" [3].
テンプレートデスクリプション属性は、x.520標準属性「説明」[3]に変換されます。
We further establish the convention that SLP template characteristics that can't be translated into LDAP are inserted into the DESC field of the object class definition. The items are separated by empty lines (consisting of two "LINE FEED" characters), are preceded by a LINE FEED character, and are tagged at the beginning of the line to indicate what they represent. This allows the template to be reconstructed from the schema by properly parsing the comments.
さらに、LDAPに翻訳できないSLPテンプレート特性がオブジェクトクラス定義のDESCフィールドに挿入されるという条約を確立します。アイテムは空の線（2つの「ラインフィード」文字で構成される）で区切られ、前にラインフィード文字が付いており、それらが表すものを示すためにラインの先頭にタグ付けされます。これにより、コメントを適切に解析することにより、テンプレートをスキーマから再構築できます。
The bulk of an SLP template consists of attribute definitions. There are four items in an SLP template attribute definition that need to be mapped into LDAP:
SLPテンプレートの大部分は、属性定義で構成されています。LDAPにマッピングする必要があるSLPテンプレート属性定義には4つの項目があります。
Attribute Name - Since SLPv2 attribute names are defined to be compatible with LDAPv3, SLP attributes map directly into LDAP attributes with no change. Similarly, LDAP attributes map directly to SLP attributes.
属性名 - SLPV2属性名はLDAPV3と互換性があると定義されるため、SLP属性は変更なしでLDAP属性に直接マップします。同様に、LDAP属性はSLP属性に直接マップします。
Attribute Type - The SLP attribute type is mapped into the LDAP attribute type.
属性タイプ-SLP属性タイプは、LDAP属性タイプにマッピングされます。
Attribute Flags - The SLP attribute flags are mapped into characteristics of the LDAP attribute definition, or into the DESC field if no equivalent LDAP attribute definition characteristic occurs.
属性フラグ-SLP属性フラグは、LDAP属性定義の特性にマッピングされ、同等のLDAP属性定義特性が発生しない場合はDESCフィールドにマッピングされます。
Default and Allowed Values - These must be handled by the client or a DA enabled to handle templates, as in SLP. For reference, however, they should be included in the DESC field of the LDAP attribute definition.
デフォルトと許可された値 - これらは、SLPのように、クライアントまたはテンプレートを処理できるDA対応によって処理する必要があります。ただし、参照のために、LDAP属性定義のDESCフィールドに含める必要があります。
Descriptive Text - The SLP template descriptive text should be mapped into the DESC field.
記述テキスト-SLPテンプレートの説明テキストは、DESCフィールドにマッピングする必要があります。
We discuss mapping of types, flags, default and allowed values, and descriptive text in the subsections below.
以下のサブセクションで、タイプ、フラグ、デフォルト、許可された値、および説明的なテキストのマッピングについて説明します。
OIDs for SLP template conversion schema elements are standardized under the enterprise number of SrvLoc.Org (6252) [18].
SLPテンプレート変換スキーマ要素のOIDは、srvloc.org（6252）[18]のエンタープライズ数の下で標準化されています。
For purposes of representing an SLP entry, we also define two standardized LDAP syntaxes and attributes with standardized OIDs.
SLPエントリを表す目的で、標準化されたOIDを使用して、2つの標準化されたLDAP構文と属性も定義します。
( 1.3.6.1.4.1.6252.2.27.6.2.2 DESC 'SLP Service Type' )
（1.3.6.1.4.1.6252.2.27.6.2.2 DESC 'SLPサービスタイプ'）
Defines the syntax for the service type name. The syntax is defined in the BNF for the service URL in RFC 2609 Section 2.1 [1].
サービスタイプ名の構文を定義します。構文は、RFC 2609セクション2.1 [1]のサービスURLのBNFで定義されています。
( 1.3.6.1.4.1.6252.2.27.6.2.3 DESC 'SLP Scope' )
（1.3.6.1.4.1.6252.2.27.6.2.3 DESC 'SLPスコープ'）
Defines the syntax for the scope name. The syntax is defined in the BNF for scope names in RFC 2608 Section 6.4.1 [5].
スコープ名の構文を定義します。構文は、RFC 2608セクション6.4.1 [5]のスコープ名のBNFで定義されています。
( 1.3.6.1.4.1.6252.2.27.6.1.4 NAME 'service-advert-service-type' DESC 'The service type of the service advertisement, including the "service:" prefix.' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.6252.2.27.6.2.2 SINGLE-VALUE )
（1.3.6.1.4.1.6252.2.27.6.1.4 Name 'Service-Advert-Service-Service-Service-Service-Sc' ''サービス広告のサービスタイプ「サービス：」を含むサービス広告 '' equality caseexactia5match Syntax 1.3.6.1.4.1。6252.2.27.6.2.2単一価値）
Defines an attribute for the service type name.
サービスタイプ名の属性を定義します。
( 1.3.6.1.4.1.6252.2.27.6.1.5 NAME 'service-advert-scopes' DESC 'A list of scopes for a service advertisement.' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.6252.2.27.6.2.3 )
（1.3.6.1.4.1.6252.2.27.6.1.5 Name 'Service-Advert-Scopes' Desc 'サービス広告のスコープのリスト。
Defines a multivalued attribute for the scopes.
スコープの多価属性を定義します。
Searches for abstract types can be made with an LDAP query that wildcards the concrete type. For example, a search for all service advertisements of the printer abstract type can be made with the following query:
抽象タイプの検索は、コンクリートタイプをワイルドカードするLDAPクエリで作成できます。たとえば、プリンターの抽象タイプのすべてのサービス広告の検索は、次のクエリで作成できます。
(service-advert-service-type=service:printer:*)
SLP specifies that service URLs and attribute lists can be accompanied by a structured authenticator consisting of a digital signature and information necessary to verify the signature. A syntax and two standardized SLP attributes are defined for this purpose:
SLPは、サービスURLと属性リストには、署名を検証するために必要なデジタル署名と情報で構成される構造化された認証器を添付できることを指定します。この目的のために、構文と2つの標準化されたSLP属性が定義されています。
( 1.3.6.1.4.1.6252.2.27.6.2.3 DESC 'SLP Authenticator')
（1.3.6.1.4.1.6252.2.27.6.2.3 DESC 'SLP Authenticator'）
The syntax of an SLP authenticator is the bytes of the authenticator in network byte order, see RFC 2608, Section 9.2 [5].
SLP認証器の構文は、ネットワークバイトの順序で認証器のバイトです。RFC2608、セクション9.2 [5]を参照してください。
( 1.3.6.1.4.1.6252.2.27.6.1.6 NAME 'service-advert-url-authenticator' DESC 'The authenticator for the URL, null if none.' SYNTAX 1.3.6.1.4.1.6252.2.27.6.2.3 SINGLE-VALUE )
（1.3.6.1.4.1.6252.2.27.6.1.6 Name 'Service-Advert-Url-Authenticator' Desc 'URLの認証機、null' none。））
This attribute contains the SLP URL authenticator, as defined in RFC 2608, Section 9.2 [5].
この属性には、RFC 2608、セクション9.2 [5]で定義されているSLP URL認証器が含まれています。
( 1.3.6.1.4.1.6252.2.27.6.1.7 NAME 'service-advert-attribute-authenticator' DESC 'The authenticator for the attribute list, null if none.' SYNTAX 1.3.6.1.4.1.6252.2.27.6.2.3 SINGLE_VALUE )
（1.3.6.1.4.1.6252.2.27.6.1.7 Name 'Service-Advert-Attribute-Authenticator' Desc '属性リストの認証者、null if none。
This attribute contains the SLP attribute authenticator, as defined in RFC 2608, Section 9.2 [5].
この属性には、RFC 2608、セクション9.2 [5]で定義されているSLP属性認証器が含まれています。
We define the mapping from SLP attribute types to LDAP as follows:
次のように、SLP属性のタイプからLDAPへのマッピングを定義します。
SLP Type ASN.1 Type LDAP Type
---------------------------------------------------
Integer INTEGER INTEGER
String DirectoryString Directory String
Boolean BOOLEAN Boolean
Opaque OCTET STRING Octet String
Keyword (N/A) IA5 String
The following subsections discuss further details of the mapping.
次のサブセクションでは、マッピングの詳細について説明します。
SLP integers compare as integers when performing a query. LDAP integers behave similarly. Consequently, the mapping from the SLP integer type to LDAP is INTEGER, with the integerMatch matching rule.
SLP整数は、クエリを実行するときに整数と比較します。LDAP整数も同様に動作します。その結果、SLP整数型からLDAPへのマッピングは整数であり、Integermatchはルールを一致させます。
SLP strings are encoded as described in the SLP protocol specification [5]. All value strings are considered case insensitive for matching operations. SLP strings are not null terminated and are encoded in UTF-8.
SLP文字列は、SLPプロトコル仕様[5]で説明されているようにエンコードされます。すべてのバリュー文字列は、一致する操作に対して症例が鈍感であると見なされます。SLP文字列はヌル終端ではなく、UTF-8でエンコードされています。
SLP strings are mapped to the LDAP Directory String type. The Directory String type exactly matches the SLP string type, i.e. it is a non-null terminated UTF-8 string. The caseIgnoreMatch equality rule, caseIgnoreOrderingMatch ordering rule, and caseIgnoreSubstringsMatch substring rule are used for comparing string attribute values.
SLP文字列は、LDAPディレクトリ文字列タイプにマッピングされます。ディレクトリ文字列タイプは、SLP文字列タイプ、つまり非ヌル終端UTF-8文字列と正確に一致します。caseignorematch equalityルール、caseignoreordingmatchの順序付けルール、およびcaseignoreorouresubstringsmatchサブストリングルールは、文字列属性値を比較するために使用されます。
Boolean attributes may have one of two possible values. In SLP, these values are represented as strings, TRUE and FALSE. In SLP's string encoding of a boolean value, case does not matter.
ブール属性には、2つの可能な値のいずれかがあります。SLPでは、これらの値は文字列として表されます。ブール値のSLPの文字列エンコードでは、ケースは問題ではありません。
The SLP Boolean type maps directly into an LDAP BOOLEAN. The caseIgnoreMatch rule is used for equality matching.
SLPブールタイプは、LDAPブール波に直接マップします。caseignorematchルールは、平等マッチングに使用されます。
SLP attribute values of type Opaque are represented as OCTET STRING in LDAP, and the octetStringMatch matching rule is used to compare them.
タイプ不透明のSLP属性値は、LDAPのOctet Stringとして表され、OctetStringMatchマッチングルールを使用してそれらを比較します。
SLP service type templates allow the definition of keyword attributes. Keyword attributes are attributes whose only characteristic is their presence. Keyword attributes have no flag information, nor any default or allowed values (since, by definition, they have no values).
SLPサービスタイプテンプレートにより、キーワード属性の定義が可能になります。キーワード属性は、その存在が唯一の特徴である属性です。キーワード属性には、フラグ情報もデフォルトまたは許可された値もありません（定義上、値がないため）。
ASN.1 has no concept of keyword attributes. Keyword attributes are translated into a "May" clause in the ASN.1 class definition for the service type. If the keyword attribute is present, then its value is of no consequence, but for consistency we make it simply the NUL character, "\00".
ASN.1には、キーワード属性の概念はありません。キーワード属性は、サービスタイプのASN.1クラスの定義の「5月」節に変換されます。キーワード属性が存在する場合、その値は結果ではありませんが、一貫性のために、単にnul文字「\ 00」になります。
SLP template flags can be handled as described in the following subsections.
SLPテンプレートフラグは、以下のサブセクションで説明されているように処理できます。
Multi-valued attributes are defined in an SLP template using the one value. All values for a given attribute must be of the same type.
マルチ値属性は、1つの値を使用してSLPテンプレートで定義されます。特定の属性のすべての値は同じタイプでなければなりません。
LDAP attribute definitions require that a single valued attribute include the SINGLE-VALUE tag if the attribute is single valued. Otherwise, the attribute is assumed to be multivalued by default.
LDAP属性の定義では、単一の価値のある属性に、属性が単一の価値がある場合、単一値タグが含まれることが必要です。それ以外の場合、属性はデフォルトでマルチバリュームされていると想定されます。
SLP uses the 'O' flag to indicate an attribute may or may not be present. These optional attributes are defined using the "May" clause in the ASN.1 definition class definition for the service type. All other attributes must be defined as a "Must".
SLPは「O」フラグを使用して、属性が存在する場合と存在しない場合がある場合と表示されます。これらのオプションの属性は、サービスタイプのASN.1定義クラス定義の「5月」節を使用して定義されます。他のすべての属性は、「必須」として定義する必要があります。
ASN.1 does not have a mechanism to indicate that the values of an attribute may not be translated from one language to another, since ASN.1 schema are not typically translated. This flag is dropped when translating a template, but presence of the flag should be noted in the DESC field. It should be placed on a separate line and tagged with "Literal:" so the template can be reconstructed from the schema.
ASN.1は、属性の値をある言語から別の言語に翻訳しないことを示すメカニズムを持っていません。ASN.1スキーマは通常翻訳されていません。このフラグは、テンプレートを翻訳するときにドロップされますが、フラグの存在はDESCフィールドに注意する必要があります。別のラインに配置し、「リテラル：」でタグ付けする必要があります。したがって、テンプレートはスキーマから再構築できます。
The SLP template syntax uses a flag of 'X' to indicate that an attribute must be present in order for the query to be properly satisfied. There is no provision for requiring that particular attributes be in a query. Consequently, this flag is dropped when translating a template, but presence of the flag should be noted in the DESC field. It should be placed on a separate line and tagged with "Explicit:" so the template can be reconstructed from the schema.
SLPテンプレート構文は、「X」のフラグを使用して、クエリが適切に満たされるために属性が存在する必要があることを示します。特定の属性がクエリにあることを要求する規定はありません。したがって、このフラグはテンプレートを翻訳するときにドロップされますが、Flagの存在はDESCフィールドに注意する必要があります。別のラインに配置し、「明示的：」でタグ付けする必要があります。したがって、テンプレートはスキーマから再構築できます。
The SLP template grammar provides the capability to define default and allowed values for an attribute. The SLP protocol does not enforce these restrictions on registered attributes, however. The default and allowed values may be used by client side applications, or alternatively it may also be used by DAs to initialize registrations having no attributes and to limit attribute values to the template allowed values.
SLPテンプレート文法は、属性のデフォルト値と許可された値を定義する機能を提供します。ただし、SLPプロトコルは、登録属性に対するこれらの制限を強制しません。デフォルト値と許可された値は、クライアント側のアプリケーションで使用される場合があります。あるいは、DASが属性を持たない登録を初期化し、テンプレート許可値に属性値を制限するために使用する場合もあります。
LDAP servers also do not support default and allowed values on attributes. Therefore, enforcement of default and allowed values in SLP templates is left up to the clients or a DA, if the DA is backending into LDAP. The default and allowed values should be included in the DESC field. The comments should be placed on separate lines and labeled with the "Default:" and "Allowed:" tags to allow reconstruction of the template.
LDAPサーバーは、デフォルトをサポートせず、属性の値を許可します。したがって、DAがLDAPに戻っている場合、SLPテンプレートのデフォルト値と許可された値の施行は、クライアントまたはDAに任されます。デフォルト値と許可された値は、DESCフィールドに含める必要があります。コメントは別々の行に配置し、「デフォルト：」と「許可：」というラベルを付けて、テンプレートの再構築を可能にします。
The descriptive text associated with an attribute definition should be included in the DESC field. It should start on a separate line and begin with the "Description:" tag.
属性定義に関連付けられた記述テキストは、DESCフィールドに含める必要があります。別の行で開始し、「説明：」タグから始めます。
LDAP attributes require an OID. In general, there is no a priori way that an algorithm can be defined for generating OIDs, because it will depend on the conventions used by the organization developing the template. In some cases, an organization's procedure for generating OIDs may be regular enough that a template developer can algorithmically generate OIDs off of an assigned root. Whatever means is used, the template developer should assure that unique OIDs are assigned to each SLP attribute that is translated into an LDAP attribute.
LDAP属性にはOIDが必要です。一般に、テンプレートを開発する組織が使用する規則に依存するため、OIDを生成するためにアルゴリズムを定義できるアプリオリの方法はありません。場合によっては、OIDを生成するための組織の手順は、テンプレート開発者が割り当てられたルートからOIDをアルゴリズム的に生成できるほど十分に規則的である場合があります。どんな手段でも、テンプレート開発者は、LDAP属性に翻訳される各SLP属性に一意のOIDが割り当てられることを保証する必要があります。
The template included below is a hypothetical abstract printer service template, similar to that described in [10].
以下に含まれるテンプレートは、[10]に記載されているものと同様の仮想抽象プリンターサービステンプレートです。
template-type = printer
template-version = 0.0
テンプレートversion = 0.0
template-description = The printer service template describes the attributes supported by network printing devices. Devices may be either directly connected to a network, or connected to a printer spooler that understands the a network queuing protocol such as IPP, lpr or the Salutation Architecture.
Template-description =プリンターサービステンプレートは、ネットワーク印刷デバイスによってサポートされる属性を説明します。デバイスは、ネットワークに直接接続されているか、IPP、LPR、SalutationアーキテクチャなどのAネットワークキューイングプロトコルを理解しているプリンタースプーラーに接続されている場合があります。
template-url-syntax = ;The URL syntax is specific to the printing protocol being ;employed
Template-url-syntax =; URL構文は、印刷プロトコルに固有のものです。
description = STRING # This attribute is a free form string that can contain any # site-specific descriptive information about this printer.
説明=文字列＃この属性は、このプリンターに関する＃サイト固有の説明情報を含めることができるフリーフォーム文字列です。
printer-security-mechanisms-supported = STRING L M none # This attribute indicates the security mechanisms supported tls, ssl, http-basic, http-digest, none printer-operator = STRING O L M # A person, or persons responsible for maintaining a # printer on a day-to-day basis, including such tasks # as filling empty media trays, emptying full output # trays, replacing toner cartridges, clearing simple # paper jams, etc.
プリンターセキュリティメカニズム= Supported = string l m none＃この属性は、TLS、SSL、HTTP-BASIC、HTTP-Digest、None Printer-Operator = String O L M＃Aまたは＃Printerの維持を担当する人をサポートするセキュリティメカニズムを示します。空のメディアトレイの充填、フル出力＃トレイの空を空にする、トナーカートリッジの交換、単純な＃紙ジャムのクリアなど、そのようなタスク＃を含む日々のベースで。
printer-location-address = STRING O # Physical/Postal address for this device. Useful for # nailing down a group of printers in a very large corporate # network. For example: 960 Main Street, San Jose, CA 95130
Printer-Location-Address =文字列o＃このデバイスの物理的/郵便アドレス。非常に大規模なコーポレート＃ネットワークでプリンターのグループを釘付けにするのに役立ちます。例：960メインストリート、カリフォルニア州サンノゼ95130
printer-priority-queue = BOOLEAN O FALSE # TRUE indicates this printer or print queue is a priority # queuing device.
Printer-Priority-Queue = boolean o false＃trueは、このプリンターまたは印刷キューが優先＃キューイングデバイスであることを示しています。
printer-number-up = INTEGER O 1 # This job attribute specifies the number of source # page-images to impose upon a single side of an instance # of a selected medium. 1, 2, 4
プリンター番号= integer o 1＃このジョブ属性は、選択したメディアのインスタンス＃の片側に課すソース＃ページイメージの数を指定します。1、2、4
printer-paper-output = STRING M L O standard # This attribute describes the mode in which pages output # are arranged.
Printer-Paper-Output = String M L O Standard＃この属性は、ページ出力＃が配置されるモードを説明します。
standard, noncollated sort, collated sort, stack, unknown
標準、非カルティングソート、照合されたソート、スタック、不明
We assume that the concrete type "service:printer:lpr" for printers that speak the LPR protocol [4] has the following template definition:
LPRプロトコル[4]を話すプリンターのコンクリートタイプ「サービス：プリンター：LPR」には、次のテンプレート定義があると想定しています。
template-type = printer:lpr
Template-Type = Printer：LPR
template-version = 0.0
テンプレートversion = 0.0
template-description = The printer:lpr service template describes the attributes supported by network printing devices that speak the LPR protocol. No new attributes are included.
Template-description = Printer：LPR Serviceテンプレートは、LPRプロトコルを話すネットワーク印刷デバイスによってサポートされる属性を説明します。新しい属性は含まれていません。
template-url-syntax = queue queue = ;The queue name, see RFC 1179.
Template-url-syntax = queue queue =;キュー名、RFC 1179を参照してください。
The LDAP class definition for the "service:printer:lpr" concrete service type is translated as follows:
「サービス：プリンター：LPR」コンクリートサービスタイプのLDAPクラスの定義は、次のように翻訳されます。
( ---place the assigned OID here--- NAME 'service-printer-lpr' DESC 'Description: The printer:lpr service template describes the attributes supported by network printing devices that speak the LPR protocol. No new attributes are included.
（---割り当てられたOIDをここに配置します---名前 'Service-Printer-LPR' DESC '説明：プリンター：LPRサービステンプレートは、LPRプロトコルを話すネットワーク印刷デバイスによってサポートされる属性を説明します。新しい属性は含まれていません。
URL Syntax: queue queue = ;The queue name, see RFC 1179.' SUP slpService MUST ( description $ security-mechanisms-supported $ labeledURI) MAY ( operator $ location-address $ priority-queue $ number-up $ paper-output) )
URL構文：キューキュー=;キュー名、RFC1179を参照してください。sup slpservice（説明$ security-mechanisms-supported $ labeleduri）5月（オペレーター$ location-address $ priority-queue $ number-up $ paper-output））））））
The attribute definitions are translated as follows:
属性の定義は次のように翻訳されます。
( ---place the assigned OID here--- NAME 'printer-security-mechanisms-supported' DESC 'Description: This attribute indicates the security mechanisms supported.
（---割り当てられたOIDをここに配置します---名前 'プリンターセキュリティメカニズムがサポートする「DESC」説明：この属性は、サポートされているセキュリティメカニズムを示します。
Default: value
デフォルト：値
Allowed: tls, ssl, http-basic, http-digest, none
許可：TLS、SSL、HTTP-BASIC、HTTP-DIGEST、なし
Literal:' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
リテラル： 'caseignorematch caseignore -orderingmatch substr caseignoresubstringsmatchの構文を注文するcaseignore -orderingmatch syntax 1.3.6.1.4.1.146.115.121.1.15）
( ---place the assigned OID here--- NAME 'printer-operator' DESC 'Description: A person, or persons responsible for maintaining a printer on a day-to-day basis, including such tasks as filling empty media trays, emptying full output trays, replacing toner cartridges, clearing simple paper jams, etc.
（---ここに割り当てられたOIDを配置します---名前「プリンターオペレーター」DESC '説明：人、または空のメディアトレイを埋めるなどのタスクを含む、日々のベースでプリンターを維持する責任者の人、またはフル出力トレイを空にし、トナーカートリッジの交換、簡単な紙ジャムなど。
Literal:' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
リテラル： 'caseignorematch caseignore -orderingmatch substr caseignoresubstringsmatchの構文を注文するcaseignore -orderingmatch syntax 1.3.6.1.4.1.146.115.121.1.15）
( --place the assigned OID here--- NAME 'printer-location-address' DESC 'Description Physical/Postal address for this device. Useful for nailing down a group of printers in a very large corporate network. For example: 960 Main Street, San Jose, CA 95130.' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
（ - ここに割り当てられたOIDを配置します---名前「プリンターロケーション - アドレス「DESC」説明このデバイスの物理/郵便アドレス。非常に大きなコーポレートネットワークのプリンターのグループを釘付けにするのに役立ちます。たとえば：960 MainStreet、San Jose、CA95130。
( ---place the assigned OID here--- NAME 'printer-priority-queue' DESC 'Description: TRUE indicates this printer or print queue is a priority queuing device.' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )
（---割り当てられたOIDをここに配置します---名前「プリンター - プリンター - プリフリティ」「DESC」説明：trueこのプリンターまたは印刷キューは優先キューイングデバイスであることを示します。.7単一価値）
( ---place the assigned OID here--- NAME 'printer-number-up' DESC 'Description: This job attribute specifies the number of source page-images to impose upon a single side of an instance of a selected medium. This attribute is INTEGER.
（---ここに割り当てられたoidを配置します---名前「プリンター番号」desc '説明：このジョブ属性は、選択したメディアのインスタンスの片側に課すソースページイメージの数を指定します。属性は整数です。
Default: 1
デフォルト：1
Allowed: 1, 2, 3, 4' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) ( ---place the assigned OID here--- NAME 'printer-paper-output' DESC 'Description: This attribute describes the mode in which pages output are arranged. Default value is standard.
許可：1、2、3、4 'equality Integermatch Syntax 1.3.6.1.4.1.1466.115.121.1.27単一価値）説明：この属性は、ページ出力が配置されるモードを記述します。デフォルト値は標準です。
Default: standard
デフォルト：標準
Allowed: standard, noncollated sort, collated sort, stack, unknown. Literal:' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
許可：標準、非カル化されたソート、照合並べ替え、スタック、不明。リテラル： 'caseignorematch caseignore -orderingmatch substr caseignoresubstringsmatchの構文を注文するcaseignore -orderingmatch syntax 1.3.6.1.4.1.146.115.121.1.15）
LDAP has a flat name space, and attribute names and OIDs must be unique in a directory server. In order to avoid name conflicts in the translation of SLP templates to LDAP schemas, template developers may want to consider prepending the name of the service type to the attribute. Postprocessing attribute names to make them unique when translated is not possible, because it would require the DA to rewrite queries before submitting them to the directory server. In addition, developers should use standard LDAP attributes when such attributes are available.
LDAPにはフラット名スペースがあり、属性名とOIDはディレクトリサーバーで一意でなければなりません。SLPテンプレートのLDAPスキーマへの翻訳における名前の競合を回避するために、テンプレート開発者は、サービスタイプの名前を属性に準備することを検討することをお勧めします。DAがディレクトリサーバーに送信する前にクエリを書き換える必要があるため、翻訳されたときに一意にするために属性をポストプロセスする属性名が不可能です。さらに、開発者は、そのような属性が利用可能な場合は、標準のLDAP属性を使用する必要があります。
In the above example template, the abstract type name "printer" is prepended to attributes to avoid conflicts. The standard "description" attribute defined by X.520 [3] is used to translate the template description attribute.
上記の例テンプレートでは、抽象タイプ名「プリンター」は、競合を回避するための属性に加えられています。X.520 [3]で定義された標準の「説明」属性は、テンプレートの説明属性を変換するために使用されます。
The reverse mapping from LDAP schema to SLP service type templates requires dealing with both LDAP and ASN.1 data types. RFC 2252 defines 33 attribute syntaxes that should be supported by LDAP directory servers. These syntaxes are defined using BNF for strings or using ASN.1 for binary valued attributes defined by X.520.
LDAPスキーマからSLPサービスタイプまでの逆マッピングには、LDAPとASN.1の両方のデータ型を扱う必要があります。RFC 2252は、LDAPディレクトリサーバーによってサポートされる必要のある33の属性構文を定義します。これらの構文は、文字列にBNFを使用して、またはX.520で定義されたバイナリの価値属性に対してasn.1を使用して定義されます。
Mapping of the LDAP data types into SLP template types is fairly straightforward, but mapping arbitrary ASN.1 data types is somewhat more complicated and requires encoding the ASN.1 data type into a string. To a certain extent, this masks the ASN.1 data type because it becomes impossible to distinguish between a native string having content equivalent to an encoded ASN.1 string. However, inclusion of the ASN.1 data type in the comment provides additional information should a reverse transformation from SLP to ASN.1 be required.
LDAPデータ型のSLPテンプレートタイプへのマッピングはかなり簡単ですが、任意のASN.1データ型のマッピングはやや複雑であり、asn.1データ型を文字列にエンコードする必要があります。ある程度、これは、エンコードされたASN.1文字列に相当するコンテンツを持つネイティブ文字列を区別することが不可能になるため、ASN.1データ型をマスクします。ただし、コメントにasn.1データ型を含めると、SLPからasn.1への逆変換が必要な場合、追加情報が提供されます。
The following subsections deal with both LDAP and ASN.1 attribute data type mappings.
次のサブセクションでは、LDAPとASN.1属性データ型マッピングの両方を扱います。
The following table contains the mappings for LDAP syntaxes to SLP data types:
次の表には、LDAP構文のマッピングがSLPデータ型に含まれています。
LDAP Type SLP Type
--------------------------------------------------------
ACI Item NA
Access Point NA
Attribute Type Description NA
Audio Opaque
Binary ASN.1 escape
Bit String String
Boolean Boolean
Certificate Opaque
Certificate List Opaque
Certificate Pair Opaque
Country String String
DN String
Data Quality Syntax NA
Delivery Method NA
Directory String String
DIT Content Rule Description NA
DIT Structure Rule Description NA
DL Submit Permission NA
DSA Quality Syntax NA
Enhanced Guide NA
Facsimile Telephone Number String
Fax Opaque
Generalized Time String
Guide NA
IA5 String String
INTEGER Integer
JPEG Opaque
LDAP Syntax Description NA
LDAP Schema Definition NA
LDAP Schema Description NA
Master and Shadow Access Points NA
Matching Rule Description NA
Matching Rule Use Description NA
Mail Preference NA
MHS OR Address String
Modify Rights NA
Name and Optional UID NA
Name Form Description NA
Numeric String String
Object Class Description NA
Octet String Opaque
OID String
Other Mailbox String
Postal Address String
Protocol Information NA
Presentation Address String
Printable String String
Substring Assertion NA
Subtree Specification NA
Supplier Information NA
Supplier or Consumer NA
Supplier And Consumer NA
Supported Algorithm NA
DSE Type NA
Telephone Number String
Teletex Terminal Identifier String
Telex Number String
UTC Time String
ASN.1 employs a much richer set of data types than provided by SLP. The table below show the mapping of selected ASN.1 data type to their nearest SLP equivalent. Because of the complexity and flexibility of ASN.1, a complete list cannot be provided.
ASN.1は、SLPによって提供されるよりもはるかに豊富なデータ型セットを採用しています。以下の表は、選択したASN.1データ型の最寄りのSLP等価物へのマッピングを示しています。ASN.1の複雑さと柔軟性のため、完全なリストを提供することはできません。
As sample of some ASN.1 encodings and their mappings to SLP:
いくつかのasn.1エンコーディングとそのマッピングのSLPへのサンプルとして：
ASN.1 type SLP type
-----------------------------------------
INTEGER Integer
BOOLEAN Boolean
ENUMERATED String
OBJECT IDENTIFIER String
OCTET STRING Opaque
REAL String
Data types that do not map directly to SLP data types should be defined as either a String, or as Opaque. ASN.1 types that may only contain valid characters for Strings, as defined in X.680 [9] should be encoded as strings. ASN.1 types such as GraphicString that change their character set encoding in part way through a value should not be encoded as strings, however, If such types are required, the SLP Opaque type should be used. In either case, the first line of the help text is used to indicate the original ASN.1 data type.
SLPデータ型に直接マッピングしないデータ型は、文字列または不透明として定義する必要があります。x.680 [9]で定義されているように、文字列の有効な文字のみを含む可能性のあるASN.1タイプは、文字列としてエンコードする必要があります。asn.1のasn.1タイプは、値を部分的にエンコードする文字セットを変更するGraphicStringなど、文字列としてエンコードする必要はありませんが、そのようなタイプが必要な場合は、SLP不透明なタイプを使用する必要があります。どちらの場合でも、ヘルプテキストの最初の行を使用して、元のasn.1データ型を示すために使用されます。
The following subsections describe how to convert from the ASN.1 BER [9] to the SLP template for the different types in the table above.
次のサブセクションでは、上記のテーブルのさまざまなタイプのASN.1 BER [9]からSLPテンプレートに変換する方法について説明します。
Both SLP templates and ASN.1 support Integers, so there is a one to one mapping between an SLP Integer attribute and an ASN.1 Integer attribute. Details on the encoding of integers is summarized in the SLP template to ASN.1 section above.
SLPテンプレートとASN.1の両方が整数をサポートするため、SLP整数属性とASN.1整数属性の間に1対1のマッピングがあります。整数のエンコーディングの詳細は、上記のSLPテンプレートからASN.1セクションに要約されています。
Boolean values are supported by both SLP and ASN.1, though on wire encodings differ. X.680 [9] specifies zero and non-zero encoding for booleans, where SLP encodes booleans using the strings TRUE and FALSE. In general, most LDAP servers will use the LDAP Boolean type (which is a string), so again the ASN.1 type should be recorded in the comment or it will be lost.
ブール値はSLPとASN.1の両方でサポートされていますが、ワイヤーエンコーディングでは異なります。X.680 [9]は、ゼロと非ゼロのエンコーディングをブリアンと指定します。ここで、SLPは文字列を真と偽を使用してブリアンをエンコードします。一般に、ほとんどのLDAPサーバーはLDAPブール型タイプ（文字列です）を使用するため、コメントにASN.1タイプを記録するか、失われます。
SLP templates support the concept of enumerations through the listing of allowed values in the attribute definition. These enumerations are not strictly binding on clients or DAs, but they are similar to the ASN.1 definition of enumerations. BER encodes the ASN.1 enumeration by passing the number of the element's position in the enumeration. This requires both sides to have knowledge of the specific enumeration prior to decoding an enumeration's value. SLP provides no specific support for transmitting enumerations. They are simply String types. Information on the ASN.1 type and ASN.1 encoding of the enumeration values is recorded in the comment.
SLPテンプレートは、属性定義の許可値のリストを通じて列挙の概念をサポートしています。これらの列挙は、クライアントやDASを厳密に拘束するものではありませんが、列挙の定義に似ています。BERは、列挙における要素の位置の数を渡すことにより、ASN.1列挙をエンコードします。これには、列挙の価値を解読する前に、双方が特定の列挙の知識を持つ必要があります。SLPは、列挙の送信に関する特定のサポートを提供しません。それらは単に文字列タイプです。ASN.1タイプとasn.1列挙値のエンコードに関する情報は、コメントに記録されています。
Example:
例：
color-supported = STRING M
none
# ASN.1: Enumeration.
# ASN.1 Mapping: none = 0, highlight = 1, three color = 2,
# four color = 4, monochromatic = 5
#This attribute specifies whether the Printer supports
# color and, if so, what type.
none,highlight,three color,four color,monochromatic
Object identifiers(OIDs) are commonly used in the ASN.1 world to identify object and attributes. OIDs are a numerical representation of an element's place in the naming hierarchy. Each element at a particular level of a hierarchy has a unique number assigned within that level of the hierarchy. A sample OID would be the naming tree for SNMP MIBs: iso(1) org(3) dod(6) internet(1) mgmt(2) mib(1) would be written as the string "1.3.6.1.2.1".
オブジェクト識別子（OID）は、オブジェクトと属性を識別するためにASN.1世界で一般的に使用されます。OIDは、命名階層内の要素の場所の数値表現です。階層の特定のレベルの各要素には、そのレベルの階層内に割り当てられた一意の数字があります。サンプルOIDは、SNMP MIBSの命名ツリーです。ISO（1）org（3）dod（6）インターネット（1）mgmt（2）mib（1）は、文字列「1.3.6.1.2.1」として記述されます。
Because this representation reduces down to a string of dot separated numbers, this maps easily to the SLP String type. The help text for this element should indicate it is an ASN.1 OID
この表現は、一連のドット分離数に減少するため、このマップはSLP文字列型に簡単にマップします。この要素のヘルプテキストは、それがasn.1 oidであることを示す必要があります
identifier = STRING # ASN.1: OID # The object identifier for this SNMP agent.
識別子=文字列＃asn.1：oid＃このSNMPエージェントのオブジェクト識別子。
An ASN.1 octet string should be mapped to an Opaque in an SLP template. An octet string is a sequence of bytes, whereas an Opaque is a a string that encodes a sequence of bytes. Again, the ASN.1 type is lost unless recorded in the comment.
ASN.1オクテット文字列は、SLPテンプレートの不透明にマッピングする必要があります。オクテット文字列はバイトのシーケンスですが、不透明はバイトのシーケンスをコードする文字列です。繰り返しますが、コメントに記録されない限り、ASN.1タイプは失われます。
There is no direct mapping between floating point numbers and any SLP data types. Attributes having the ASN.1 type of Real are mapped to SLP type String. Comments are added to the attribute help text indicating the value was originally an ASN.1 real. For example:
フローティングポイント番号とSLPデータ型の間に直接マッピングはありません。ASN.1タイプのREALを持つ属性は、SLPタイプの文字列にマッピングされます。コメントは、値が元々ASN.1 REALであったことを示す属性ヘルプテキストに追加されます。例えば：
weight = STRING # ASN.1: Real # The objects weight in pounds.
Weight = String＃ASN.1：REAL＃オブジェクトの重量はポンドで。
The following is an example schema for an exported filesystem. The section presents it as in ASN.1 and the following section shows the SLP template translation. The template translation does not capture the actual attribute format for the Set type, that would be done in the LDAP client software making the translation. Note that even though the class definition does not conform with the previously defined conventions for SLP classes, the schema can still be translated into an SLP template. The syntax used in this example follows
以下は、エクスポートされたファイルシステムのスキーマの例です。このセクションでは、ASN.1と同様に説明し、次のセクションではSLPテンプレートの翻訳を示しています。テンプレート変換は、翻訳を作成するLDAPクライアントソフトウェアで行われるセットタイプの実際の属性形式をキャプチャしません。クラスの定義は、以前に定義されたSLPクラスの規則に準拠していない場合でも、スキーマをSLPテンプレートに翻訳できることに注意してください。この例で使用される構文は次のとおりです
-- Abstraction of a fstab entry (a "mount").
-- These lookups would likely be performed by an
-- an automounter type application.
mount OBJECT-CLASS ::= {
SUBCLASS OF { top }
MUST CONTAIN { mountHost |
mountDirectory |
mountType
}
MAY CONTAIN { mountOption |
mountDumpFrequency |
mountPassNo
}
ID { <oid1> }
}
- The mount host. mountHost ATTRIBUTE ::= { WITH SYNTAX caseIgnoreString EQUALITY MATCHING RULE caseIgnoreMatch SINGLE VALUE ID { <oid2> } }
- マウントホスト。mounthost属性:: = {構文caseignorestring等式マッチングルールcaseignorematchシングル値id {<oid2>}}}
- The file system to mount. mountDirectory ATTRIBUTE ::= { WITH SYNTAX caseIgnoreString EQUALITY MATCHING RULE caseIgnoreMatch SINGLE VALUE ID { <oid3> } }
- マウントするファイルシステム。MountDirectory属性:: = {構文caseignorestring equalityマッチングルールcaseignorematchシングル値id {<oid3>}}}
- The type of file system being mounted. mountType ATTRIBUTE ::= { WITH SYNTAX INTEGER { ufs(1), hsfs(2), nfs(3), rfs(4) } EQUALITY MATCHING RULE integerMatch SINGLE VALUE ID { <oid4> } }
- マウントされるファイルシステムのタイプ。mountType属性:: = {syntax integer {ufs（1）、hsfs（2）、nfs（3）、rfs（4）} equalityマッチングルールintegermatchシングル値id {<oid4>}}}
- Options for the mount operation. mountOption ATTRIBUTE ::= { WITH SYNTAX caseIgnoreString EQUALITY MATCHING RULE caseIgnoreString ID { <oid5> } }
- マウント操作のオプション。mountoption属性:: = {構文caseignorestring equalityマッチングルールcaseignorestring id {<oid5>}}
- How often to dump the file system. mountDumpFrequency ATTRIBUTE :: = { WITH SYNTAX INTEGER (0..9) EQUALITY MATCHING RULE integerMatch SINGLE VALUE ID { <oid6> } }
- ファイルシステムをダンプする頻度。MountDumpFrequency属性:: = {Syntax Integer（0..9）等式マッチングルールIntegermatchシングル値ID {<oid6>}}}
- Boot time mount pass number. mountPassNo ATTRIBUTE ::= { WITH SYNTAX INTEGER EQUALITY MATCHING RULE integerMatch SINGLE VALUE ID { <oid7> } }
- ブートタイムマウントパス番号。MountPassno属性:: = {syntax integer equalityマッチングルールintegermatch単一値ID {<oid7>}}
The translated SLP template is:
翻訳されたSLPテンプレートは次のとおりです。
template-type = mount
template-version = 1.0
テンプレート-version = 1.0
template-description = "Describes a remote filesystem access protocol"
Template-description = "リモートファイルシステムアクセスプロトコルを説明する"
template-url-syntax =
filesystem = 1*[ DIGIT / ALPHA ]
urlpath = "/" filesystem
mountHost = STRING L # ASN.1: Case Ignore String, Single Value # The mount host
mounthost = string l＃asn.1：ケースは文字列、単一値＃マウントホストを無視します
mountDirectory = STRING L
# ASN.1: Case Ignore String, Single Value
# The filesystem to mount
mountType = STRING L
ufs
# ASN.1: Enumeration, Single Value
# ASN.1 Mapping: ufs = 1, hsfs = 2, nfs = 3, rfs = 4
# The type of the filesystem being mounted
ufs, hsfs, nfs, rfs
mountOption = STRING M O L # ASN.1: Case Ignore String # mount options for this filesystem
mountoption = string m o l＃asn.1：ケースはこのファイルシステムの文字列＃マウントオプションを無視します
mountDumpFrequency = INTEGER O 0 # ASN.1: Integer Range, Single Value # How often to dump this filesystem 0, 1, 2, 3, 4, 5, 6, 7, 8, 9
mountdumpfrequency = integer o 0＃asn.1：整数範囲、単一値＃このファイルシステムをダンプする頻度0、1、2、3、4、5、6、7、8、9
mountPassNo = INTEGER O # ASN.1: Integer, Single Value # Boot time mount pass number
MountPassno = integer o＃asn.1：整数、単一値＃ブートタイムマウントパス番号
In addition to translating between SLP templates and LDAP schema, another area requiring compatibility is the representation of SLP service advertisements in an LDAP DIT. A standardized representation for service information allows SLP DAs to store service advertisements in LDAP, and for LDAP clients to query the DIT for those services. Similarly, if LDAP clients represent service information in the same form, SLP clients can benefit from interoperability.
SLPテンプレートとLDAPスキーマ間の翻訳に加えて、互換性を必要とする別の領域は、LDAP DITでのSLPサービス広告の表現です。サービス情報の標準化された表現により、SLP DASはLDAPにサービス広告を保存し、LDAPクライアントがそれらのサービスのDITを照会することができます。同様に、LDAPクライアントが同じ形式でサービス情報を表している場合、SLPクライアントは相互運用性から利益を得ることができます。
A service advertisement contains the service URL in a 'labeledURI' attribute [11]. The labeledURI attribute in a service advertisement should only contain the service URL for the service, with no additional label. It is recommended that the labeledURI be used as the RDN for the service object in the DIT.
サービス広告には、「labeleduri」属性[11]のサービスURLが含まれています。Service AdvertisementのLabeleDuri属性には、追加のラベルがないサービス用のサービスURLのみを含める必要があります。LaveleduriをDITのサービスオブジェクトのRDNとして使用することをお勧めします。
Although service advertisements can appear anywhere within the DIT, it is recommended that all services be stored under a single common point, or root node, to facilitate searching in a domain. This allows a client to search for all of advertisements of a particular service type, say, for all printers. The recommended parent entry is one named "ou=service" below the entry which is the representation of the domain, as described in RFC 2247.
サービス広告はDIT内に表示される可能性がありますが、ドメインでの検索を容易にするために、すべてのサービスを単一の共通点またはルートノードの下に保存することをお勧めします。これにより、クライアントは、特定のサービスタイプのすべての広告、たとえばすべてのプリンターに対して検索できます。推奨される親エントリは、RFC 2247で説明されているように、ドメインの表現であるエントリの下にある「ou = service」という名前のものです。
For example, a printer service with labeledURI of "service:lpr://printsrv/queue1" in the domain foobar.com advertised in the LDAP server that holds the entry "dc=foobar,dc=com" tree has the following DN:
たとえば、「サービス：lpr：// printsrv/queue1」のlabeleduriを備えたプリンターサービスは、エントリを保持するLDAPサーバーで宣伝されているドメインfoobar.comのdc = foobar、dc = com "ツリーに次のdnを持っています。
"labeledURI=service:lpr://printsrv/queue1, ou=service, dc=foobar,
dc=com"
While this leads to a flat space of service storage, since SLP uses search filters from LDAP for searches, these filters can be used for one-level searches from the root node.
これにより、SLPは検索にLDAPの検索フィルターを使用するため、サービスストレージのフラットスペースにつながりますが、これらのフィルターはルートノードからの1レベルの検索に使用できます。
The following example illustrates how an advertisement having a simple service type is represented. The advertisement (in conceptual form) for a printer is:
次の例は、簡単なサービスタイプを持つ広告がどのように表されているかを示しています。プリンターの広告（概念的な形式）は次のとおりです。
Service Type: service:lpr://printsrv/queue1
Scopes: eng,corp
Attributes:
description = A general printer for all to use.
security-mechanisms-supported = none
Authentication: none
The RDN of the object is labeledURI=service:lpr://printsrv/queue1, and the following LDAP search filter will return this object, along with any others of the service type "service:lpr" that match the other attributes:
オブジェクトのrdnはlabeleduri = service：lpr：// printsrv/queue1であり、次のLDAP検索フィルターは、他の属性と一致するサービスタイプ「サービス：LPR」の他の任意のオブジェクトとともにこのオブジェクトを返します。
(&(service-advert-service-type=service:lpr)
(service-advert-scopes=eng)
(service-advert-scopes=corp)
(description=A general printer for all to use.)
(security-mechanisms-supported=none))
Service advertisements in SLP also have a lease time associated with them. In LDAP servers that support the extensions for dynamic directory services [12], the service advertisement entry objectClass should be extended with the dynamicObject class. This allows the service advertisement to time out within the LDAP directory server. If the LDAP directory server does not support the dynamic directory services extension, then advertisement lease timeouts must be handled by the SLP agent.
SLPのサービス広告には、それらに関連するリース時間もあります。動的ディレクトリサービスの拡張機能[12]をサポートするLDAPサーバーでは、Service Advertisement Entry ObjectClassをDynamicObjectクラスで拡張する必要があります。これにより、サービス広告はLDAPディレクトリサーバー内でタイムアウトできます。LDAPディレクトリサーバーが動的ディレクトリサービス拡張機能をサポートしていない場合、広告リースタイムアウトはSLPエージェントが処理する必要があります。
While the service advertisement schema outlined in this section is primarily for SLP DAs that use LDAP as a backing store, if LDAP agents register services using the same format, complete interoperability with SLP is achieved.
このセクションで概説されているサービス広告スキーマは、主にLDAPをバッキングストアとして使用するSLP DAS向けですが、LDAPエージェントが同じ形式を使用してサービスを登録する場合、SLPとの完全な相互運用性が達成されます。
SLP specifies that an RFC 1766 [13] language code accompanies every service advertisement. Language codes for service advertisements in LDAP must be represented according to RFC 2596 [14].
SLPは、RFC 1766 [13]言語コードがすべてのサービス広告に付随することを指定しています。LDAPのサービス広告の言語コードは、RFC 2596 [14]に従って表現する必要があります。
RFC 2596 prohibits language codes in DNs, and specifies that a directory server which does not support language codes must treat an attribute with a language code as an unrecognized attributes. According to RFC 2596, language codes are appended to attribute names with a semicolon (";"). For example, the following attribute/value pair is in the German locale:
RFC 2596はDNSの言語コードを禁止し、言語コードをサポートしていないディレクトリサーバーは、言語コードを使用して属性を認識されていない属性として扱う必要があることを指定します。RFC 2596によると、言語コードは、名前をSemicolon（ ";"）に属性に追加するように追加されます。たとえば、次の属性/値ペアはドイツのロケールにあります。
(address;lang-de=44 Bahnhofstrasse, 2365 Weibstadt, Deutschland)
（住所; lang-de = 44 Bahnhofstrasse、2365 Weibstadt、Deutschland）
An attribute with a language tag in a specific locale is considered a separate attribute from attributes in other locales.
特定のロケールに言語タグを持つ属性は、他のロケールの属性から個別の属性と見なされます。
If the service advertisement is in the default SLP locale ("en", no dialect), then the language code need not be appended to the attribute name.
サービス広告がデフォルトのSLPロケール（「en」、方言なし）にある場合、言語コードを属性名に追加する必要はありません。
SLP queries in locales other than the default need not be rewritten to include language tags before being submitted to the directory server. RFC 2596 specifies that all entries that match are returned, including those with language tags, without requiring the language tags to be explicitly present in the query. The SLP DA can then postprocess the result to select the entries from the required locale.
デフォルト以外のロケールのSLPクエリは、ディレクトリサーバーに送信する前に、言語タグを含めるように書き換える必要はありません。RFC 2596は、言語タグを含むものを含む一致するすべてのエントリがクエリに明示的に存在することを要求することなく、返されることを指定します。SLP DAは、結果をポストプロセスして、必要なロケールからエントリを選択できます。
SLP authenticators are stored with the service advertisement in the DIT, as discussed in Section~7ef{slpdit}. LDAP clients need to use LDAP authentication [15] to assure that they are connecting with a secure server. In particular, SLP DAs that use LDAP as a back end store and that implement SLP authentication MUST use LDAP authentication to assure that the LDAP entries for their service registrations are secure.
SLP認証器は、セクション〜7EF {SLPDIT}で説明されているように、DITのサービス広告とともに保存されます。LDAPクライアントは、LDAP認証[15]を使用して、安全なサーバーに接続していることを保証する必要があります。特に、LDAPをバックエンドストアとして使用し、SLP認証を実装するSLP DASは、LDAP認証を使用して、サービス登録のLDAPエントリが安全であることを保証する必要があります。
Acknowledgements
謝辞
Many thanks are due to Mark Wahl whose detailed and insightful comments were instrumental in helping improve the technical accuracy of this document with respect to LDAP.
Mark Wahlに感謝しています。MarkWahlの詳細で洞察に満ちたコメントは、LDAPに関するこのドキュメントの技術的正確性を改善するのに役立ちました。
[1] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and service: Schemes", RFC 2609, April 1999.
[1] Guttman、E.、Perkins、C。and J. Kempf、「サービステンプレートとサービス：スキーム」、RFC 2609、1999年4月。
[2] Wahl, W., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[2] Wahl、W.、Howes、T。およびS. Killee、「Lightweight Directory Access Protocol（V3）」、RFC 2251、1997年12月。
[3] International Telecommunications Union. The Directory:Selected Attribute Types. ITU Recommendation X.520. August, 1997.
[3] 国際電気通信連合。ディレクトリ：選択された属性タイプ。ITU推奨X.520。1997年8月。
[4] McLaughlin, L., "Line Printer Daemon Protocol, RFC 1179, August 1990.
[4] マクラフリン、L。、「ラインプリンターデーモンプロトコル、RFC 1179、1990年8月。
[5] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol Version 2", RFC 2608, April 1999.
[5] Guttman、E.、Perkins、C.、Veizades、J。、およびM. Day、「Service Location Protocolバージョン2」、RFC 2608、1999年4月。
[6] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[6] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 2234、1997年11月。
[7] Howes, T., "The String Representation of LDAP Search Filters", RFC 2254, December 1997.
[7] Howes、T。、「LDAP検索フィルターの文字列表現」、RFC 2254、1997年12月。
[8] Wahl, W., Coulbeck, A., Howe, T. and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definition", RFC 2252, December 1997.
[8] Wahl、W.、Coulbeck、A.、Howe、T。およびS. Kille、「Lightweight Directory Access Protocol（V3）：属性構文定義」、RFC 2252、1997年12月。
[9] ITU-T Rec. X.680. Abstract Syntax Notation One (ASN.1) - Specification of Basic Notation. 1994.
[9] itu-t rec。X.680。要約構文表記1（ASN.1） - 基本表記の仕様。1994年。
[10] Fleming, P., Jones, K., Lewis, H., and McDonald, I., "Internet Printing Protocol (IPP): LDAP Schema for Printer Services", Work in Progress.
[10] フレミング、P.、ジョーンズ、K。、ルイス、H。、およびマクドナルド、I。、「インターネット印刷プロトコル（IPP）：プリンターサービスのLDAPスキーマ」、進行中の作業。
[11] Smith, M., "Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifiers (URIs)", RFC 2079, January 1997.
[11] Smith、M。、「X.500属性タイプの定義と、均一なリソース識別子（URIS）を保持するオブジェクトクラス」、RFC 2079、1997年1月。
[12] Yaacovi, Y., Wahl, M. and T. Genovese, "Lightweight Directory Access Protocol (v3): Extensions for Dynamic Directory Services", RFC 2589, May 1999.
[12] Yaacovi、Y.、Wahl、M。and T. Genovese、「Lightweight Directory Access Protocol（V3）：Dynamic Directory Servicesの拡張」、RFC 2589、1999年5月。
[13] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, December 1997.
[13] Alvestrand、H。、「言語の識別のためのタグ」、RFC 1766、1997年12月。
[14] Wahl, M. and T. Howes, "Use of Language Codes in LDAP", RFC 2596, May 1999.
[14] Wahl、M。and T. Howes、「LDAPでの言語コードの使用」、RFC 2596、1999年5月。
[15] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan, "Authentication Methods for LDAP", RFC 2829, May 2000.
[15] Wahl、M.、Alvestrand、H.、Hodges、J。およびR. Morgan、「LDAPの認証方法」、RFC 2829、2000年5月。
[16] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[16] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[17] Dubuisson, O. ASN.1: Communication between Heterogeneous Systems. OSS Nokalva, 2000.
[17] Dubuisson、O。Asn.1：不均一なシステム間のコミュニケーション。Oss Nokalva、2000。
[18] http://www.srvloc.org
[18] http://www.srvloc.org
James Kempf Sun Microsystems 901 San Antonio Avenue Palo Alto, CA 94303 USA
James Kempf Sun Microsystems 901 San Antonio Avenue Palo Alto、CA 94303 USA
Phone: +1 650 786-5890
EMail: james.kempf@sun.com
Ryan Moats Coreon, Inc. 15621 Drexel Circle Omaha, NE, 68135 USA
Ryan Moats Coreon、Inc。15621 Drexel Circle Omaha、NE、68135 USA
EMail: rmoats@coreon.net
Pete St. Pierre Sun Microsystems 901 San Antonio Avenue Palo Alto, CA 94303 USA
ピートセントピエールサンマイクロシステムズ901サンアントニオアベニューパロアルト、カリフォルニア州94303 USA
Phone: +1 415 786-5790
EMail: Pete.StPierre@Eng.Sun.COM
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。