RFC 2646

RFC 2646

text/plain

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.

Table of Contents

  1. 1. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 2
  2. 2. Conventions Used in this Document . . . . . . . . . . . . . 2
  3. 3. The Problem . . . . . . . . . . . . . . . . . . . . . . . . 2
    1. 3.1. Paragraph Text . . . . . . . . . . . . . . . . . . . . 3
    2. 3.2. Embarrassing Line Wrap . . . . . . . . . . . . . . . . . 3
    3. 3.3. New Media Types . . . . . . . . . . . . . . . . . . . . 4
  4. 4. The Format Parameter to the Text/Plain Media Type . . . . . 4
    1. 4.1. Generating Format=Flowed . . . . . . . . . . . . . . . 5
    2. 4.2. Interpreting Format=Flowed . . . . . . . . . . . . . . . 6
    3. 4.3. Usenet Signature Convention . . . . . . . . . . . . . . 7
    4. 4.4. Space-Stuffing . . . . . . . . . . . . . . . . . . . . . 7
    5. 4.5. Quoting . . . . . . . . . . . . . . . . . . . . . . . . 8
    6. 4.6. Digital Signatures and Encryption . . . . . . . . . . . 9
    7. 4.7. Line Analysis Table . . . . . . . . . . . . . . . . . . 10
    8. 4.8. Examples . . . . . . . . . . . . . . . . . . . . . . . . 10
  5. 5. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
  6. 6. Failure Modes . . . . . . . . . . . . . . . . . . . . . . . 11
    1. 6.1. Trailing White Space Corruption . . . . . . . . . . . . 11
  7. 7. Security Considerations . . . . . . . . . . . . . . . . . . 12
  8. 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12
  9. 9. Internationalization Considerations . . . . . . . . . . . . 12
  10. 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 12
  11. 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
  12. 12. Editor's Address . . . . . . . . . . . . . . . . . . . . . 13
  13. 13. Full Copyright Statement . . . . . . . . . . . . . . . . . . 14
  1. 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
  2. 2. Conventions Used in this Document . . . . . . . . . . . . . . 2
  3. 3. The Problem . . . . . . . . . . . . . . . . . . . . . . . . . 3
    1. 3.1. Paragraph Text. . . . . . . . . . . . . . . . . . . . . 3
    2. 3.2. Embarrassing Line Wrap . . . . . . . . . . . . . . . . 3
    3. 3.3. New Media Types . . . . . . . . . . . . . . . . . . . . 4
  4. 4. The Format and DelSp Parameters . . . . . . . . . . . . . . . 5
    1. 4.1. Interpreting Format=Flowed. . . . . . . . . . . . . . . 6
    2. 4.2. Generating Format=Flowed . . . . . . . . . . . . . . . 7
    3. 4.3. Usenet Signature Convention . . . . . . . . . . . . . . 9
    4. 4.5. Quoting . . . . . . . . . . . . . . . . . . . . . . . . 9
    5. 4.6. Digital Signatures and Encryption . . . . . . . . . . . 11
    6. 4.7. Examples. . . . . . . . . . . . . . . . . . . . . . . . 12
  5. 5. Interoperability. . . . . . . . . . . . . . . . . . . . . . . 12
  6. 6. ABNF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
  7. 7. Failure Modes . . . . . . . . . . . . . . . . . . . . . . . . 14
    1. 7.1. Trailing White Space Corruption . . . . . . . . . . . . 14
  8. 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
  9. 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
  10. 10. Internationalization Considerations . . . . . . . . . . . . . 15
  11. 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
  12. 12. Normative References. . . . . . . . . . . . . . . . . . . . . 16
  13. 13. Informative References. . . . . . . . . . . . . . . . . . . . 16
  14. Appendix A: Changes from RFC 2646 . . . . . . . . . . . . . . . . 18
  15. Author's Address. . . . . . . . . . . . . . . . . . . . . . . . . 19
  16. Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 20

1. Abstract Introduction

