[要約] RFC 2646は、テキスト/プレーン形式のパラメータに関する規格であり、テキストメッセージのフォーマットを制御するための目的を持つ。要約すると、テキスト/プレーン形式のパラメータの使用方法と効果的な適用についてのガイドラインを提供している。
Network Working Group R. Gellens, Editor
Request for Comments: 2646 Qualcomm
Updates: 2046 August 1999
Category: Standards Track
The Text/Plain Format Parameter
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 (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
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
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.
テキストなどの新しいメディアの種類を、展開するための試み/エンリッチド[RICH]と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.
必要なのは、すべての重要な方法でtext / plainである形式であるため、text / plainのような表示のために非常に適しており、まだ送信側は線が論理段落と考えることができる受信機に表現することができ、したがって、流入します必要に応じて（包んで接合）。
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.
このメモは、このパラメータの存在下で、示すために空白を後続の使用はラインを流し、テキスト/プレーンで使用される新しいパラメータを提案し、そして。それは実際、通常のテキスト/平野であるので、これは、古い実装では、通常のテキスト/平野として表示されますエンコーディングになります。
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 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 / plainのメディアタイプは、（慣例通常せいぜい80による）を超えない997文字の線と、インターネット電子メールの最小公分母であり、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.
text / plainでは、通常、多くの場合、固定フォントで、プリフォーマットテキストとして表示されます。これは、文字が新しい行が左マージンで再び、開始された時点でCRLFシーケンスが見られるまで、右、左表示窓のマージン、事前に開始し、あります。行の長さは、表示ウィンドウを超えると他の人が水平スクロールバーを起動している間、いくつかのクライアントは、行をラップします。
Text which meets this description is defined by this memo as "fixed".
この説明に合致するテキストは、「固定」としてこのメモによって定義されます。
Some interoperability problems have been observed with this media type:
いくつかの相互運用性の問題は、このメディアタイプで観察されています：
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 / plainのように、このメディアタイプにラベルを付けます。
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 / 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.
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個の文字が、より一般的になっ幅、恥ずかしいラインラップでも引用符で囲まれていないテキストで、さらに普及しています。
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.
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.
テキストなどの新しいメディアの種類を、展開するための試み/エンリッチド[RICH]と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 / 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.
明示的に現在配備ソフトウェアとの相互運用性の欠如に苦しん段落の形を表現するために、新しいメディアタイプを定義するための提案。一部のプログラムは添付ファイルとしてテキストの未知のサブタイプを扱います。
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 document defines a new MIME parameter for use with Text/Plain:
この文書では、テキスト/平野で使用する新しい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].
指定されていない場合は、固定の値が想定されます。固定値のセマンティクスは、text / plainの[MIME-IMT]に関連付けられている通常です。
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.
流れの値が流れテキスト（このメモで指定されている）の定義は生成に使用し、受信に使用され得ることを示しています。
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.
流入した行はすべて-しかし、区別できない固定回線からなので、現在配備ソフトウェアの扱いは（彼らが何であるかである）通常のテキスト/平野としてラインを流れました。このように、何の相互運用性の問題は予想されません。
Note that this memo describes an on-the-wire format. It does not address formats for local file storage.
このメモは、オン・ワイヤー形式について説明しています。これは、ローカルファイルストレージのためのフォーマットには対応していません。
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.
フォーマット=流れたテキストを生成するとき、行が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.)
（ワイヤ上のCRLFの間に79文字以下に制限する理由は、非流入認識プログラムによって表示される場合でも、すべての行が、ラップさせずに、標準的な80列の画面に収まることを保証することです。ライン上の80フィットしながら、最後の列は、多くの場合、ラインラップインジケータ用に予約されているので制限は、79、80ではないです。）
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.
発生剤は、単語（スペースを含まない、印刷可能な文字の列）に空白を挿入すべきではありません。 79文字（未満998の文字行の長さで、[SMTP]限界）を超えた単語に直面した場合、エージェントはそのままワードを送信し、線路長に79文字の制限を超えなければなりません。
A generating agent 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文字を超えない限り、全てのライン（固定と流入）は、末尾のスペースをカウントする長さ79文字以下であるが、CRLFをカウントしていないことを確認します。ユーザーが挿入されたハード改行の前に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.
スペース詰め物を必要とし、フォーマット=固定として見た場合に、より美的ありませんメッセージを作成するためには、発生剤は、「>」、「から」、またはスペースの直前にラップを回避することができます。
(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.
固定回線の任意の数の段落の間に表示することができます。
[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形式の使用はこれを妨げ、フォーマット=流れたが、エンドユーザーによって拒否される可能性があります。
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 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).
つの固定ラインに続く一つ以上の流入ラインの一連の段落とみなされ、ディスプレイ上の新しいメッセージ（セクション4.5を参照）の構成に適宜（ラップされ、開封された）流すことができます。
A line consisting of one or more spaces (after deleting a stuffed space) is considered a flowed line.
1つ以上のスペース（詰めスペースを削除した後）からなるラインが流れた行であると考えられます。
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ニュースのコンベンションがあります。署名前ユーズネットスタイルのセパレータを含む形式=流れたメッセージを生成するときに、区切り線がそのまま送信されます。これは特殊なケースです。 DASHダッシュSPからなる（必要に応じて引用）ラインを流すとは見なされません。
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.
世代で、で始まる任意の引用符で囲まれていない行は、「>」、およびスペースまたは「から」で始まる行は、スペース詰めであるべきです。必要に応じて他の行はスペースを詰めてもよい（MAY）。
(Note that space-stuffing is similar to dot-stuffing as specified in [SMTP].)
（その空間スタッフィングはドットスタッフィングする[SMTP]で指定されたものと同様であることに注意してください。）
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.
スペース詰めメッセージは書式=は流れを扱うエージェントによって受信された場合は、スペース詰めが逆転されるため、メッセージがそのまま表示されます。フォーマットを認識していないエージェントは=流れたが、もちろん任意のスペース詰め、これフォーマットを元に戻すことはありません=流さ引用されていないいくつかの行（空白で始まるものが、上の主要なスペース「>」と表示されることがありますメッセージインジケータ、または）の "From"。めったに発生しないスペーススタッフィングを必要とする回線、およびunreversedスペーススタッフィングの審美的な影響は最小限であるため、これは重要な問題であることが予想されていません。
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. 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.
引用された流れたラインを生成する場合、エージェントは、引用の深さの変化に注意を払う必要があります。同じ引用深度の引用された行の順序を固定し、流した従来線が生成されるような生成された最後の行と、段落として符号化されるべきです。
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.
受信エージェントは、ディスプレイ上に引用されたライン（接合及び/又はそれらを包む）を流したり、新しいメッセージを生成する際に、ラインは、引用された脱再フォーマットし、再度引用されるべきである。再フォーマットすることを望む場合脱引用するために、各ラインの開始時に引用インジケータに近い角括弧の数がカウントされます。同じ引用深さの連続した行を1つの段落とみなされ、一緒に再フォーマットされています。再引用する再フォーマットした後、元々存在近い角括弧の同じ数を含む引用インジケータは、各ラインの前に付けています。
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.
深さを引用の変化が流れ線に発生した場合、受信に、これは、不適切にフォーマットされたメッセージです。受信機が流れインジケータを無視して固定され、ラインを処理することである「引用深さ勝利」ルールを使用してこのエラーを処理します。つまり、引用深さの変化は、段落を終了します。
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 should 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 SHOULD NOT create this situation; a receiving agent SHOULD handle it using quote-depth wins.
発生剤は、このような状況を作るべきではありません。受信エージェントがquote-深さの勝利を使用して、それを処理する必要があります。
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.
メッセージがデジタル署名または暗号化されている場合には、暗号処理が、オン・ザ・ワイヤ形式=流れたフォーマットを使用することが重要です。すなわち、生成時メッセージは、デジタル署名または暗号化される前（ソフト改行を保護する）ソフト改行の添加を含む送信、空間スタッフィング、及び[引用印刷可能]符号化のために準備する必要がありますされます。同様に、受信時にメッセージが署名が検証または[引用印刷可能】復号及び詰めスペース、ソフト改行や引用符、及びリフローを除去する前に解読することが持っているべきです。
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:
フォーマット=流れたとtext / plainの身体の一部に含まれている行は、行の開始と終了を調べることによって分析することができます。行が引用指標で始まる場合、それが引用されています。行が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
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.#
The constructs used in Text/Plain; Format=Flowed body parts are described using [ABNF], including the Core Rules:
text / plainのに使用される構造。フォーマットは=コアルールを含む、本体部分は、[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
パラグラフ= 1 *流入ライン固定回線固定回線=固定/ SIG-9月固定= [引用] [スタッフィング] *テキスト文字以外のSP CRLF流入ライン=流量QT /フローunqt流量QT =引用[スタッフィング] *テキストCHAR 1 * SPのCRLFフローunqt = [スタッフィング] *テキストCHAR 1 * SP CRLF非SP =％x01-09 /％X0B /％x0C /％x0E-1F /％x21- 7F;すべての7ビットUS-ASCII文字、除きます。 NUL、CR、LF、およびSP引用= 1 * ">" SIG-9月= [引用] " - " SP CRLFスタッフィング= [SP]。スペース詰め、生成に追加した場合は、受信テキスト文字=非SP / SP上で削除、必要に応じて
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.
それらを通過するメッセージに末尾の空白を変える現存するシステムがあります。そのようなシステムは、ストリップ、又は稀な場合では、RFC 821 [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つの末尾の空白文字を使用する行を流します。しかし、今日のようなシステムの希少性を考慮すると、それは追加の複雑価値はありません。
This parameter introduces no security considerations beyond those which apply to Text/Plain.
このパラメータには、text / plainにするために適用されるものを超えて何のセキュリティ問題も紹介しません。
Section 4.6 discusses the interaction between Format=Flowed and digital signatures or encryption.
4.6節は、フォーマット=流れ、デジタル署名や暗号化の間の相互作用について説明します。
IANA is requested to add 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 should be taken in applying format=flowed in these cases, as format=fixed combined with quoted-printable encoding may be more suitable.
行の折り返しとFormat =は流れの引用仕様は、そのような右から左に読んでアラビア語とヘブライ文字のように特定の文字セット、に適していないかもしれません。引用された、印刷可能な符号化と組み合わせる形式=固定がより適切であり得るように注意が書式を適用する際に注意しなければならない=、これらの場合に流し。
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.
この提案は、IETF 822メーリングリストで行われたクリス・ニューマンのテキスト/段落案の議論から発展しました。彼らのレビュー、コメント、提案、議論のためのイアン・ベル、スティーブ・ドルナー、ブライアン・ケリー、ダンコーン、ローレンスLundblade、ダンウィングに感謝します。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[ABNF]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 2234、1997年11月。
[KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] S.ブラドナー、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RICH] Resnick, P. and A. Walker, "The text/enriched MIME Content-type", RFC 1896, February 1996.
[RICH]レズニック、P.とA.ウォーカー、 "テキスト/濃縮のMIMEコンテンツタイプ"、RFC 1896、1996年2月。
[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月。
[SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[SMTP]ポステル、J.、 "簡易メール転送プロトコル"、STD 10、RFC 821、1982年8月。
[HTML] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language -- 2.0", RFC 1866, November 1995.
[HTML]バーナーズ=リー、T.、およびD.コノリー、 "ハイパーテキストマークアップ言語 - 2.0"、RFC 1866、1995年11月。
Randall Gellens QUALCOMM Incorporated 5775 Morehouse Dr. San Diego, CA 92121-2779 USA
ランドールGellens QUALCOMM Incorporatedの5775モアハウス博士サンディエゴ、CA 92121から2779 USA
Phone: +1 619 651 5115 EMail: randy@qualcomm.com
電話：+1 619 651 5115 Eメール：randy@qualcomm.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。