Network Working Group R. Gellens
Request for Comments: 3676 Qualcomm
Obsoletes: 2646 February 2004
Category: Standards Track
The Text/Plain Format and DelSp Parameters
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（C）インターネット協会（2004）。全著作権所有。
Abstract
抽象
This specification establishes two parameters (Format and DelSP) to be used with the Text/Plain media type. In the presence of these parameters, trailing whitespace is used to indicate flowed lines and a canonical quote indicator is used to indicate quoted lines. This results in an encoding which appears as normal Text/Plain in older implementations, since it is in fact normal Text/Plain, yet provides for superior wrapping/flowing, and quoting.
この仕様は、text / plainのメディアタイプで使用される2つのパラメータ（フォーマット及びDelSP）を確立します。これらのパラメータの存在下で、末尾の空白は、流入ラインを示すために使用され、正規引用インジケータは、引用されたラインを示すために使用されます。それは実際には通常のtext / plainであるので、これは、古い実装では、通常のテキスト/平野として表示されますエンコーディングになり、まだ優れたラッピング/流れ、および引用のために用意されています。
This document supersedes the one specified in RFC 2646, "The Text/Plain Format Parameter", and adds the DelSp parameter to accommodate languages/coded character sets in which ASCII spaces are not used or appear rarely.
この文書は、RFC 2646で指定されたものを優先し、「text / plainのフォーマットパラメータ」、およびASCIIのスペースを使用したり、まれにしか表示されないされていない言語/コード化文字セットに対応するためにDelSpパラメータを追加します。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in this Document . . . . . . . . . . . . . . 2
3. The Problem . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Paragraph Text. . . . . . . . . . . . . . . . . . . . . 3
3.2. Embarrassing Line Wrap . . . . . . . . . . . . . . . . 3
3.3. New Media Types . . . . . . . . . . . . . . . . . . . . 4
4. The Format and DelSp Parameters . . . . . . . . . . . . . . . 5
4.1. Interpreting Format=Flowed. . . . . . . . . . . . . . . 6
4.2. Generating Format=Flowed . . . . . . . . . . . . . . . 7
4.3. Usenet Signature Convention . . . . . . . . . . . . . . 9
4.4. Space-Stuffing . . . . . . . . . . . . . . . . . . . . 9
4.5. Quoting . . . . . . . . . . . . . . . . . . . . . . . . 9
4.6. Digital Signatures and Encryption . . . . . . . . . . . 11
4.7. Examples. . . . . . . . . . . . . . . . . . . . . . . . 12
5. Interoperability. . . . . . . . . . . . . . . . . . . . . . . 12
6. ABNF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Failure Modes . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Trailing White Space Corruption . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10. Internationalization Considerations . . . . . . . . . . . . . 15
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
12. Normative References. . . . . . . . . . . . . . . . . . . . . 16
13. Informative References. . . . . . . . . . . . . . . . . . . . 16
Appendix A: Changes from RFC 2646 . . . . . . . . . . . . . . . . 18
Author's Address. . . . . . . . . . . . . . . . . . . . . . . . . 19
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 20
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.)
相互運用性の問題は、テキスト/平野として、そして「恥ずかしいラインラップ」の様々な形を持つ段落テキストの誤ったラベルで観察されています。 （セクション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.
テキストなどの新しいメディアの種類を、展開するための試み/エンリッチド[リッチ]およびテキスト/ 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 are quoted and which lines are considered a logical paragraph, and thus eligible to be flowed (wrapped and joined) as appropriate.
必要なのは、すべての重要な点テキスト/平野にあるフォーマットであるため、text / plainのようなディスプレイのために非常に適しており、まだ送信者が行が引用され、ラインが論理的な段落と見なされている受信機に表現することができます、したがって流入対象（包み接合）適宜。
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].
キーワード「REQUIRED」、「MUST」、「MUST NOT」、「SHOULD」、「SHOULD NOT」、要件レベルを示すためにRFCで使用するためのキーワード」で説明したように、この文書に解釈されるべきである「MAY」 「[キーワード]。
The term "paragraph" is used here to mean a series of lines which are logically to be treated as a unit for display purposes and eligible to be flowed (wrapped and joined) as appropriate to fit in the display window and when creating text for replies, forwarding, etc.
用語「段落は、」表示窓に合わせて必要に応じて、論理的に表示のための単位として扱われると流さ対象（ラップと参加しました）一連の線を意味するためにここで使用され、返信用のテキストを作成する場合、転送、など
The Text/Plain media type is the lowest common denominator of Internet email, with lines of no more than 998 characters (by convention usually no more than 78), and where the carriage-return and line-feed (CRLF) sequence represents a line break (see [MIME-IMT] and [MSG-FMT]).
text / plainのメディアタイプは、（慣例通常せいぜい78）を超えない998文字の線と、インターネット電子メールの最小公分母であり、キャリッジリターンとラインフィードは、（CRLF）の配列は、行を表しますブレーク（[MIME-IMT]と[MSG-FMT]を参照）。
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.
text / plainでは、通常、多くの場合、固定フォントで、プリフォーマットテキストとして表示されます。これは、文字が新しい行が左マージンで再び、開始された時点でCRLFシーケンスが見られるまで、右、左表示窓のマージン、事前に開始し、あります。行の長さは、表示ウィンドウを超えると他の人が水平スクロールバーを起動している間、いくつかのクライアントは、行をラップします。
Text which meets this description is defined by this memo as "fixed".
この説明に合致するテキストは、「固定」としてこのメモによって定義されます。
Some interoperability problems have been observed with this format:
いくつかの相互運用性の問題は、この形式で観察されています：
Many modern programs use a proportional-spaced font, and use 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 format as Text/Plain, resulting in much user discomfort.
多くのソフトウェア製品は、誤って多くのユーザーの不快感が得られ、text / plainで、この形式にラベルを付けます。
As Text/Plain messages are quoted in replies or forwarded messages, each line gradually increases in length, eventually being arbitrarily hard wrapped, resulting in "embarrassing line wrap". This produces text which is, at best, hard to read, and often confuses attributions.
text / plainのメッセージが返信または転送メッセージに引用されているように、各ラインは徐々に「恥ずかしいラインラップ」で、その結果、最終的には任意のハード包まれ、長さが増加します。これは、最高の状態で、読みにくいテキストを生成し、多くの場合、帰属を混乱させる。
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番目のメッセージからのコメントです>>>>>。 >>>>これは、第3のメッセージからのコメントです。 >>>これは、4番目のメッセージからのコメントです。
It can be confusing to assign attribution to lines 2 and 4 above.
なお、上記の行2及び4に属性を割り当てることが混乱することができます。
In addition, as devices with display widths smaller than 79 or 80 characters become more popular, embarrassing line wrap has become even more prevalent, even with unquoted text.
また、ディスプレイを備えた装置としてより小さい79個のまたは80文字が、より一般的になっ幅、恥ずかしいラインラップでも引用符で囲まれていないテキストで、さらに普及しています。
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.
これは、複数の行にわたって流されることを意図された段落テキストです。しかし、送信メーラーはわずか30文字行とPDA上に示されたときに、それはこのように見えるようになり72文字の幅、固定テキストに変換されます。
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.
テキストなどの新しいメディアの種類を、展開するための試み/エンリッチド[リッチ]およびテキスト/ 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 / plainのように見たときに、ユーザ不幸に得られたと、倍増することが必要です。テキスト/ 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.
望まれることは、すべての重要な方法でtext / plainである形式であるため、text / plainのような表示のために非常に適しており、まだ送信側は線が論理段落と考えることができる受信機に表現することができ、したがって、流入します必要に応じて（包んで接合）。
This specification defines two MIME parameters for use with Text/Plain:
この仕様は、テキスト/平野で使用するための2つのMIMEパラメータを定義します。
Name: Format Value: Fixed, Flowed
名前：形式値：固定、流される
Name: DelSp Value: Yes, No
名前：DelSp値：はい、いいえ
(Neither the parameter names nor values are case sensitive.)
（パラメータ名や値はいずれも、大文字と小文字が区別されます。）
If Format is not specified, or if the value is not recognized, a value of Fixed is assumed. The semantics of the Fixed value are the usual associated with Text/Plain [MIME-IMT].
フォーマットが指定されていない場合値が認識されない場合、または、固定の値が想定されます。固定値のセマンティクスは、text / plainの[MIME-IMT]に関連付けられている通常です。
A Format 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.
流れの形式値が流れテキスト（このメモで指定されている）の定義は生成に使用し、受信に使用され得ることを示しています。
Note that because Format is a parameter of the Text/Plain content-type, any content-transfer-encoding used is irrelevant to the processing of flowed text.
フォーマットは、text / plainのコンテンツ・タイプのパラメータであるので、使用される任意のコンテンツ転送エンコードが流れテキストの処理とは無関係であることに留意されたいです。
If DelSp is not specified, or if its value is not recognized, a value of No is assumed. The use of DelSp without a Format value of Flowed is undefined. When creating messages, DelSp SHOULD NOT be specified in Text content types other than Text/Plain with Format = Flowed. When receiving messages, DelSp SHOULD be ignored if used in a Text content type other than Text/Plain with Format = Flowed.
DelSpが指定されていない場合、その値が認識されない場合、または、ノーの値が想定されます。流れのフォーマット値のないDelSpの使用が定義されていません。メッセージを作成するとき、DelSpはフォーマット=流れたとtext / plainの以外のテキストコンテンツタイプに指定することはできません。メッセージを受信するとフォーマット=流れたとtext / plainの以外のテキストコンテンツタイプで使用する場合、DelSpは無視されるべきです。
This section discusses flowed text; section 6 provides a formal definition.
このセクションでは、流入したテキストを議論します。セクション6は、形式的な定義を提供します。
Section 5 discusses interoperability.
第5節は、相互運用性について説明します。
Note that this memo describes an on-the-wire format. It does not address formats for local file storage.
このメモは、オン・ワイヤー形式について説明しています。これは、ローカルファイルストレージのためのフォーマットには対応していません。
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節を参照）を引用していると考えられます。論理的に、全ての引用符がカウントされ、非ゼロ引用深さ、及びコンテンツに沿って得られた、削除します。 （エージェントはもちろん、引用符や抜粋バーまたは何か他のものとのコンテンツを表示して自由である。）論理的には、引用された行については、このテストは、他のテスト（つまり、スペース詰めと流さをチェックする前に、ある）の前に行われます。
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 a space, the line is flowed. Otherwise it is fixed. The exception to this rule is a signature separator line, described in Section 4.3. Such lines end in a space but are neither flowed nor fixed.
行が空白で終わる場合、行が流されています。それ以外の場合は、固定されています。この規則の例外は、セクション4.3で説明した署名区切り線です。このような行がスペースで終了しますが、どちらも流さず固定されています。
If the line is flowed and DelSp is "yes", the trailing space immediately prior to the line's CRLF is logically deleted. If the DelSp parameter is "no" (or not specified, or set to an unrecognized value), the trailing space is not deleted.
ラインが流れ、DelSpは「yes」ですされている場合は、ラインのCRLFの直前に末尾のスペースは、論理的に削除されます。 DelSpパラメータが「ノー」である場合（または指定された、または認識されない値に設定されていない）、末尾のスペースは削除されません。
Any remaining trailing spaces are part of the line's content, but the CRLF of a soft line break is not.
残りの末尾のスペースは、行の内容の一部ですが、ソフト改行の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つの固定回線に続く一本の以上流れた一連の線は、段落とみなされ、ディスプレイ上の新しいメッセージ（4.5節を参照）の建設に必要に応じて（ラップされ、開封された）流されてもよいです。
An interpreting agent SHOULD allow for three exceptions to the rule that paragraphs end with a fixed line. These exceptions are improperly constructed messages: a flowed line SHOULD be considered to end the paragraph if it is followed by a line of a different quote depth (see 4.5) or by a signature separator (see 4.3); the end of the body also ends the paragraph.
通訳エージェントは、段落は固定回線で終わる規則の3つの例外を許可する必要があります。これらの例外は不適切メッセージを構築している：それは異なる引用深さの線で（4.5を参照）または署名セパレータ（4.3を参照）が続く場合に流れた行は、段落を終了するために考慮されるべきです。体の終わりにも段落を終了します。
A line consisting of one or more spaces (after deleting a space acting as stuffing) is considered a flowed line.
（詰め物として機能するスペースを削除した後）1つまたは複数のスペースからなるラインが流れた行であると考えられます。
An empty line (just a CRLF) is a fixed line.
空行（ただCRLF）が固定されたラインです。
Note that, for Unicode text, [Annex-14] provides guidance for choosing at which characters to wrap a line.
Unicodeテキストのために、[附属書-14]行をラップするためにどの文字で選択するためのガイダンスを提供し、ことに注意してください。
When generating Format=Flowed text, lines SHOULD be 78 characters or shorter, including any trailing white space and also including any space added as part of stuffing (see Section 4.4). As suggested values, any paragraph longer than 78 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.)
フォーマットを生成するときにテキストを流し=、行は（セクション4.4を参照）詰め物の一部として追加された空間を含む任意の末尾の空白とも含む、78文字より短くあるべきです。推奨値として、全長が78文字より長い任意の段落は、72文字以下の行を使用して巻き付けることができました。使用される特定の行の長さは、美学と好みの問題ですが、長い行は、リラップを必要とするし、古いメーラーで困難に直面する可能性が高くなります。 （66本の文字の線が最も読みやすいであることが示唆されています。）
The restriction to 78 or fewer characters between CRLFs on the wire is to conform to [MSG-FMT].
ワイヤ上のCRLFの間に78文字以下に制限する[MSG-FMT]に準拠することです。
(In addition to conformance to [MSG-FMT], there is a historical need that all lines, even when displayed by a non-flowed-aware program, will fit in a standard 79- or 80-column screen without having to be wrapped. The limit is 78, not 79 or 80, because while 79 or 80 fit on a line, the last column is often reserved for a line-wrap indicator.)
（[MSG-FMT]への適合に加えて、非流入認識プログラムによって表示される場合でも、すべての行が、ラップさせずに、標準的な79-又は80-列画面に収まることは歴史的必要性が存在しますライン上の79又は80にフィットしながら、最後の列は、しばしばラインラップインジケータのために予約されているからである。限界は、78ではなく、79または80です。）
When creating flowed text, the generating agent wraps, that is, inserts 'soft' line breaks as needed. Soft line breaks are added at natural wrapping points, such as between words. A soft line break is a SP CRLF sequence.
テキストを流さ作成する場合は、発生剤は、必要に応じつまり、挿入「ソフト」改行、ラップ。ソフト改行は、単語間のように、天然の包装点で添加されます。ソフト改行は、SP CRLFシーケンスです。
There are two techniques for inserting soft line breaks. The older technique, established by RFC 2646, creates a soft line break by inserting a CRLF after the occurrence of a space. With this technique, soft line breaks are only possible where spaces already occur. When this technique is used, the DelSp parameter SHOULD be used; if used it MUST be set to "no".
ソフト改行を挿入するための2つの技術があります。 RFC 2646によって確立された古い技術は、空間の発生後にCRLFを挿入することにより、ソフトな改行を作成します。この技術では、ソフト改行はスペースがすでに発生し、可能な場合のみです。この技術を用いる場合、DelSpパラメータが使用されるべきです。使用している場合には「いいえ」に設定しなければなりません。
The newer technique, suitable for use even with languages/coded character sets in which the ASCII space character is rare or not used, creates a soft line break by inserting a SP CRLF sequence. When this technique is used, the DelSp parameter MUST be used and MUST be set to "yes". Note that because of space-stuffing (see Section 4.4), when this technique is used and a soft line break is inserted at a point where a SP already exists (such as between words), if the SP CRLF sequence is added immediately before the SP, the pre-existing SP becomes leading and thus requires stuffing. It is RECOMMENDED that agents avoid this by inserting the SP CRLF sequence following the existing SP.
ASCIIスペース文字が使用稀かである言語/コード化文字セットで使用するのに適した新しい技術は、SP CRLF配列を挿入することによってソフト改行を作成します。この技術を使用すると、DelSpパラメータを使用しなければなりませんし、「はい」に設定しなければなりません。 SP CRLFシーケンスは直前に追加された場合、この技術が使用され、ソフト改行は、SPは、既に（例えば単語間のような）が存在する点に挿入されたときに、スペーススタッフィングで、（セクション4.4を参照）ことに留意されたいですSP、既存のSPは一流になり、したがって、詰め物を必要とします。エージェントが、既存のSP以下SP CRLF配列を挿入することによってこれを避けることが推奨されます。
Generating agents MAY use either method within each Text/Plain body part.
発生剤は、それぞれtext / plainの身体の部分の中のいずれかの方法を使用することができます。
Regardless of which technique is used, a generating agent SHOULD NOT insert a space in an unnatural location, such as into a word (a sequence of printable characters, not containing spaces, in a language/coded character set in which spaces are common). If faced with such a word which exceeds 78 characters (but less than 998 characters, the [SMTP] limit on line length), the agent SHOULD send the word as is and exceed the 78-character limit on line length.
かかわらず、使用される技術の、発生剤は、（スペースが共通である設定された言語/符号化された文字にスペースを含まない印刷可能な文字のシーケンス）ワードにとして、不自然な場所にスペースを挿入すべきではありません。 78文字（未満998の文字行の長さで、[SMTP]限界）を超えるような単語に直面した場合、エージェントはそのままワードを送信し、線路長に78文字の制限を超えなければなりません。
A generating agent SHOULD:
発生剤必要があります。
o Ensure all lines (fixed and flowed) are 78 characters or fewer in length, counting any trailing space as well as a space added as stuffing, but not counting the CRLF, unless a word by itself exceeds 78 characters.
Oすべての行を確認し（固定と流入）自体によって単語が78文字を超えない限り、任意の末尾のスペースだけでなく、スタッフィングとして追加スペースをカウント長さは78文字以下であるが、CRLFをカウントしません。
o Trim spaces before user-inserted hard line breaks.
Oユーザー挿入ハード改行の前にスペースをトリム。
A generating agent MUST:
発生剤の必要があります。
o Space-stuff lines which start with a space, "From ", or ">".
、「から」のスペースで始まるスペーススタッフラインO、または「>」。
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.
スペース詰め物を必要とし、フォーマット=固定として見た場合に、より美的ありませんメッセージを作成するためには、発生剤は、「>」、「から」、またはスペースの直前にラップを回避することができます。
(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.
形式=流れたメッセージは、一つ以上を含有するそれぞれ1つの固定されたラインに続くラインを流し、ゼロ以上の段落から成ります。通常の場合には、それらの間にブランク（空の）固定回線と流し込みテキスト行のシリーズです。
Any number of fixed lines can appear between paragraphs.
固定回線の任意の数の段落の間に表示することができます。
When placing soft line breaks in a paragraph, generating agents MUST NOT place them in a way that causes any line of the paragraph to be a signature separator line, because paragraphs cannot contain signature separator lines (see Sections 4.3 and 6).
段落のソフト改行を入れる場合は、エージェントを生成する段落が署名区切り線（セクション4.3および6を参照）を含めることができないため、署名区切り線であることを、段落の任意の行を引き起こし方法でそれらを配置してはならず。
[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).
[引用印刷可能]符号化形式には使用しないでください=（たとえば、未伸長[SMTP]として厳密に7ビットのトランスポートを介して、例えば、非US-ASCII（8ビット）文字）絶対に必要でない限り流します。具体的には、メッセージは、身体の一部が暗号（セクション4.6を参照）署名または暗号化されていない限り行を流しに末尾のスペースを保護する唯一の目的のために引用印刷可能で符号化されるべきではありません。
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.
フォーマットの目的は、=流れたユーザエージェントは（任意デコードなし）純粋、生のテキスト/プレーンとして見たときに非不快である流し込みテキストを生成できるようにすることです。 quoted-printable形式の使用はこれを妨げ、フォーマット=流れたが、エンドユーザーによって拒否される可能性があります。
There is a long-standing convention in Usenet news which also commonly appears in Internet mail 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 or quoted and stuffed) line consisting of DASH DASH SP is neither fixed nor flowed.
「 - 」は、身体とメッセージの署名との間に区切り線としても一般的に使用してのインターネットメールに表示されてUsenetニュースで長年の慣習があります。署名前ユーズネットスタイルのセパレータを含む形式=流れたメッセージを生成するときに、区切り線がそのまま送信されます。これは特殊なケースです。 DASHダッシュSPからなる（必要に応じて引用または引用詰め）線を固定することも、流入もされていません。
Generating agents MUST NOT end a paragraph with such a signature line.
発生剤は、このような署名行と段落を終了することはできません。
A receiving agent needs to test for a signature line both before the test for a quoted line (see Section 4.5) and also after logically counting and deleting quote marks and stuffing (see Section 4.4) from a quoted line.
受信エージェントは、両方の引用されたラインのためのテストの前に署名欄をテストする必要があります（4.5節を参照）、また、後に論理的に引用された行から（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 (which logically counts and deletes any quote marks), 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 " MUST be space-stuffed. Other lines MAY be space-stuffed as desired.
世代で、で始まる任意の引用符で囲まれていない行は、「>」、およびスペースまたは「から」で始まる行はスペースを詰めなければなりません。必要に応じて他の行はスペースを詰めてもよい（MAY）。
(Note that space-stuffing is conceptually similar to dot-stuffing as specified in [SMTP].)
（その空間スタッフィングはドットスタッフィングする[SMTP]で指定されるように概念的に類似であることに注意してください。）
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.
フォーマットで=は流れ、標準的な引用指標（または引用符）は、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".
なお、スペース詰めの、ライン>>終了し、ステージ左と>>終了し、ステージ左は意味的に同じです。両方とも2の引用深さ、および「終了、ステージ左」の内容を持っています。
However, the line > > Exit, Stage Left is different. It has a quote-depth of one, and a content of "> Exit, Stage Left".
しかし、ライン>>終了し、ステージ左は異なっています。これは、1つの引用深さ、および「>終了し、ステージ左」の内容を持っています。
When generating quoted flowed lines, an agent needs to pay attention to changes in quote depth. All lines of a paragraph MUST be unquoted, or else they MUST all be quoted and have the same quote depth. Therefore, whenever there is a change in quote depth, or a change from quoted to unquoted, or change from unquoted to quoted, the line immediately preceding the change MUST NOT be a flowed line.
引用された流れたラインを生成する場合、エージェントは、引用の深さの変化に注意を払う必要があります。段落のすべての行が引用符で囲まなければなりません、さもなければそれらはすべて引用されたと同じ引用深さを持っていなければなりません。引用深さの変化、または引用符で囲まれていない、または引用符で囲まれていないから引用の変化に引用から変更があるたびにそのため、直ちに変更の前の行が流れ線であるはずがありません。
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. To re-quote after reformatting, a quote indicator containing the same number of close angle brackets originally present are prefixed to each line.
受信エージェントは、ディスプレイ上に引用されたライン（接合及び/又はそれらを包む）を流したり、新しいメッセージを生成する際に、ラインは、引用された脱再フォーマットし、再度引用されるべきである。再フォーマットすることを望む場合脱引用するために、各ラインの開始時に引用インジケータに近い角括弧の数がカウントされます。再引用する再フォーマットした後、元々存在近い角括弧の同じ数を含む引用インジケータは、各行に前置されています。
On reception, if a change in quote 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 consider the paragraph to end with the flowed line immediately preceding the change in quote depth.
引用深さの変化が流れ線に発生した場合、受信に、これは、不適切にフォーマットされたメッセージです。受信機はすぐに引用深さの変化の前に流れた行で終了する段落を考慮することである「引用深さの勝利」のルールを、使用することで、このエラーを処理する必要があります。
In other words, whenever two adjacent lines have different quote depths, senders MUST ensure that the earlier line is not flowed (does not end in a space), and receivers finding a flowed line there SHOULD treat it as the last line of a paragraph.
隣接する二つの線が異なる引用の深さを持っている時はいつでも言い換えれば、送信者は、以前の行が（スペースで終わっていない）流されていないことを確認しなければならない、と流れたラインを見つけるの受信機は、段落の最後の行としてそれをそこに扱うべきです。
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):
例えば、（すなわち、CRLF、ハード改行を示すために、すなわち、SP 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?#
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 is to be interpreted, considering that the next line is the first line of the two-deep quote block.
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の引用深さで、セクションを流します。 3行目と4行目は、2の引用深さで、引用され、流入部となります。
A generating agent MUST NOT create this situation; a receiving agent SHOULD handle it by giving preference to the quote depth.
発生剤は、このような状況を作成してはいけません。受信エージェントは、引用の深さを優先してそれを処理する必要があります。
If a message is digitally signed or encrypted it is important that cryptographic processing use the same text for signature verification and/or decryption as was used for signature generation and/or encryption. Since the use of format=flowed allows text to be altered (by adding or removing line breaks and trailing spaces) between composition and transmission, and between reception and display, interoperability problems or security vulnerabilities may arise if originator and recipient do not both use the on-the-wire format for cryptographic processing.
メッセージがデジタル署名または暗号化されている場合は、署名生成及び/又は暗号化のために使用されたように、暗号処理、署名検証および/または復号化に同じテキストを使用することが重要です。形式=流しの使用は、組成物と変速機との間に（改行と末尾のスペースを追加または削除することにより）テキストが変更されることを可能にし、発信者と受信者の両方が使用していない場合は受信とディスプレイとの間に、相互運用性の問題やセキュリティの脆弱性が生じる可能性があるので暗号処理のためのオン・ザ・ワイヤ形式。
The implications of the interaction between format=flowed and any specific cryptographic process depend on the details of the cryptographic processing and should be understood before using format=flowed in conjunction with signed and/or encrypted messages.
署名されたおよび/またはメッセージを暗号化に関連して流し=フォーマットとの間の相互作用の影響は=流し、特定の暗号処理は、暗号処理の詳細に依存し、形式を使用する前に理解すべきです。
Note that [OpenPGP] specifies (in Section 7.1) that "any trailing whitespace (spaces, and tabs, 0x09) at the end of any line is ignored when the cleartext signature is calculated."
注【のOpenPGP]その（セクション7.1）で指定された「末尾の空白（スペース、タブ、0x09の）平文署名が計算されるとき、任意の行の最後に無視されます。」
Thus it would be possible to add, in transit, a format=flowed header to a regular, format=fixed vanilla PGP (not [OpenPGP-MIME]) signed message and add arbitrary trailing space characters without this addition being detected. This would change the rendering of the article by a client which supported format=flowed.
したがって、それは輸送中に、追加することも可能で、フォーマットは=レギュラー、形式=固定バニラPGP（ない[のOpenPGP-MIME]）署名されたメッセージにヘッダを流し、この添加は、検出されることなく、任意の末尾の空白文字を追加します。これは=が流れたフォーマットをサポートし、クライアントによる記事のレンダリングを変更します。
Therefore, the use of [OpenPGP] with format=flowed messages is strongly discouraged. [OpenPGP-MIME] is recommended instead.
したがって、[のOpenPGP]の使用は形式で=強く推奨されたメッセージを流します。 【のOpenPGP-MIME]は代わりに推奨されます。
The following example contains three paragraphs:
次の例では、3つのパラグラフが含まれています。
`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.'
`あなたがLESSを取ることができない意味、「帽子屋さんは言った：`それは何もないより多くを取ることは非常に簡単です。」
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):
これは、以下のように（つまり、CRLFで、ハード改行を示すために、それは、SP 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.'#
`もう少しお茶を取り、「三月うさぎは非常に*真剣に、アリスに言った。##`私はまだ何もなかったしましたが、アリスは怒った口調で答えた、 `私はより多くを取ることができない*。"の##の `あなたはLESSを取ることができない意味、「帽子屋さんは言った： `それは何もないより多くを取ることは容易では非常に*です。」＃
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.#
>>>もう少しお茶を取る。＃>>私はまだ何もなかったしましたので、私はより多くを取ることができない。＃>あなたはLESSを取ることができない意味、それは何もないより*> MOREを取ることは非常に簡単です。＃
Because flowed lines are all-but-indistinguishable from fixed lines, software which does not recognize Format=Flowed treats flowed lines as normal Text/Plain (which is what they are). Thus, Format=Flowed interoperates with older clients, although flowed lines will have trailing white space inserted.
行が固定回線と区別できないすべて - しかし、ある流れたので、フォーマットを認識しないソフトウェアは=扱いが（彼らが何であるかである）通常のテキスト/ plainとしてラインを流れて流れました。流れた行が挿入された空白を末尾に持つことになりますが、このように、フォーマット=流れたが、古いクライアントと相互運用できます。
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.
スペース詰めメッセージは書式=は流れを扱うエージェントによって受信された場合は、スペース詰めが逆転されるため、メッセージがそのまま表示されます。フォーマットを認識していないエージェントは=流れたが、もちろん任意のスペーススタッフィングを元に戻すことはありません。これフォーマット=流れたメッセージは、（引用インジケータ、または「から」ではありませんスペース、「>」で始まるもの）は、いくつかの行に先頭のスペースで表示されることがあります。めったに発生しないスペーススタッフィングを必要とする回線、およびunreversedスペーススタッフィングの審美的な影響は最小限であるため、これは重要な問題であることが予想されていません。
If some lines begin with one or more spaces, the generating agent MAY space-stuff all lines, to maintain the relative indentation of the lines when viewed by clients which are not aware of Format=Flowed.
いくつかの行は、フォーマット=は流れを認識していないクライアントで見たときの線の相対的なインデントを維持するために、すべての行、1つ以上のスペースで発生剤MAYスペース-ものを開始した場合。
Messages generated with DelSp=yes and received by clients which are aware of Format=Flowed but are not aware of the DelSp parameter will have an extra space remaining after removal of soft line breaks. Thus, when generating text in languages/coded character sets in which spaces are common, the generating agent MAY always use the DelSp=no method.
DelSpで生成されたメッセージ= YESとFormat =は流れを認識していますが、柔らかいラインブレイクを除去した後に残った余分なスペースを持っていますDelSpパラメータを認識していないクライアントが受信しました。スペースが共通である言語/コード化文字セットでテキストを生成するときにこのように、発生剤は、常にDelSp =なしの方法を使用することができます。
Hand-aligned text, such as ASCII tables or art, source code, etc., SHOULD be sent as fixed, not flowed lines.
固定されたような等ASCIIテーブルや技術、ソースコード、などの手整列テキストは、送信されるべきであり、行を流しません。
The constructs used in Text/Plain; Format=Flowed body parts are described using Augmented Backus-Naur Form [ABNF], including the core rules defined in Appendix A.
text / plainのに使用される構造。フォーマットは=身体の部分は、付録Aで定義されたコア・ルールを含めた拡張バッカスナウア記法[ABNF]を使用して記述されている流入しました
Note that the SP (space) and ">" characters are encoded according to the charset parameter.
SP（空間）と「>」の文字が文字セットパラメータに従って符号化されることに留意されたいです。
flowed-body = *( paragraph / fixed-line / sig-sep ) paragraph = 1*flowed-line fixed-line ; all lines in paragraph MUST be unquoted or ; have same quote depth flowed-line = ( flowed-line-qt / flowed-line-unqt ) flow CRLF flowed-line-qt = quote ( ( stuffing stuffed-flowed ) / unstuffed-flowed ) flowed-line-unqt = ( stuffing stuffed-flowed ) / unstuffed-flowed stuffed-flowed = *text-char unstuffed-flowed = non-sp-quote *text-char fixed-line = fixed-line-qt / fixed-line-unqt fixed-line-qt = quote ( ( stuffing stuffed-fixed ) /
= *（段落/固定ライン/ SIG-9）段落= 1 *流入ライン固定回線体を流します。段落内のすべての行は引用符で囲まれていないか、しなければなりません。同じ引用深さが持って流入ライン= CRLF =引用（（詰め流さ）/ unstuffed流さがスタッフィング）=ライン-unqt流入ライン-QT流し（スタッフィングフロー（/流入ライン-unqtライン-QT流入） =流さぬいぐるみ）/ unstuffed流さ詰め流さ= *テキスト文字unstuffed流さ=非SP-引用*テキスト文字固定回線=固定回線-QT /固定ラインunqt固定回線-QT引用符（（詰め詰め-固定）/
unstuffed-fixed ) CRLF fixed-line-unqt = ( stuffed-fixed / unstuffed-fixed ) CRLF stuffed-fixed = *text-char non-sp unstuffed-fixed = non-sp-quote [ *text-char non-sp ] sig-sep = [ quote [stuffing] ] "--" SP CRLF quote-mark = ">" quote = 1*quote-mark stuffing = SP ; space-stuffed, added on generation if ; needed, deleted on reception flow = SP ; space before CRLF indicates flowed line, ; if DelSp=yes, space was added on generation ; and is deleted on reception non-sp-quote = < any character except NUL, CR, LF, SP, quote-mark > non-sp = non-sp-quote / quote-mark text-char = non-sp / SP
unstuffed固定）CRLF固定ラインunqt =（ぬいぐるみ固定/-unstuffed固定）CRLF = *テキスト文字非SP unstuffed固定=非SP-引用[*テキスト文字非SP]詰め固定SIG-9月= [引用[スタッフィング] " - " SP CRLF引用マーク= ">" 引用= 1 *引用マークスタッフィング= SP。スペース詰め、生成に追加した場合は、受信フロー= SPで削除、必要に応じて、 CRLFの前のスペースは、流れた行を示します。もしDelSp = yesの場合、スペースが生成に追加されました。そして、受信非SP-引用符で削除された=非SP =非SP引用符/引用マークテキスト文字=非SP / SP <NUL、CR、LF、SP、引用マーク以外の任意の文字>
That is, a Format=Flowed message body consists of any number of paragraphs and/or fixed lines and/or signature separator lines; paragraphs need at least one flowed line and are terminated by a fixed line; the fixed line terminating the paragraph is part of the paragraph. (There are some exceptions to this described in the text.)
すなわち、形式=流しメッセージ本体が段落の任意の数で構成され、及び/又は線及び/又は署名区切り線を固定。段落は、少なくとも1つのラインを流し、固定ラインによって終了される必要があります。段落の終端固定回線は、段落の一部です。 （本文中で説明した本にはいくつかの例外があります。）
Without at least one flowed line, there is a series of fixed lines, each independent. There is no paragraph.
少なくとも一つのラインを流すことなく、固定された一連の線、各々独立あります。何の段落はありません。
With at least one flowed line, there is a paragraph, and the received lines can be reformed and flowed to fit the display window size. This can only be done if the lines are part of a logical grouping, the paragraph.
少なくとも一つの流れたラインで、そこに段落があり、受信したラインは、改革と表示ウィンドウサイズに合わせて流すことができます。行が論理的なグループ、段落の一部である場合にのみ行うことができます。
Note that the definitions of flowed-line and sig-sep are potentially ambiguous: a signature separator line matches both, but is treated as a signature separator line and not a flowed line.
流入ラインおよびSIG-9月の定義は、潜在的に曖昧であることに注意：署名区切り線が共に一致するが、署名区切り線としない流し込みラインとして扱われます。
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 2821 [SMTP] Section 4.5.2.
それらを通過するメッセージに末尾の空白を変える現存するシステムがあります。そのようなシステムは、ストリップ、又は稀な場合では、RFC 2821 [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.
末尾の空白を剥離する形式=流れたが、使用されていない場合より悪くないメッセージをもたらす、固定回線に回線を流し変換する効果を有します。
Adding trailing whitespace to a Format=Flowed message may result in a malformed display or reply.
形式=流れたメッセージに末尾の空白を追加すると、不正な表示または応答をもたらすことができます。
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).
末尾の空白を追加し、ほとんどのシステムは、内部レコード形式を満たす行を作成するためにそれを行うので、結果はほとんど常に（追加末尾の空白をカウント）文字の数が偶数個のラインです。
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.
一つの可能な回避は、従って、フォーマットを定義することであろう=総線長が奇数であるように、流れたラインを示すために1つのまたは2つの末尾の空白文字を使用する行を流します。しかし、今日のようなシステムの希少性を考慮すると、それは追加の複雑価値はありません。
Any security considerations which apply to Text/Plain also apply to Text/Plain with Format=Flowed.
/平野をテキストに適用するセキュリティの考慮も=フォーマットでは流れをtext / plainにするために適用されます。
Section 4.6 discusses the interaction between Format=Flowed and digital signatures or encryption.
4.6節は、フォーマット=流れ、デジタル署名や暗号化の間の相互作用について説明します。
IANA has added a reference to this specification in the Text/Plain Media Type registration.
IANAは、text / plainのメディアタイプの登録でこの仕様への参照を追加しました。
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 needs to be taken in applying format=flowed in these cases, as format=fixed combined with [quoted-printable] encoding may be more suitable.
行の折り返しとFormat =は流れの引用仕様は、そのような右から左に読んでアラビア語とヘブライ文字のように特定の文字セット、に適していないかもしれません。ケア=フォーマットを適用することで撮影これらの場合に流れ、フォーマットのよう=より適切であってもよい[引用印刷可能]符号化と組み合わせて固定する必要があります。
The DelSp parameter was added specifically to permit Format=Flowed to be used with languages/coded character sets in which the ASCII space character is rarely used, or not used at all.
DelSpパラメータは、フォーマットのASCIIスペース文字はほとんど使用されない、または全く使用されている言語/コード化文字セットで使用する=は流れを可能にするために、特に追加されました。
The DelSp parameter was developed during a series of discussions among a number of people, including Harald Alvestrand, Grant Baillie, Ian Bell, Steve Dorner, Patrik Faltstrom, Eric Fischer, Ned Freed, Alexey Melnikov, John Myers, and Pete Resnick.
DelSpパラメータはハラルドAlvestrand、グラントベイリー、イアンベル、スティーブ・ドルナー、パトリックFaltstrom、エリック・フィッシャー、ネッドフリード、アレクセイ・メルニコフ、ジョン・マイヤーズ、そしてピートレズニックなど、人の数、の間で議論の一連の間に開発されました。
Corrections and clarifications to RFC 2646 and early versions of this document were pointed out by several people, including Adam Costello, Jutta Degener, Tony Hansen, Simon Josefsson, Dan Kohn, Ragho Mahalingam, Keith Moore, Greg Troxel, and Dan Wing.
RFC 2646およびこのドキュメントの初期バージョンの訂正と明確化はアダム・コステロ、ユッタ・デッジナー、トニー・ハンセン、サイモンJosefsson氏、ダンコーン、Ragho Mahalingam、キースムーア、グレッグTroxel、そしてダン・ウィングを含むいくつかの人々によって指摘されました。
I'm told that NeXT's mail application used a very similar mechanism (without support for non-Western languages) in 1992.
私は次のメールアプリケーションは、1992年（非西洋言語のサポートなしで）非常によく似たメカニズムを使用したことを聞いています。
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[ABNF]クロッカー、D.、エド。そして、P. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 2234、1997年11月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[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：メディアタイプ"、RFC 2046、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.
[quoted-printableの]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[Annex-14] Unicode Standard Annex #14, "Line Breaking Properties" <URL:http://www.unicode.org/unicode/reports/tr14/>
[附属書-14] Unicode標準の附属書＃14、 "行分割のプロパティ" <URL：のhttp：//www.unicode.org/unicode/reports/tr14/>
[MSG-FMT] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001.
[MSG-FMT]レズニック、P.、エド。、 "インターネットメッセージ形式"、RFC 2822、2001年4月。
[OpenPGP] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.
【のOpenPGP]カラス、J.、Donnerhacke、L.、フィニー、H.及びR.セイヤー、 "OpenPGPのメッセージフォーマット"、RFC 2440、1998年11月。
[OpenPGP-MIME] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC 2015, October 1996.
[のOpenPGP-MIME]エルキンズ、M.、 "プリティグッドプライバシーとMIMEセキュリティ（PGP）"、RFC 2015、1996年10月。
Elkins, M., Del Torto, D., Levien, R. and J.
Roessler, "MIME Security with OpenPGP", RFC 3156,
August 2001.
[Rich] Resnick, P. and A. Walker, "The text/enriched MIME Content-type", RFC 1896, February 1996.
[リッチ]レズニック、P.とA.ウォーカー、 "テキスト/濃縮のMIMEコンテンツタイプ"、RFC 1896、1996年2月。
[SMTP] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[SMTP] Klensin、J.、エド。、 "簡易メール転送プロトコル"、RFC 2821、2001年4月。
Appendix A: Changes from RFC 2646
付録A：RFC 2646からの変更点
Substantive:
実質的な：
o Added DelSp parameter to handle languages and coded character sets in which space is less common or not used. o Updated text on generating and interpreting to accommodate the DelSp parameter. o Changed the limits of 79 or 80 to be 78 in conformance with RFC 2822. o Added text on generating to clarify that the 78-character limit includes trailing white space and stuffing. o Changed sig-sep in ABNF to allow stuffing. o Changed fixed-line to allow empty lines in ABNF. o Added explanatory text following ABNF. o Moved text from Abstract to new Introduction; rewrote Abstract. o Moved interoperability text to new section, and updated. o Clarified Security Considerations. o Text on digital signatures now discusses that OpenPGP ignores trailing white space. o Mention Unicode Annex 14. o Added mention of quoting to Abstract and Introduction. o Deleted line analysis table. o Added recommendations for OpenPGP and OpenPGP-MIME. o Rewrote ABNF rules to remove most ambiguity and note remaining case. o Added note that c-t-e is irrelevant to flowed text processing. o Added text indicating that end of data terminates a paragraph. o Moved sig-sep out of fixed-line ABNF. o Changed some SHOULDs to MUSTs (space-stuffing, quoted paragraphs). o Added note to ABNF that space and ">" are encoded according to charset. o Mentioned exceptions in section on interpreting. o Clarified and made consistent treatment of signature separator lines.
Oを追加しましたDelSpパラメータは、言語やスペースがあまり一般的または使用されていない符号化文字集合を処理します。 Oの生成とDelSpパラメータに対応するために、解釈上のテキストを更新しました。 O 78文字の制限が空白とスタッフィング末尾含まれていることを明確にするために生成で追加のテキストO RFC 2822に準拠した78であることが79または80の制限を変更しました。 O詰めを許可するようにABNFにSIG-9月に変更しました。 O ABNFに空白行を可能に固定されたラインを変更しました。 O ABNF以下の説明文を追加しました。 O抽象から新しいはじめにテキストを移動。要約を書き直しました。 O新しいセクションへの相互運用性のテキストを移動し、更新しました。 Oセキュリティの考慮事項を明らかにしました。デジタル署名のOテキストは現在のOpenPGPは、末尾の空白は無視されていることについて説明します。 O抽象と紹介に引用を追加しまし言及oをUnicodeの附属書14に言及。 Oライン分析表を削除しました。 OのOpenPGPとのOpenPGP-MIMEのための提言を追加しました。 O書き直しABNF規則は、ほとんどの曖昧さやノート残りのケースを削除します。 O C-T-Eは、テキスト処理を流すとは無関係であることに注意を追加しました。 Oデータの終了を示す追加のテキストは、段落を終了します。 O固定回線ABNFのうち、SIG-9月に移動しました。 O（段落を引用し、スペース詰め）マストにいくつかのSHOULDsを変更しました。 OそのスペースをABNFにメモを追加しましたし、「>」は文字セットに従って符号化されます。 O解釈上のセクションで例外に言及しました。 O清澄化し、署名区切り線の一貫した処理を行いました。
Editorial:
社説：
o Added mention of NeXT's mail application to Acknowledgments. o Updated Acknowledgments. o Updated [SMTP] reference to 2821. o Added Notices. o Split References into Normative and Informative. o Improved text wording in some areas. o Standardize on "quote depth", not "quoting depth". o Moved section on interpreting before section on generating. o Reworded non-normative "should"s. o Noted meaning of "paragraph".
O謝辞の隣のメールアプリケーションの言及を追加しました。 O更新謝辞。 Oを追加しました注意事項oを2821に、[SMTP]の参照を更新しました。 O規範的で有益に参照を分割します。 O一部の地域では、テキストの文言を改善しました。 o「の深さを引用」ではない、「引用深さ」を標準化。 O生成のセクションの前に解釈上のセクションを移動しました。 O非規範的な「べき」Sを言い換えました。 O「段落」の意味を指摘しました。
The DelSp parameter was added specifically to permit Format=Flowed to be used with languages/coded character sets in which the ASCII space character is rarely used, or not used at all. The DelSp mechanism was selected despite having been initially rejected as too much of a kludge, because among the many different techniques proposed, it allows for maximum interoperability among clients which support neither this specification nor RFC 2646, those which do support RFC 2646 but not this specification, and those that do support this specification; this set is multiplied by those that handle languages/coded character sets in which spaces are common, and in which they are uncommon or not used.
DelSpパラメータは、フォーマットのASCIIスペース文字はほとんど使用されない、または全く使用されている言語/コード化文字セットで使用する=は流れを可能にするために、特に追加されました。提案されている多くの異なった技術の中で、それはRFC 2646をサポートしていますものではなく、この、この仕様もRFC 2646のいずれをサポートするクライアントの間で最大の相互運用が可能になりますので、DelSp機構は、最初にその場しのぎのあまりとして拒否されたにも関わらず、選択しました仕様、およびこの仕様をサポートしていないもの。このセットは、その中にスペースが共通であり、それらが珍しいかを使用している言語/コード化文字セットを処理するもので乗算されます。
Author's Address
著者のアドレス
Randall Gellens QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121 USA
ランドールGellens QUALCOMM Incorporatedの5775モアハウスドライブサンディエゴ、CA 92121 USA
Phone: +1 858 651 5115 EMail: randy@qualcomm.com
電話：+1 858 651 5115 Eメール：randy@qualcomm.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.
著作権（C）インターネット協会（2004）。この文書では、BCP 78に含まれる権利、ライセンスおよび制限があり、そこに記載された以外、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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 procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。