Interoperability problems have been observed with erroneous labelling of paragraph text as Text/Plain, and with various forms of "embarrassing line wrap." (See section Section 3.)

段落文を text/plain と誤って札付けすることや、 色々な形の困った行折返しによる相互運用性の問題が見られています。

Attempts to deploy new media types, such as Text/Enriched [RICH] [Rich] and Text/HTML [HTML] have suffered from a lack of backwards compatibility and an often hostile user reaction at the receiving end.

text/enrichedtext/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 can be are considered a logical paragraph, and thus eligible to be 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.

このメモは text/plain で使用する新しい引数と、 この引数が存在する場合の、流し行を示す行末の空白の使用を提案します。 これによって古目の実装には通常の text/plain のように見える符号化となります。というか実際通常の text/plain なのです。

2. Conventions Used in this Document

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].

この文書中の鍵語必要である, しなければならない, してはならない, するべきである, するべきではない, して構わないは、 『RFC 中で要求水準を示すために使用する鍵語』に記述されているように解釈することとします。

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.

用語段落は、ここでは、論理的に表示目的の単位として扱い、 表示窓に合うように、あるいは返答・転送その他の文章作成の時に適当に流したり (折畳んだり連結したり) しても適切である行の系列を意味するために使います。

3. The Problem

The Text/Plain media type is the lowest common denominator of Internet email, with lines of no more than 997 998 characters (by convention usually no more than 80 78), and where the CRLF carriage-return and line-feed (CRLF) sequence represents a line break (see [MIME-IMT] and [MSG-FMT]).

Text/Plain 媒体型はインターネット電子メイルの最小公分母で、 998文字未満 (実際には通常78文字未満) の行で構成され、 復帰改行 (CRLF) の列が改行を表します。

訳注: などと書かれていますが、あまり正しくなく、 行長制限は Content-Transfer-Encoding と使用するプロトコルに依存しますし、 CRLF正準形における改行の表現です。

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 列が見つかるまで右に進み、 CRLF 列のところで新しい行が再び左余白から始まります。 行長が表示窓を超えた時は、行を折畳むクライアントもあれば、 水平 scroll 棒を出すクライアントもあります。

Text which meets this description is defined by this memo as "fixed".

この説明に合致する文章はこのメモでは固定 (fixed) と定義します。

Some interoperability problems have been observed with this media type format:

この媒体型書式には幾つかの相互運用についての問題が見つかっています。

3.1. Paragraph Text

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 を使用します。 改行は「やわらかく (soft) 」、表示で必要な時に行われます。 すなわち、文字は CRLF 列が見つかるまでが一つの段落に集団化され、 CRLF 列のところで新しい段落が始まります。 各段落は左余白から (または段落字下げで) 表示され、 残る表示幅に当てはまらない語が現れるまで右に続けます。 当てはまらなくなった語は次の行の左余白に表示します。 これは段落が終了するまで (CRLF が見つかるまで) 続きます。余分な垂直間隔を段落間に置きます。

Text which meets this description is defined by this memo as "flowed".

この説明に合致する定義はこのメモでは流しと定義します。

Numerous software products erroneously label this media type format as Text/Plain, resulting in much user discomfort.

数々のソフトウェア製品が誤ってこの媒体型書式Text/Plain と札付けしていまして、 利用者は甚だ不快に思うこととなっています。

3.2. Embarrassing Line Wrap

As Text/Plain messages get are quoted in replies or forwarded messages, the length of each line gradually increases, each line gradually increases in length, eventually being arbitrarily hard wrapped, resulting in "embarrassing line wrap." This results in 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.

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 文字固定としてしまったた
めに、
1 行で 30 文字しか表示できない
 PDA で見るとこのようになって
しまいます。

3.3. New Media Types

Attempts to deploy new media types, such as Text/Enriched [RICH] [Rich] and Text/HTML [HTML] have suffered from a lack of backwards compatibility and an often hostile user reaction at the receiving end.

