[要約] RFC 3676は、テキスト/プレーン形式とDelSpパラメータに関する仕様を定めたものであり、メールのテキスト形式の改善と削除スペースの処理に関する目的を持っています。
Network Working Group R. Gellens
Request for Comments: 3676 Qualcomm
Obsoletes: 2646 February 2004
Category: Standards Track
The Text/Plain Format and DelSp Parameters
テキスト/プレーン形式とDELSPパラメーター
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）The Internet Society（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.
この仕様は、テキスト/プレーンメディアタイプで使用する2つのパラメーター（フォーマットとDELSP）を確立します。これらのパラメーターの存在下では、トレーリングホワイトスペースを使用して流れた線を示すために使用され、引用符のある線を示すために標準的な引用インジケーターが使用されます。これにより、実際には通常のテキスト/プレーンであるが、優れたラッピング/フローを提供し、引用を提供するため、古い実装では通常のテキスト/プレーンとして表示されるエンコードが発生します。
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で指定されたもの、「テキスト/プレーン形式パラメーター」に取って代わり、DELSPパラメーターを追加して、ASCIIスペースが使用されない、またはめったに表示されない言語/コード化された文字セットに対応します。
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.
必要なのは、すべての重要な方法でテキスト/プレーンであるため、テキスト/プレーンとして表示するのに非常に適した形式です。、したがって、必要に応じて、流れる（包まれて結合）する資格があります。
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].
このドキュメントの「必須」、「必須」、「必要はない」、「そうでなければ」、「そうでない」、「必要はない」、「必要はない」というキーワードは、「RFCSで使用するためのキーワードで要件レベルを示すように解釈されるべきです。「[キーワード]。
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]).
テキスト/プレーンメディアタイプは、インターネット電子メールの最低の一般的な分母であり、998文字以下（通常は78以下）で、キャリッジリターンとラインフィード（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.
テキスト/プレーンは、通常、事前にフォーマットされたテキストとして表示され、多くの場合固定フォントに表示されます。つまり、文字はディスプレイウィンドウの左マージンから始まり、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.
多数のソフトウェア製品は、この形式をテキスト/プレーンに誤ってラベル付けし、多くのユーザーの不快感をもたらします。
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.
テキスト/プレーンメッセージが返信または転送されたメッセージで引用されているため、各ラインの長さが徐々に増加し、最終的には任意に硬く包まれ、「恥ずかしいラインラップ」になります。これにより、せいぜい読みにくいテキストが生成され、しばしば帰属を混乱させます。
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.
これは、いくつかの行に流れることを意図した段落テキストです。ただし、送信メーラーは72文字の幅で固定テキストに変換しているため、PDAに30文字のラインのみが表示されると、このように見えます。
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.
特に、テキスト/濃縮されたものでは、オープンな角度ブラケット（ "<"）とハードラインブレークを2倍にし、テキスト/プレーンと見なされるとユーザーの不幸が不幸になることが必要です。テキスト/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.
望ましいのは、すべての重要な方法でテキスト/プレーンであるため、テキスト/プレーンとして表示するのに非常に適した形式です。必要に応じて（包まれて結合）。
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].
フォーマットが指定されていない場合、または値が認識されていない場合、固定の値が想定されます。固定値のセマンティクスは、テキスト/プレーン[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.
Flowedのフォーマット値は、フローテキストの定義（このメモで指定されている）が生成時に使用され、受信で使用される可能性があることを示しています。
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.
フォーマットはテキスト/プレーンコンテンツタイプのパラメーターであるため、使用されるコンテンツ移動エンコードは、流れたテキストの処理とは無関係であることに注意してください。
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が指定されていない場合、またはその値が認識されていない場合、NOの値が想定されます。Flowedのフォーマット値なしでDELSPの使用は未定義です。メッセージを作成する場合、delSPは、形式= flowedを備えたテキスト/プレーン以外のテキストコンテンツタイプで指定するべきではありません。メッセージを受信する場合、format = flowedのテキスト/プレーン以外のテキストコンテンツタイプで使用する場合は、DELSPを無視する必要があります。
This section discusses flowed text; section 6 provides a formal definition.
このセクションでは、Flowed Textについて説明します。セクション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が「はい」の場合、ラインの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つ以上の固定線が続く一連の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テキストの場合、[Annex-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.)
Format = Flowed Textを生成する場合、行は78文字または短縮されている必要があります。たとえば、詰め物の一部として追加されたスペースを含めます（セクション4.4を参照）。提案された値のように、72文字以下のラインを使用して、合計長さの78文字より長い段落を包むことができます。使用される特定のラインの長さは美学と好みの問題ですが、長い行は書き直しを必要とし、古いメーラーでの困難に遭遇する可能性が高くなります。（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]への適合に加えて、すべての行は、flow延していないプログラムによって表示された場合でも、ラップする必要なく標準の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.
Flowed Textを作成するとき、生成エージェントラップ、つまり、必要に応じて「ソフト」ラインが壊れます。ソフトラインブレークは、単語間などの自然なラッピングポイントで追加されます。ソフトラインブレークは、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パラメーターを使用する必要があり、「はい」に設定する必要があります。スペース詰まりのため（セクション4.4を参照）、この手法が使用され、SPが既に存在するポイント（単語の間など）にソフトラインブレークが挿入されることに注意してください。SP、既存のSPがリードするため、詰め物が必要です。既存のSPに続いてSP CRLFシーケンスを挿入することにより、エージェントがこれを回避することをお勧めします。
Generating agents MAY use either method within each Text/Plain body part.
生成エージェントは、各テキスト/プレーンボディパーツ内のいずれかの方法を使用できます。
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 「From」、または「>」で始まるスペース積みの線。
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.
スペース詰まりを必要としないため、形式=固定と見なされるとより審美的に心地よいメッセージを作成するために、生成エージェントは「>」、「from」、またはスペースの直前にラッピングを避けることができます。
(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 = Flowedメッセージは、ゼロ以上の段落で構成され、それぞれに1つ以上の流れの行が含まれ、その後に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).
[引用プリント可能]エンコードは、絶対に必要でない限り（例えば、Unextended [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.
FORMAT = Flowedの意図は、ユーザーエージェントが純粋で生のテキスト/プレーン（デコードなし）と見なされると非毒性のある流れのテキストを生成できるようにすることです。引用された印刷可能な使用はこれを妨げ、フォーマット=エンドユーザーによって拒否される可能性があります。
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 Newsには、本文とメッセージの署名の間のセパレーターラインとして「 - 」を使用するインターネットメールにも一般的に表示される長年のコンベンションがあります。署名の前にusenetスタイルのセパレーターを含むformat = flowedメッセージを生成する場合、セパレーターラインはそのまま送信されます。これは特別なケースです。Dash 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.
「>」で始まる引用されていない線を許可し、「マンジーから」輸送中のメッセージを保護するために（「 "から"から "> from"で始まる行を変更する）、format = flowedは提供しますスペースストーフィング用。
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.
世代では、「>」で始まる引用されていない線、およびスペースまたは「from」から始まる線は空間を詰めなければなりません。他の線は、必要に応じてスペースが詰まっている場合があります。
(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.
FORMAT = Flowedでは、Canonical Quote Indicator（またはQuote Mark）は、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.
言い換えれば、2つの隣接する線が異なる引用符の深さを持っているときはいつでも、送信者は以前の線が流れないことを確認する必要があり（スペースで終わりません）、流れのある線を見つけるレシーバーはそれを段落の最後のラインとして扱う必要があります。
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?#
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番目の行は、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.
上記の例のテキストは、引用された深みの勝利に従って処理された場合、最初の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.
メッセージがデジタル署名または暗号化されている場合、暗号化処理が署名の生成および/または暗号化に使用されたのと同じテキストを署名検証および/または復号化に使用することが重要です。フォーマット= Flowedの使用により、テキストを（ラインブレークとトレーリングスペースを追加または削除することにより）組成と送信の間に変更できるため、受信と表示の間に、相互運用性の問題またはセキュリティの脆弱性が発生する可能性があります。暗号化処理用のオンザワイヤ形式。
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.
形式= flowedと特定の暗号化プロセス間の相互作用の意味は、暗号化処理の詳細に依存し、署名されたメッセージおよび/または暗号化されたメッセージと組み合わせてFlowed = Flowedを使用する前に理解する必要があります。
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." 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.
[OpenPGP]は（セクション7.1で）「任意の行の終わりにある任意の後続の空白（スペース、およびタブ、0x09）を指定していることに注意してください。したがって、トランジットでは、形式= Flowed Headerを通常のフォーマットに追加することができます。これにより、フォーマット= Flowedをサポートするクライアントによる記事のレンダリングが変更されます。
Therefore, the use of [OpenPGP] with format=flowed messages is strongly discouraged. [OpenPGP-MIME] is recommended instead.
したがって、形式= Flowedメッセージを使用して[OpenPGP]を使用することは強く落胆しています。[OpenPGP-Mime]代わりに推奨されます。
The following example contains three paragraphs:
次の例には、3つの段落が含まれています。
`Take some more tea,' the March Hare said to Alice, very earnestly.
「もう少しお茶を飲んでください」と3月のヘアは、非常に真剣にアリスに言った。
`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.'
「あなたはそれを減らすことができないということです」とハッターは言った：「何もない以上に服用するのは非常に簡単だ」
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.'#
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.#
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.
流れのある線は固定線とはまったく測定できないため、形式を認識しないソフトウェア=流れた扱いに流れたラインが通常のテキスト/プレーン（これが何であるか）として流れました。したがって、FORMAT = Flowedは古いクライアントと相互運用しますが、流れた線には、後続の空白が挿入されます。
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.
フォーマット= flowedを処理するエージェントによってスペースが詰め込まれたメッセージが受信されると、スペース詰まりが逆になるため、メッセージは変更されていません。フォーマット= Flowedを認識していないエージェントは、もちろんスペースの詰まりを取り消すことはありません。したがって、Format = Flowedメッセージは、いくつかの行の先頭のスペース（スペースから始まるもの、「>」が引用インジケーターではない、または「from」）で表示される場合があります。スペース詰まりを必要とするラインはめったに発生しないため、反転していない空間詰まりの美的結果は最小限であるため、これは重大な問題になるとは予想されていません。
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つ以上のスペースから始まる場合、生成エージェントはすべてのラインを空間積み上げることができ、フォーマット= Flowedを認識していないクライアントが表示すると、線の相対的なインデントを維持できます。
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で生成され、フォーマット= flowedを認識しているクライアントが受信したメッセージは、delspパラメーターには、ソフトラインブレークを削除した後に余分なスペースが残っています。したがって、スペースが一般的な言語/コード化された文字セットでテキストを生成する場合、生成エージェントは常にDELSP = NOメソッドを使用できます。
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.
テキスト/プレーンで使用されるコンストラクト。Format = Flowed Body Partsは、付録Aで定義されているコアルールを含む、拡張されたバックスノーフォーム[ABNF]を使用して説明されています。
Note that the SP (space) and ">" characters are encoded according to the charset parameter.
SP（スペース）および「>」文字は、CharSetパラメーターに従ってエンコードされることに注意してください。
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 ) /
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
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.)
つまり、Format = Flowedメッセージ本文は、任意の数の段落および/または固定行および/または署名分離線で構成されています。段落には、少なくとも1つの流れのある線が必要で、固定線によって終了します。段落を終了する固定行は、段落の一部です。（テキストで説明されているこれにはいくつかの例外があります。）
Without at least one flowed line, there is a series of fixed lines, each independent. There is no paragraph.
少なくとも1つの流れのある線がなければ、それぞれに独立した一連の固定線があります。段落はありません。
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.
少なくとも1つの流れのラインがある場合、段落があり、受信したラインを改革し、ディスプレイウィンドウサイズに合わせて流れることができます。これは、行が論理グループの一部である段落の一部である場合にのみ行うことができます。
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.
Flowed-lineとSig-Sepの定義は潜在的に曖昧であることに注意してください。特徴分離機のラインは両方と一致しますが、流れのあるラインではなく、署名分離線として扱われます。
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.
ストリップトレーリングホワイトスペースは、流れた線を固定線に変換する効果があり、その結果、フォーマット= Flowedが使用されていない場合よりもメッセージが悪くなります。
Adding trailing whitespace to a Format=Flowed message may result in a malformed display or reply.
Trailing Whitespaceをフォーマット= Flowedメッセージに追加すると、不正な表示または返信が行われる場合があります。
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つは、1つまたは2つのトレーリングスペース文字を使用して、総線の長さが奇数になるように、1つまたは2つのトレーリングスペース文字を使用するように定義することです。ただし、今日のこのようなシステムの希少性を考慮すると、複雑さを増す価値はありません。
Any security considerations which apply to Text/Plain also apply to Text/Plain with Format=Flowed.
テキスト/プレーンに適用されるセキュリティ上の考慮事項は、形式= flowedでテキスト/プレーンにも適用されます。
Section 4.6 discusses the interaction between Format=Flowed and digital signatures or encryption.
セクション4.6では、Format = FlowedとDigital Signaturesまたは暗号化の間の相互作用について説明します。
IANA has added a reference to this specification in the Text/Plain Media Type registration.
IANAは、テキスト/プレーンメディアタイプの登録にこの仕様への参照を追加しました。
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.
ラインラップと引用形式の仕様= flowedは、右から左に読まれるアラビア語やヘブライ語のキャラクターなど、特定の充電器には適していない場合があります。[引用プリント可能]エンコードと組み合わされた形式=固定がより適切になるため、これらの場合にFlowed format = Flowedの適用に注意する必要があります。
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スペース文字がめったに使用されない、またはまったく使用されない言語/コード化された文字セットで使用されるようにFlowed = Flued = Flued = Flowedを許可するために特別に追加されました。
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パラメーターは、ハラルド・アルベスランド、グラント・バイリー、イアン・ベル、スティーブ・ドーナー、パトリック・ファートストローム、エリック・フィッシャー、ネッド・フリード、アレクセイ・メルニコフ、ジョン・マイヤーズ、ピート・レストニックなど、多くの人々の間の一連の議論の中で開発されました。
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およびこの文書の初期バージョンの修正と説明は、アダム・コステロ、ジュッタ・デジェナー、トニー・ハンセン、サイモン・ジョセフソン、ダン・コーン、ラゴ・マハリンガム、キース・ムーア、グレッグ・トルセル、ダン・ウィングなど、数人の人々によって指摘されました。
I'm told that NeXT's mail application used a very similar mechanism (without support for non-Western languages) in 1992.
Nextのメールアプリケーションは、1992年に非常に類似したメカニズム（非西言語のサポートなし）を使用したと言われています。
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[ABNF] Crocker、D.、ed。および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.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Freed、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.
[引用プリント可能] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[Annex-14] Unicode Standard Annex #14, "Line Breaking
Properties"
<URL:http://www.unicode.org/unicode/reports/tr14/>
[MSG-FMT] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001.
[MSG-FMT] Resnick、P.、ed。、「インターネットメッセージ形式」、RFC 2822、2001年4月。
[OpenPGP] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.
[OpenPGP] Callas、J.、Donnerhacke、L.、Finney、H。およびR. Thayer、「OpenPGPメッセージ形式」、RFC 2440、1998年11月。
[OpenPGP-MIME] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC 2015, October 1996.
[OpenPGP-Mime] Elkins、M。、「Pretty Good Privacy（PGP）のMIMEセキュリティ」、RFC 2015、1996年10月。
Elkins, M., Del Torto, D., Levien, R. and J. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001.
Elkins、M.、Del Torto、D.、Levien、R.およびJ. Roessler、「Mime Security with OpenPGP」、RFC 3156、2001年8月。
[Rich] Resnick, P. and A. Walker, "The text/enriched MIME Content-type", RFC 1896, February 1996.
[Rich] Resnick、P。およびA. Walker、「The Text/Rediched Mime Content-Type」、RFC 1896、1996年2月。
[SMTP] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[SMTP] Klensin、J.、ed。、「Simple Mail Transfer Protocol」、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 RFC 2822に準拠して79または80の制限を78に変更しました。O生成に関するテキストを追加して、78文字の制限にはトレーリングホワイトスペースと詰め物が含まれていることを明確にしました。o詰め物を許可するために、ABNFのSIG-SEPを変更しました。o abnfの空の線を許可するために固定線を変更しました。o ABNFに続いて説明テキストを追加しました。oテキストを要約から新しい紹介に移動しました。要約を書き直します。o相互運用性テキストを新しいセクションに移動し、更新しました。oセキュリティ上の考慮事項を明確にしました。oデジタル署名に関するテキストでは、OpenPGPが後続の空白を無視することを説明します。o unicode付録14に言及します。o削除されたライン分析テーブル。o openPGPとopenPGP-Mimeの推奨事項を追加しました。o ABNFルールを書き直して、ほとんどのあいまいさを削除し、残りのケースに注意してください。o C-T-Eは、流れたテキスト処理とは無関係であることにメモを追加しました。oデータの終わりが段落を終了することを示すテキストを追加しました。o固定線ABNFからsig-sepを移動しました。oいくつかの支持者を必須に変更しました（スペースが詰まっている、引用された段落）。o ABNFにメモを追加し、「>」がCharsetに従ってエンコードされていることを追加しました。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 2821への[SMTP]参照を更新しました。O通知を追加しました。o参照を規範的で有益なものに分割します。o一部の領域でテキスト文言を改善しました。o「引用深度」ではなく、「引用深度」を標準化します。o生成に関するセクションの前に解釈することについてセクションを移動しました。o非正規の「必要のある」と語った。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スペース文字がめったに使用されない、またはまったく使用されない言語/コード化された文字セットで使用されるようにFlowed = Flued = Flued = Flowedを許可するために特別に追加されました。DELSPメカニズムは、当初、あまりにも多くのクラッジとして拒否されたにもかかわらず選択されました。これは、提案されている多くの異なる手法の中で、この仕様もRFC 2646もサポートしていないクライアント間で最大限の相互運用性を可能にするため、RFC 2646をサポートするが、これではないからです。仕様、およびこの仕様をサポートするもの。このセットには、スペースが一般的である言語/コード化された文字セットを処理するものと、それらが珍しいか使用されていないものが掛けられます。
Author's Address
著者の連絡先
Randall Gellens QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121 USA
ランドール・ゲレンズ・クアルコム・インコーポレーテッド5775モアハウス・ドライブサンディエゴ、カリフォルニア州92121 USA
Phone: +1 858 651 5115
EMail: 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）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。