[要約] RFC 3930は、コンピュータプロトコルにおけるプロトコルとドキュメントの視点の違いについて説明しています。このRFCの目的は、プロトコルの設計とドキュメントの作成において、両者の視点の重要性を理解することです。
Network Working Group D. Eastlake 3rd
Request for Comments: 3930 Motorola Laboratories
Category: Informational October 2004
The Protocol versus Document Points of View in Computer Protocols
コンピュータープロトコルのプロトコルとドキュメントの視点
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 (2004).
著作権（c）The Internet Society（2004）。
Abstract
概要
This document contrasts two points of view: the "document" point of view, where digital objects of interest are like pieces of paper written and viewed by people, and the "protocol" point of view where objects of interest are composite dynamic network messages. Although each point of view has a place, adherence to a document point of view can be damaging to protocol design. By understanding both points of view, conflicts between them may be clarified and reduced.
このドキュメントは、2つの視点とは対照的です。「ドキュメント」の視点、関心のあるデジタルオブジェクトは、人々によって書かれて表示される紙のようなものであり、対象のオブジェクトが複合動的ネットワークメッセージである「プロトコル」の視点です。視点のそれぞれには場所がありますが、ドキュメントの視点への順守は、プロトコル設計に損害を与える可能性があります。両方の視点を理解することにより、それらの間の対立は明確にされ、減少する可能性があります。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Points of View . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1. The Basic Points of View . . . . . . . . . . . . . . . . 3
2.2. Questions of Meaning . . . . . . . . . . . . . . . . . . 3
2.2.1. Core Meaning . . . . . . . . . . . . . . . . . . 3
2.2.2. Adjunct Meaning. . . . . . . . . . . . . . . . . 4
2.3. Processing Models. . . . . . . . . . . . . . . . . . . . 5
2.3.1. Amount of Processing . . . . . . . . . . . . . . 5
2.3.2. Granularity of Processing. . . . . . . . . . . . 5
2.3.3. Extensibility of Processing. . . . . . . . . . . 6
2.4. Security and Canonicalization. . . . . . . . . . . . . . 6
2.4.1. Canonicalization . . . . . . . . . . . . . . . . 6
2.4.2. Digital Authentication . . . . . . . . . . . . . 8
2.4.3. Canonicalization and Digital Authentication. . . 8
2.4.4. Encryption . . . . . . . . . . . . . . . . . . . 9
2.5. Unique Internal Labels . . . . . . . . . . . . . . . . . 10
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4. Resolution of the Points of View . . . . . . . . . . . . . . . 11
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 12
Informative References . . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 15
This document contrasts: the "document" point of view, where digital objects of interest are thought of as pieces of paper written and viewed by people, and the "protocol" point of view, where objects of interest are composite dynamic network messages. Those accustomed to one point of view frequently have great difficulty appreciating the other: Even after they understand it, they almost always start by considering things from their accustomed point of view, assume that most of the universe of interest is best viewed from their perspective, and commonly slip back into thinking about things entirely from that point of view. Although each point of view has a place, adherence to a document point of view can be damaging to protocol design. By understanding both points of view, conflicts between them may be clarified and reduced.
このドキュメントは対照的です。「ドキュメント」の視点、関心のあるデジタルオブジェクトは、人々によって書かれて表示されている紙の一部と考えられています。ある視点に慣れている人々は、頻繁に他の視点を評価するのが非常に困難です。彼らがそれを理解した後でも、彼らはほとんどの場合、慣れた観点から物事を考慮することから始まります。そして一般的に、その観点から完全に物事について考えるように戻ります。視点のそれぞれには場所がありますが、ドキュメントの視点への順守は、プロトコル設計に損害を与える可能性があります。両方の視点を理解することにより、それらの間の対立は明確にされ、減少する可能性があります。
Much of the IETF's traditional work has concerned low level binary protocol constructs. These are almost always viewed from the protocol point of view. But as higher level application constructs and syntaxes are involved in the IETF and other standards processes, difficulties can arise due to participants who have the document point of view. These two different points of view defined and explored in section 2 below.
IETFの従来の作業の多くは、低レベルのバイナリプロトコル構造に関するものです。これらは、ほとんどの場合、プロトコルの観点から見られます。しかし、より高いレベルのアプリケーションコンストラクトと構文がIETFおよびその他の標準プロセスに関与しているため、文書の視点を持つ参加者のために困難が生じる可能性があります。これらの2つの異なる視点は、以下のセクション2で定義および調査されています。
Section 3 gives some examples. Section 4 tries to synthesize the views and give general design advice in areas that can reasonably be viewed either way.
セクション3にいくつかの例があります。セクション4は、どちらの方法でも合理的に表示できる分野で、意見を統合し、一般的なデザインアドバイスを提供しようとします。
The following subsections contrast the document and protocol points of view. Each viewpoint is EXAGGERATED for effect.
次のサブセクションは、ドキュメントとプロトコルの視点とは対照的です。各視点は効果のために誇張されています。
The document point of view is indicated in paragraphs headed "DOCUM", and the protocol point of view is indicated in paragraphs headed "PROTO".
文書の視点は、「docum」に向かう段落に示されており、プロトコルの観点は「proto」という段落に示されています。
DOCUM: What is important are complete (digital) documents, analogous to pieces of paper, viewed by people. A major concern is to be able to present such documents as directly as possible to a court or other third party. Because what is presented to the person is all that is important, anything that can effect this, such as a "style sheet" [CSS], MUST be considered part of the document. Sometimes it is forgotten that the "document" originates in a computer, may travel over, be processed in, and be stored in computer systems, and is viewed on a computer, and that such operations may involve transcoding, enveloping, or data reconstruction.
Docum：重要なのは、人々が視聴する紙に類似した完全な（デジタル）ドキュメントです。大きな懸念は、そのような文書をできるだけ直接的に裁判所または他の第三者に提示できることです。人に提示されるのは重要なことであるため、「スタイルシート」[CSS]など、これに影響を与えることができるものはすべて、ドキュメントの一部と見なされなければなりません。「ドキュメント」がコンピューターに由来し、移動し、処理され、コンピューターシステムに保存される可能性があり、コンピューターに表示されることが忘れられ、そのような操作がトランスコーディング、封筒、またはデータの再構築を伴う場合があります。
PROTO: What is important are bits on the wire generated and consumed by well-defined computer protocol processes. No person ever sees the full messages as such; it is only viewed as a whole by geeks when debugging, and even then they only see some translated visible form. If one actually ever has to demonstrate something about such a message in a court or to a third party, there isn't any way to avoid having computer experts interpret it. Sometimes it is forgotten that pieces of such messages may end up being included in or influencing data displayed to a person.
proto：重要なのは、明確に定義されたコンピュータープロトコルプロセスによって生成および消費されるワイヤーのビットです。完全なメッセージを見る人はいません。それはデバッグ時にオタクによってのみ全体として表示され、それでも彼らはいくつかの翻訳された目に見える形式だけを見るだけです。実際に裁判所や第三者にそのようなメッセージについて何かを示さなければならない場合、コンピューターの専門家にそれを解釈させることを避ける方法はありません。そのようなメッセージの一部が、人に表示されるデータに含まれるか、影響を与えることになる可能性があることが忘れられている場合があります。
The document and protocol points of view have radically different concepts of the "meaning" of data. The document oriented tend to consider "meaning" to a human reader extremely important, but this is something the protocol oriented rarely think about at all.
ドキュメントとプロトコルの視点には、データの「意味」の根本的に異なる概念があります。ドキュメント指向は、人間の読者にとって非常に重要な「意味」を考慮する傾向がありますが、これはプロトコル指向がまったく考えないものです。
This difference in point of view extends beyond the core meaning to the meaning of addenda to data. Both core and addenda meaning are discussed below.
視点のこの違いは、コアの意味を超えてデータに対する補遺の意味にまで及びます。コアと補遺の両方の意味について、以下で説明します。
DOCUM: The "meaning" of a document is a deep and interesting human question related to volition. It is probably necessary for the document to include or reference human language policy and/or warranty/disclaimer information. At an absolute minimum, some sort of semantic labelling is required. The assumed situation is always a person interpreting the whole "document" without other context. Thus it is reasonable to consult attorneys during message design, to require that human-readable statements be "within the four corners" of the document, etc.
Docum：文書の「意味」は、意志に関連する深く興味深い人間の質問です。おそらく、ドキュメントが人間の言語ポリシーおよび/または保証/免責事項情報を含めるか、参照する必要があります。絶対的な最小限では、何らかのセマンティックラベルが必要です。想定される状況は、常に他のコンテキストなしで「ドキュメント」全体を解釈する人です。したがって、メッセージデザイン中に弁護士に相談し、人間の読み取り可能なステートメントが文書の「四隅の中に」であることを要求することが合理的です。
PROTO: The "meaning" of a protocol message should be clear and unambiguous from the protocol specification. It is frequently defined in terms of the state machines of the sender and recipient processes and may have only the most remote connection with human volition. Such processes have additional context, and the message is usually only meaningful with that additional context. Adding any human-readable text that is not functionally required is silly. Consulting attorneys during design is a bad idea that complicates the protocol and could tie a design effort in knots.
proto：プロトコルメッセージの「意味」は、プロトコルの仕様から明確で明確でなければなりません。これは、送信者および受信者のプロセスの状態マシンの観点から頻繁に定義されており、人間の意志との最も遠隔のつながりのみを持っている可能性があります。このようなプロセスには追加のコンテキストがあり、メッセージは通常、その追加コンテキストでのみ意味があります。機能的に必要とされていない人間の読み取り可能なテキストを追加することはばかげています。デザイン中の弁護士コンサルティングは、プロトコルを複雑にし、結び目でデザインの努力を結び付ける可能性のある悪い考えです。
Adjunct items can be added or are logical addenda to a message.
補助項目を追加することも、メッセージに論理的な補遺を追加できます。
DOCUM: From a document point of view, at the top level is a person looking at a document. So adjunct items such as digital signatures, person's names, dates, etc., must be carefully labeled as to meaning. Thus a digital signature needs to include, in more or less human-readable form, what that signature means (is the signer a witness, author, guarantor, authorizer, or what?). Similarly, a person's name needs to be accompanied by that person's role, such as editor, author, subject, or contributor. As another example, a date needs to be accompanied by the significance of the date, such as date of creation, modification, distribution, or some other event. Given the unrestrained scope of what can be documented, there is a risk of trying to enumerate and standardize all possible "semantic tags" for each kind of adjunct data during in the design process. This can be a difficult, complex, and essentially infinite task (i.e., a rat hole).
docum：ドキュメントの観点から、上位レベルではドキュメントを見ている人がいます。したがって、デジタル署名、人の名前、日付などの補助項目は、意味について慎重にラベル付けする必要があります。したがって、デジタル署名には、多かれ少なかれ人間の読み取り可能な形式で、その署名の意味を含める必要があります（署名者は証人、著者、保証人、承認者、または何ですか？）。同様に、編集者、著者、科目、貢献者など、その人の役割を伴う必要があります。別の例として、日付には、作成日、変更、配布、またはその他のイベントなど、日付の重要性を伴う必要があります。文書化できるものの抑制されていない範囲を考えると、設計プロセス中に、各種類の補助データに対してすべての可能な「セマンティックタグ」を列挙し、標準化しようとするリスクがあります。これは、困難で複雑で、本質的に無限のタスク（つまり、ネズミの穴）になります。
PROTO: From a protocol point of view, the semantics of the message and every adjunct in it are defined in the protocol specification. Thus, if there is a slot for a digital signature, person's name, a date, or whatever, the party who is to enter that data, the party or parties who are to read it, and its meaning are all pre-defined. Even if there are several possible meanings, the specific meaning that applies can be specified by a separate enumerated type field. There is no reason for such a field to be directly human readable. Only the "meanings" directly relevant to the particular protocol need be considered. Another way to look at this is that the "meaning" of each adjunct, instead of being pushed into and coupled with the adjunct itself, as the document point of view encourages, is commonly promoted to the level of the protocol specification, resulting in simpler adjuncts.
Proto：プロトコルの観点から、メッセージのセマンティクスとその中のすべての付属物は、プロトコル仕様で定義されています。したがって、デジタル署名、人の名前、日付などのスロットがある場合、そのデータを入力する当事者、それを読む当事者、またはその意味はすべて事前に定義されています。いくつかの考えられる意味がある場合でも、適用される特定の意味は、個別の列挙型フィールドによって指定できます。そのようなフィールドが直接人間が読みやすくなる理由はありません。特定のプロトコルに直接関連する「意味」のみを考慮する必要があります。これを見る別の方法は、ドキュメントの観点が奨励するように、補助自体に押し込まれて結合するのではなく、各補助の「意味」が一般的にプロトコル仕様のレベルに促進され、より単純なものになることです。補助。
The document oriented and protocol oriented have very different views on what is likely to happen to an object.
ドキュメント指向とプロトコル指向は、オブジェクトに起こりそうなことについて非常に異なる見解を持っています。
DOCUM: The model is of a quasi-static object like a piece of paper. About all one does to pieces of paper is transfer them as a whole, from one storage area to another, or add signatures, date stamps, or similar adjuncts. (Possibly one might want an extract from a document or to combine multiple documents into a summary, but this isn't the common case.)
Docum：モデルは、紙のような準静的オブジェクトです。1つの紙には、1つのストレージエリアから別のストレージエリアに移動するか、署名、日付スタンプ、または同様の付属物を追加するだけです。（おそらく、ドキュメントからの抽出を望んでいるか、複数のドキュメントを要約に組み合わせることを望むかもしれませんが、これは一般的なケースではありません。）
PROTO: The standard model of a protocol message is as an ephemeral composite, multi-level object created by a source process and consumed by a destination process. Such a message is constructed from information contained in previously received messages, locally stored information, local calculations, etc. Quite complex processing is normal.
proto：プロトコルメッセージの標準モデルは、ソースプロセスによって作成され、宛先プロセスによって消費される一時的な複合、マルチレベルオブジェクトです。このようなメッセージは、以前に受信したメッセージ、ローカルに保存された情報、ローカル計算などに含まれる情報から構築されています。非常に複雑な処理は正常です。
DOCUM: The document view is generally of uniform processing or evaluation of the object being specified. There may be an allowance for attachments or addenda, but, if so, they would probably be simple, one level, self documenting attachments or addenda. (Separate processing of an attachment or addenda is possible but not usual.)
Docum：ドキュメントビューは、一般に指定されているオブジェクトの均一な処理または評価のものです。添付ファイルや補遺には手当があるかもしれませんが、もしそうなら、それらはおそらく単純で、1つのレベルで、添付ファイルまたは補遺を自己文書化するでしょう。（添付ファイルまたは補遺の個別の処理は可能ですが、通常はありません。）
PROTO: Processing is complex and almost always affects different pieces of the message differently. Some pieces may be intended for use only by the destination process and may be extensively processed there. Others may be present so that the destination process can, at some point, do minimal processing and forward them in other messages to yet more processes. The object's structure can be quite rich and have multilevel or recursive aspects. Because messages are processed in a local context, elements of the message may include items like a signature that covers multiple data elements, some of which are in the message, some received in previous messages, and some locally calculated.
Proto：処理は複雑であり、ほとんどの場合、メッセージの異なる部分に異なって影響します。一部のピースは、宛先プロセスのみで使用することを目的としている場合があり、そこで広範囲に処理される場合があります。他のものが存在する可能性があるため、宛先プロセスは、ある時点で最小限の処理を行い、他のメッセージでさらにプロセスに転送できます。オブジェクトの構造は非常に豊富で、マルチレベルまたは再帰的な側面を持つことができます。メッセージはローカルコンテキストで処理されるため、メッセージの要素には、複数のデータ要素をカバーする署名のようなアイテムが含まれる場合があります。これらの要素はメッセージに含まれており、一部は以前のメッセージで受信され、一部はローカルで計算されています。
DOCUM: The document oriented don't usually think of extensibility as a major problem. They assume that their design, perhaps with some simple version scheme, will meet all requirements. Or, coming from an SGML/DTD world of closed systems, they may assume that knowledge of new versions or extensions can be easily and synchronously distributed to all participating sites.
Docum：ドキュメント指向は、通常、拡張性を大きな問題とは考えていません。彼らは、おそらくいくつかの単純なバージョンスキームを使用して、すべての要件を満たすと彼らの設計を想定しています。または、閉じたシステムのSGML/DTDの世界から来て、新しいバージョンまたは拡張機能の知識をすべての参加サイトに簡単かつ同期することができると想定する場合があります。
PROTO: Those who are protocol oriented assume that protocols will always need to be extended and that it will not be possible to update all implementations as such extensions are deployed and/or retired. This is a difficult problem but those from the protocol point of view try to provide the tools needed. For example, they specify carefully defined versioning and extension/feature labelling, including the ability to negotiate versions and features where possible and at least a specification of how parties running different levels should interact, providing length/delimiting information for all data so that it can be skipped if not understood, and providing destination labelling so that a process can tell that it should ignore data except for passing it through to a later player.
Proto：プロトコル指向の人は、プロトコルを常に拡張する必要があり、そのような拡張機能が展開および/または廃止されるなど、すべての実装を更新することはできないと仮定します。これは難しい問題ですが、プロトコルの観点からの問題は、必要なツールを提供しようとします。たとえば、可能な限りバージョンと機能を交渉する機能、少なくとも異なるレベルを実行するパーティーが相互作用する方法の仕様を含む、慎重に定義されたバージョンと拡張機能/機能のラベル付けを指定し、すべてのデータの長さ/削除情報を提供して、できるようにします。理解されていない場合はスキップされ、プロセスが後のプレーヤーに渡すことを除いてデータを無視する必要があることがわかります。
Security is a subtle area. Sometime problems can be solved in a way that is effective across many applications. Those solutions are typically incorporated into standard security syntaxes such as those for ASN.1 [RFC3852] and XML [RFC3275, XMLENC]. But there are almost always application specific questions, particularly the question of exactly what information needs to be authenticated or encrypted.
セキュリティは微妙な領域です。多くのアプリケーションで効果的な方法で問題を解決することができます。これらのソリューションは通常、ASN.1 [RFC3852]およびXML [RFC3275、XMLENC]のような標準セキュリティ構文に組み込まれます。しかし、ほとんどの場合、アプリケーション固有の質問、特にどの情報を認証または暗号化する必要があるかという正確な問題があります。
Questions of exactly what needs to be secured and how to do so robustly are deeply entwined with canonicalization. They are also somewhat different for authentication and encryption, as discussed below.
何を保護する必要があるか、どのようにして堅牢に行う方法の質問は、標準化に深く絡み合っています。また、以下で説明するように、認証と暗号化についても多少異なります。
Canonicalization is the transformation of the "significant" information in a message into a "standard" form, discarding "insignificant" information, for example, encoding into a standard character set or changing line endings into a standard encoding and discarding the information about the original character set or line ending encodings. Obviously, what is "significant" and what is "insignificant" varies with the application or protocol and can be tricky to determine. However, it is common that for each particular syntax, such as ASCII [ASCII], ASN.1 [ASN.1], or XML [XML], a standard canonicalization (or canonicalizations) is specified or developed through practice. This leads to the design of applications that assume one of such standard canonicalizations, thus reducing the need for per-application canonicalization. (See also [RFC3076, RFC3741].)
標準化とは、メッセージの「重要な」情報の「標準」形式への変換であり、たとえば標準の文字セットにエンコードするか、元のエンコードにラインエンディングを変更して元の情報を標準エンコードして破棄するなど、「重要な」情報を破棄します。文字セットまたはラインエンディングエンコーディング。明らかに、「重要な」ものと「取るに足らない」ものは、アプリケーションまたはプロトコルによって異なり、決定するのが難しい場合があります。ただし、ASCII [ASCII]、ASN.1 [ASN.1]、またはXML [XML]などの特定の各構文について、標準的な標準化（または標準化）が練習を通じて指定または開発されることがよくあります。これにより、このような標準的な標準化の1つを想定するアプリケーションの設計につながり、アプリケーションごとの標準化の必要性が減少します。（[RFC3076、RFC3741]も参照してください。）
DOCUM: From the document point of view, canonicalization is suspect if not outright evil. After all, if you have a piece of paper with writing on it, any modification to "standardize" its format can be an unauthorized change in the original message as created by the "author", who is always visualized as a person. Digital signatures are like authenticating signatures or seals or time stamps on the bottom of the "piece of paper". They do not justify and should not depend on changes in the message appearing above them. Similarly, encryption is just putting the "piece of paper" in a vault that only certain people can open and does not justify any standardization or canonicalization of the message.
Docum：文書の観点から、標準化は完全に悪ではないにしても疑わしい。結局のところ、書いた紙がある場合、その形式を「標準化」するための変更は、常に人として視覚化されている「著者」によって作成された元のメッセージの不正な変更になります。デジタル署名は、「紙」の底にある署名やシール、またはタイムスタンプを認証するようなものです。彼らは正当化することはなく、それらの上に表示されるメッセージの変更に依存するべきではありません。同様に、暗号化とは、特定の人だけが開くことができ、メッセージの標準化や標準化を正当化しない「紙の一部」を金庫に入れているだけです。
PROTO: From the protocol point of view, canonicalization is simply a necessity. It is just a question of exactly what canonicalization or canonicalizations to apply to a pattern of bits that are calculated, processed, stored, communicated, and finally parsed and acted on. Most of these bits have never been seen and never will be seen by a person. In fact, many of the parts of the message will be artifacts of encoding, protocol structure, and computer representation rather than anything intended for a person to see. Perhaps in theory, the "original", idiosyncratic form of any digitally signed part could be conveyed unchanged through the computer process, storage, and communications channels that implement the protocol and could be usefully signed in that form. But in practical systems of any complexity, this is unreasonably difficult, at least for most parts of messages. And if it were possible, it would be virtually useless, because to authenticate messages you would still have to determine their equivalence with the preserved original form. Thus, signed data must be canonicalized as part of signing and verification to compensate for insignificant changes made in processing, storage, and communication. Even if, miraculously, an initial system design avoids all cases of signed message reconstruction based on processed data or re-encoding based on character set or line ending or capitalization or numeric representation or time zones or whatever, later protocol revisions and extensions are certain to require such reconstruction and/or re-encoding eventually. If such "insignificant" changes are not ameliorated by canonicalization, signatures won't work, as discussed in more detail in 2.4.3 below.
Proto：プロトコルの観点から、標準化は単に必要性です。これは、計算、処理、保存、通信、最終的に解析されて作動するビットのパターンに適用するための正確な標準化または標準化の問題です。これらのビットのほとんどは見られたことがなく、人には決して見られません。実際、メッセージの部分の多くは、人が見ることを意図したものではなく、エンコード、プロトコル構造、およびコンピューター表現のアーティファクトになります。おそらく理論的には、デジタル的に署名された部分の「オリジナル」の特異な形式は、プロトコルを実装し、その形式で有用に署名する可能性のあるコンピュータープロセス、ストレージ、および通信チャネルを通じて変更されずに伝えられます。しかし、あらゆる複雑さの実際のシステムでは、少なくともメッセージのほとんどの部分では、これは不当に困難です。そして、それが可能であれば、それは事実上役に立たないでしょう。なぜなら、メッセージを認証するには、保存された元のフォームとの同等性を決定する必要があるからです。したがって、署名されたデータは、処理、ストレージ、通信に行われた取るに足らない変更を補うために、署名と検証の一環として標準化されなければなりません。奇跡的に、初期システム設計が、キャラクターセットまたはラインエンディング、大文字、数値表現またはタイムゾーンなどに基づいて、処理されたデータまたは再エンコードに基づいて署名されたメッセージ再構成のすべてのケースを回避しても、後のプロトコルリビジョンと拡張は確実ですそのような再構築および/または再エンコードが最終的に必要です。このような「取るに足らない」変更が標準化によって改善されない場合、以下2.4.3で詳細に説明するように、署名は機能しません。
DOCUM: The document-oriented view on authentication tends to be a "digital signature" and "forms" point of view. (The "forms" point of view is a subset of the document point of view that believes that a principal activity is presenting forms to human beings so that they can fill out and sign portions of those forms [XForms]). Since the worry is always about human third parties and viewing the document in isolation, those who are document oriented always want "digital signature" (asymmetric key) authentication, with its characteristics of "non-repudiability", etc. As a result, they reject secret key based message authentication codes, which provide the verifier with the capability of forging an authentication code, as useless. (See any standard reference on the subject for the usual meaning of these terms.) From their point of view, you have a piece of paper or form which a person signs. Sometimes a signature covers only part of a form, but that's usually because a signature can only cover data that is already there. And normally at least one signature covers the "whole" document/form. Thus the document oriented want to be able to insert digital signatures into documents without changing the document type and even "inside" the data being signed, which requires a mechanism to skip the signature so that it does not try to sign itself.
Docum：認証に関するドキュメント指向のビューは、「デジタル署名」および「フォーム」の視点である傾向があります。（「フォーム」の視点は、主要な活動が人間にフォームを提示していると考えている文書の視点のサブセットであり、それらのフォームの部分に記入して署名できる[XForms]）。心配は常に人間の第三者に関するものであり、文書を単独で見ることについてであるため、ドキュメント指向の人は常に「デジタル署名」（非対称キー）認証を望んでいます。結果として、彼らはSecret Keyベースのメッセージ認証コードを拒否します。これは、認証コードを役に立たないと評価する機能を検証者に提供します。（これらの用語の通常の意味については、主題に関する標準リファレンスを参照してください。）その観点から、人が署名する紙または形式があります。署名はフォームの一部のみをカバーする場合がありますが、それは通常、署名がすでにそこにあるデータのみをカバーできるためです。通常、少なくとも1つの署名が「全体」ドキュメント/フォームをカバーします。したがって、ドキュメント指向は、ドキュメントの種類を変更せずにデジタル署名をドキュメントに挿入し、署名されているデータを「内部」に挿入できるようにしたいと考えています。
PROTO: From a protocol point of view, the right kind of authentication to use, whether "digital signature" or symmetric keyed authentication code (or biometric or whatever), is just another engineering decision affected by questions of efficiency, desired security model, etc. Furthermore, the concept of signing a "whole" message seems very peculiar (unless it is a copy being saved for archival purposes, in which case you might be signing a whole archive at once anyway). Typical messages are made up of various pieces with various destinations, sources, and security requirements. Furthermore, there are common fields that it is rarely useful to sign because they change as the message is communicated and processed. Examples include hop counts, routing history, and local forwarding tags.
Proto：プロトコルの観点から、「デジタル署名」または対称キー付き認証コード（またはバイオメトリックなど）であろうと、使用する正しい種類の認証は、効率性、望ましいセキュリティモデルなどの問題に影響を受ける別のエンジニアリング決定です。さらに、「全体」メッセージに署名するという概念は非常に独特のように思えます（アーカイブの目的で保存されているコピーでない限り、とにかくアーカイブ全体に署名するかもしれません）。典型的なメッセージは、さまざまな目的地、ソース、セキュリティ要件を備えたさまざまな部分で構成されています。さらに、メッセージが通信および処理されるにつれて変更されるため、署名することはめったに有用ではない一般的なフィールドがあります。例には、ホップカウント、ルーティング履歴、ローカル転送タグが含まれます。
For authenticating protocol system messages of practical complexity, you are faced with the choice of doing
実用的な複雑さのプロトコルシステムメッセージを認証するために、あなたは行うという選択に直面しています
(1) "too little canonicalization" and having brittle authentication, useless due to verification failures caused by surface representation changes without significance,
(1) 「標準化が少なすぎる」と脆性認証があり、重要な表面表現の変化によって引き起こされる検証障害のために役に立たない、
(2) the sometimes difficult and tricky work of selecting or designing an appropriate canonicalization or canonicalizations to be used as part of authentication generation and verification, producing robust and useful authentication, or
(2) 認証と検証の一部として使用される適切な標準化または標準化、堅牢で有用な認証を生成する、または標準化された適切な標準化または標準化を選択または設計することの時々困難でトリッキーな作業
(3) "too much canonicalization" and having insecure authentication, useless because it still verifies even when significant changes are made in the signed data.
(3) 「標準化が多すぎる」と不安定な認証を持つことは、署名されたデータに大幅な変更が加えられた場合でも検証するため、役に立たない。
The only useful option above is number 2.
上記の唯一の便利なオプションは2番です。
In terms of processing, transmission, and storage, encryption turns out to be much easier to get working than signatures. Why? Because the output of encryption is essentially random bits. It is clear from the beginning that those bits need to be transferred to the destination in some absolutely clean way that does not change even one bit. Because the encrypted bits are meaningless to a human being, there is no temptation among the document oriented to try to make them more "readable". So appropriate techniques of encoding at the source, such as Base64 [RFC2045], and decoding at the destination, are always incorporated to protect or "armor" the encrypted data.
処理、送信、保管の観点から、暗号化は署名よりも機能しやすくなります。なぜ？暗号化の出力は本質的にランダムビットであるためです。最初から、これらのビットを、少しでも変えないいくつかの絶対にきれいな方法で目的地に転送する必要があることは明らかです。暗号化されたビットは人間にとって無意味であるため、ドキュメントの間には、より「読みやすい」ようにしようとする誘惑はありません。Base64 [RFC2045]などのソースでのエンコードの適切な手法、および目的地でのデコードは、暗号化されたデータを保護または「装甲」するために常に組み込まれています。
Although the application of canonicalization is more obvious with digital signatures, it may also apply to encryption, particularly encryption of parts of a message. Sometimes elements of the environment where the plain text data is found may affect its interpretation. For example, interpretation can be affected by the character encoding or bindings of dummy symbols. When the data is decrypted, it may be into an environment with a different character encoding or dummy symbol bindings. With a plain text message part, it is usually clear which of these environmental elements need to be incorporated in or conveyed with the message. But an encrypted message part is opaque. Thus some canonical representation that incorporates such environmental factors may be needed.
標準化の適用はデジタル署名ではより明白ですが、暗号化、特にメッセージの一部の暗号化にも適用される場合があります。時には、平易なテキストデータが見つかった環境の要素がその解釈に影響を与える可能性があります。たとえば、解釈は、ダミーシンボルのエンコードまたはバインディングによって影響を受ける可能性があります。データが復号化されると、異なる文字エンコードまたはダミーシンボルのバインディングがある環境にある可能性があります。単純なテキストメッセージの部分を使用すると、これらの環境要素のどれをメッセージに組み込むか、伝達する必要があるかが通常明確です。しかし、暗号化されたメッセージ部分は不透明です。したがって、このような環境要因を組み込んだいくつかの標準的な表現が必要になる場合があります。
DOCUM: Encryption of the entire document is usually what is considered. Because signatures are always thought of as human assent, people with a document point of view tend to vehemently assert that encrypted data should never be signed unless the plain text of it is known.
Docum：通常、ドキュメント全体の暗号化が考慮されるものです。署名は常に人間の同意と考えられているため、文書の視点を持つ人々は、暗号化されたデータが知られていない限り、暗号化されたデータに署名しないでくださいと激しく主張する傾向があります。
PROTO: Messages are complex composite multi-level structures, some pieces of which are forwarded multiple hops. Thus the design question is what fields should be encrypted by what techniques to what destination or destinations and with what canonicalization.
proto：メッセージは複雑な複合マルチレベル構造で、その一部は複数のホップを転送します。したがって、デザインの問題は、どのようなテクニックがどのような目的地や目的地や目的地にどのような技術と、どのような標準化によって暗号化されるべきかです。
It sometimes makes perfect sense to sign encrypted data you don't understand; for example, the signature could just be for integrity protection or for use as a time stamp, as specified in the protocol.
理解していない暗号化されたデータに署名することは完全に理にかなっています。たとえば、署名は、プロトコルで指定されているように、整合性保護またはタイムスタンプとして使用するためのものです。
It is desirable to be able to reference parts of structured messages or objects by some sort of "label" or "id" or "tag". The idea is that this forms a fixed "anchor" that can be used "globally", at least within an application domain, to reference the tagged part.
構造化されたメッセージまたはオブジェクトの部分を、何らかの「ラベル」または「ID」または「タグ」で参照できることが望ましいです。アイデアは、これにより、少なくともアプリケーションドメイン内で「グローバルに」使用できる固定された「アンカー」を形成して、タグ付けされた部分を参照するということです。
DOCUM: From the document point of view, it seems logical just to provide for a text tag. Users or applications could easily come up with short readable tags. These would probably be meaningful to a person if humanly generated (e.g., "Susan") and at least fairly short and systematic if automatically generated (e.g., "A123"). The ID attribute type in XML [XML] appears to have been thought of this way, although it can be used in other ways.
Docum：ドキュメントの観点から、テキストタグを提供するだけで論理的に思えます。ユーザーまたはアプリケーションは、読みやすいタグを簡単に作成できます。これらはおそらく、人間が生成された場合（「スーザン」など）、自動的に生成された場合（「A123」など）、少なくともかなり短く、体系的な人にとって意味があります。XML [XML]のID属性タイプは、このように考えられていたようですが、他の方法で使用できます。
PROTO: From a protocol point of view, unique internal labels look very different than they do from a document point of view. Since this point of view assumes that pieces of different protocol messages will later be combined in a variety of ways, previously unique labels can conflict. There are really only three possibilities if such tags are needed, as follows:
Proto：プロトコルの観点から、一意の内部ラベルは、ドキュメントの観点からは非常に異なって見えます。この観点は、異なるプロトコルメッセージの一部が後でさまざまな方法で組み合わされると仮定しているため、以前はユニークなラベルが矛盾する可能性があります。次のように、そのようなタグが必要な場合、実際には3つの可能性しかありません。
(1) Have a system for dynamically rewriting such tags to maintain uniqueness. This is usually a disaster, as it (a) invalidates any stored copies of the tags that are not rewritten, and it is usually impossible to be sure there aren't more copies lurking somewhere you failed to update, and (b) invalidates digital signatures that cover a changed tag. (2) Use some form of hierarchical qualified tags. Thus the total tag can remain unique even if a part is moved, because its qualification changes. This avoids the digital signature problems described above. But it destroys the concept of a globally-unique anchor embedded in and moving with the data. And stored tags may still be invalidated by data moves. Nevertheless, within the scope of a particular carefully designed protocol, such as IOTP [RFC2801], this can work. (3) Construct a lengthy globally-unique tag string. This can be done successfully by using a good enough random number generator and big enough random tags (perhaps about 24 characters) sequentially, as in the way email messages IDs are created [RFC2822].
(1) このようなタグを動的に書き換えて、一意性を維持するシステムがあります。これは通常、（a）書き換えられていないタグの保存されたコピーを無効にするため、通常は災害です。通常、更新に失敗した場所に潜んでいるコピーがこれ以上ないことを確認することは不可能です。変更されたタグをカバーする署名。（2）何らかの形の階層的資格のタグを使用します。したがって、資格が変化するため、部品が移動されても、合計タグは一意のままになります。これにより、上記のデジタル署名の問題が回避されます。しかし、それは、データに埋め込まれ、データに移動されたグローバルにないアンカーの概念を破壊します。保存されたタグは、データの動きによってまだ無効になる場合があります。それにもかかわらず、IOTP [RFC2801]などの特定の慎重に設計されたプロトコルの範囲内で、これは機能します。（3）グローバルに長いタグ文字列を構築します。これは、電子メールメッセージIDが作成される方法のように、十分なランダム数ジェネレーターと十分なランダムタグ（おそらく約24文字）を順番に使用することで正常に実行できます[RFC2822]。
Thus, from a protocol point of view, such tags are difficult but if they are needed, choice 3 works best.
したがって、プロトコルの観点からは、そのようなタグは困難ですが、必要な場合は選択3が最適です。
IETF protocols are replete with examples of the protocol viewpoint such as TCP [RFC793], IPSEC [RFC2411], SMTP [RFC2821], and IOTP [RFC2801, RFC2802].
IETFプロトコルには、TCP [RFC793]、IPSEC [RFC2411]、SMTP [RFC2821]、IOTP [RFC2801、RFC2802]などのプロトコルの観点の例が豊富にあります。
The eXtensible Markup Language [XML] is an example of something that can easily be viewed both ways and where the best results frequently require attention to both the document and the protocol points of view.
拡張可能なマークアップ言語[XML]は、両方の方法で簡単に表示できるものの例であり、最良の結果がドキュメントとプロトコルの両方の視点に注意を頻繁に必要とする場合です。
Computerized court documents, human-to-human email, and the X.509v3 Certificate [X509v3], particularly the X509v3 policy portion, are examples primarily designed from the document point of view.
コンピューター化された裁判所の文書、人間から人間への電子メール、X.509v3証明書[X509V3]、特にX509V3ポリシー部分は、主に文書の観点から設計された例です。
There is some merit to each point of view. Certainly the document point of view has some intuitive simplicity and appeal and is OK for applications where it meets needs.
各視点にはいくつかのメリットがあります。確かに、ドキュメントの視点には直感的なシンプルさと魅力があり、ニーズを満たすアプリケーションでは問題ありません。
The protocol point of view can come close to encompassing the document point of view as a limiting case. In particular, it does so under the following circumstances:
プロトコルの視点は、制限的なケースとして文書の視点を網羅することに近づくことができます。特に、次の状況下でそうします。
1. As the complexity of messages declines to a single payload (perhaps with a few attachments).
1. メッセージの複雑さが単一のペイロードに低下するにつれて（おそらくいくつかの添付ファイルがあります）。
2. As the mutability of the payload declines to some standard format that needs little or no canonicalization.
2. ペイロードの可変性は、標準化をほとんどまたはまったく必要とする標準形式に低下します。
3. As the number of parties and amount of processing declines as messages are transferred.
3. メッセージが転送されると、当事者の数と処理の量が減少するにつれて。
4. As the portion of the message intended for more or less direct human consumption increases.
4. 多かれ少なかれ直接的な人間の消費を目的としたメッセージの部分が増加するにつれて。
Under the above circumstances, the protocol point of view would be narrowed to something quite close to the document point of view. Even when the document point of view is questionable, the addition of a few options to a protocol will usually mollify the perceived needs of those looking at things from that point of view. For example, adding optional non-canonicalization or an optional policy statement, or inclusion of semantic labels, or the like.
上記の状況では、プロトコルの視点は、文書の視点に非常に近いものに絞り込まれます。ドキュメントの視点が疑わしい場合でも、プロトコルにいくつかのオプションを追加すると、通常、その観点から物事を見ている人の知覚されたニーズが緩和されます。たとえば、オプションの非標準化またはオプションのポリシーステートメントの追加、またはセマンティックラベルなどを含めるなど。
On the other hand, the document point of view is hard to stretch to encompass the protocol case. From a strict piece of paper perspective, canonicalization is wrong; inclusion of human language policy text within every significant object and a semantic tag with every adjunct should be mandatory; and so on. Objects designed in this way are rarely suitable for protocol use, as they tend to be improperly structured to accommodate hierarchy and complexity, inefficient (due to unnecessary text and self-documenting inclusions), and insecure (due to brittle signatures).
一方、ドキュメントの視点は、プロトコルのケースを含めるために伸びるのが難しいです。厳格な紙の観点から、標準化は間違っています。すべての重要なオブジェクトに人間の言語ポリシーテキストを含めることと、すべての付属物を伴うセマンティックタグは必須である必要があります。等々。このように設計されたオブジェクトは、階層と複雑さ、非効率的（不必要なテキストと自己文書化の包含物のため）、および安全で（脆性署名のため）に不適切に構造化される傾向があるため、プロトコルの使用に適していることはほとんどありません。
Thus, to produce usable protocols, it is best to start with the protocol point of view and add document point of view items as necessary to achieve consensus.
したがって、使用可能なプロトコルを作成するには、プロトコルの視点から始めて、コンセンサスを達成するために必要なドキュメントポイント項目を追加することをお勧めします。
I hope that this document will help explain to those of either point of view where those with the other view are coming from. It is my hope that this will decrease conflict, shed some light -- in particular on the difficulties of security design -- and lead to better protocol designs.
この文書が、他の見解を持つ人々が来ている人のいずれかの視点の人々に説明するのに役立つことを願っています。これが競合を減らし、特にセキュリティ設計の難しさに光を当て、より良いプロトコル設計につながることを願っています。
This document considers the security implications of the Document and Protocol points of view, as defined in Sections 2.1 and 2.2, and warns of the security defects in the Document view. Most of these security considerations appear in Section 2.4 but they are also touched on elsewhere in Section 2 which should be read in its entirety.
このドキュメントでは、セクション2.1および2.2で定義されているように、ドキュメントとプロトコルの視点のセキュリティへの影響を考慮し、ドキュメントビューのセキュリティ欠陥を警告します。これらのセキュリティ上の考慮事項のほとんどはセクション2.4に表示されますが、セクション2の他の場所でも触れられています。
Informative References
参考引用
[ASCII] "USA Standard Code for Information Interchange", X3.4, American National Standards Institute: New York, 1968.
[ASCII]「情報インターチェンジの米国標準コード」、X3.4、アメリカ国立標準研究所：ニューヨーク、1968。
[ASN.1] ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998, "Information Technology - Abstract Syntax Notation One (ASN.1): Specification of Basic Notation".
[ASN.1] ITU-T推奨X.680（1997）|ISO/IEC 8824-1：1998、「情報技術 - 要約構文表記1（ASN.1）：基本表記の仕様」。
ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998, "Information Technology - ASN.1 Encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)". <http://www.itu.int/ITU-T/studygroups/com17/languages/index.html>.
ITU-T推奨X.690（1997）|ISO/IEC 8825-1：1998、「情報技術-ASN.1エンコーディングルール：基本エンコードルール（BER）、標準エンコーディングルール（CER）、および区別されたエンコードルール（DER）の仕様」。<http://www.itu.int/itu-t/studygroups/com17/languages/index.html>。
[CSS] "Cascading Style Sheets, level 2 revision 1 CSS 2.1 Specification", B. Bos, T. Gelik, I. Hickson, H. Lie, W3C Candidate Recommendation, 25 February 2004. <http://www.w3.org/TR/CSS21>
[CSS]「カスケードスタイルシート、レベル2改訂1 CSS 2.1仕様」、B。ボス、T。ジェリック、I。ヒクソン、H。リー、W3C候補の推奨、2004年2月25日。<http：//www.w3。org/tr/css21>
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045] Freed、N。およびN. Borenstein、「多目的インターネットメールエクステンション（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[RFC2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[RFC2411] Thayer、R.、Doraswamy、N。、およびR. Glenn、「IP Security Document Roadmap」、RFC 2411、1998年11月。
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[RFC3852] Housley、R。、「暗号化メッセージ構文（CMS）」、RFC 3852、2004年7月。
[RFC2801] Burdett, D., "Internet Open Trading Protocol - IOTP Version 1.0", RFC 2801, April 2000.
[RFC2801] Burdett、D。、「インターネットオープントレーディングプロトコル-IOTPバージョン1.0」、RFC 2801、2000年4月。
[RFC2802] Davidson, K. and Y. Kawatsura, "Digital Signatures for the v1.0 Internet Open Trading Protocol (IOTP)", RFC 2802, April 2000.
[RFC2802] Davidson、K。およびY. Kawatsura、「V1.0 Internet Open Trading Protocol（IOTP）のデジタル署名」、RFC 2802、2000年4月。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821]クレンシン、J。、「Simple Mail Transfer Protocol」、RFC 2821、2001年4月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2822] Resnick、P。、「インターネットメッセージ形式」、RFC 2822、2001年4月。
[RFC3076] Boyer, J., "Canonical XML Version 1.0", RFC 3076, March 2001.
[RFC3076] Boyer、J。、「Canonical XMLバージョン1.0」、RFC 3076、2001年3月。
[RFC3275] Eastlake 3rd, D., Reagle, J., and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, March 2002.
[RFC3275] EastLake 3rd、D.、Reagle、J。、およびD. Solo、 "（拡張可能なマークアップ言語）XML-Signature構文と処理"、RFC 3275、2002年3月。
[RFC3741] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3741] Berger、L。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナル伝達機能説明」、RFC 3471、2003年1月。
[X509v3] "ITU-T Recommendation X.509 version 3 (1997), Information Technology - Open Systems Interconnection - The Directory Authentication Framework", ISO/IEC 9594- 8:1997.
[X509V3]「ITU -T推奨X.509バージョン3（1997）、情報技術 - オープンシステムの相互接続 - ディレクトリ認証フレームワーク」、ISO/IEC 9594- 8：1997。
[XForms] "XForms 1.0", M. Dubinko, L. Klotz, R. Merrick, T. Raman, W3C Recommendation 14 October 2003. <http://www.w3.org/TR/xforms/>
[Xforms] "Xforms 1.0"、M。Dubinko、L。Klotz、R。Merrick、T。Raman、W3C推奨2003年10月14日。<http://www.w3.org/tr/xforms/>
[XML] "Extensible Markup Language (XML) 1.0 Recommendation (2nd Edition)". T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, October 2000. <http://www.w3.org/TR/2000/REC-xml-20001006>
[XML]「拡張可能なマークアップ言語（XML）1.0推奨（第2版）」」。T. Bray、J。Paoli、C。M。Sperberg-Mcqueen、E。Maler、2000年10月。
[XMLENC] "XML Encryption Syntax and Processing", J. Reagle, D. Eastlake, December 2002. <http://www.w3.org/TR/2001/RED-xmlenc-core-20021210/>
[xmlenc] "xml暗号化構文と処理"、J。Reagle、D。Eastlake、2002年12月。
Author's Address
著者の連絡先
Donald E. Eastlake 3rd Motorola Laboratories 155 Beaver Street Milford, MA 01757 USA
ドナルドE.イーストレイク第3モトローラ研究所155ビーバーストリートミルフォード、マサチューセッツ州01757 USA
Phone: +1 508-786-7554 (w)
+1 508-634-2066 (h)
Fax: +1 508-786-7501 (w)
EMail: Donald.Eastlake@motorola.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（2004）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and at www.rfc-editor.org, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78およびwww.rfc-editor.orgに含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the ISOC's procedures with respect to rights in ISOC Documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。ISOCドキュメントの権利に関するISOCの手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。