[要約] RFC 3224は、Service Location Protocol（SLP）のベンダー拡張機能に関する仕様であり、バージョン2を対象としています。このRFCの目的は、SLPの機能を拡張し、ベンダー固有の機能をサポートすることです。
Network Working Group E. Guttman
Request for Comments: 3224 Sun Microsystems
Updates: 2608 January 2002
Category: Standards Track
Vendor Extensions for Service Location Protocol, Version 2
サービスロケーションプロトコルのベンダー拡張機能、バージョン2
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
Abstract
概要
This document specifies how the features of the Service Location Protocol, Version 2 allow for vendor extensibility safely, with no possibility of collisions. The specification introduces a new SLPv2 extension: The Vendor Opaque Extension. While proprietary protocol extensions are not encouraged by IETF standards, it is important that they not hinder interoperability of compliant implementations when they are undertaken. This document udpates RFC 2608, "The Service Location Protocol."
このドキュメントは、サービスロケーションプロトコルの機能バージョン2の機能により、衝突の可能性がなく、ベンダーの拡張が安全に可能になる方法を指定しています。この仕様では、新しいSLPV2拡張機能：ベンダーオパーク拡張機能を紹介します。独自のプロトコル拡張はIETF標準では奨励されていませんが、実施されたときに準拠した実装の相互運用性を妨げないことが重要です。このドキュメントUDPATES RFC 2608、「サービスロケーションプロトコル」。
Table of Contents
目次
1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . 2
2.0 Enterprise Numbers . . . . . . . . . . . . . . . . . . . . . 3
3.0 Naming Authorities . . . . . . . . . . . . . . . . . . . . . 3
4.0 Vendor Defined Attributes . . . . . . . . . . . . . . . . . 4
5.0 Vendor Opaque Extension . . . . . . . . . . . . . . . . . . 5
5.1 Vendor Opaque Extension Format . . . . . . . . . . . . . . 6
5.2 Example: Acme Extension for UA Authentication . . . . . . . 6
6.0 Extensions Requiring IETF Action . . . . . . . . . . . . . . 7
7.0 IANA Considerations . . . . . . . . . . . . . . . . . . . . 7
8.0 Security Considerations . . . . . . . . . . . . . . . . . . 8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 8
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 10
The Service Location Protocol, Version 2 [1] defines a number of features which are extensible. This document clarifies exactly which mechanisms can be used to that end (Sections 3-5) and which cannot (Section 6). This document updates [1], specifying conventions that ensure the protocol extension mechanisms in the SLPv2 specification will not possibly have ambiguous interpretations.
サービスロケーションプロトコル、バージョン2 [1]は、拡張可能な多くの機能を定義しています。このドキュメントでは、どのメカニズムをその端（セクション3-5）に使用できるか（セクション6）を正確に明確にします。このドキュメントは、[1]を更新し、SLPV2仕様のプロトコル拡張メカニズムを保証する規則を指定しても、あいまいな解釈がない可能性があります。
This specification introduces only one new protocol element, the Vendor Opaque Extension. This Extension makes it possible for a vendor to extend SLP independently, once the vendor has registered itself with IANA and obtained an Enterprise Number. This is useful for vendor-specific applications.
この仕様では、1つの新しいプロトコル要素であるベンダーオパーク拡張機能のみが導入されています。この拡張機能により、ベンダーがIANAに登録し、エンタープライズ番号を取得した後、ベンダーがSLPを独立して拡張できるようになります。これは、ベンダー固有のアプリケーションに役立ちます。
Vendor extensions to standard protocols come at a cost.
標準プロトコルへのベンダー拡張にはコストがかかります。
- Vendor extensions occur without review from the community. They may not make good engineering sense in the context of the protocol they extend, and the engineers responsible may discover this too late.
- ベンダー拡張機能は、コミュニティからのレビューなしで発生します。彼らは、彼らが拡張するプロトコルのコンテキストではエンジニアリングの意味を持たないかもしれません、そして、責任者はこれを遅すぎることを発見するかもしれません。
- Vendor extensions preclude interoperation with compliant but non-extended implementations. There is a real danger of incompatibility if different implementations support different feature sets.
- ベンダー拡張は、準拠しているが拡張されていない実装との相互操作を排除します。異なる実装が異なる機能セットをサポートする場合、非互換性の本当の危険があります。
- By extending SLPv2 privately, ubiquitous automatic configuration is impossible, which is the primary benefit of a standard service discovery framework.
- SLPV2を個人的に拡張することにより、ユビキタスの自動構成は不可能であり、これが標準的なサービスディスカバリーフレームワークの主な利点です。
For these reasons, registration of service templates with IANA is strongly encouraged! This process is easy and has proved to be rapid (taking less than 2 weeks in most cases).
これらの理由から、IANAとのサービステンプレートの登録が強く奨励されています！このプロセスは簡単で、迅速であることが証明されています（ほとんどの場合2週間未満かかります）。
In this document, the key words "MAY", "MUST", "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [2].
このドキュメントでは、キーワードは「may」、「must」、「must」、「optional」、「推奨」、「必要」、および「必要はない」と、[2]で説明されているように解釈されるべきではありません。
Service Location Protocol terminology is defined in [1]. IANA registration terminology is defined in [5].
サービスロケーションプロトコルの用語は[1]で定義されています。IANA登録用語は[5]で定義されています。
Enterprise Numbers are used to distinguish different vendors in IETF protocols. Vendor Extensions to SLPv2 SHOULD use these values to avoid any possibility of a name space collision. Each vendor is responsible for ensuring that vendor extensions under their own authority are non-conflicting.
エンタープライズ番号は、IETFプロトコルのさまざまなベンダーを区別するために使用されます。SLPV2へのベンダー拡張機能は、これらの値を使用して、名前スペースの衝突の可能性を回避する必要があります。各ベンダーは、自分の権限の下でベンダー拡張が非紛争であることを保証する責任があります。
IANA maintains a repository of all 'SMI Network Management Private Enterprise Codes,' whose prefix is iso.org.dod.internet.private.enterprise (1.3.6.1.4.1). The number which follows is unique and may be registered by an on-line form [3].
IANAは、すべての「SMIネットワーク管理プライベートエンタープライズコード」のリポジトリを維持しており、そのプレフィックスはiso.org.dod.internet.private.enterprise（1.3.6.1.4.1）です。次の数字は一意であり、オンラインフォーム[3]で登録される場合があります。
The complete up-to-date list of Enterprise Numbers is maintained by IANA [3].
エンタープライズ番号の完全な最新リストは、IANA [3]によって維持されています。
Naming Authorities are defined by SLPv2 [1] as an agency or group which catalogues Service Types and attributes.
命名当局は、SLPV2 [1]によって、サービスの種類と属性をカタログ化する代理店またはグループとして定義されています。
A Service Type is a string representing a service which can be discovered by SLPv2. Attributes may be associated with a particular Service Type which is advertised by SLPv2.
サービスタイプは、SLPV2で発見できるサービスを表す文字列です。属性は、SLPV2によって宣伝されている特定のサービスタイプに関連付けられている場合があります。
Service Type strings and service attributes may be registered with IANA by creating a Service Template [4]. The template is included in an internet draft and an email message is sent to srvloc-list@iana.org requesting that the template be included in the Service Template registry. In this case, the naming authority for the service type is IANA.
サービスタイプの文字列とサービス属性は、サービステンプレート[4]を作成することにより、IANAに登録できます。テンプレートはインターネットドラフトに含まれており、電子メールメッセージがsrvloc-list@iana.orgに送信され、テンプレートをサービステンプレートレジストリに含めるように要求します。この場合、サービスタイプの命名当局はIANAです。
It is also possible for a Vendor to create their own naming authority. In this case, any service type or attribute may be used. SLPv2 allows arbitrary naming authorities to coexist. To use an explicit naming authority, a vendor simply employs their Enterprise Number as a naming authority. For example, for the following (fictitious) Enterprise Number
ベンダーが独自の命名権限を作成することも可能です。この場合、任意のサービスタイプまたは属性を使用できます。SLPV2により、任意の命名当局が共存することができます。明示的な命名当局を使用するために、ベンダーは単に命名権限としてエンタープライズ番号を採用しています。たとえば、次の（架空の）エンタープライズ番号について
9999 Acme, Inc. Erik Guttman femur@example.com
9999 Acme、Inc。Erik Guttman femur@example.com
the Naming Authority string to use would be "9999". A service: URL which used this Naming Authority to advertise a Roadrunner Detector service could look like
使用する命名機関の文字列は「9999」です。サービス：この命名機関を使用してロードランナー検出器サービスを宣伝したURLは、
service:roadrunner-detector.9999://example.com:9341
Service types which are defined under a naming authority based on an Enterprise Number are guaranteed not to conflict with other service type strings which mean something entirely different. That is also true of attributes defined for service types defined under a naming authority.
エンタープライズ番号に基づいて命名当局の下で定義されているサービスタイプは、まったく異なる何かを意味する他のサービスタイプの文字列と競合しないように保証されています。これは、命名当局の下で定義されたサービスタイプに対して定義された属性にも当てはまります。
To create a safe naming authority with no possibility of name collisions, a vendor SHOULD use their Enterprise Number as a naming authority.
名前の衝突の可能性なしに安全な命名機関を作成するには、ベンダーはエンタープライズ番号を命名当局として使用する必要があります。
SLPv2 [1] suggests that
Slpv2 [1]はそれを示唆しています
Non-standard attribute names SHOULD begin with "x-", because no standard attribute name will ever have those initial characters.
非標準の属性名は「X-」で始まる必要があります。なぜなら、標準の属性名にそれらの初期文字がないため、「X-」から始める必要があります。
It is possible that two non-standard attributes will conflict that both use the "x-" prefix notation. For that reason, vendors SHOULD use "x-" followed by their Enterprise Number followed by a "-" to guarantee that the non-standard attribute name's interpretation is not ambiguous.
両方とも「X-」プレフィックス表記を使用する2つの非標準属性が競合する可能性があります。そのため、ベンダーは「X-」を使用して、エンタープライズ番号が続く「 - 」が続く必要があります。
For example, Acme, Inc.'s Enterprise Number is 9999. Say the Service Template for NetHive (a fictitious game) was:
たとえば、Acme、Inc。のエンタープライズ番号は9999です。
------------------------------------------------------------
template-type=NetHive
template-version=1.0
テンプレート-version = 1.0
template-description= The popular NetHive game.
Template-description =人気のあるゲーム。
template-url-syntax= url-path = ; There is no path for a NetHive service URL.
Template-url-syntax = url-path =;無敵のサービスURLのパスはありません。
features= string M O # The list of optional features the NetHive server supports. secure session, fast mode
feature = string m o＃オプションの機能のリストは、サポートされていません。セッションセッション、高速モード
current-users= string M
# The list of users currently playing
------------------------------------------------------------
Acme's server advertises a feature which is not on the list of standard features, "x-9999-cheat-mode". Only an Acme client would request this attribute to discover servers, since it is not standard.
ACMEのサーバーは、標準機能「X-9999-Cheat-Mode」のリストにない機能を宣伝しています。ACMEクライアントのみがこの属性を要求して、標準ではないため、サーバーを発見します。
SLPv2 [1] defines a protocol extensibility mechanism. SLPv2 Extensions are added at the end of a message and have the following format:
SLPV2 [1]は、プロトコルの拡張性メカニズムを定義します。SLPV2拡張機能はメッセージの最後に追加され、次の形式があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension ID | Next Extension Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset, contd.| Extension Data /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the Extension Data depends on the Extension ID. Refer to [4] for a full description of different mechanisms available for registration of values with IANA.
拡張データの形式は、拡張機能IDによって異なります。IANAとの値の登録に利用できるさまざまなメカニズムの完全な説明については、[4]を参照してください。
SLPv2 may be extended in any of three ways.
SLPV2は、3つの方法のいずれかで拡張できます。
(1) Anyone may request the designated expert for SLP to register a new extension ID with IANA. Send requests to the svrloc-list@iana.org.
(1) 誰でも、SLPの指定された専門家にIANAに新しい拡張機能IDを登録するよう要求することができます。svrloc-list@iana.orgにリクエストを送信します。
It is recommended that an internet draft specifying this extension be published, with the intention of publishing the document as an Informational RFC. This way others can use the extension as well. This is not a 'vendor extension' - rather this is the preferred way of extending the protocol in a vendor neutral manner.
このドキュメントを情報RFCとして公開することを目的として、この拡張機能を指定するインターネットドラフトを公開することをお勧めします。これにより、他の人も拡張機能を使用できます。これは「ベンダー拡張」ではありません。むしろ、これはプロトコルをベンダーの中立的な方法で拡張する好ましい方法です。
If no specification is published and the extension is intended for vendor specific use only - the 'Vendor Extension' option below probably makes more sense than assigning an extension ID.
仕様が公開されておらず、拡張機能がベンダー固有の使用のみを目的としている場合 - 以下の「ベンダー拡張機能」オプションは、おそらく拡張機能IDを割り当てるよりも理にかなっています。
(2) An experimental extension may be done using the range 0x8000 to 0x8FFF. There is always the risk, however, that another vendor will use the same ID, since these IDs are not registered.
(2) 範囲0x8000〜0x8fffを使用して、実験的拡張機能を実行できます。ただし、これらのIDが登録されていないため、別のベンダーが同じIDを使用するというリスクが常にあります。
(3) A Vendor Extension may be used. This extension allows a Vendor to define their own extensions which are guaranteed to have a unique interpretation. It is OPTIONAL to implement.
(3) ベンダー拡張機能を使用できます。この拡張機能により、ベンダーは独自の解釈があることが保証されている独自の拡張機能を定義できます。実装することはオプションです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension ID = 0x0003 | Next Extension Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset, contd.| Enterprise Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ent. #, contd.| Extension Data /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Enterprise Number is included in the Extension as a 4 byte unsigned integer value. The Extension Data following is guaranteed to have an unambiguous interpretation determined by the vendor.
エンタープライズ番号は、拡張機能に4バイトの署名されていない整数値として含まれています。拡張データフォローには、ベンダーが決定する明確な解釈が保証されています。
The Acme Corporation, whose Enterprise Number is 9999, can define an extension to SLP. In this example, Acme creates one such extension to create an application level access control to service information. This would allow replies to be sent only to clients who could authenticate themselves.
エンタープライズ番号が9999であるACME Corporationは、SLPの拡張機能を定義できます。この例では、ACMEはそのような拡張機能の1つを作成して、サービス情報へのアプリケーションレベルアクセス制御を作成します。これにより、返信は自分自身を認証できるクライアントにのみ送信できます。
The engineers at Acme give the Extension Data the following form:
ACMEのエンジニアは、拡張データに次の形式を提供します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ACME Ext ID = 1| Client ID Length | Client ID ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authenticator ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ACME Ext ID: The ACME engineers decided to define the first byte of their extension data as an extension ID field. In the future, ACME may decide to define more than this extension. Since there is 8 bits in the ID field, ACME can define up to 256 different extensions. If ACME were to omit this field and begin directly with their 'Extension for UA Authentication', they would only be able to define one ACME specific SLP extension. For the 'Extension for UA Authentication,' the ACME Extension ID is set to 1. This ID has to be managed within ACME, to make sure that each new extension they invent has a unique ID assigned to it.
ACME EXT ID：ACMEエンジニアは、拡張データの最初のバイトを拡張IDフィールドとして定義することを決定しました。将来的には、ACMEはこの拡張機能よりも多くを定義することを決定する場合があります。IDフィールドに8ビットがあるため、ACMEは最大256の異なる拡張機能を定義できます。ACMEがこのフィールドを省略し、「UA認証用の拡張機能」から直接開始する場合、1つのACME固有のSLP拡張機能を定義することのみができます。「UA認証の拡張機能」の場合、ACME拡張機能IDは1に設定されます。このIDは、ACME内で管理する必要があります。
Client ID Length: This declares how many bytes of Client ID data follow.
クライアントIDの長さ：これは、クライアントIDデータのバイト数を宣言します。
Client ID: The Acme application user ID.
クライアントID：ACMEアプリケーションユーザーID。
Timestamp: # of seconds since January 1, 2000, 0:00 GMT.
タイムスタンプ：2000年1月1日以降の秒、0：00GMT。
Authenticator: a 16 byte MD5 digest [6] calculated on the following data fields, concatenated together
Authenticator：次のデータフィールドで計算された16バイトMD5ダイジェスト[6]、連結された
- UA request bytes, including the header, but not any extensions. - UA SECRET PASS PHRASE - Acme UA Authentication Extension - Client ID - Acme UA Authentication Extension - Timestamp
- ヘッダーを含むUA要求バイテスですが、拡張機能はありません。-UAシークレットパスフレーズ-ACME UA認証拡張機能 - クライアントID -ACME UA認証拡張機能 - タイムスタンプ
The SA or DA which receives this extension and supports this extension will check if it (1) recognizes the Client ID, (2) has an associated SECRET PASS PHRASE for it, (3) whether upon calculating an MD5 digest over the same data as listed above it arrives at the same Authenticator value as included in the extension. If all 3 of these steps succeed, the UA has been authenticated.
この拡張機能を受信してこの拡張機能をサポートするSAまたはDAは、（1）クライアントIDが認識されるかどうかを確認します。上にリストされているのは、拡張機能に含まれるのと同じ認証因子値に届きます。これらの3つのステップがすべて成功した場合、UAは認証されています。
Note this example is for explanatory purposes only. It would not work well in practice. It requires a shared secret be configured in SAs and DAs, for every UA. Furthermore, the UA secret pass phrase would be susceptible to a dictionary attack.
この例は、説明のみを目的としています。実際にはうまくいきません。すべてのUAに対して、SASおよびDASで共有された秘密を構成する必要があります。さらに、UA Secret Passフレーズは、辞書攻撃の影響を受けやすくなります。
Modification or extension of any feature of SLPv2 whatsoever, aside from those listed in Sections 3-5 of this document, requires a standards action as defined in [1].
このドキュメントのセクション3〜5にリストされているものとは別に、SLPV2の機能の変更または拡張には、[1]で定義されている標準アクションが必要です。
Terminology and procedures for IETF Actions related to registration of IDs with IANA are defined in [5]. Existing SLPv2 extensions assignments are registered with IANA [3].
IANAによるIDの登録に関連するIETFアクションの用語と手順は、[5]で定義されています。既存のSLPV2エクステンションの割り当ては、IANAに登録されています[3]。
This document clarifies procedures described in other documents [1] [4]. The Vendor Opaque Extension ID has already been registered [3]. No additional IANA action is required for publication of this document.
この文書は、他の文書[1] [4]に記載されている手順を明確にします。ベンダーの不透明な拡張IDはすでに登録されています[3]。このドキュメントの公開には追加のIANAアクションは必要ありません。
Vendor extensions may introduce additional security considerations into SLP.
ベンダー拡張機能は、SLPに追加のセキュリティ上の考慮事項を導入する場合があります。
This memo describes mechanisms which are standardized elsewhere [1] [4]. The only protocol mechanism described in this document (see Section 5 above) is no less secure than 'private use' extensions defined in SLPv2 [1].
このメモは、他の場所で標準化されたメカニズムを説明しています[1] [4]。このドキュメントで説明されている唯一のプロトコルメカニズム（上記のセクション5を参照）は、SLPV2 [1]で定義されている「プライベート使用」拡張機能よりも安全です。
The example in Section 5.2 above shows how Vendor Opaque Extensions can be used to include an access control mechanism to SLP so that SAs can enforce an access control policy using an authentication mechanism. This is merely an example and protocol details were intentionally not provided. A vendor could, however, create a mechanism similar to this one and provide additional security services to SLPv2 in the manner indicated in the example.
上記のセクション5.2の例は、SASが認証メカニズムを使用してアクセス制御ポリシーを実施できるように、SLPへのアクセス制御メカニズムを含めるためにベンダーの不透明な拡張機能を使用する方法を示しています。これは単なる例であり、プロトコルの詳細は意図的に提供されていません。ただし、ベンダーはこれに類似したメカニズムを作成し、例に示されている方法でSLPV2に追加のセキュリティサービスを提供できます。
Acknowledgements
謝辞
I thank the IESG, for their usual persistence and attention to detail.
IESGに、彼らの通常の粘り強さと細部へのこだわりに感謝します。
References
参考文献
[1] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2", RFC 2608, July 1999.
[1] Guttman、E.、Perkins、C.、Veizades、J。and M. Day、「サービスロケーションプロトコル、バージョン2」、RFC 2608、1999年7月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] http://www.iana.org/numbers.html
[3] http://www.iana.org/numbers.html
[4] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and URLs", RFC 2609, July 1999.
[4] Guttman、E.、Perkins、C。and J. Kempf、「サービステンプレートとURL」、RFC 2609、1999年7月。
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[5] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[6] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[6] Rivest、R。、「The Md5 Message-Digest Algorithm」、RFC 1321、1992年4月。
Author's Address
著者の連絡先
Erik Guttman Sun Microsystems Eichhoelzelstr. 7 74915 Waibstadt Germany
Erik Guttman Sun Microsystems Eichhoelzelstr。7 74915 Waibstadtドイツ
Phone: +49 7263 911 701
Messages: +49 6221 356 202
EMail: erik.guttman@sun.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
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エディター機能の資金は現在、インターネット協会によって提供されています。