新しい媒体型、例えば text/enrichedtext/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/enriched は開き角括弧 (<) と硬い改行を重ねる必要がありますから、利用者が text/plain として見た時に嬉しくありません。 text/html はそれ以上に文章の置換えが必要となりますから、 利用者の不満もそれに対応して増加します。

A proposal to define a new media type to explicitly represent the paragraph form suffered from a lack of interoperability with currently deployed software. Some programs treat unknown subtypes of Text TEXT as an attachment.

段落形式を明確に表現する新しい媒体型を定義しようと提案しても、 現在既に使用されているソフトウェアとの相互運用性の欠如の問題に悩まされます。 未知の text の亜型を添付として扱うプログラムもあります。

訳注: もっとも、そのようなプログラムは MIME 違反です。

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 として表示するのが極めて適当であり、 されども送信者が受信者にどの行を論理的な段落と考えることができるかを表現でき、 よって適当に流し (行送りや連結) を行うことのできる書式です。

4. The Format and DelSp Parameters to the Text/Plain Media Type

This document specification defines a new two MIME parameters for use with Text/Plain:

この仕様書は、 text/plain で使用する2つの MIME 引数を定義します。

Name
Format
Value
Fixed, Flowed
Name
DelSp
Value
Yes, No

(Neither the parameter names nor its 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].

Format が指定されていないか、 値が認識できないときには、 fixed という値であるとみなします。 fixed という値は、 通常の text/plain を表すこととします。

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.

Format の値が 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.

Formattext/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 が指定されていないか、値が認識できない時には、 no の値であるとみなします。 Format の値を flowed にせずに delsp を使用することは、未定義とします。メッセージを作成する時には、 formatflowed である text/plain 以外で text 内容型に delsp を指定するべきではありません。メッセージを受信する時には、 formatflowed である text/plain 以外の text 内容型で delsp が使われていても、無視するべきです

This section discusses flowed text; section 5 6 provides a formal definition.

この章は流し文について議論します。正式な定義は6章にあります。

Because flowed lines are all-but-indistinguishable from fixed lines, currently deployed software treats flowed lines as normal Text/Plain (which is what they are). Thus, no interoperability problems are expected.

流し行は固定行とほとんど区別できませんから、 現在使用されているソフトウェアは流し行を通常の text/plain として扱います (というかそうなのです)。ですから、 相互運用性の問題はないと思われます。

Section 5 discusses interoperability.

相互運用性については5章で議論します。

Note that this memo describes an on-the-wire format. It does not address formats for local file storage.

このメモは通信用の書式について説明していることに注意してください。 局所ファイル蓄積用の書式については言及していません。

4.2. 4.1. Interpreting Format=Flowed

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).

ある行の最初の文字が引用符 (>) であれば、 その行は引用されていると考えます。論理的には、 すべての引用符を数えて削除すれば、行は引用の深さ (非零) と内容になります。 (利用者エージェントはもちろん内容を引用符や引用棒や他の何で表示しても自由です。) 論理的には、この引用行の検査は他の検査の前に (つまり間隔詰込みや流しの検査の前に) 行います。

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).

行の最初の文字が間隔であれば、その行は間隔詰込みされています。 論理的には、この最初の間隔は行を更に検査する前に (つまり、流しの検査の前に) 削除します。

If the line ends in one or more a 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. 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章で説明しています。行末の間隔は行の内容の一部ですが、軟改行の CRLF はそうではありません。署名分離子行は間隔で終わりますが、 流しでも固定でもありません。

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.

行が流しで、 delspyes なら、 その行の CRLF のすぐ前の間隔は論理的に削除します。 delspno (か指定されていないか認識できない値に設定されている) なら、 行末の間隔は削除しません。

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 Section 4.5).

