RFC3930 日本語訳
3930 The Protocol versus Document Points of View in ComputerProtocols. D. Eastlake 3rd. October 2004. (Format: TXT=36892 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Eastlake 3rd Request for Comments: 3930 Motorola Laboratories Category: Informational October 2004
コメントを求めるワーキンググループのD.イーストレーク第3要求をネットワークでつないでください: 3930年のモトローラ研究所カテゴリ: 情報の2004年10月
The Protocol versus Document Points of View in Computer Protocols
プロトコル対コンピュータプロトコルのドキュメント観点
Status of this Memo
この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).
Copyright(C)インターネット協会(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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 観点. . . . . . . . . . . . . . . . . . . . . . . . 2 2.1。 基本的な観点. . . . . . . . . . . . . . . . 3 2.2。 意味. . . . . . . . . . . . . . . . . . 3 2.2.1の問題。 コア意味. . . . . . . . . . . . . . . . . . 3 2.2.2。 付属物意味。 . . . . . . . . . . . . . . . . 4 2.3. 処理はモデル化されます。 . . . . . . . . . . . . . . . . . . . 5 2.3.1. 処理. . . . . . . . . . . . . . 5 2.3.2の量。 処理の粒状。 . . . . . . . . . . . 5 2.3.3. 処理の伸展性。 . . . . . . . . . . 6 2.4. セキュリティとCanonicalization。 . . . . . . . . . . . . . 6 2.4.1. Canonicalization. . . . . . . . . . . . . . . . 6 2.4.2。 デジタル認証. . . . . . . . . . . . . 8 2.4.3。 Canonicalizationとデジタル認証。 . . 8 2.4.4. 暗号化. . . . . . . . . . . . . . . . . . . 9 2.5。 ユニークな内部のラベル. . . . . . . . . . . . . . . . . 10 3。 例. . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4。 観点. . . . . . . . . . . . . . . 11の解決
Eastlake Informational [Page 1] RFC 3930 Protocol versus Document Viewpoints October 2004
イーストレーク情報[1ページ]のRFC3930Protocol対ドキュメント観点2004年10月
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations. . . . . . . . . . . . . . . . . . . . 12 Informative References . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 15
5. 結論. . . . . . . . . . . . . . . . . . . . . . . . . . 12 6。 セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 12 有益な参照. . . . . . . . . . . . . . . . . . . . . . 12作者のアドレスの.14の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
1. 序論
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.
このドキュメントは対照をなします: そこでは、興味があるデジタル物が人々によって書かれて、見られた論文の枚として考えられます。「ドキュメント」観点、および「プロトコル」観点。そこでは、興味がある物が合成ダイナミックなネットワークメッセージです。 1つの観点に慣れているものは頻繁にもう片方に感謝することにおける重大な苦労をします: それを理解した後にさえ、彼らは彼らのいつもの観点からものを考えることによって、ほとんどいつも始めます、そして、興味がある宇宙の大部分がそれらの見解から最も上手に見られると仮定してください、そして、一般的に完全にその観点からものについて考えるのに悪くなってください。 各観点は位置を占めますが、ドキュメント観点への固守は、デザインについて議定書の中で述べるためにダメージが大きい場合があります。 両方の観点を理解していることによって、それらの間の闘争は、はっきりさせられて、抑えられるかもしれません。
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の伝統的な仕事の多くが低い平らな2進のプロトコル構造物に関係がありました。 これらはプロトコル観点からほとんどいつも見られます。 しかし、より高い平らなアプリケーション構造物と構文が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は、合理的にいずれにせよ見ることができる領域で視点を統合して、一般的なデザインアドバイスを与えようとします。
2. Points of View
2. 観点
The following subsections contrast the document and protocol points of view. Each viewpoint is EXAGGERATED for effect.
以下の小区分はドキュメントとプロトコル観点を対照します。 各観点は効果のためのEXAGGERATEDです。
The document point of view is indicated in paragraphs headed "DOCUM", and the protocol point of view is indicated in paragraphs headed "PROTO".
ドキュメント観点は示されて、パラグラフでは、"DOCUM"が向かっていて、プロトコル観点がパラグラフの頭の「プロト」で示されるということです。
Eastlake Informational [Page 2] RFC 3930 Protocol versus Document Viewpoints October 2004
イーストレーク情報[2ページ]のRFC3930Protocol対ドキュメント観点2004年10月
2.1. The Basic Points of View
2.1. 基本的な観点
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.
プロト: 重要なことは明確なコンピュータプロトコル工程で発生して、消費されたワイヤのビットです。 どんな人もそういうものの完全なメッセージを見ません。 デバッグするときだけ、それはおたくによって全体で見られます、そして、その時でさえ、彼らは何らかの翻訳された目に見えるフォームを見るだけです。 人が実際にそのようなメッセージに関して法廷か第三者に何かを示さなければならないなら、コンピュータの専門家にそれを解釈させるのを避ける少しの方法もありません。 時々、人に表示されたデータに含まれているか、または影響を及ぼす場合そのようなメッセージの断片が終わったかもしれないのが忘れられています。
2.2. Questions of Meaning
2.2. 意味の問題
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.
観点のこの違いはコア意味を超えてデータへの付加物の意味に広がっています。 以下でコアと付加物意味の両方について議論します。
2.2.1. Core Meaning
2.2.1. コア意味
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: ドキュメントの「意味」は意志に関連する深くておもしろい人間の問題です。 それがたぶん含んでいるドキュメントか参照人間言語政策、そして/または、保証/注意書き情報に必要です。 絶対最小値では、ある種の意味ラベルが必要です。 いつも想定された状況は他の文脈なしで全体の「ドキュメント」を解釈する人です。 したがって、メッセージデザインの間、弁護士に相談するのは、人間読み込み可能な声明がドキュメントの「全領域」であることなどが必要であるように妥当です。
Eastlake Informational [Page 3] RFC 3930 Protocol versus Document Viewpoints October 2004
イーストレーク情報[3ページ]のRFC3930Protocol対ドキュメント観点2004年10月
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.
プロト: プロトコルメッセージの「意味」は、プロトコル仕様から明確であって、明白であるべきです。 それには、頻繁に送付者と受取人の過程の州のマシンに関して定義されて、最もリモートな接続しか人間の意志をもってないかもしれません。 そのような過程に、追加文脈があります、そして、通常、メッセージはその追加文脈によって重要であるだけです。 機能上必要でない少しの人間読み込み可能なテキストも加えるのは愚かです。 デザインの間、弁護士に相談するのは、プロトコルを複雑にして、結びでデザインの努力を結ぶことができた悪い考えです。
2.2.2. Adjunct Meaning
2.2.2. 付属物意味
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: ドキュメント観点から、レベルは先端では、ドキュメントを見ている人です。 それで、意味に関して慎重にデジタル署名、人の名前、日付などの付属物の品目をラベルしなければなりません。 したがって、デジタル署名は、多少人間読み込み可能なフォームにその署名が意味することを含む必要があります(署名者が目撃者、作者、保証人、authorizerですかそれとも何ですか?)。 同様に、人の名前は、エディタ、作者、対象、または貢献者などのその人の役割によって伴われる必要があります。 別の例として、日付は、日付の意味によって伴われる必要があります、創造、変更、分配、またはある他の出来事の日付などのように。 記録できることに関する気ままな範囲を考えて、デザイン過程で各種類の付属データのためのすべての可能な「意味タグ」を列挙して、標準化するトライのリスクがあります。 これは難しくて、複雑で、本質的には無限のタスクであるかもしれません(すなわち、ネズミの通る穴)。
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.
プロト: プロトコル観点から、メッセージの意味論とそれのあらゆる付属物がプロトコル仕様に基づき定義されます。 したがって、スロットがデジタル署名、人の名前、日付、または何でものためにあれば、そのデータかパーティーかそれを読むことになっているパーティーと、その意味を入力することになっているパーティーは皆、あらかじめ定義されます。 いくつかの可能な意味があっても、別々の列挙型分野で適用される特定の意味は指定できます。 そのような分野が人間直接読み込み可能になる理由が全くありません。 直接特定のプロトコルに関連している「意味」だけ、が考えられなければなりません。 これを見る別の方法はドキュメント観点が奨励するので、付属物自体に押し込まれて、結びつけられることの代わりにそれぞれの付属物の「意味」が一般的にプロトコル仕様のレベルに促進されるということです、より簡単な付属物をもたらして。
Eastlake Informational [Page 4] RFC 3930 Protocol versus Document Viewpoints October 2004
イーストレーク情報[4ページ]のRFC3930Protocol対ドキュメント観点2004年10月
2.3. Processing Models
2.3. 処理モデル
The document oriented and protocol oriented have very different views on what is likely to happen to an object.
適応するドキュメントと適応するプロトコルは何が物に起こりそうであるかに関する非常に異なった意見を持っています。
2.3.1. Amount of Processing
2.3.1. 処理の量
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.
プロト: ソース工程で作成されて、目的地工程で消費されたはかない合成していて、マルチレベルの物としてプロトコルメッセージのスタンダード・モデルはいます。 そのようなメッセージは以前に受信されたメッセージに含まれた情報、局所的に記憶された情報、ローカルな計算などから構成されます。 かなり複雑な処理は通常です。
2.3.2. Granularity of Processing
2.3.2. 処理の粒状
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.
プロト: 処理は、複雑であり、ほとんどいつもメッセージの異なった断片に異なって影響します。 いくつかの断片が、使用のために目的地の過程だけで意図して、手広くそこに処理されるかもしれません。 他のものは、目的地の過程が何らかのポイントで最小量の処理をして、他のメッセージでまだより多くの過程に彼らを送ることができるように、出席しているかもしれません。 物の構造は、かなり豊かであり、多レベルか再帰的な局面を持つことができます。 メッセージがローカルの関係で処理されるので、メッセージの要素はそれの或るものがメッセージにある複数のデータ要素をカバーする署名のような項目を含むかもしれません、と或るものが前のメッセージで受けて、或るものは局所的に見込みました。
Eastlake Informational [Page 5] RFC 3930 Protocol versus Document Viewpoints October 2004
イーストレーク情報[5ページ]のRFC3930Protocol対ドキュメント観点2004年10月
2.3.3. Extensibility of Processing
2.3.3. 処理の伸展性
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.
プロト: プロトコル指向のものはそれがプロトコルが、いつも広げられる必要があって、そのような拡大が配備されるときすべての実現をアップデートするのにおいて可能である、そして/または、退職しないと仮定します。 これは難問ですが、プロトコル観点からのものは必要であるツールを提供しようとします。 例えば、彼らは可能であるところでバージョンと特徴を交渉する能力と少なくとも異なったレベルを走らせているパーティーがどう相互作用するべきであるかに関する仕様を含んでいて、それをスキップするか、または理解できるようにすべてのデータのための長さ/区切り情報を提供して、過程が、それを通過するのを除いたデータを無視するべきであると言うことができるように目的地ラベルを提供するのを後のプレーヤーにとって突き抜けるとラベルする慎重に定義されたversioningと拡大/特徴を指定します。
2.4. Security and Canonicalization
2.4. セキュリティとCanonicalization
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で深く強壮にからませられます。 また、認証と暗号化において、それらも以下で議論するようにいくらか異なっています。
2.4.1. Canonicalization
2.4.1. Canonicalization
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
Canonicalizationは「標準」のフォームへのメッセージの、「重要な」情報の変化です、例えば、encodingsを終わらせるオリジナルの文字の組か線の情報をコード化して、捨てる規格への結末を標準文字セットか変化線にコード化しながら「無意味に」情報を捨てて。 明らかに、「重要な」ことと「無意味に」ことは、アプリケーションかプロトコルで異なって、決定するために扱いにくい場合があります。 しかしながら、それは、コモンのASCIIなどの特定のそれぞれの構文のためのそれ[ASCII]、ASN.1[ASN.1]、またはXML[XML]です。
Eastlake Informational [Page 6] RFC 3930 Protocol versus Document Viewpoints October 2004
イーストレーク情報[6ページ]のRFC3930Protocol対ドキュメント観点2004年10月
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].)
標準のcanonicalization(または、canonicalizations)は習慣で指定されるか、または開発されます。 これはそのような標準のcanonicalizationsの1つを仮定するアプリケーションの設計に通じます、その結果、1アプリケーションあたりのcanonicalizationの必要性を減少させます。 (また、[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: ドキュメント観点から、canonicalizationは疑わしいか完全な弊害です。 結局、それを書き続けるのがある1枚の紙がありましたら、「作者」(人としていつも想像される)によって作成されるように形式を「標準化する」どんな変更もオリジナルのメッセージで未承認の変更であるかもしれません。 デジタル署名は「紙の枚」の下部で署名、シールまたはタイムスタンプを認証しているようです。 彼らが正当化しないで、メッセージ排臨で変化によるべきでない、それら。 同様に、暗号化は、ただ人々が開くことができるのをそんなに確信しているだけの金庫に「紙の枚」を入れていて、メッセージの標準化かいずれのもcanonicalizationを正当化しません。
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.
プロト: プロトコル観点から、canonicalizationは単に必要性です。 それはただ計算されるビットのパターンに適用する処理されて、格納されたcanonicalizationかcanonicalizationsがまさに何で交信して、最終的に分析して、オンに作動したかという問題です。 これらのビットの大部分は、一度も見られたことがなくて、人によって決して見られないでしょう。 事実上、メッセージの部分の多くが、コード化の人工物と、プロトコル構造と、コンピュータ表現になるでしょう人が見ることを意図するものは何よりもむしろ。 恐らく理論上「オリジナル」、どんなデジタルにサインされた部分の特有のフォームも、プロトコルを実行するコンピュータの過程、格納、およびコミュニケーションチャンネルで変わりがない状態で運ぶことができて、有効にそのフォームにサインインすることができました。 しかし、どんな複雑さの実用的なシステムではも、少なくともメッセージの大部分には、これは無分別に難しいです。 そして、それが可能であるなら、実際には役に立たないでしょうに、あなたはメッセージを認証するためにまだ保存された原型があるそれらの等価性を決定しなければならないでしょう、したがって。 処理、格納、およびコミュニケーションで作られた重要でない変更を補うために調印と検証の一部としてこのようにしてサインされたデータをcanonicalizedしなければなりません。 初期のシステム設計が奇跡的に処理データに基づく、サインされたメッセージ再建、文字の組、線結末、資源化、数値表現または時間帯に基づく再コード化または何でもに関するすべてのケースを避けても、後のプロトコル改正と拡大は結局そのような再建、そして/または、再コード化を必要とするのが確かです。 そのような「無意味に」変化がcanonicalizationによって改善されないと、署名がさらに詳細に中で議論するように働かない、2.4、.3未満
Eastlake Informational [Page 7] RFC 3930 Protocol versus Document Viewpoints October 2004
イーストレーク情報[7ページ]のRFC3930Protocol対ドキュメント観点2004年10月
2.4.2. Digital Authentication
2.4.2. デジタル認証
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]の一部に書き込んで、サインできるように主要な活動が人間にフォームを提示していると信じているドキュメント観点の部分集合です。) 心配がいつもほとんど人間の第三者と分離してドキュメントを見ることであるので、ドキュメント指向のものはいつも「デジタル署名」(非対称のキー)認証を必要とします、「非repudiability」などの特性で その結果、彼らは秘密の主要なベースのメッセージ確認コードを拒絶します、役に立たないとして。(メッセージ確認コードは認証子を作り出す能力を検証に提供します)。 (これらの用語の普通の意味に関してこの件に関するあらゆる標準の参照を見てください。) 彼らの観点から、あなたは人がサインする紙か1通の書類を持っています。 時々、署名は形式の一部だけを覆っていますが、通常、署名が既にそこにあるデータをカバーできるだけであるので、それはそうです。 そして、通常、少なくとも1つの署名が「全体」のドキュメント/フォームをカバーしています。 したがって、適応するドキュメントはドキュメントタイプを変えないでデジタル署名をドキュメントに挿入できるようになりたがっています、そして、データ存在の“inside"さえサインされて、どれが署名をサボるためにメカニズムを必要とするかので、それはそれ自体にサインしようとしません。
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.
プロト: プロトコル観点、使用する認証の正しい種類「デジタル署名」か左右対称の合わせられた認証コードである、(バイオメトリックであるかすべて)、ただの工学決定は効率の質問、必要な機密保護モデルなどで影響を受けます。 その上、「全体」のメッセージにサインする概念は非常に独特に見えます(それが保存目的のために保存されるコピーでないなら、その場合、あなたはすぐに、とにかく全体のアーカイブにサインするかもしれません)。 典型的なメッセージは様々な目的地、ソース、およびセキュリティ要件で様々な断片から作られます。 その上、メッセージが伝えられて、処理されるとき変化するので、サインするのがめったに役に立たない共同耕地があります。 例はホップカウント、ルーティング歴史、および地方の推進タグを含んでいます。
2.4.3. Canonicalization and Digital Authentication
2.4.3. Canonicalizationとデジタル認証
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) 「あまりに小さいcanonicalization」ともろい認証を持っていること表面表現変化によって意味なしで引き起こされた検証失敗のために役に立たない。
Eastlake Informational [Page 8] RFC 3930 Protocol versus Document Viewpoints October 2004
イーストレーク情報[8ページ]のRFC3930Protocol対ドキュメント観点2004年10月
(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) 認証世代と検証の一部、生産の強健で役に立つ認証として使用されるように適切なcanonicalizationかcanonicalizationsを選択するか、または設計する時々難しくて扱いにくい仕事。
(3) "too much canonicalization" and having insecure authentication,
useless because it still verifies even when significant changes
are made in the signed data.
(3) 「あまりに多くのcanonicalization」と不安定な認証を持っていること著しい変化がいつサインされたデータで作られさえするかをまだ確かめているので役に立たない。
The only useful option above is number 2.
上の唯一の役に立つオプションがNo.2です。
2.4.4. Encryption
2.4.4. 暗号化
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.
処理、トランスミッション、および格納で、暗号化は署名よりはるかに得やすい働きであると判明します。 なぜですか? 暗号化の出力が本質的には無作為のビットであるので。 始めから、それらのビットが、1ビットさえ変えない何らかの絶対に清潔な方法で目的地に移される必要があるのは、明確です。 人間にとって、コード化されたビットが無意味であるので、それらをより「読み込み可能に」しようとするように適応するドキュメントの中に誘惑が全くありません。 目的地で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.
canonicalizationのアプリケーションはデジタル署名で、より明白ですが、また、それは暗号化(特にメッセージの部分の暗号化)に適用されるかもしれません。 時々、プレーンテキストデータが見つけられる環境の要素は解釈に影響するかもしれません。 例えば、解釈は代役記号のキャラクタコード化か結合で影響を受けることができます。 データが解読されるとき、環境にはそれが異なったキャラクタコード化か代役記号結合と共にあるかもしれません。 プレーンテキストメッセージ部分について、通常、これらの環境要素のどれが、メッセージで法人組織か運ばれる必要があるかは、明確です。 しかし、暗号化メッセージ部分は不透明です。 したがって、そのような環境要因を取り入れる何らかの正準な表現が必要であるかもしれません。
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.
プロト: メッセージは複雑な合成マルチレベル構造です。複数のホップがそれのいくつかの断片に送られます。 したがって、デザイン質問はどんな分野がどんな目的地か目的地とどんなcanonicalizationでどんなテクニックでコード化されるべきであるかということです。
Eastlake Informational [Page 9] RFC 3930 Protocol versus Document Viewpoints October 2004
イーストレーク情報[9ページ]のRFC3930Protocol対ドキュメント観点2004年10月
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.
それは時々あなたが理解していないコード化されたデータにサインする完全な意味になります。 例えば、署名はタイムスタンプとしてただ保全保護か使用のためのものであるかもしれません、プロトコルで指定されるように。
2.5. Unique Internal Labels
2.5. ユニークな内部のラベル
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.
ある種の「ラベル」、「イド」または「タグ」で構造化されたメッセージかオブジェクトの参照一部にできるのは望ましいです。 考えはこれが「グローバルに」使用できる固定「アンカー」を形成するということです、少なくともアプリケーションドメインの中で、参照へのタグ付けをされた部分。
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:
プロト: プロトコル観点から、ユニークな内部のラベルはドキュメント観点からするより非常に異なるように見えます。 この観点が、異なったプロトコルメッセージの断片が後でさまざまな方法で結合されると仮定するので、以前にユニークなラベルは闘争できます。 本当に、そのようなタグが以下の通り必要であるなら、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)は書き直されないタグのどんな保存されたコピーも無効にします、そして、通常、以上がないのを確信しているのがどこかでのあなたがアップデートしなかった潜行をコピーして、(b)が変えられたタグをカバーするデジタル署名を無効にするのは、不可能です。 (2) 何らかの形式の階層的な適切なタグを使用してください。 したがって、部分が動かされても、資格が変化するので、総タグはユニークなままであることができます。 これは上で説明されたデジタル署名問題を避けます。 しかし、それは、データで埋め込まれたグローバルにユニークなアンカーの概念を無効にして、移行します。 そして、保存されたタグはデータ移動でまだ無効にされているかもしれません。 それにもかかわらず、IOTPなどの特定の入念に設計されたプロトコル[RFC2801]の範囲の中では、これは働くことができます。 (3) 長いグローバルにユニークなタグストリングを構成してください。 十分良い乱数発生器と十分大きい無作為のタグ(恐らくおよそ24のキャラクタ)を連続して、使用することによって、これが首尾よくできます、メールメッセージIDが作成される方法[RFC2822]のように。
Eastlake Informational [Page 10] RFC 3930 Protocol versus Document Viewpoints October 2004
イーストレーク情報[10ページ]のRFC3930Protocol対ドキュメント観点2004年10月
Thus, from a protocol point of view, such tags are difficult but
if they are needed, choice 3 works best.
したがって、プロトコル観点から、そのようなタグは難しいのですが、それらが必要であるなら、特選している3はうまくいきます。
3. Examples
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.
eXtensible Markup Language[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 Certificate[X509v3]、特にX509v3方針部分であるとコンピューター化されているのは、ドキュメント観点から主として設計された例です。
4. Resolution of the Points of View
4. 観点の解決
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.
各観点への何らかの長所があります。 確かに、ドキュメント観点は、何らかの直感的な簡単さとアピールを持って、それがニーズを満たすアプリケーションには、OKです。
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. ペイロードの無常が何らかの標準書式に減退するとき、それはまずcanonicalizationを必要としません。
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.
上記の状況で、プロトコル観点は全くドキュメント観点の近くで何かに狭くされるでしょう。 ドキュメント観点が疑わしいときにさえ、通常、プロトコルへのいくつかのオプションの追加は慰めるでしょう。ものがその観点からものを見る知覚された必要性。 例えば、任意の非canonicalizationか任意の施政方針を加えるか、または意味ラベル、または同様のものの包含。
Eastlake Informational [Page 11] RFC 3930 Protocol versus Document Viewpoints October 2004
イーストレーク情報[11ページ]のRFC3930Protocol対ドキュメント観点2004年10月
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).
他方では、ドキュメント観点は、プロトコルケースを包含するように伸ばしにくいです。 厳しい紙の見解から、canonicalizationは間違っています。 あらゆる重要なオブジェクトと意味タグの中のあらゆる付属物がある人間の言語政策テキストの包含は義務的であるべきです。 など。 このように設計されたオブジェクトはめったにプロトコル使用に適していません、階層構造と複雑さに対応するために不適切に構造化されていて、効率が悪くて(不要なテキストと自己を記録する包含による)、不安定である(もろい署名による)傾向があるとき。
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.
したがって、使用可能なプロトコルを作成するために、プロトコル観点から始まって、コンセンサスを達成するために必要に応じてドキュメント観点の品目を加えるのは最も良いです。
5. Conclusion
5. 結論
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.
このドキュメントが、もう片方の視点があるものが来る予定であるどちらの観点についてもものに説明するのを助けることを願っています。 それはこれが闘争を静まらせて、特にセキュリティデザインの困難のいくらかの光をはじいて、より良いプロトコルデザインに通じるという私の望みです。
6. Security Considerations
6. セキュリティ問題
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で定義されるようにセキュリティがDocumentとプロトコル観点の含意であると考えて、Document視点におけるセキュリティー上の欠陥を警告します。 これらのセキュリティ問題の大部分はセクション2.4に現れますが、また、それらは全体として読まれるべきであるセクション2のほかの場所に触れられます。
Informative References
有益な参照
[ASCII] "USA Standard Code for Information Interchange", X3.4,
American National Standards Institute: New York, 1968.
[ASCII]「米国の標準の情報交換用符号」、X3.4、American National Standards Institut: ニューヨーク、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/IEC8824-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/IEC8825-1: 1998 「情報技術--ASN.1コード化は以下を統治します」。 「基本的なコード化の仕様は(BER)、正準な符号化規則(CER)、および顕著な符号化規則(DER)を統治します。」 <http://www.itu.int/ITU T/studygroups/com17/言語/index.html>。
Eastlake Informational [Page 12] RFC 3930 Protocol versus Document Viewpoints October 2004
イーストレーク情報[12ページ]のRFC3930Protocol対ドキュメント観点2004年10月
[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改正1CSS2.1Specificationを平らにしてください」、B.ボス、T.Gelik、I.ヒクソン、H.Lie、W3C Candidate Recommendation、2004年2月25日。 <http://www.w3.org/TR/CSS21>。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC793] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、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]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
[RFC2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security
Document Roadmap", RFC 2411, November 1998.
[RFC2411] セイヤーとR.とDoraswamy、N.とR.グレン、「IPセキュリティドキュメント道路地図」、RFC2411、1998年11月。
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
3852, July 2004.
[RFC3852] Housley、R.、「暗号のメッセージ構文(cm)」、RFC3852、2004年7月。
[RFC2801] Burdett, D., "Internet Open Trading Protocol - IOTP
Version 1.0", RFC 2801, April 2000.
[RFC2801]バーデット、D.、「インターネットの開いている取り引きプロトコル--、IOTP、バージョン1インチ、RFC2801、2000インチ年4月。
[RFC2802] Davidson, K. and Y. Kawatsura, "Digital Signatures for
the v1.0 Internet Open Trading Protocol (IOTP)", RFC
2802, April 2000.
[RFC2802]ディヴィッドソンとK.とY.Kawatsura、「v1.0インターネットオープンTradingプロトコル(IOTP)のためのデジタルSignatures」、RFC2802、2000年4月。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[RFC2821] Klensin、J.、「簡単なメール転送プロトコル」、RFC2821、2001年4月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April
2001.
[RFC2822] レズニック、P.、「インターネットメッセージ・フォーマット」、RFC2822、2001年4月。
[RFC3076] Boyer, J., "Canonical XML Version 1.0", RFC 3076, March
2001.
[RFC3076]ボワイエ、J.、「正準なXML、バージョン1インチ、RFC3076、2001インチ年3月。
[RFC3275] Eastlake 3rd, D., Reagle, J., and D. Solo, "(Extensible
Markup Language) XML-Signature Syntax and Processing",
RFC 3275, March 2002.
[RFC3275]イーストレーク3番目、D.、Reagle、J.、およびD.は独奏して、「(拡張マークアップ言語)XML-署名構文と処理」(RFC3275)は2002を行進させます。
[RFC3741] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[RFC3741] バーガー、L.、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)のシグナリングの機能的な記述」、RFC3471、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 Recommendation X.509バージョン3(1997)、情報Technology--オープン・システム・インターコネクション--ディレクトリAuthentication Framework」、ISO/IEC9594- 8:1997
Eastlake Informational [Page 13] RFC 3930 Protocol versus Document Viewpoints October 2004
イーストレーク情報[13ページ]のRFC3930Protocol対ドキュメント観点2004年10月
[XForms] "XForms 1.0", M. Dubinko, L. Klotz, R. Merrick, T.
Raman, W3C Recommendation 14 October 2003.
<http://www.w3.org/TR/xforms/>
[XForms。]「XForms1インチ、M.Dubinko、L.クロッツ、R.メリック、T.ラマン、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。 C.M.Sperbergロバの鳴き声、J.パオリ、マックィーン、E.Maler、2000年10月。 <http://www.w3.org/TR/2000/REC-xml-20001006>。
[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.イーストレーク、12月2002日 <の赤いxmlenc http://www.w3.org/TR/2001/コア20021210/>。
Author's Address
作者のアドレス
Donald E. Eastlake 3rd Motorola Laboratories 155 Beaver Street Milford, MA 01757 USA
ドナルドE.イーストレーク第3モトローラ研究所155ビーバー通りMA01757ミルフォード(米国)
Phone: +1 508-786-7554 (w)
+1 508-634-2066 (h)
Fax: +1 508-786-7501 (w)
EMail: Donald.Eastlake@motorola.com
以下に電話をしてください。 +1 508-786-7554(w)+1 508-634-2066(h)Fax: +1 508-786-7501 (w) メールしてください: Donald.Eastlake@motorola.com
Eastlake Informational [Page 14] RFC 3930 Protocol versus Document Viewpoints October 2004
イーストレーク情報[14ページ]のRFC3930Protocol対ドキュメント観点2004年10月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2004).
Copyright(C)インターネット協会(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.
このドキュメントはBCP78と、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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でISOC Documentsの権利に関するISOCの手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。
Eastlake Informational [Page 15]
イーストレークInformationalです。[15ページ]
一覧
スポンサーリンク
