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
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.
著作権（C）インターネット協会（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.
この仕様は、唯一の新しいプロトコル要素、ベンダー不透明拡張を紹介します。ベンダーは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 NOT"、 "オプション" は、 "推奨"、 "SHOULD"、および "SHOULD NOT"、[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は、接頭辞iso.org.dod.internet.private.enterprise（1.3.6.1.4.1）であるすべての「SMIネットワーク管理プライベートエンタープライズコード」のリポジトリを維持します。次の番号は一意であり、オンラインフォーム[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.
命名当局[1]サービスタイプと属性をカタログ代理店またはグループとしてSLPv2のによって定義されます。
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アクメ社エリック・グットマン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
サービス：ロードランナー-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-」で始まらなければなりません。
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.
2つの非標準の属性は両方とも「X-」接頭表記を使用することを競合する可能性があります。そのため、ベンダーが続く彼らのエンタープライズ番号に続いて「X-」を使用すべきである「 - 」非標準の属性名の解釈があいまいでないことを保証します。
For example, Acme, Inc.'s Enterprise Number is 9999. Say the Service Template for NetHive (a fictitious game) was:
たとえば、Acme社の企業数は9999であるがNetHiveのためのサービステンプレート（架空のゲームは）だったと言います。
------------------------------------------------------------
template-type=NetHive
template-version=1.0
テンプレート・バージョン= 1.0
template-description= The popular NetHive game.
テンプレート説明=人気NetHiveゲーム。
template-url-syntax= url-path = ; There is no path for a NetHive service URL.
テンプレートのurl-構文= URLパス=; NetHiveサービスURLにはパスはありません。
features= string M O # The list of optional features the NetHive server supports. secure session, fast mode
機能=文字列MのOの＃NetHiveサーバーがサポートするオプション機能の一覧。安全なセッション、高速モード
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.
アクメのサーバは標準機能、「X-9999-チートモード」のリストにない機能をアドバタイズします。それは標準ではありませんので、唯一のアクメ・クライアントは、サーバーを検出するために、この属性を要求します。
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）誰もがIANAでの新しい拡張IDを登録するSLPのために指定された専門家を要求することができます。 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.
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）実験的な拡張は0x8FFFの範囲は0x8000を使用して行うことができます。リスクは、これらの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社は、SLPへの拡張を定義することができます。この例では、Acme社は、情報をサービスするために、アプリケーション・レベルのアクセス制御を作成するために、そのような拡張を作成します。これは、応答が自身を認証することができ、クライアントにのみ送信することが可能となります。
The engineers at Acme give the Extension Data the following form:
アクメのエンジニアは、拡張データに次のような形式を与えます：
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内線ID：ACMEのエンジニアは、拡張IDフィールドとしての拡張データの最初のバイトを定義することにしました。将来的には、ACMEは、この拡張機能以上のものを定義することもできます。 IDフィールドの8ビットがあるので、ACMEは、256の異なる拡張機能を定義できます。 ACMEは、このフィールドを省略し、彼らの「UA認証のための拡張」で直接開始した場合、彼らは唯一のACME特定のSLPの拡張を定義することができるだろう。以下のために「UA認証のための拡張、」ACME拡張IDは、彼らが発明し、それぞれの新しい拡張機能がそれに割り当てられた固有のIDを持っていることを確認するために、このIDは、ACME内で管理する必要が1に設定されています。
Client ID Length: This declares how many bytes of Client ID data follow.
クライアントIDの長さ：これは、クライアントのIDデータのバイトが続くどのように多く宣言する。
Client ID: The Acme application user ID.
クライアントID：アクメアプリケーション・ユーザーID。
Timestamp: # of seconds since January 1, 2000, 0:00 GMT.
タイムスタンプ：2000年1月1日、午後12時00 GMTからの秒＃。
Authenticator: a 16 byte MD5 digest [6] calculated on the following data fields, concatenated together
オーセンティケータ：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秘密のパスフレーズ - アクメUA認証拡張 - クライアントID - アクメ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を認識するかどうかを確認し、（2）そのための関連SECRETパスフレーズを持っている、（3）かどうかと同じデータ上にMD5ダイジェストを計算する際になります拡張に含まれるように、それは同じ認証値に到達上記。これらの手順のすべての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の秘密のパスフレーズは辞書攻撃を受けやすいだろう。
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].
[1]で定義された変更または全くSLPv2の任意の機能の拡張は、さておき、このドキュメントのセクション3-5にリストされているから、標準アクションを必要とします。
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は、認証機構を使用して、アクセス制御ポリシーを施行することができるように、ベンダー不透明Extensionsは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]ガットマン、E.、パーキンス、C.、Veizades、J.とM.日、 "サービスロケーションプロトコル、バージョン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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] http://www.iana.org/numbers.html
「３」 ｈっｔｐ：／／ｗっｗ。いあな。おｒｇ／ぬｍべｒｓ。ｈｔｍｌ
[4] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and URLs", RFC 2609, July 1999.
[4]ガットマン、E.、パーキンス、C.及びJ.ケンプ、 "サービステンプレートと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]リベスト、R.、 "MD5メッセージダイジェストアルゴリズム"、RFC 1321、1992年4月。
Author's Address
著者のアドレス
Erik Guttman Sun Microsystems Eichhoelzelstr. 7 74915 Waibstadt Germany
エリック・グットマンSun MicrosystemsのEichhoelzelstr。 7 74915ヴァイプシュタットドイツ
Phone: +49 7263 911 701 Messages: +49 6221 356 202 EMail: erik.guttman@sun.com
電話：+49 7263 911 701メッセージ：+49 6221 356 202 Eメール：erik.guttman@sun.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。