The Text/Plain Format and DelSp Parameters
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.
Copyright (C) The Internet Society (
19992004). All Rights Reserved.
This specification establishes two parameters (Format and DelSP) to be used with the Text/Plain media type. In the presence of these parameters, trailing whitespace is used to indicate flowed lines and a canonical quote indicator is used to indicate quoted lines. This results in an encoding which appears as normal Text/Plain in older implementations, since it is in fact normal Text/Plain, yet provides for superior wrapping/flowing, and quoting.
この仕様書は、 text/plain
媒体型で使用する
2つの引数 (format
および delsp
)
を規定します。これらの引数が存在すると、行末の空白は流し行を示すために使われ、
正準引用指示子は引用行を示すために使われます。
この結果、古目の実装には通常の text/plain
のように見える符号化を行えます。実際、これは通常の text/plain
であって、しかも折返し・流し込みや引用ができるものなのです。
This document supersedes the one specified in RFC 2646, "The Text/Plain Format Parameter", and adds the DelSp parameter to accommodate languages/coded character sets in which ASCII spaces are not used or appear rarely.
この文書は RFC 2646 text/plain
format
引数
で規定されていたものを上書きすると共に、 ASCII
の間隔が使われないか稀にしか現れない言語・符号化文字集合で便利な
delsp
引数を追加します。
- 1. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 2
- 2. Conventions Used in this Document . . . . . . . . . . . . . 2
- 3. The Problem . . . . . . . . . . . . . . . . . . . . . . . . 2
- 3.1. Paragraph Text . . . . . . . . . . . . . . . . . . . . 3
- 3.2. Embarrassing Line Wrap . . . . . . . . . . . . . . . . . 3
- 3.3. New Media Types . . . . . . . . . . . . . . . . . . . . 4
- 4. The Format Parameter to the Text/Plain Media Type . . . . . 4
- 4.1. Generating Format=Flowed . . . . . . . . . . . . . . . 5
- 4.2. Interpreting Format=Flowed . . . . . . . . . . . . . . . 6
- 4.3. Usenet Signature Convention . . . . . . . . . . . . . . 7
- 4.4. Space-Stuffing . . . . . . . . . . . . . . . . . . . . . 7
- 4.5. Quoting . . . . . . . . . . . . . . . . . . . . . . . . 8
- 4.6. Digital Signatures and Encryption . . . . . . . . . . . 9
- 4.7. Line Analysis Table . . . . . . . . . . . . . . . . . . 10
- 4.8. Examples . . . . . . . . . . . . . . . . . . . . . . . . 10
- 5. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
- 6. Failure Modes . . . . . . . . . . . . . . . . . . . . . . . 11
- 6.1. Trailing White Space Corruption . . . . . . . . . . . . 11
- 7. Security Considerations . . . . . . . . . . . . . . . . . . 12
- 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12
- 9. Internationalization Considerations . . . . . . . . . . . . 12
- 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 12
- 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
- 12. Editor's Address . . . . . . . . . . . . . . . . . . . . . 13
- 13. Full Copyright Statement . . . . . . . . . . . . . . . . . . 14
- 1. 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.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
sectionSection 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/enriched
や text/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 beare 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
なのです。
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.
用語段落は、ここでは、論理的に表示目的の単位として扱い、 表示窓に合うように、あるいは返答・転送その他の文章作成の時に適当に流したり (折畳んだり連結したり) しても適切である行の系列を意味するために使います。
The Text/Plain media type is the lowest common denominator of Internet email, with lines of no more than
997998 characters (by convention usually no more than8078), and where theCRLFcarriage-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".
この説明に合致する文章はこのメモでは固定と定義します。
Some interoperability problems have been observed with this
media typeformat:
この媒体型書式には幾つかの相互運用についての問題が見つかっています。
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
列のところで新しい段落が始まります。
各段落は左余白から (または段落字下げで) 表示され、
残る表示幅に当てはまらない語が現れるまで右に続けます。
当てはまらなくなった語は次の行の左余白に表示します。
これは段落が終了するまで (CRLF
が見つかるまで)
続きます。余分な垂直間隔を段落間に置きます。
Text which meets this description is defined by this memo as "flowed".
この説明に合致する定義はこのメモでは流しと定義します。
Numerous software products erroneously label this
media typeformat as Text/Plain, resulting in much user discomfort.
数々のソフトウェア製品が誤ってこの媒体型書式を
Text/Plain
と札付けしていまして、
利用者は甚だ不快に思うこととなっています。
As Text/Plain messages
getare 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." Thisresults inproduces 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 で見るとこのようになって しまいます。
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/enriched
や
text/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
TextTEXT 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
として表示するのが極めて適当であり、
されども送信者が受信者にどの行を論理的な段落と考えることができるかを表現でき、
よって適当に流し (行送りや連結) を行うことのできる書式です。
This
documentspecification definesa newtwo 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
itsvalues 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.
Format
は text/plain
内容型の引数ですから、
どんな内容転送符号化が使われていようが流し文の処理には関係ないことに注意してください。
If DelSp is not specified, or if its value is not recognized, a value of No is assumed. The use of DelSp without a Format value of Flowed is undefined. When creating messages, DelSp SHOULD NOT be specified in Text content types other than Text/Plain with Format = Flowed. When receiving messages, DelSp SHOULD be ignored if used in a Text content type other than Text/Plain with Format = Flowed.
Delsp
が指定されていないか、値が認識できない時には、
no
の値であるとみなします。 Format
の値を
flowed
にせずに delsp
を使用することは、未定義とします。メッセージを作成する時には、
format
が flowed
である text/plain
以外で text
内容型に delsp
を指定するべきではありません。メッセージを受信する時には、
format
が flowed
である text/plain
以外の text
内容型で delsp
が使われていても、無視するべきです。
This section discusses flowed text; section
56 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.
このメモは通信用の書式について説明していることに注意してください。 局所ファイル蓄積用の書式については言及していません。
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 morea 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.
行が流しで、 delsp
が yes
なら、
その行の CRLF
のすぐ前の間隔は論理的に削除します。
delsp
が no
(か指定されていないか認識できない値に設定されている) なら、
行末の間隔は削除しません。
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
sectionSection 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
stuffedspace 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.
When generating Format=Flowed text, lines SHOULD be
shorter than 80 characters78 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 than7978 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 ensureIn 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 is7978, 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 aA 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
Agenerating agent SHOULD NOT insert awhitespace 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 exceeds7978 characters (but less than 998 characters, the [SMTP] limit on line length), the agent SHOULD send the word as is and exceed the79-character78-character limit on line length.
どちらの方法を使うにせよ、生成エージェントは語 (間隔を普通に使う言語・符号化文字集合で、印字可能文字の列であり、 間隔を含まないもの) の中のような不自然な場所に空白を挿入するべきではありません。 78文字の制限を超える (ものの SMTP の998文字の行長制限よりは短い) 語が現れた時は、エージェントはその語をそのまま78文字行長制限を超して送るべきです。
A generating agent SHOULD:
1.o Ensure all lines (fixed and flowed) are7978 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 exceeds7978 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
sectionsSections 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
が末端利用者から排除されてしまうことになるかもしれません。
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 consideredneither 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度行う必要があります。
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 "
SHOULDMUST 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
で始まる行) は頭に間隔がついて見えます。
間隔詰込みが必要な行はめったに現れませんし、見た目的にも最小限しか違いませんから、
大きな問題とはならないと思われます。
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 Leftand>>Exit, Stage Leftare 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 Leftis 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 presentisare prefixed to each line.
受信したエージェントが流し引用行を表示時や新しいメッセージの生成時に再整形
(行をつなげたり分割したり) したい時は、各行の引用をやめ、
再整形し、再び引用するべきです。引用をやめる時には、
行頭の引用指示子の閉じ角括弧の数を数えます。同じ引用の深さの連続する行は一つの段落と考え、一緒に再整形します。
再整形の後再び引用する時には、もとあったのと同じ数の閉じ角括弧を各行の最初に追加します。
On reception, if a change in
quotingquote 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 toignore the flowed indicator and treat the line as fixedconsider 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
shouldis 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
SHOULDMUST NOT create this situation; a receiving agent SHOULD handle itusing quote-depth winsby giving preference to the quote depth.
生成エージェントは、この状況をつくってはなりません。 受信エージェントは、引用の深さを優先させてこの状況を扱うべきです。
If a message is digitally signed or encrypted it is important that cryptographic processing use the
on-the-wire Format=Flowed formatsame 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 を推奨します。
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=flowed
の text/plain
本体部分に含まれる行は行の始めと終わりを調べて解析できます。
行が引用指示子で始まるなら、その行は引用です。
行が一つ以上の文字で終わるなら、その行は流しです。
次の表にまとめます。
Starts with Quote Ends in One or More Spaces Line Type ------ ----------- --------------- no no unquoted, fixed yes no quoted, fixed no yes unquoted, flowed yes yes quoted, flowed
引用符で開始 | 一つ以上の間隔で終わる | 行の種類 |
------ | ----------- | --------------- |
× | × | 引用ではない、固定 |
○ | × | 引用、固定 |
× | ○ | 引用ではない、固定 |
○ | ○ | 引用、固定 |
The following example contains three paragraphs:
次の例は3段落含みます。
`Take some more tea,' the March Hare said to Alice, very earnestly. `I've had nothing yet,' Alice replied in an offended tone, `so I can't take more.' `You mean you can't take LESS,' said the Hatter: `it's very easy to take MORE than nothing.'
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
を認識しないソフトウェアは流し行を通常の
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.
The constructs used in Text/Plain; Format=Flowed body parts are described using Augmented Backus-Naur Form [ABNF], including the
Core Rulescore 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-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]
sectionSection 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
を定義することもできたでしょう。
しかし、今日ではそのようなシステムも珍しくなってきたことを考えますと、
わざわざ複雑にするだけの価値はないでしょう。
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=flowed
の text/plain
にも適用されます。
Section 4.6 discusses the interaction between Format=Flowed and digital signatures or encryption.
デジタル署名や暗号化と format=flowed
の相互作用については 4.6 節で議論しています。
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
媒体型登録簿に追加しています。
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
shouldneeds to be taken in applying format=flowed in these cases, as format=fixed combined withquoted-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=flowed
を ASCII 間隔が稀にしか使われないか、まったく使われない言語・
符号化文字集合で使うために特に追加されました。
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 のメイル応用は (非西洋言語対応を除き) 非常に似た方法を使っていました。
[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.
[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.
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
引数を考慮して生成と解釈の文章を修正しました。sig-sep
を詰込みができるように変更しました。fixed-line
を空行を認めるように変更しました。sig-sep
を fixed-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".
編集上の変更点:
引用する深さでなく
引用の深さに統一します。
べきの言い回しを修正しました。
段落の意味を注記しました。
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 は対応しているがこの仕様書には対応していないクライアント、
この仕様書には対応しているクライアント。それ掛ける、
間隔が普通の言語・符号化文字集合を扱うクライアント、
普通でないか使わないものを扱うクライアント。)
の中で最大の相互運用性を持つことから選択されることになりました。
Randall Gellens QUALCOMM Incorporated 5775 MorehouseDr.Drive San Diego, CA 92121-2779USA Phone: +1 858 651 5115 EMail: randy@qualcomm.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
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.
This document and translations of it may be copied and furnished to thers, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein
isare 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 DISCLAIMSALL 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.
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.
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.
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.
Funding for the RFC Editor function is currently provided by the Internet Society.
[1] 読むの疲れます。同じことの繰り返しばっかじゃん。