1つ以上の流し行に1つの固定行が続く系列は、 段落とみなし、表示の際や新しいメッセージの構築の際に適切に流して (行送りや行送り復元を行って) 構いません

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つ例外を認めるべきです。3つの例外は不適切に構築されたメッセージです。 流し行は、異なる引用の深さの行が続く場合や署名分離子行が続く場合には段落の終わりと考えるべきです。 本体の終わりも段落の終わりとするべきです

A line consisting of one or more spaces (after deleting a stuffed 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 文では、 UAX #14 が行を送る文字を選ぶ際の指針を提供していることに注意してください。

4.1. 4.2. Generating Format=Flowed

When generating Format=Flowed text, lines SHOULD be shorter than 80 characters 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 79 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 の文章を生成する時には、 行は末尾の空白や詰込みの一部として追加した間隔も含めて、 78文字以下にするべきです。 全部の長さが78文字より長い段落は、一行を72文字以下にして折返すことを提案します。 行の長さは美学と好みの問題ですが、 長い行は古いメイル器で再折返しする必要があってやっかいなことになりやすそうです。 (一行を66文字にするのがもっとも読みやすいのではないかといわれています。)

The restriction to 78 or fewer characters between CRLFs on the wire is to conform to [MSG-FMT].

通信時に CRLF の間を78文字以下に制限するのは RFC 2822 に適合します。

(The reason for the restriction to 79 or fewer characters between CRLFs on the wire is to ensure 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 79 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.)

RFC 2822 への適合に加えて、歴史的にすべての行が (流しを知らないプログラムで表示する時であっても) 標準の79〜80列の画面で折返さずに幅に合うようにする必要がありました。 一行は79〜80ですが、最後の列は行折返しの印として予約されていることがよくありますから、 制限は78になります。

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. Because a 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 の列です。

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 引数を使うべきですdelsp を使用するときには no と設定しなければなりません

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 引数を使わなければなりません。 その値は yes に設定しなければなりません。 注意していただきたいのは、間隔の詰込みがありますから、 この方法を使う時で SP が既に存在するところ (語間など) に軟改行を挿入する時には、 SP CRLF 列を SP の直前に追加すると元々存在していた SP が行頭に来て、詰込みが必要になります。エージェントは SP CRLF 列を既存の SP の後に挿入してこれを避けることを推奨します。

Generating agents MAY use either method within each Text/Plain body part.

生成エージェントは text/plain 本体部分それぞれの中でどちらの方法を使っても構いません

Regardless of which technique is used, a A generating agent SHOULD NOT insert a white 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 79 78 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 78-character limit on line length.

どちらの方法を使うにせよ、生成エージェントは語 (間隔を普通に使う言語・符号化文字集合で、印字可能文字の列であり、 間隔を含まないもの) の中のような不自然な場所に空白を挿入するべきではありません。 78文字の制限を超える (ものの SMTP の998文字の行長制限よりは短い) 語が現れた時は、エージェントはその語をそのまま78文字行長制限を超して送るべきです

A generating agent SHOULD:

  • 1. o Ensure all lines (fixed and flowed) are 79 78 characters or fewer in length, counting the trailing space as well as a space added as stuffing, but not counting the CRLF, unless a word by itself exceeds 79 78 characters.
  • 2. o Trim spaces before user-inserted hard line breaks.

生成エージェントは、

  • すべての行 (固定、流し) を末尾の間隔や詰込みの間隔も含めて (CRLF は除いて) 78文字以下の長さに収めるべきです。 ただし、78文字を超える語の場合は除きます。
  • 利用者が挿入した硬改行の前の間隔を取除くべきです

A generating agent MUST:

生成エージェントは、

  • 3. o Space-stuff lines which start with a space, "From ", or ">".
  • 間隔, 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.

間隔の詰込みが必要ないメッセージを作成するため、 そして format=fixed として見た時により美しくなるように、 生成エージェントは >, From , 間隔の直前で折返すことを避けても構いません

(See sections 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つの固定行が続きます。 普通は流し行の間には空の固定行を入れます。

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).

生成エージェントは、段落に軟改行をおくときは、 段落の任意のぎゅが署名分離子行となるように置いてはなりません。 段落は署名分離子行を含むことができません。

[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 [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).

Quoted-Printable (引用印字可能) 符号化は、 絶対に必要でない限り (例えば非 US-ASCII (8ビット) 文字を未拡張の SMTP のように厳密に7ビットな輸送路で使う場合) を除き、使用するべきではありません。 特に、本体部分を署名または暗号化する場合以外は、 メッセージを単に流し行の末尾の間隔を保護する目的で引用印字可能で符号化するべきではありません

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 はそのまま生の text/plain として (復号せずに) 見た時に不愉快にならない流し文を利用者エージェントが生成できるようにすることを目指しています。 引用印字可能を使うとこれを果たせず、 format=flowed が末端利用者から排除されてしまうことになるかもしれません。

4.3. Usenet Signature Convention

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 not considered neither fixed nor flowed.

Usenet ニュースには、メッセージの本文と署名の間に -- を区切りの行として使うという長きにわたる慣習があり、 インターネット・メイルでもよく使われています。署名の前に Usenet 式分離子を含む format=flowed メッセージを生成する時には、 分離子行はそのままで送ります。これは特例です。 横線・横線・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.

受信エージェントは、署名行の確認を引用行の確認の前と引用行から引用符と詰込みを論理的に数えて削除した後の2度行う必要があります。

4.4. Space-Stuffing

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 いじりする (From で始まる行を >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.

間隔詰込みは、メッセージを生成する時に保護が必要な行の最初に間隔を1つ追加します。 受信時には、行の最初の文字が間隔なら、これを論理的に削除します。 これは引用行の検査 (引用行を論理的に数えて削除) の後で、流し行の検査に行います。

On generation, any unquoted lines which start with ">", and any lines which start with a space or "From " SHOULD 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 の点詰込みと似ています。

If a space-stuffed message is received by an agent which handles Format=Flowed, the space-stuffing is reversed and thus the message appears unchanged. An agent which is not aware of Format=Flowed will of course not undo any space-stuffing, thus Format=Flowed messages may appear with a leading space on some lines (those which start with a space, ">" which is not a quote indicator, or "From "). Since lines which require space-stuffing rarely occur, and the aesthetic consequences of unreversed space-stuffing are minimal, this is not expected to be a significant problem.

間隔詰込みしたメッセージを format=flowed を扱うエージェントが受信したら、 間隔詰込みは元に戻され、メッセージは元のようになります。 format=flowed を知らないエージェントはもちろん間隔詰込みを戻さないので、 format=flowed メッセージは一部の行 (間隔、引用を表さない >, From で始まる行) は頭に間隔がついて見えます。 間隔詰込みが必要な行はめったに現れませんし、見た目的にも最小限しか違いませんから、 大きな問題とはならないと思われます。

4.5. Quoting

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 では、正準引用指示子 (引用符) は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例は意味的に同一です。 双方共に引用の深さが2で、内容が Exit, Stage Left です。

However, the line

> > Exit, Stage Left
is different. It has a quote-depth of one, and a content of "> Exit, Stage Left".

しかし、こちらの例は違います。こちらは引用の深さが1で、 内容が > Exit, Stage Left です。

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. 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. 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 are prefixed to each line.

受信したエージェントが流し引用行を表示時や新しいメッセージの生成時に再整形 (行をつなげたり分割したり) したい時は、各行の引用をやめ、 再整形し、再び引用するべきです。引用をやめる時には、 行頭の引用指示子の閉じ角括弧の数を数えます。同じ引用の深さの連続する行は一つの段落と考え、一緒に再整形します。 再整形の後再び引用する時には、もとあったのと同じ数の閉じ角括弧を各行の最初に追加します。

On reception, if a change in quoting 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 ignore the flowed indicator and treat the line as fixed consider the paragraph to end with the flowed line immediately preceding the change in quote depth. That is, the change in quote depth ends the paragraph.

受信の際で、流し行で引用の深さが変更されていたら、 それは不適切に書式付けされたメッセージです。受信者はこの誤りを 引用の深さの勝ち則 (段落が引用の深さの直前の流し行で終わっていると考える。) を使って取扱うべきです

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 should 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つの引用流し節で引用の深さは1と考えます。 3行目と4行目は引用流し節で、引用の深さは2となります。

A generating agent SHOULD MUST NOT create this situation; a receiving agent SHOULD handle it using quote-depth wins by giving preference to the quote depth.

生成エージェントは、この状況をつくってはなりません。 受信エージェントは、引用の深さを優先させてこの状況を扱うべきです

4.6. Digital Signatures and Encryption

If a message is digitally signed or encrypted it is important that cryptographic processing use the on-the-wire Format=Flowed format same text for signature verification and/or decryption as was used for signature generation and/or encryption. 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. 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.

メッセージがデジタル的に署名または暗号化される場合は、 暗号処理がネットワーク転送する format=flowed 書式署名生成及び/又は暗号化の時と署名検証及び/又は解読の際に同じ文章を使うことが重要です。つまり、生成中には軟改行、間隔詰め、 (軟改行の保護のための) 引用印字可能符号化を含めた転送用のメッセージをデジタル署名・暗号化の前に用意するべきです。同様に、受信時には引用印字可能復号、間隔詰め、軟改行、引用符の削除、再流込みを行う前に署名検証・復号するべきです format=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.

format=flowed と特定の暗号処理の相互作用はその暗号処理の詳細に依存しますから、 format=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."

OpenPGP] は清文署名を計算する時には行末の空白 (間隔、タブ、 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.

ですから、輸送中に普通の format=fixed の素の (OpenPGP-MIME ではない) PGP の署名メッセージに format=flowed 頭を追加して、 任意の間隔文字を行末に加えて、この変更に気づかれないようにすることが可能でしょう。 そうすると format=flowed に対応したクライアントでの記事のレンダリングが変わってしまいます。

Therefore, the use of [OpenPGP] with format=flowed messages is strongly discouraged. [OpenPGP-MIME] is recommended instead.

ですから、 format=flowed メッセージでの OpenPGP の使用は強く非推奨とします。代わりに OpenPGP-MIME を推奨します。

4.7. Line Analysis Table

Lines contained in a Text/Plain body part with Format=Flowed can be analyzed by examining the start and end of the line. If the line starts with the quote indicator, it is quoted. If the line ends with one or more space characters, it is flowed. This is summarized by the following table:

format=flowedtext/plain 本体部分に含まれる行は行の始めと終わりを調べて解析できます。 行が引用指示子で始まるなら、その行は引用です。 行が一つ以上の文字で終わるなら、その行は流しです。 次の表にまとめます。

Starts with QuoteEnds in One or More SpacesLine Type
--------------------------------
nonounquoted, fixed
yesnoquoted, fixed
noyesunquoted, flowed
yesyesquoted, flowed
引用符で開始一つ以上の間隔で終わる行の種類
--------------------------------
××引用ではない、固定
×引用、固定
×引用ではない、固定
引用、固定

4.8. 4.7. Examples

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.'

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.#

5. Interoperability

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 を認識しないソフトウェアは流し行を通常の text/plain として扱います (というか、そうなのです)。 ですから、 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.

間隔詰込みメッセージを format=flowed を扱うエージェントが受信したら、 間隔詰込みは元に戻されてメッセージは元のように見えます。 format=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.

生成エージェントは、一つ以上の間隔で始まる行があれば、 format=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 でメッセージが生成され、 format=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 表、 AA原始符号 (ソース・コード) その他は、 流し行ではなく、固定行として送信するべきです

5. 6. ABNF

The constructs used in Text/Plain; Format=Flowed body parts are described using Augmented Backus-Naur Form [ABNF], including the Core Rules core rules defined in Appendix A:

text/plain; format=flowed 本体部分で使う構造を増補 Backus‐Naur 式 (ABNF) とその附属書 A で定義された中核規則を使って記述します。

Note that the SP (space) and ">" characters are encoded according to the charset parameter.

SP (間隔) と > の文字は charset 引数に従って符号化することに注意してください。

  • 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
  • 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つの流し行が必要で、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.

flowed-linesig-sep の定義が曖昧たりえることに注意してください。 署名分離子行は両方に一致しますが、 流し行ではなく署名分離子行として扱います。

6. 7. Failure Modes

6.1. 7.1. Trailing White Space Corruption

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 Section 4.5.2.

通過するメッセージの行末の空白を変えてしまうシステムが存在します。 そのようなシステムは行末の空白を落とすかもしれませんし、 稀に追加するかもしれません。これは RFC 2821 4.5.2節違反です。

Stripping trailing whitespace has the effect of converting flowed lines to fixed lines, which results in a message no worse than if Format=Flowed had not been used.

行末の空白を落とすと流し行が固定行に変わってしまいますが、 format=flowed を使わなかった時より悪くはなりません。

Adding trailing whitespace to a Format=Flowed message may result in a malformed display or reply.

format=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つか2つの間隔文字を行末に使い、 行長が全体で奇数になるようにすると format=flowed を定義することもできたでしょう。 しかし、今日 (こんにち) ではそのようなシステムも珍しくなってきたことを考えますと、 わざわざ複雑にするだけの価値はないでしょう。

7. 8. Security Considerations

This parameter introduces no security considerations beyond those which apply to Text/Plain. Any security considerations which apply to Text/Plain also apply to Text/Plain with Format=Flowed.

この引数には text/plain に適用される安全上の考察以上のことは特にありません。

text/plain に適用される安全上の考察はすべて format=flowedtext/plain にも適用されます。

Section 4.6 discusses the interaction between Format=Flowed and digital signatures or encryption.

デジタル署名や暗号化と format=flowed の相互作用については 4.6 節で議論しています。

8. 9. IANA Considerations

IANA is requested to add a reference to this specification in the Text/Plain Media Type registration. IANA has added a reference to this specification in the Text/Plain Media Type registration.

IANA はこの仕様書への参照を text/plain 媒体型登録簿に加えてください。

IANA はこの仕様書への参照を text/plain 媒体型登録簿に追加しています。

9. 10. Internationalization Considerations

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 needs to be taken in applying format=flowed in these cases, as format=fixed combined with quoted-printable [quoted-printable] encoding may be more suitable.

format=flowed の行折返しと引用の規定は特定の charset, 例えばアラビア文字やヘブライ文字のような右から左の書くものには適当でないかもしれません。 format=flowed をそのような場合に適用するのには注意が必要で、 format=fixed を引用印字可能符号化と組合せるのがより適当かもしれません。

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 引数は format=flowedASCII 間隔が稀にしか使われないか、まったく使われない言語・ 符号化文字集合で使うために特に追加されました。

10. 11. Acknowledgments

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 メイリング・リストでの Chris Newman の text/paragraph 案の議論から出てきました。 Ian Bell, Steve Dorner, Brian Kelly, Dan Kohn, Laurence Lundblade, Dan Wing の評論、注釈、提案、議論に特に感謝します。

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. 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.

delsp 引数は Harald Alvestrand, Grant Baillie, Ian Bell, Steve Dorner, Patrik Faltstrom, Eric Fischer, Ned Freed, Alexey Melnikov, John Myers, Pete Resnick を含む大勢の人々の一連の議論から開発されました。 RFC 2646 とこの文書の初期の版の訂正と明確化を Adam Costello, Jutta Degener, Tony Hansen, Simon Josefsson, Dan Kohn, Ragho Mahalingam, Keith Moore, Greg Troxel, Dan Wing を含む数々の人々が指摘してくれました。

I'm told that NeXT's mail application used a very similar mechanism (without support for non-Western languages) in 1992.

1992年に NeXT のメイル応用は (非西洋言語対応を除き) 非常に似た方法を使っていました。

11. References 12. Normative References

[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.

[KEYWORDS] S. Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RICH] Resnick, P. and A. Walker, "The text/enriched MIME Content-type", RFC 1896, February 1996.

[MIME-IMT] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.

[Quoted-Printable] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.

13. Informative References

[SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.

[HTML] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language -- 2.0", RFC 1866, November 1995.

[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.

[OpenPGP] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.

[OpenPGP-MIME] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC 2015, October 1996. 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.

[SMTP] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821, April 2001.

Appendix A: Changes from 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.

本質的な変更点:

  • 空白が一般的でないかまったく使わない言語と符号化文字集合を扱うために delsp 引数を追加しました。
  • delsp 引数を考慮して生成と解釈の文章を修正しました。
  • RFC 2822 に適合するように79〜80文字の制限を78文字に変更しました。
  • 78文字制限が行末の空白と詰込みを含むことを明確化する文章を生成のところに追加しました。
  • ABNF の sig-sep を詰込みができるように変更しました。
  • ABNF の fixed-line を空行を認めるように変更しました。
  • ABNF の後の説明文を追加しました。
  • 概要の文章を新しく導入に移動し、概要を書き直しました。
  • 相互運用性の文章を新しい章に移動し、修正しました。
  • 安全性に関して明確化しました。
  • デジタル署名の話で OpenPGP が末尾の空白を無視することを追記しました。
  • Unicode 附属書 14 に言及しました。
  • 概要と導入に引用について追記しました。
  • 行分析表を削除しました。
  • OpenPGP と OpenPGP-MIME についての推奨を追加しました。
  • ほとんど曖昧でないように ABNF 規則を書き直し、 残った場合も注記しました。
  • 内容転送符号化が流し文処理に無関係であることの注記を追加しました。
  • データの末尾が段落を終えることを示す文章を追加しました。
  • sig-sepfixed-line ABNF の外に出しました。
  • いくつかのべきならないに変更しました (間隔詰込み、引用段落)。
  • 間隔と >charset に従って符号化することの注記を ABNF に追加しました。
  • 解釈の章で例外に言及しました。
  • 署名分離子行の扱いを明確化し一貫するようにしました。

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".

編集上の変更点:

  • 謝辞で NeXT のメイル応用に言及しました。
  • 謝辞を更新しました。
  • SMTP の参照を 2821 に更新しました。
  • 注意を追加しました。
  • 参考文献を規定と参考に分けました。
  • 幾つかの部分で言い回しを直しました。
  • 引用する深さでなく引用の深さに統一します。
  • 解釈の章を生成の章の前に移動しました。
  • 規定でないべきの言い回しを修正しました。
  • 段落の意味を注記しました。

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 間隔を稀にしか使わないか、 まったく使わない言語・符号化文字集合で format=flowed を使えるようにするために追加しました。 delsp の仕組みは、最初は組合せ不調和が大き過ぎるとして却下されましたが、 多くの別の手法が提案された中でも各種のクライアント (この仕様書も RFC 2646 も対応していないクライアント、 RFC 2646 は対応しているがこの仕様書には対応していないクライアント、 この仕様書には対応しているクライアント。それ掛ける、 間隔が普通の言語・符号化文字集合を扱うクライアント、 普通でないか使わないものを扱うクライアント。) の中で最大の相互運用性を持つことから選択されることになりました。

12. Editor's Author's Address

Randall Gellens
QUALCOMM Incorporated
5775 Morehouse Dr. Drive
San Diego, CA  92121-2779
USA

Phone: +1 858 651 5115
EMail: randy@qualcomm.com

Acknowledgement

Funding for the RFC Editor function is currently provided by the Internet Society.

License

[3] RFCのライセンス

メモ

[1] 読むの疲れます。同じことの繰り返しばっかじゃん。