RFC2646 日本語訳
2646 The Text/Plain Format Parameter. R. Gellens, Ed.. August 1999. (Format: TXT=29175 bytes) (Obsoleted by RFC3676) (Updates RFC2046) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Gellens, Editor Request for Comments: 2646 Qualcomm Updates: 2046 August 1999 Category: Standards Track
ワーキンググループR.Gellens、コメントを求めるエディタ要求をネットワークでつないでください: 2646のクアルコムアップデート: 2046 1999年8月のカテゴリ: 標準化過程
The Text/Plain Format Parameter
テキスト/明瞭な形式パラメタ
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
Table of Contents
目次
1. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in this Document . . . . . . . . . . . . . 2
3. The Problem . . . . . . . . . . . . . . . . . . . . . . . . 2
3.1. Paragraph Text . . . . . . . . . . . . . . . . . . . . 3
3.2. Embarrassing Line Wrap . . . . . . . . . . . . . . . . . 3
3.3. New Media Types . . . . . . . . . . . . . . . . . . . . 4
4. The Format Parameter to the Text/Plain Media Type . . . . . 4
4.1. Generating Format=Flowed . . . . . . . . . . . . . . . 5
4.2. Interpreting Format=Flowed . . . . . . . . . . . . . . . 6
4.3. Usenet Signature Convention . . . . . . . . . . . . . . 7
4.4. Space-Stuffing . . . . . . . . . . . . . . . . . . . . . 7
4.5. Quoting . . . . . . . . . . . . . . . . . . . . . . . . 8
4.6. Digital Signatures and Encryption . . . . . . . . . . . 9
4.7. Line Analysis Table . . . . . . . . . . . . . . . . . . 10
4.8. Examples . . . . . . . . . . . . . . . . . . . . . . . . 10
5. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Failure Modes . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Trailing White Space Corruption . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12
9. Internationalization Considerations . . . . . . . . . . . . 12
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
12. Editor's Address . . . . . . . . . . . . . . . . . . . . . 13
13. Full Copyright Statement . . . . . . . . . . . . . . . . . . 14
1. 要約. . . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 このDocument. . . . . . . . . . . . . 2 3のコンベンションUsed。 問題. . . . . . . . . . . . . . . . . . . . . . . . 2 3.1。 パラグラフテキスト. . . . . . . . . . . . . . . . . . . . 3 3.2 線包装. . . . . . . . . . . . . . . . . 3 3.3を当惑させます。 ニューメディアは.4 4をタイプします。 テキスト/明瞭なメディアへの形式パラメタは.44.1をタイプします。 形式=を発生させるのは.54.2に流れました。 解釈形式=は.64.3に流れました。 Usenet署名コンベンション. . . . . . . . . . . . . . 7 4.4。 スペースを詰める.74.5。 .84.6を引用します。 デジタル署名と暗号化. . . . . . . . . . . 9 4.7。 分析テーブル. . . . . . . . . . . . . . . . . . 10 4.8を裏打ちしてください。 例. . . . . . . . . . . . . . . . . . . . . . . . 10 5。 ABNF. . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6。 故障モード. . . . . . . . . . . . . . . . . . . . . . . 11 6.1。 余白不正. . . . . . . . . . . . 11 7を引きずります。 セキュリティ問題. . . . . . . . . . . . . . . . . . 12 8。 IANA問題. . . . . . . . . . . . . . . . . . . . 12 9。 国際化問題. . . . . . . . . . . . 12 10。 承認. . . . . . . . . . . . . . . . . . . . . . 12 11。 参照. . . . . . . . . . . . . . . . . . . . . . . . . 13 12。 エディタのアドレス. . . . . . . . . . . . . . . . . . . . . 13 13。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . 14
Gellens Standards Track [Page 1] RFC 2646 The Text/Plain Format Parameter August 1999
Gellens規格はテキスト/明瞭な形式パラメタ1999年8月にRFC2646を追跡します[1ページ]。
1. Abstract
1. 要約
Interoperability problems have been observed with erroneous labelling of paragraph text as Text/Plain, and with various forms of "embarrassing line wrap." (See section 3.)
相互運用性問題はText/平野としてのパラグラフテキストの誤ったラベル、および様々なフォームの「恥ずかしい線包装」で観測されました。 (セクション3を見てください。)
Attempts to deploy new media types, such as Text/Enriched [RICH] and Text/HTML [HTML] have suffered from a lack of backwards compatibility and an often hostile user reaction at the receiving end.
ニューメディアを配備する試みは、[リッシュ]をTextなどのようにタイプしたか、または豊かにしました、そして、Text/HTML[HTML]は犠牲者に後方にの不足から互換性としばしば敵対的なユーザ反応を受けました。
What is required is a format which is in all significant ways Text/Plain, and therefore is quite suitable for display as Text/Plain, and yet allows the sender to express to the receiver which lines can be considered a logical paragraph, and thus flowed (wrapped and joined) as appropriate.
何があるか、必要であることで、すべての重要な方法であるa形式がText/明瞭である、したがって、Text/平野として表示にかなり適していますが、送付者が、どの線が流れると(包装されて、接合されます)論理的なパラグラフに、このようにして考えることができるかを受信機に適宜言い表すのを許容します。
This memo proposes a new parameter to be used with Text/Plain, and, in the presence of this parameter, the use of trailing whitespace to indicate flowed lines. This results in an encoding which appears as normal Text/Plain in older implementations, since it is in fact normal Text/Plain.
このメモは、流れる線を示すのにText/平野、およびこのパラメタがあるとき引きずっている空白の使用と共に使用されるために新しいパラメタを提案します。 これは事実上、それが正常なText/明瞭であるので標準として、より古い実現でText/明瞭に見えるコード化をもたらします。
2. Conventions Used in this Document
2. このDocumentのコンベンションUsed
The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS].
“MUST"、「必須NOT」がキーワードが、「必要でした」、“SHOULD"、「」 「5月」は「RFCsにおける使用が要件レベルを示すキーワード」[キーワード]で説明されるように本書では解釈されることになっているべきです。
3. The Problem
3. 問題
The Text/Plain media type is the lowest common denominator of Internet email, with lines of no more than 997 characters (by convention usually no more than 80), and where the CRLF sequence represents a line break [MIME-IMT].
Text/明瞭なメディアタイプはインターネットメールの最小公分母です、997未満のキャラクタ(通常コンベンションによる80がない)の線とCRLF系列がどこにラインブレイク[MIME-IMT]を表すかで。
Text/Plain is usually displayed as preformatted text, often in a fixed font. That is, the characters start at the left margin of the display window, and advance to the right until a CRLF sequence is seen, at which point a new line is started, again at the left margin. When a line length exceeds the display window, some clients will wrap the line, while others invoke a horizontal scroll bar.
通常、前フォーマットされたテキストとしてしばしば固定字体でテキスト/平野を表示します。 すなわち、キャラクタは、ディスプレイ・ウィンドウの左のマージンで始まって、CRLF系列が見られるまで、右に達して、復帰改行はそのポイントで始動されます、再び左のマージンで。 行長がディスプレイ・ウィンドウを超えていると、何人かのクライアントが線を包装するでしょう、他のものは水平なスクロールバーを呼び出しますが。
Text which meets this description is defined by this memo as "fixed".
この記述を満たすテキストがこのメモで「修理される」と定義されます。
Some interoperability problems have been observed with this media type:
いくつかの相互運用性問題がこのメディアタイプで観測されました:
Gellens Standards Track [Page 2] RFC 2646 The Text/Plain Format Parameter August 1999
Gellens規格はテキスト/明瞭な形式パラメタ1999年8月にRFC2646を追跡します[2ページ]。
3.1. Paragraph Text
3.1. パラグラフテキスト
Many modern programs use a proportional-spaced font and CRLF to represent paragraph breaks. Line breaks are "soft", occurring as needed on display. That is, characters are grouped into a paragraph until a CRLF sequence is seen, at which point a new paragraph is started. Each paragraph is displayed, starting at the left margin (or paragraph indent), and continuing to the right until a word is encountered which does not fit in the remaining display width. This word is displayed at the left margin of the next line. This continues until the paragraph ends (a CRLF is seen). Extra vertical space is left between paragraphs.
多くの現代のプログラムが比例して区切られた字体を使用します、そして、パラグラフを表すCRLFは壊れます。 必要であるとしてディスプレーされていた状態で起こって、ラインブレイクは「柔らかいです」。 CRLF系列が見られて、新しいパラグラフがそのポイントで始められるまで、すなわち、キャラクタはパラグラフに分類されます。 各パラグラフは、表示されて、左のマージン(または、パラグラフインデント)で始まって、単語が遭遇するまで、右に続くことです残っている表示幅をうまくはめ込まない。 次の線の左の橋でこの言葉を表示します。 パラグラフが終わるまで(CRLFは見られます)、これは続きます。 余分な垂直なスペースはパラグラフの間に残されます。
Text which meets this description is defined by this memo as "flowed".
この記述を満たすテキストがこのメモで「流れる」と定義されます。
Numerous software products erroneously label this media type as Text/Plain, resulting in much user discomfort.
多数のソフトウェア・プロダクトは誤ってText/明瞭であって、結果になるとしての相当なユーザ不快でのメディアタイプとこれをラベルします。
3.2. Embarrassing Line Wrap
3.2. 恥ずかしい線包装
As Text/Plain messages get quoted in replies or forwarded messages, the length of each line gradually increases, resulting in "embarrassing line wrap." This results in text which is at best hard to read, and often confuses attributions.
Text/明瞭なメッセージが回答で引用するか、またはメッセージを転送するようになるのに従って、それぞれの線の長さは徐々に増加します、「恥ずかしい線包装」をもたらして。 これはせいぜい読みにくくて、属性をしばしば混乱させるテキストをもたらします。
Example:
例:
>>>>>>This is a comment from the first message to show a
>quoting example.
>>>>>This is a comment from the second message to show a
>quoting example.
>>>>This is a comment from the third message.
>>>This is a comment from the fourth message.
>>>>>>、これは>が例を引用するのを示す最初のメッセージからのコメントです。 >>>>>は、>が例を引用するのを示すために2番目から通信しますaが、論評する。 >>>>は3日から通信しますaが、論評する。 >>>は4日から通信しますaが、論評する。
It can be confusing to assign attribution to lines 2 and 4 above.
上の2と4の線に属性を割り当てるのは紛らわしい場合があります。
In addition, as devices with display widths smaller than 80 characters become more popular, embarrassing line wrap has become even more prevalent, even with unquoted text.
さらに、表示幅が80のキャラクタが、よりポピュラーになるよりわずかの装置として、恥ずかしい線包装はさらに一般的になりました、引用を終わっているテキストがあっても。
Gellens Standards Track [Page 3] RFC 2646 The Text/Plain Format Parameter August 1999
Gellens規格はテキスト/明瞭な形式パラメタ1999年8月にRFC2646を追跡します[3ページ]。
Example:
例:
This is paragraph text that is
meant to be flowed across
several lines.
However, the sending mailer is
converting it to fixed text at
a width of 72
characters, which causes it to
look like this when shown on a
PDA with only
30 character lines.
これはパラグラフテキストです、すなわち、流れることが意味されて、数個が立ち並んでいます。 しかしながら、送付郵送者は72のキャラクタの幅で固定テキストにそれを変換しています。(PDAの上に30個のハイライト線だけで示されると、それはそれで、これに似ています)。
3.3. New Media Types
3.3. ニューメディアタイプ
Attempts to deploy new media types, such as Text/Enriched [RICH] and Text/HTML [HTML] have suffered from a lack of backwards compatibility and an often hostile user reaction at the receiving end.
ニューメディアを配備する試みは、[リッシュ]をTextなどのようにタイプしたか、または豊かにしました、そして、Text/HTML[HTML]は犠牲者に後方にの不足から互換性としばしば敵対的なユーザ反応を受けました。
In particular, Text/Enriched requires that open angle brackets ("<")
and hard line breaks be doubled, with resulting user unhappiness when
viewed as Text/Plain. Text/HTML requires even more alteration of
text, with a corresponding increase in user complaints.
テキスト/平野として見なされると、特に、豊かにされたText/は、開いている角ブラケット("<")と困難なラインブレイクが結果として起こるユーザ不幸で倍にされるのを必要とします。 テキスト/HTMLはユーザ苦情の対応する増加に伴うテキストのさらに多くの変更を必要とします。
A proposal to define a new media type to explicitly represent the paragraph form suffered from a lack of interoperability with currently deployed software. Some programs treat unknown subtypes of Text as an attachment.
明らかに成文パラグラフを表すためにニューメディアタイプを定義するという提案は現在配備されたソフトウェアで相互運用性の不足に苦しみました。 いくつかのプログラムが添付書類でTextの未知の血液型亜型を扱います。
What is desired is a format which is in all significant ways Text/Plain, and therefore is quite suitable for display as Text/Plain, and yet allows the sender to express to the receiver which lines can be considered a logical paragraph, and thus flowed (wrapped and joined) as appropriate.
何があるか、望まれていて、すべての重要な方法であるa形式がText/明瞭である、したがって、Text/平野として表示にかなり適していますが、送付者が、どの線が流れると(包装されて、接合されます)論理的なパラグラフに、このようにして考えることができるかを受信機に適宜言い表すのを許容します。
4. The Format Parameter to the Text/Plain Media Type
4. テキスト/明瞭なメディアタイプへの形式パラメタ
This document defines a new MIME parameter for use with Text/Plain:
このドキュメントはText/平野との使用のための新しいMIMEパラメタを定義します:
Name: Format
Value: Fixed, Flowed
以下を命名してください。 値をフォーマットしてください: 修理されて、流れます。
(Neither the parameter name nor its value are case sensitive.)
(パラメタ名もその値も大文字と小文字を区別していません。)
If not specified, a value of Fixed is assumed. The semantics of the Fixed value are the usual associated with Text/Plain [MIME-IMT].
指定されないなら、Fixedの値は想定されます。 Fixed価値の意味論はText/平野[MIME-IMT]に関連している普通です。
Gellens Standards Track [Page 4] RFC 2646 The Text/Plain Format Parameter August 1999
Gellens規格はテキスト/明瞭な形式パラメタ1999年8月にRFC2646を追跡します[4ページ]。
A value of Flowed indicates that the definition of flowed text (as specified in this memo) was used on generation, and MAY be used on reception.
Flowedの値は、流れるテキスト(このメモで指定されるように)の定義が世代のときに使用されて、レセプションで使用されるかもしれないのを示します。
This section discusses flowed text; section 5 provides a formal definition.
このセクションは流れるテキストについて論じます。 セクション5は公式の定義を提供します。
Because flowed lines are all-but-indistinguishable from fixed lines, currently deployed software treats flowed lines as normal Text/Plain (which is what they are). Thus, no interoperability problems are expected.
オールしかし、流れる線がそうので、固定線から区別がつかなくて、現在配備されたソフトウェアは正常なText/平野として流れる線を扱います(それらが何であるかということです)。 したがって、相互運用性問題は全く予想されません。
Note that this memo describes an on-the-wire format. It does not address formats for local file storage.
このメモがワイヤの形式について説明することに注意してください。 それはローカルファイル格納にどんなアドレス形式もしません。
4.1. Generating Format=Flowed
4.1. 形式=を発生させるのは流れました。
When generating Format=Flowed text, lines SHOULD be shorter than 80 characters. As suggested values, any paragraph longer than 79 characters in total length could be wrapped using lines of 72 or fewer characters. While the specific line length used is a matter of aesthetics and preference, longer lines are more likely to require rewrapping and to encounter difficulties with older mailers. It has been suggested that 66 character lines are the most readable.
線SHOULD、発生するとき、Formatは流れるテキストと等しいです。80のキャラクタより短くいてください。 提案された値として、全長における79のキャラクタがそうすることができたよりどんなパラグラフ長い間も、72か、より少ないキャラクタの線を使用することで包装されてください。 長さが使用した特定の線が美意識と好みの問題ですが、より長い線は、再包装するのが必要であり、より年取った郵送者における困難により遭遇しそうです。 66個のハイライト線が最も読み込み可能であると示唆されました。
(The reason for the restriction to 79 or fewer characters between CRLFs on the wire is to ensure that all lines, even when displayed by a non-flowed-aware program, will fit in a standard 80-column screen without having to be wrapped. The limit is 79, not 80, because while 80 fit on a line, the last column is often reserved for a line-wrap indicator.)
(79への制限かワイヤの上のCRLFsの間の、より少ないキャラクタの理由はすべてが立ち並ぶのを保証することです、aから表示すると非、意識していた状態で流れる、プログラム、包装される必要はなくて、意志が標準の80コラムのスクリーンをうまくはめ込みました。 80ではなく80が線に合っている間、最後のコラムが線包装インディケータのためにしばしば予約されるので、限界は79です。)
When creating flowed text, the generating agent wraps, that is, inserts 'soft' line breaks as needed. Soft line breaks are added between words. Because a soft line break is a SP CRLF sequence, the generating agent creates one by inserting a CRLF after the occurance of a space.
流れるテキスト、発生しているエージェント機密を作成するとき、それは作成して、差し込みは必要であるとして'柔らかい'ラインブレイクです。 柔らかいラインブレイクは単語の間で加えられます。 柔らかいラインブレイクがSP CRLF系列であるので、発生しているエージェントはスペースのoccuranceの後にCRLFを挿入することによって、1つを作成します。
A generating agent SHOULD NOT insert white space into a word (a sequence of printable characters not containing spaces). If faced with a word which exceeds 79 characters (but less than 998 characters, the [SMTP] limit on line length), the agent SHOULD send the word as is and exceed the 79-character limit on line length.
発生しているエージェントSHOULD NOTは単語(空間を含まない印刷可能なキャラクタの系列)に余白を挿入します。 79のキャラクタ(しかし、998未満のキャラクタ、行長における[SMTP]限界)を超えている単語が直面されているなら、エージェントSHOULDは行長でそのままで知らせを送って、79キャラクタの限界を超えています。
Gellens Standards Track [Page 5] RFC 2646 The Text/Plain Format Parameter August 1999
Gellens規格はテキスト/明瞭な形式パラメタ1999年8月にRFC2646を追跡します[5ページ]。
A generating agent SHOULD:
発生しているエージェントSHOULD:
1. Ensure all lines (fixed and flowed) are 79 characters or
fewer in length, counting the trailing space but not
counting the CRLF, unless a word by itself exceeds 79
characters.
2. Trim spaces before user-inserted hard line breaks.
3. Space-stuff lines which start with a space, "From ", or
">".
1. すべての線(修理して、流れる)がそれほど長さが79のキャラクタであることを確実にしてください、引きずっているスペースを数えますが、CRLFは数えないで、それ自体で単語が79のキャラクタを超えていない場合。 2. ユーザによって挿入された強硬路線が壊れる前に空間を整えてください。 3. スペースものがスペースでどの始めを裏打ちするか、「」 ">"から。
In order to create messages which do not require space-stuffing, and are thus more aesthetically pleasing when viewed as Format=Fixed, a generating agent MAY avoid wrapping immediately before ">", "From ", or space.
どれがそうしないかがメッセージを作成するためにスペースで詰めるのが必要であり、あって、その結果、=が修理したFormat、発生として見なされると美しくより嬉しいエージェントが、">"の直前包装するのを避けるかもしれない、「」 スペースから。
(See sections 4.4 and 4.5 for more information on space-stuffing and quoting, respectively.)
(スペース詰め物に関する詳しい情報と引用に関してそれぞれセクション4.4と4.5を見てください。)
A Format=Flowed message consists of zero or more paragraphs, each containing one or more flowed lines followed by one fixed line. The usual case is a series of flowed text lines with blank (empty) fixed lines between them.
流れるFormat=メッセージはゼロか、より多くのパラグラフから成ります、それぞれ1つの固定線が支えた1つ以上の流れる線を含んでいて。 普通のケースはそれらの間には、空白(空の)の固定線がある一連の流れるテキスト線です。
Any number of fixed lines can appear between paragraphs.
いろいろな固定線がパラグラフの間に現れることができます。
[Quoted-Printable] encoding SHOULD NOT be used with Format=Flowed unless absolutely necessary (for example, non-US-ASCII (8-bit) characters over a strictly 7-bit transport such as unextended SMTP). In particular, a message SHOULD NOT be encoded in Quoted-Printable for the sole purpose of protecting the trailing space on flowed lines unless the body part is cryptographically signed or encrypted (see Section 4.6).
[引用されて印刷可能な] SHOULD NOTをコード化して、絶対に必要でない場合(例えば、unextended SMTPなどの厳密に7ビットの輸送の上の非米国のASCII(8ビット)キャラクタ)流れたFormat=と共に使用されてください。 特定のaメッセージSHOULD NOTでは、中で身体の部分が暗号でサインされるか、またはコード化されない場合(セクション4.6を見てください)流れる線の引きずっているスペースを保護する唯一の目的のためにQuoted印刷可能な状態でコード化されてください。
The intent of Format=Flowed is to allow user agents to generate flowed text which is non-obnoxious when viewed as pure, raw Text/Plain (without any decoding); use of Quoted-Printable hinders this and may cause Format=Flowed to be rejected by end users.
Format=の意図が流れた、ユーザエージェントを純粋で、生のText/明瞭(少しも解読のない)として見なされると非不愉快な流れるテキストは発生させることになっていることができます。 Quoted印刷可能の使用はこれを妨げます、そして、Format=が注いだ原因がエンドユーザによって拒絶されますように。
4.2. Interpreting Format=Flowed
4.2. 解釈形式=は流れました。
If the first character of a line is a quote mark (">"), the line is
considered to be quoted (see section 4.5). Logically, all quote
marks are counted and deleted, resulting in a line with a non-zero
quote depth, and content. (The agent is of course free to display the
content with quote marks or excerpt bars or anything else.)
Logically, this test for quoted lines is done before any other tests
(that is, before checking for space-stuffed and flowed).
線の最初のキャラクタが引用符(">")であるなら、線が引用されると考えられます(セクション4.5を見てください)。 非ゼロ引用文の深さ、および内容で線をもたらして、すべての引用符が、論理的に、数えられて、削除されます。 (エージェントはもちろん自由に引用符、抜粋バーまたは他の何かがある内容を表示できます。) 論理的に、いかなる他のテストの前にも引用された線のためのこのテストをします。(それがそう、以前、チェックする、スペースで詰められて流れる、)
Gellens Standards Track [Page 6] RFC 2646 The Text/Plain Format Parameter August 1999
Gellens規格はテキスト/明瞭な形式パラメタ1999年8月にRFC2646を追跡します[6ページ]。
If the first character of a line is a space, the line has been space-stuffed (see section 4.4). Logically, this leading space is deleted before examining the line further (that is, before checking for flowed).
線の最初のキャラクタがそうなら、スペース、線はスペースによって詰められています(セクション4.4を見てください)。 さらに線を調べる前に、論理的に、この主なスペースは削除されます。(それがそう、以前、チェックする、流れ、)
If the line ends in one or more spaces, the line is flowed. Otherwise it is fixed. Trailing spaces are part of the line's content, but the CRLF of a soft line break is not.
1つ以上が区切るコネ、線がある列の最後尾が流れたなら。 さもなければ、それは固定されています。 引きずっている空間は行内容の一部ですが、柔らかいラインブレイクのCRLFは一部であるというわけではありません。
A series of one or more flowed lines followed by one fixed line is considered a paragraph, and MAY be flowed (wrapped and unwrapped) as appropriate on display and in the construction of new messages (see section 4.5).
1つの固定線が支えた一連の1つ以上の流れる線はパラグラフであると考えられて、あるかもしれない、適宜流れる、(包装されて、開けられます)ディスプレー、そして、新しいことの構造が通信させる(セクション4.5を見ます)コネ。
A line consisting of one or more spaces (after deleting a stuffed space) is considered a flowed line.
1つ以上の空間(詰められたスペースを削除した後の)から成る線は流れる線であると考えられます。
4.3. Usenet Signature Convention
4.3. Usenet署名コンベンション
There is a convention in Usenet news of using "-- " as the separator line between the body and the signature of a message. When generating a Format=Flowed message containing a Usenet-style separator before the signature, the separator line is sent as-is. This is a special case; an (optionally quoted) line consisting of DASH DASH SP is not considered flowed.
メッセージのボディーと署名の間の区切り線として「--」を使用するというUsenetニュースにおけるコンベンションがあります。 署名の前にUsenet-スタイル分離符を含む流れるFormat=メッセージを発生させるとき、そのままで区切り線を送ります。 これは特別なそうです。 (任意に引用されています)の線は流れましたDASH DASH SPから成るのが考えられない。
4.4. Space-Stuffing
4.4. スペース詰め物
In order to allow for unquoted lines which start with ">", and to protect against systems which "From-munge" in-transit messages (modifying any line which starts with "From " to ">From "), Format=Flowed provides for space-stuffing.
形式=は流れました。">"から始まる引用を終わっている線を考慮して、システムに対して「munge」からのトランジットにおけるどのメッセージを保護するか、(いずれもどの始めを裏打ちする変更、「」、「>、」、)、スペースで詰めるのに提供します。
Space-stuffing adds a single space to the start of any line which needs protection when the message is generated. On reception, if the first character of a line is a space, it is logically deleted. This occurs after the test for a quoted line, and before the test for a flowed line.
スペース詰め物はメッセージが発生するとき保護を必要とするどんな線の始まりにもシングルスペースを加えます。 レセプションに関して、線の最初のキャラクタがそうであるなら、スペースであり、削除されて、それは論理的にそうです。 これは引用された線と、流れる線のためのテストの前にテストの後に起こります。
On generation, any unquoted lines which start with ">", and any lines which start with a space or "From " SHOULD be space-stuffed. Other lines MAY be space-stuffed as desired.
または、世代のときにいずれも">"から始まる線、およびスペースから始まるどんな線にも引用を終わらせた、「」 スペースで、詰められるべきであってください。 他の線はスペースによって同じくらい必要な状態で詰められるかもしれません。
(Note that space-stuffing is similar to dot-stuffing as specified in [SMTP].)
(スペース詰め物が[SMTP]の指定されるとしてのドット詰め物と同様であることに注意してください。)
Gellens Standards Track [Page 7] RFC 2646 The Text/Plain Format Parameter August 1999
Gellens規格はテキスト/明瞭な形式パラメタ1999年8月にRFC2646を追跡します[7ページ]。
If a space-stuffed message is received by an agent which handles Format=Flowed, the space-stuffing is reversed and thus the message appears unchanged. An agent which is not aware of Format=Flowed will of course not undo any space-stuffing, thus Format=Flowed messages may appear with a leading space on some lines (those which start with a space, ">" which is not a quote indicator, or "From "). Since lines which require space-stuffing rarely occur, and the aesthetic consequences of unreversed space-stuffing are minimal, this is not expected to be a significant problem.
スペースで詰められたメッセージがエージェントによって受け取られて、どれがFormat=を扱うかが流れて、スペース詰め物が逆にされるということであり、その結果、メッセージが変わりがなく見えるなら。 または、いくつかの線の上に主なスペースがある状態で流れるその結果、どんなスペース詰め物、Formatも=メッセージが見えるかもしれないアンドゥではなく、もちろん流れるFormat=意志を意識していないエージェント、(スペース、引用文のインディケータでない">"から始めるもの、「」、) スペースで詰めるのを必要とする線がめったに現れないで、非逆にされたスペース詰め物の美的な結果が最小限ので、これは重大な問題でないと予想されます。
4.5. Quoting
4.5. 引用
In Format=Flowed, the canonical quote indicator (or quote mark) is
one or more close angle bracket (">") characters. Lines which start
with the quote indicator are considered quoted. The number of ">"
characters at the start of the line specifies the quote depth.
Flowed lines which are also quoted may require special handling on
display and when copied to new messages.
Formatでは、=は流れて、正準な引用文のインディケータ(または、引用符)は1個以上の近い角ブラケット(">")のキャラクタです。 引用文のインディケータから始まる線は引用されていると考えられます。 線の始めの">"キャラクタの数は引用文の深さを指定します。 また、引用される流れる台詞が特別な取り扱いを必要とするかもしれない、ディスプレー、そして、新しいメッセージにコピーされたいつ?。
When creating quoted flowed lines, each such line starts with the quote indicator.
引用された流れる線を作成するとき、そのような各線は引用文のインディケータから始まります。
Note that because of space-stuffing, the lines
>> Exit, Stage Left
and
>>Exit, Stage Left
are semantically identical; both have a quote-depth of two, and a
content of "Exit, Stage Left".
線のスペース詰め物、>>Exit、Stage Left、および>>Exitのために、Stage Leftが意味的に同じであることに注意してください。 両方には、2の引用文深さ、および「出てください、そして、左を上演してください」の内容があります。
However, the line
> > Exit, Stage Left
is different. It has a quote-depth of one, and a content of
"> Exit, Stage Left".
しかしながら、線>>Exitであり、Stage Leftは異なっています。 それには、1の引用文深さ、および「>出口、上手」の内容があります。
When generating quoted flowed lines, an agent needs to pay attention to changes in quote depth. A sequence of quoted lines of the same quote depth SHOULD be encoded as a paragraph, with the last line generated as fixed and prior lines generated as flowed.
引用された流れる線を発生させるとき、エージェントは、引用文の深さの変化に注意を向ける必要があります。 同じくらいの引用された線の系列は、深さSHOULDがパラグラフとしてコード化されるのを引用します、最終ラインが修理されるとして発生して、先の線が流れるとして発生している状態で。
If a receiving agent wishes to reformat flowed quoted lines (joining and/or wrapping them) on display or when generating new messages, the lines SHOULD be de-quoted, reformatted, and then re-quoted. To de-quote, the number of close angle brackets in the quote indicator at the start of each line is counted. Consecutive lines with the same quoting depth are considered one paragraph and are reformatted together. To re-quote after reformatting, a quote indicator containing the same number of close angle brackets originally present is prefixed to each line.
受信エージェントが、(それらを接合する、そして/または、包装します)がディスプレーされていることを再フォーマットの流れる引用された線に願うか、または新しいメッセージ、反-引用されて、再フォーマットされて、次に再引用された線SHOULDを発生させるとき。 反-引用文に、それぞれの線の始めの引用文のインディケータにおける、近い角ブラケットの数は数えられます。 同じくらいが深さを引用している連続した線は、1つのパラグラフであると考えられて、一緒に再フォーマットされます。 再フォーマットした後の再引用文に、元々の現在の同じ数の近い角ブラケットを含む引用文のインディケータは各線へ前に置かれています。
Gellens Standards Track [Page 8] RFC 2646 The Text/Plain Format Parameter August 1999
Gellens規格はテキスト/明瞭な形式パラメタ1999年8月にRFC2646を追跡します[8ページ]。
On reception, if a change in quoting depth occurs on a flowed line, this is an improperly formatted message. The receiver SHOULD handle this error by using the 'quote-depth-wins' rule, which is to ignore the flowed indicator and treat the line as fixed. That is, the change in quote depth ends the paragraph.
レセプションでは、深さを引用することにおける変化が流れる線の上に起こるなら、これは不適切にフォーマットされたメッセージです。 受信機SHOULDは、流れるインディケータを無視して、修理されるとして線を扱うことである'引用文の深さ勝利'規則を使用することによって、この誤りを扱います。 すなわち、引用文の深さの変化はパラグラフを終わらせます。
For example, consider the following sequence of lines (using '*' to indicate a soft line break, i.e., SP CRLF, and '#' to indicate a hard line break, i.e., CRLF):
例えば、線(柔らかいラインブレイク、すなわち、SP CRLFを示すのに'*'を使用して、困難なラインブレイク、すなわち、CRLFを示す'#')の以下の系列を考えてください:
> Thou villainous ill-breeding spongy dizzy-eyed*
> reeky elf-skinned pigeon-egg!* <--- problem ---<
>> Thou artless swag-bellied milk-livered*
>> dismal-dreaming idle-headed scut!#
>>> Thou errant folly-fallen spleeny reeling-ripe*
>>> unmuzzled ratsbane!#
>>>> Henceforth, the coding style is to be strictly*
>>>> enforced, including the use of only upper case.#
>>>>> I've noticed a lack of adherence to the coding*
>>>>> styles, of late.#
>>>>>> Any complaints?#
>、なんじ、とてもひどいスポンジ状のめまいがする目をした無作法*>reeky小妖精皮膚をした鳩卵!*<。--- 問題---素朴な飾り綱腹をしたミルク肝をした*>>陰気な夢想活動していない頭の短い尾!#>のThouの誤った愚かさで堕落しているspleenyの>>よろめき熟している*>>>は猫いらずに「非-口輪をかけ」ました!#>>>>Henceforth、コード化スタイルは厳密にであることです。<>>、なんじ、大文字だけの使用を含んでいて、実施された*>>>>; #>>>>>Iが>>が最近流行に合わせるコード化*>>>において固守の不足に気付いた、#>>>>>>Any苦情?#
The second line ends in a soft line break, even though it is the last line of the one-deep quote block. The question then arises as to how this line should be interpreted, considering that the next line is the first line of the two-deep quote block.
セカンドラインは柔らかいラインブレイクに終わります、それが1深い引用文のブロックの最終ラインですが。 次に、この線がどう解釈されるべきであるかに関して質問は起こります、次の線が2深い引用文のブロックの最初の線であると考える場合。
The example text above, when processed according to quote-depth wins, results in the first two lines being considered as one quoted, flowed section, with a quote depth of 1; the third and fourth lines become a quoted, flowed section, with a quote depth of 2.
1つの引用されて、流れるセクションであるとみなされながら、最初の2における結果引用文深さ勝利に従って処理されるとを超えた例のテキストは立ち並んでいます、1の引用文の深さで。 3番目と4番目の線は2の引用文の深さがある引用されて、流れるセクションになります。
A generating agent SHOULD NOT create this situation; a receiving agent SHOULD handle it using quote-depth wins.
発生しているエージェントSHOULD NOTはこの状況を作成します。 受信エージェントSHOULDは、引用文深さ勝利を使用することでそれを扱います。
4.6. Digital Signatures and Encryption
4.6. デジタル署名と暗号化
If a message is digitally signed or encrypted it is important that cryptographic processing use the on-the-wire Format=Flowed format. That is, during generation the message SHOULD be prepared for transmission, including addition of soft line breaks, space-stuffing, and [Quoted-Printable] encoding (to protect soft line breaks) before being digitally signed or encrypted; similarly, on receipt the message SHOULD have the signature verified or be decrypted before [Quoted-Printable] decoding and removal of stuffed spaces, soft line breaks and quote marks, and reflowing.
メッセージがデジタルにサインされるか、またはコード化されて、暗号の処理がワイヤを使用するのが、重要であるなら、Formatは流れる形式と等しいです。 世代の間のメッセージSHOULDが柔らかいラインブレイク、スペース詰め物の添加を含むトランスミッションのために準備されて、コード化して[引用されて印刷可能な](柔らかいラインブレイクを保護する)、デジタルにサインされるか、またはコード化される前に、それはいます。 同様に、領収書の上では、メッセージSHOULDは署名が確かめられるか、または[引用されて印刷可能]の解読と詰められた空間、柔らかいラインブレイク、引用符、および逆流の取り外しの前に解読されるのをさせます。
Gellens Standards Track [Page 9] RFC 2646 The Text/Plain Format Parameter August 1999
Gellens規格はテキスト/明瞭な形式パラメタ1999年8月にRFC2646を追跡します[9ページ]。
4.7. Line Analysis Table
4.7. 線分析テーブル
Lines contained in a Text/Plain body part with Format=Flowed can be analyzed by examining the start and end of the line. If the line starts with the quote indicator, it is quoted. If the line ends with one or more space characters, it is flowed. This is summarized by the following table:
行の始めと終わりを調べることによって、Format=が流れたText/平らな身体の部分に含まれた線は分析できます。 線が引用文のインディケータから始まるなら、それは引用されます。 線が1つ以上の間隔文字で終わるなら、それは終わります。流れました。 これは以下のテーブルによってまとめられます:
Starts Ends in
with One or Line
Quote More Spaces Type
------ ----------- ---------------
no no unquoted, fixed
yes no quoted, fixed
no yes unquoted, flowed
yes yes quoted, flowed
始めは1か線引用文で、より多くの空間タイプに終わります。------ ----------- --------------- いいえは全く引用を終わらないで、はいが引用を終わっていて、流れるはいはいが引用しなかった全く修理されて、引用されなかった固定はいは流れました。
4.8. Examples
4.8. 例
The following example contains three paragraphs:
以下の例は3つのパラグラフを含んでいます:
`Take some more tea,' the March Hare said to Alice, very
earnestly.
'撮影それ以上の紅茶'、非常に本気でアリスに言われた3月のHare。
`I've had nothing yet,' Alice replied in an offended tone, `so I
can't take more.'
アリスは、怒っているトーンで'私には、何もまだありません'、'したがって、私はさらに取ることができない'と返答しました。
`You mean you can't take LESS,' said the Hatter: `it's very easy
to take MORE than nothing.'
Hatterは、'あなたは、LESSを取ることができないと言っています'と言いました: 'MOREを取るのは無より非常に簡単です'。
This could be encoded as follows (using '*' to indicate a soft line break, that is, SP CRLF sequence, and '#' to indicate a hard line break, that is, CRLF):
以下の通り(柔らかいラインブレイク、すなわち、SP CRLF系列を示すのに'*'を使用して、困難なラインブレイク、すなわち、CRLFを示す'#')これをコード化できました:
`Take some more tea,' the March Hare said to Alice, very*
earnestly.*
#
`I've had nothing yet,' Alice replied in an offended tone, `so*
I can't take more.'*
#
`You mean you can't take LESS,' said the Hatter: `it's very*
easy to take MORE than nothing.'#
3月のHareは、'それ以上の紅茶を取ってください'と本気でアリス、まさしくその*に言いました。*#アリスは、怒っているトーンで'私には、何もまだありません'と返答して、'*したがって、私はさらに取ることができません'。*#Hatterは、'あなたは、LESSを取ることができないと言っています'と言いました: 'それは無よりMOREを取りやすいまさしくその*です'、#
Gellens Standards Track [Page 10] RFC 2646 The Text/Plain Format Parameter August 1999
Gellens規格はテキスト/明瞭な形式パラメタ1999年8月にRFC2646を追跡します[10ページ]。
To show an example of quoting, here we have the same exchange, presented as a series of direct quotes:
引用に関する例を示しているために、ここに、私たちは一連の直接引用文として提示された同じ交換を持っています:
>>>Take some more tea.#
>>I've had nothing yet, so I can't take more.#
>You mean you can't take LESS, it's very easy to take*
>MORE than nothing.#
>>>はそれ以上の紅茶を取ります。#>>Iには、何もまだありません、したがって、私はさらに取ることができません。#取ることができないあなたがLESS、それのまさしくその小休止を言っている>が無より*>MOREを取る、#
5. ABNF
5. ABNF
The constructs used in Text/Plain; Format=Flowed body parts are described using [ABNF], including the Core Rules:
Text/平野の中で使用された構造物。 流れる身体の形式=部分はCore Rulesを含む[ABNF]を使用することで説明されます:
paragraph = 1*flowed-line fixed-line
fixed-line = fixed / sig-sep
fixed = [quote] [stuffing] *text-char non-sp CRLF
flowed-line = flow-qt / flow-unqt
flow-qt = quote [stuffing] *text-char 1*SP CRLF
flow-unqt = [stuffing] *text-char 1*SP CRLF
non-sp = %x01-09 / %x0B / %x0C / %x0E-1F / %x21-7F
; any 7-bit US-ASCII character, excluding
; NUL, CR, LF, and SP
quote = 1*">"
sig-sep = [quote] "--" SP CRLF
stuffing = [SP] ; space-stuffed, added on generation if
; needed, deleted on reception
text-char = non-sp / SP
パラグラフ..等しい..流れる..線..修理..線..修理..線..修理..修理..引用..詰める..テキスト..炭..流れる..線..流れる..流れる..流れる..引用文..詰める..テキスト..炭..流れる..詰める..テキスト..炭 どんな7ビットの米国-ASCII文字、除外。 NUL、CR、LF、およびSPは=[SP]を詰める=1*">"sig-sep=[引用します]「--」SP CRLFを引用します。 スペースで詰められて、世代加えられる、。 非レセプションテキスト炭=sp / SPで必要で、削除されています。
6. Failure Modes
6. 故障モード
6.1. Trailing White Space Corruption
6.1. 引きずっている余白不正
There are systems in existence which alter trailing whitespace on messages which pass through them. Such systems may strip, or in rarer cases, add trailing whitespace, in violation of RFC 821 [SMTP] section 4.5.2.
引きずっている空白を変更する現存するシステムがそれらを通り抜けるメッセージにあります。 そのようなシステムが剥取られるかもしれませんか、またはもっともまれな場合には、RFC821[SMTP]部4.5の.2を違反して引きずっている空白を加えてください。
Stripping trailing whitespace has the effect of converting flowed lines to fixed lines, which results in a message no worse than if Format=Flowed had not been used.
引きずっている空白が=がFormatであるなら流れたほど悪くないメッセージのその結果が使用されていなかった固定線に流れる線を変換しながら効果を持っているストリップ。
Adding trailing whitespace to a Format=Flowed message may result in a malformed display or reply.
メッセージは奇形の表示か回答をもたらして、Format=への引きずっている空白が流れたと言い足すかもしれません。
Since most systems which add trailing white space do so to create a line which fills an internal record format, the result is almost always a line which contains an even number of characters (counting the added trailing white space).
引きずっている余白を加えるほとんどのシステムが内部のレコード形式をいっぱいにする線を作成するためにするので、ほとんどいつも結果はキャラクタの偶数を含む線(加えられた引きずっている余白を数えて)です。
Gellens Standards Track [Page 11] RFC 2646 The Text/Plain Format Parameter August 1999
Gellens規格はテキスト/明瞭な形式パラメタ1999年8月にRFC2646を追跡します[11ページ]。
One possible avoidance, therefore, would be to define Format=Flowed lines to use either one or two trailing space characters to indicate a flowed line, such that the total line length is odd. However, considering the scarcity of such systems today, it is not worth the added complexity.
回避がしたがって、Formatを定義することであることが可能な1つは流れる線を示すのにどちらかか2つの引きずっている間隔文字を使用するために流れる線と等しいです、総行長が変であるように。 しかしながら、今日そのようなシステムへの不足を考える場合、それは加えられた複雑さの価値がありません。
7. Security Considerations
7. セキュリティ問題
This parameter introduces no security considerations beyond those which apply to Text/Plain.
このパラメタはText/平野に適用されるものを超えてセキュリティ問題を全く紹介しません。
Section 4.6 discusses the interaction between Format=Flowed and digital signatures or encryption.
セクション4.6は流れてデジタルのFormat=署名か暗号化の間の相互作用について論じます。
8. IANA Considerations
8. IANA問題
IANA is requested to add a reference to this specification in the Text/Plain Media Type registration.
IANAがText/明瞭なメディアType登録におけるこの仕様の参照を加えるよう要求されています。
9. Internationalization Considerations
9. 国際化問題
The line wrap and quoting specifications of Format=Flowed may not be suitable for certain charsets, such as for Arabic and Hebrew characters that read from right to left. Care should be taken in applying format=flowed in these cases, as format=fixed combined with quoted-printable encoding may be more suitable.
線包装とFormat=の仕様が流れたのを引用するのはあるcharsetsに適当でないかもしれません、左への権利から読むアラビアの、そして、ヘブライ人のキャラクタなどのように。 注意は引用されて印刷可能なコード化に結合されていた状態で修理された形式=が、より適当であるかもしれないので、中に入れている適用形式=がこれらの場合で流れたということであるべきです。
10. Acknowledgments
10. 承認
This proposal evolved from a discussion of Chris Newman's Text/Paragraph draft which took place on the IETF 822 mailing list. Special thanks to Ian Bell, Steve Dorner, Brian Kelley, Dan Kohn, Laurence Lundblade, and Dan Wing for their reviews, comments, suggestions, and discussions.
この提案はIETF822メーリングリストで行われたクリス・ニューマンのText/パラグラフ草稿の議論から発展しました。 彼らのレビュー、コメント、提案、および議論のためのイアン・ベル、スティーブ・デルナー、ブライアン・ケリー、ダン・コーン、ローレンスLundblade、およびダンWingへの特別な感謝。
11. References
11. 参照
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, November
1997.
[ABNF] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[KEYWORDS]S.ブラドナー、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RICH] Resnick, P. and A. Walker, "The text/enriched MIME
Content-type", RFC 1896, February 1996.
[リッシュ]レズニックとP.とA.ウォーカー、「テキスト/豊かにされたMIME文書内容」、RFC1896、1996年2月。
Gellens Standards Track [Page 12] RFC 2646 The Text/Plain Format Parameter August 1999
Gellens規格はテキスト/明瞭な形式パラメタ1999年8月にRFC2646を追跡します[12ページ]。
[MIME-IMT] Freed, N. and N. Borenstein, "Multipurpose
Internet Mail Extensions (MIME) Part Two: Media
Types", RFC 2046, November 1996.
解放された[MIME-IMT]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は2を分けます」。 「メディアタイプ」、RFC2046、1996年11月。
[Quoted-Printable] Freed, N. and N. Borenstein, "Multipurpose
Internet Mail Extensions (MIME) Part One: Format
of Internet Message Bodies", RFC 2045, November
1996.
[引用されて印刷可能な] N.とN.Borenstein、解放されていて、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
[SMTP] Postel, J., "Simple Mail Transfer Protocol", STD
10, RFC 821, August 1982.
[SMTP] ポステル、J.、「簡単なメール転送プロトコル」、STD10、RFC821、1982年8月。
[HTML] Berners-Lee, T. and D. Connolly, "Hypertext Markup
Language -- 2.0", RFC 1866, November 1995.
そして、バーナーズ・リー、[HTML]T.、D.コノリー、「2インチ、RFC1866、1995年ハイパーテキストマークアップランゲージ--11月。」
12. Editor's Address
12. エディタのアドレス
Randall Gellens QUALCOMM Incorporated 5775 Morehouse Dr. San Diego, CA 92121-2779 USA
ランドルサンディエゴ、Gellensクアルコムの法人組織の5775モアハウス博士カリフォルニア92121-2779米国
Phone: +1 619 651 5115 EMail: randy@qualcomm.com
以下に電話をしてください。 +1 5115年の619 651メール: randy@qualcomm.com
Gellens Standards Track [Page 13] RFC 2646 The Text/Plain Format Parameter August 1999
Gellens規格はテキスト/明瞭な形式パラメタ1999年8月にRFC2646を追跡します[13ページ]。
13. Full Copyright Statement
13. 完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Gellens Standards Track [Page 14]
Gellens標準化過程[14ページ]
一覧
スポンサーリンク
