Edit

Page

Page title:

Page body:

[SEE[ [[text/plain]] ]]

'''The Text/Plain Format [INS[and DelSp]] Parameter[INS[s]]'''
-Network Working Group                                
-Request for Comments: [DEL[2646]] [INS[3676]]
-[DEL[Updates: 2046]]
-[INS[Obsoletes: 2646]]
- Category: Standards Track
- R. Gellens[DEL[, Editor]]
- Qualcomm
- [DEL[August 1999]] [INS[February 2004]]

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

* Copyright Notice
> Copyright (C) The Internet Society ([DEL[1999]] [INS[2004]]).  All Rights Reserved.

[INS[
* Abstract
> This specification establishes two parameters (Format and DelSP) to
be used with the Text/Plain media type.  In the presence of these
parameters, trailing whitespace is used to indicate flowed lines and
a canonical quote indicator is used to indicate quoted lines.  This
results in an encoding which appears as normal Text/Plain in older
implementations, since it is in fact normal Text/Plain, yet provides
for superior wrapping/flowing, and quoting.

この仕様書は、 [CODE(MIME)[text/plain]] 媒体型で使用する
2つの引数 ([CODE(MIME)[format]] および [CODE(MIME)[delsp]])
を規定します。これらの引数が存在すると、行末の空白は流し行を示すために使われ、
正準引用指示子は引用行を示すために使われます。
この結果、古目の実装には通常の [CODE(MIME)[text/plain]]
のように見える符号化を行えます。実際、これは通常の [CODE(MIME)[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 [CITE[[CODE(MIME)[text/plain]] [CODE(MIME)[format]] 引数]] 
で規定されていたものを上書きすると共に、 ASCII
の間隔が使われないか稀にしか現れない言語・符号化文字集合で便利な
[CODE(MIME)[delsp]] 引数を追加します。
]INS]

* Table of Contents
[DEL[
>
=    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
]DEL]

[INS[
>
=   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
]INS]

* 1.  [DEL[Abstract]] [INS[Introduction]]
>    Interoperability problems have been observed with erroneous labelling
of paragraph text as Text/Plain, and with various forms of
"embarrassing line wrap." (See [DEL[section]] [INS[Section]] 3.)

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

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

[CODE(MIME)[[[text/enriched]]]] や [CODE(MIME)[[[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 [INS[which lines are quoted and]] which lines [DEL[can be]] [INS[are]] considered a logical paragraph, and thus [INS[eligible to be]] flowed
(wrapped and joined) as appropriate.

必要とされているのは重要な点すべてにおいて [CODE(MIME)[[[text/plain]]]]
であって、従って [CODE(MIME)[[[text/plain]]]] として表示するのが至極適切であり、
それでいて送信者が受信者に[INS[どの行が引用であり]]どの行が論理的段落とみなせるか、
よって適当に流込む (折返したり連結したりする) ことができるかを表現できる書式であります。

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

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

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

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

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

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

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

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

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

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

[CODE(MIME)[Text/Plain]] は、通常整形済み文章として、
しばしば固定フォントで表示されます。すなわち、
文字は表示窓の左余白で始まり、 [CODE(charset)[CRLF]] 列が見つかるまで右に進み、
[CODE(charset)[CRLF]] 列のところで新しい行が再び左余白から始まります。
行長が表示窓を超えた時は、行を折畳むクライアントもあれば、
水平 scroll 棒を出すクライアントもあります。

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

この説明に合致する文章はこのメモでは[DFN[[RUBYB[固定][fixed]]]]と定義します。

> Some interoperability problems have been observed with this [DEL[media type]] [INS[format]]:

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

** 3.1.  Paragraph Text
> Many modern programs use a proportional-spaced font[INS[,]] and [INS[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.

多くの現代的なプログラムは可変間隔フォントを使用し、
改段落を表現するために [CODE(char)[CRLF]] を使用します。
改行は「[RUBYB[やわらかく][soft]]」、表示で必要な時に行われます。
すなわち、文字は [CODE(char)[CRLF]] 列が見つかるまでが一つの段落に集団化され、
[CODE(char)[CRLF]] 列のところで新しい段落が始まります。
各段落は左余白から (または段落字下げで) 表示され、
残る表示幅に当てはまらない語が現れるまで右に続けます。
当てはまらなくなった語は次の行の左余白に表示します。
これは段落が終了するまで ([CODE(char)[CRLF]] が見つかるまで)
続きます。余分な垂直間隔を段落間に置きます。

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

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

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

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

** 3.2.  Embarrassing Line Wrap
> As Text/Plain messages [DEL[get]] [INS[are]] quoted in replies or forwarded messages, [DEL[the length of each line gradually increases,]] [INS[each line gradually increases in length, eventually being arbitrarily hard wrapped,]]
resulting in "embarrassing line wrap." This [DEL[results in]] [INS[produces]] text which is[INS[,]] at best[INS[,]] hard to read, and often confuses attributions.

[CODE(MIME)[text/plain]] メッセージは、返答・転送メッセージで引用されるごとに、
各行の長さが段々と増えていき、やがて勝手に硬く行送りされて
[Q[困った改行]]になります。そうなると文章は良くても読みにくい、
時にはどうつながっているのかよくわからないようなものとなります。

> Example:
[PRE[
>>>>>>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.
]PRE]

> It can be confusing to assign attribution to lines 2 and 4 above.

この例の2行目と4行目は誰の文章なのかわかりにくくなっています。

> In addition, as devices with display widths smaller than [INS[79 or]] 80
characters become more popular, embarrassing line wrap has become
even more prevalent, even with unquoted text.

また、79〜80文字よりも小さな表示幅の装置が良く使われるようになっていますから、
困った改行問題は引用されていない文章でもより普通なことになっています。

> Example:
[PRE[
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.
]PRE]

[PRE[
これはいくつもの行にわたって流
されることを意図した段落文です
。
しかし、送信したメイル器が文章
を 72 文字固定としてしまったた
めに、
1 行で 30 文字しか表示できない
 PDA で見るとこのようになって
しまいます。
]PRE]

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

新しい媒体型、例えば [CODE(MIME)[[[text/enriched]]]] や
[CODE(MIME)[[[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.

特に、 [CODE(MIME)[text/enriched]] は開き角括弧 ([CODE(char)[<]])
と硬い改行を重ねる必要がありますから、利用者が [CODE(MIME)[text/plain]]
として見た時に嬉しくありません。 [CODE(MIME)[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 [DEL[Text]] [INS[TEXT]] as an attachment.

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

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

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

ですから、望まれるのはすべての重要な点において [CODE(MIME)[text/plain]]
であり、従って [CODE(MIME)[text/plain]] として表示するのが極めて適当であり、
されども送信者が受信者にどの行を論理的な段落と考えることができるかを表現でき、
よって適当に流し (行送りや連結) を行うことのできる書式です。

* 4.  The Format [INS[and DelSp]] Parameter[INS[s]] [DEL[to the Text/Plain Media Type]]
> This [DEL[document]] [INS[specification]] defines [DEL[a new]] [INS[two]] MIME parameter[INS[s]] for use with Text/Plain:

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

>
:       Name:  Format
:       Value:  Fixed, Flowed

[INS[
>
:      Name:  DelSp
:      Value:  Yes, No
]INS]

> (Neither the parameter name[INS[s]] nor [DEL[its]] value[INS[s]] are case sensitive.)

(引数名も引数値も、大文字・小文字を区別しません。)

> If [INS[Format is]] not specified, [INS[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].

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

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

[CODE(MIME)[Format]] の値が [CODE(MIME)[flowed]]
であれば、生成にあたって流し文の定義 (このメモで規定しているもの)
が使われたことを示し、受信した際には流し文の定義を使って'''構いません'''。

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

[CODE(MIME)[Format]] は [CODE(MIME)[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.

[CODE(MIME)[Delsp]] が指定されていないか、値が認識できない時には、
[CODE(MIME)[no]] の値であるとみなします。 [CODE(MIME)[Format]] の値を
[CODE(MIME)[flowed]] にせずに [CODE(MIME)[delsp]]
を使用することは、未定義とします。メッセージを作成する時には、
[CODE(MIME)[format]] が [CODE(MIME)[flowed]] である [CODE(MIME)[text/plain]]
以外で [CODE(MIME)[text]] 内容型に [CODE(MIME)[delsp]]
を指定する'''べきではありません'''。メッセージを受信する時には、
[CODE(MIME)[format]] が [CODE(MIME)[flowed]] である [CODE(MIME)[text/plain]]
以外の [CODE(MIME)[text]] 内容型で [CODE(MIME)[delsp]]
が使われていても、無視する'''べきです'''。
]INS]

> This section discusses flowed text; section [DEL[5]] [INS[6]] provides a formal definition.

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

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

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

[INS[
> Section 5 discusses interoperability.

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

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

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

** [DEL[4.2.]] [INS[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).

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

> 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 [DEL[one or more]] [INS[a]] space[DEL[s]], the line is flowed.
Otherwise it is fixed.  [DEL[Trailing spaces are part of the line's content, but the CRLF of a soft line break is not.]] [INS[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章で説明しています。[DEL[行末の間隔は行の内容の一部ですが、軟改行の [CODE(char)[CRLF]] はそうではありません。]]署名分離子行は間隔で終わりますが、
流しでも固定でもありません。

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

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

> Any remaining trailing spaces are part of the line's content, but the
CRLF of a soft line break is not.

他の残った間隔は行の内容の一部ですが、軟改行の [CODE(char)[CRLF]]
はそうではありません。
]INS]

>    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 [DEL[section]] [INS[Section]] 4.5).

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

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

> A line consisting of one or more spaces (after deleting a [DEL[stuffed]] space [INS[acting as stuffing]]) is considered a flowed line.

(詰込みとして働く間隔を削除した後に) 1つ以上の間隔で構成される行は、
流し行とみなします。

[INS[
> An empty line (just a CRLF) is a fixed line.

空行 ([CODE(char)[CRLF]] だけ) は固定行です。

> Note that, for Unicode text, [Annex-14] provides guidance for
choosing at which characters to wrap a line.

[[Unicode]] 文では、 [[UAX]] #14 が行を送る文字を選ぶ際の指針を提供していることに注意してください。
]INS]

** [DEL[4.1.]] [INS[4.2.]]  Generating Format=Flowed
> When generating Format=Flowed text, lines SHOULD be [DEL[shorter than 80 characters]] [INS[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 [DEL[79]] [INS[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.  [INS[(]]It has been suggested that 66
character lines are the most readable.[INS[)]]

[CODE(MIME)[format=flowed]] の文章を生成する時には、
行は末尾の空白や詰込みの一部として追加した間隔も含めて、
78文字以下にする'''べきです'''。
全部の長さが78文字より長い段落は、一行を72文字以下にして折返すことを提案します。
行の長さは美学と好みの問題ですが、
長い行は古いメイル器で再折返しする必要があってやっかいなことになりやすそうです。
(一行を66文字にするのがもっとも読みやすいのではないかといわれています。)

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

通信時に [CODE(char)[[[CRLF]]]] の間を78文字以下に制限するのは
[[RFC 2822]] に適合します。
]INS]

> ([DEL[The reason for the restriction to 79 or fewer characters between CRLFs on the wire is to ensure]] [INS[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 [INS[79- or]] 80-column screen without having
to be wrapped.  The limit is [DEL[79]] [INS[78]], not [INS[79 or]] 80, because while [INS[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 [INS[at natural wrapping points, such as]]
between words.  [DEL[Because a]] [INS[A]] soft line break is a SP CRLF sequence[DEL[, the generating agent creates one by inserting a CRLF after the occurance of a space]].

流し文を作る時に、生成エージェントは必要に応じて流しを行います。
つまり、[Q[軟]]改行を挿入します。軟改行は語の間などの自然な折返し点に追加します。
軟改行は [CODE(char)[SP]] [CODE(char)[CRLF]] の列です。

[INS[
>   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]] で確立された古い方の方法は、間隔があるところの後に
[CODE(char)[CRLF]] を挿入して軟改行を作成します。
この方法では、軟改行は間隔が既に存在するところでのみ行えます。
この方法を使う時は、 [CODE(MIME)[delsp]] 引数を使う'''べきです'''。
[CODE(MIME)[delsp]] を使用するときには [CODE(MIME)[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]] [[間隔]]文字を使うのが稀かまったく使用しない言語・
[[符号化文字集合]]であっても使える方法で、
[CODE(char)[SP]] [CODE(char)[CRLF]] 列を挿入することによって軟改行を行います。
この方法を使う時は、 [CODE(MIME)[delsp]] 引数を使わなければ'''なりません'''。
その値は [CODE(MIME)[yes]] に設定しなければ'''なりません'''。
注意していただきたいのは、間隔の詰込みがありますから、
この方法を使う時で [CODE(char)[SP]] が既に存在するところ
(語間など) に軟改行を挿入する時には、 [CODE(char)[SP]] [CODE(char)[CRLF]]
列を [CODE(char)[SP]] の直前に追加すると元々存在していた [CODE(char)[SP]]
が行頭に来て、詰込みが必要になります。エージェントは [CODE(char)[SP]]
[CODE(char)[CRLF]] 列を既存の [CODE(char)[SP]] の後に挿入してこれを避けることを'''推奨'''します。

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

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

> [INS[Regardless of which technique is used, a]] [DEL[A]] 
generating agent SHOULD NOT insert [INS[a]] [DEL[white]] space [INS[in an unnatural location, such as]] into a word (a
sequence of printable characters[INS[,]] not containing spaces[INS[, in a language/coded character set in which spaces are common]]).  If faced
with [INS[such]] a word which exceeds [DEL[79]] [INS[78]] characters (but less than 998
characters, the [SMTP] limit on line length), the agent SHOULD send
the word as is and exceed the [DEL[79-character]] [INS[78-character]] limit on line length.

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

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

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

[INS[
> A generating agent MUST:

生成エージェントは、
]INS]

>
-[DEL[3.]] [INS[o]] Space-stuff lines which start with a space, "From ", or ">".

- 間隔, [Q[From ]], [Q[>]] で始まる行に間隔を詰込まなければ'''なりません'''。

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

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

> (See [DEL[sections]] [INS[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.

[CODE(MIME)[format=flowed]] メッセージは、零個以上の段落から構成されます。
段落は、一つ以上の流し行の後に1つの固定行が続きます。
普通は流し行の間には空の固定行を入れます。

>    Any number of fixed lines can appear between paragraphs.

段落の間には任意の数の固定行が出現できます。

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

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

>    [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 [DEL[SMTP]] [INS[ [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.

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

** 4.3.  Usenet Signature Convention
> There is a [INS[long-standing]] convention in Usenet news [INS[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 [INS[or quoted and stuffed]])
line consisting of DASH DASH SP is [DEL[not considered]] [INS[neither fixed nor]] flowed.

Usenet ニュースには、メッセージの本文と署名の間に [CODE[-- ]]
を区切りの行として使うという長きにわたる慣習があり、
インターネット・メイルでもよく使われています。署名の前に Usenet
式分離子を含む [CODE(MIME)[format=flowed]] メッセージを生成する時には、
分離子行はそのままで送ります。これは特例です。
横線・横線・[CODE(char)[[[SP]]]] で構成される行
(や、それを引用したり、引用して詰込んでいる行) は、
固定でも流しでもありません。

[INS[
> 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度行う必要があります。
]INS]

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

引用されていない行が [CODE(char)[>]] から始まっても良いように、
そして転送中のメッセージを [Q[[CODE[From]] いじり]]する
([CODE[From ]] で始まる行を [CODE[>From ]] に修正する)
システムから保護するために、 [CODE(MIME)[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 [INS[(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 " [DEL[SHOULD]] [INS[MUST]] be space-stuffed.  Other
lines MAY be space-stuffed as desired.

生成時には、 [CODE(char)[>]] で始まる引用されていない行と、
間隔か [CODE[From ]] で始まる行を間隔詰込みしなければ'''なりません'''。
他の業は必要なら間隔詰込みしても'''構いません'''。

> (Note that space-stuffing is [INS[conceptually]] similar to dot-stuffing as specified in [SMTP].)

参考: 間隔詰込みは概念的には [[SMTP]] の点詰込みと似ています。

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

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

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

[CODE(MIME)[format=flowed]] では、正準引用指示子 (引用符)
は1つ以上の閉じ角括弧 ([CODE(char)[>]]) 文字です。引用指示子で始まる行は引用とみなします。
行頭からの [CODE(char)[>]] 文字の数は引用の深さを表します。
引用でもある流し行は表示や新しいメッセージへの複写の際に特別な扱いが必要かもしれません。

>    When creating quoted flowed lines, each such line starts with the
quote indicator.

引用流し行の作成の時、各行は引用指示子で始めます。

>    Note that because of space-stuffing, the lines
[PRE[
>> Exit, Stage Left
]PRE]
and
[PRE[
>>Exit, Stage Left
]PRE]
are semantically identical; both have a quote-depth of two, and a
content of "Exit, Stage Left".

間隔詰込みがありますから、前2例は意味的に同一です。
双方共に引用の深さが2で、内容が [SAMP[Exit, Stage Left]] です。

>    However, the line
[PRE[
> > Exit, Stage Left
]PRE]
is different.  It has a quote-depth of one, and a content of
"> Exit, Stage Left".

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

>    When generating quoted flowed lines, an agent needs to pay attention
to changes in quote depth.  [DEL[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.]] [INS[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.]]

引用流し行を作成する時は、エージェントは引用の深さの変更に注意する必要があります。[DEL[同じ深さの引用の行の連続は段落として符号化する'''べき'''で、最後の行は固定とし、それ以前の行は流しとして生成する'''べきです'''。]] [INS[段落のすべての行は引用されていないか、またはすべて引用されていて同じ深さでなければ'''なりません'''。従って、引用の深さが変わっている時や、引用から非引用になったり、非引用から引用になったりしている時は、変化の直前の行が流し行であっては'''なりません'''。]]

> 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.  [DEL[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 [DEL[is]] [INS[are]] prefixed to each line.

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

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

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

[INS[
>   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つの隣接する行が異なる引用の深さである時には、常に、
送信者は前の行を流しではなく (間隔で終わらなく) しなければ'''なりません'''し、
そこで流し行を見つけた受信者は段落の最後の行として扱う'''べきです'''。
]INS]

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

例えば、次の例を考えてみます。 ([CODE[*]] は軟改行、
すなわち [CODE(char)[SP]] [CODE(char)[CRLF]] をあらわし、
[CODE[#]] は硬改行、すなわち [CODE(char)[CRLF]] をあらわします。)

>
[PRE[
> 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?#
]PRE]

>    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 [DEL[should]] [INS[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 [DEL[SHOULD]] [INS[MUST]] NOT create this situation; a receiving agent
SHOULD handle it [DEL[using quote-depth wins]] [INS[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 [DEL[on-the-wire Format=Flowed format]] [INS[same text for signature verification and/or decryption as was used for signature generation and/or encryption]]. [DEL[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.]] [INS[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.]]

メッセージがデジタル的に署名または暗号化される場合は、
暗号処理が[DEL[ネットワーク転送する [CODE(MIME)[format=flowed]] 書式]][INS[署名生成[[及び/又は]]暗号化の時と署名検証[[及び/又は]]解読の際に同じ文章]]を使うことが重要です。[DEL[つまり、生成中には軟改行、間隔詰め、 (軟改行の保護のための) 引用印字可能符号化を含めた転送用のメッセージをデジタル署名・暗号化の前に用意する'''べきです'''。同様に、受信時には引用印字可能復号、間隔詰め、軟改行、引用符の削除、再流込みを行う前に署名検証・復号する'''べきです'''。]] [INS[[CODE(MIME)[format=flowed]] を使うと文章が作成と転送の間や受信と表示の間で変わってしまう (改行や行末の間隔を追加したり削除したりする) ことがありますから、発信者と受信者が共にネットワーク転送する書式を暗号処理に使わなければ相互運用性の問題や安全上の脆弱性が発生するかもしれません。]]

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

[CODE(MIME)[format=flowed]] と特定の暗号処理の相互作用はその暗号処理の詳細に依存しますから、
[CODE(MIME)[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] は[Q[[[清文署名]]を計算する時には行末の空白 (間隔、タブ、 [CODE(char)[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.

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

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

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

[DEL[
* 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:

[CODE(MIME)[format=flowed]] の [CODE(MIME)[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"

,引用符で開始,一つ以上の間隔で終わる,行の種類
,------          ,-----------        ,---------------
,×              ,×                 ,"引用ではない、固定"
,○              ,×                 ,"引用、固定"
,×              ,○                 ,"引用ではない、固定"
,○              ,○                 ,"引用、固定"
]DEL]

** [DEL[4.8.]] [INS[4.7.]]  Examples
>    The following example contains three paragraphs:

次の例は3段落含みます。

>
[PRE[
`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.'
]PRE]

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

これは次のように符号化できます ([CODE[*]] は軟改行、すなわち
[CODE(char)[SP]] [CODE(char)[CRLF]] 列を表し、 [CODE[#]]
は硬改行、すなわち [CODE(char)[CRLF]] を表します)。

>
[PRE(MIME)[
`Take some more tea,' the March Hare said to Alice, very*
earnestly.[DEL[*]][INS[#]]
#
`I've had nothing yet,' Alice replied in an offended tone, `so*
I can't take more.'[DEL[*]][INS[#]]
#
`You mean you can't take LESS,' said the Hatter: `it's very*
easy to take MORE than nothing.'#
]PRE]

>    To show an example of quoting, here we have the same exchange,
presented as a series of direct quotes:

次は引用の例です。

>
[PRE[
>>>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.#
]PRE]

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

流し行は固定行とまったく区別できないものですから、
[CODE(MIME)[format=flowed]] を認識しないソフトウェアは流し行を通常の
[CODE(MIME)[text/plain]] として扱います (というか、そうなのです)。
ですから、 [CODE(MIME)[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.

間隔詰込みメッセージを [CODE(MIME)[format=flowed]] を扱うエージェントが受信したら、
間隔詰込みは元に戻されてメッセージは元のように見えます。
[CODE(MIME)[format=flowed]] を知らないエージェントはもちろん間隔詰込みを戻しません。
ですから [CODE(MIME)[format=flowed]] メッセージは行によって
(間隔、引用指示子でない [CODE(char)[>]]、 [CODE(822)[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.

生成エージェントは、一つ以上の間隔で始まる行があれば、
[CODE(MIME)[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.

[CODE(MIME)[delsp=yes]] でメッセージが生成され、
[CODE(MIME)[format=flowed]] は知っていても [CODE(MIME)[delsp]]
引数は知らないクライアントがこれを受信した場合は、
軟改行を削除した後に余計な間隔が残ってしまいます。
ですから、生成エージェントは、
間隔が普通な言語・符号化文字集合で文章を生成する時は常に
[CODE(MIME)[delsp=no]] 方式を使って'''構いません'''。

>   Hand-aligned text, such as ASCII tables or art, source code, etc.,
SHOULD be sent as fixed, not flowed lines.

手揃えの文章、例えば [[ASCII]] 表、 [ABBR[[[AA]]][文字絵]]、
[RUBY[原始符号][ソース・コード]]その他は、
流し行ではなく、固定行として送信する'''べきです'''。
]INS]

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

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

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

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

[DEL[
>
-      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
[PRE[
; any 7-bit US-ASCII character, excluding
; NUL, CR, LF, and SP
]PRE]
-      quote         = 1*">"
-      sig-sep       = [quote] "--" SP CRLF
-      stuffing      = [SP] 
[PRE[
; space-stuffed, added on generation if
; needed, deleted on reception
]PRE]
-      text-char     = non-sp / SP
]DEL]

[INS[
>
-flowed-body      = *( paragraph / fixed-line / sig-sep )
-paragraph        = 1*flowed-line fixed-line
[PRE[
; all lines in paragraph MUST be unquoted or
; have same quote depth
]PRE]
-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 
[PRE[
; space-stuffed, added on generation if
; needed, deleted on reception
]PRE]
-flow             = SP 
[PRE[
; space before CRLF indicates flowed line,
; if DelSp=yes, space was added on generation
; and is deleted on reception
]PRE]
-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.)

すなわち、 [CODE(MIME)[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.

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

* [DEL[6.]] [INS[7.]]  Failure Modes
**[DEL[6.1.]] [INS[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 [INS[2]]821 [SMTP] [DEL[section]] [INS[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.

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

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

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

*[DEL[7.]] [INS[8.]]  Security Considerations
> [DEL[This parameter introduces no security considerations beyond those which apply to Text/Plain.]] [INS[Any security considerations which apply to Text/Plain also apply to Text/Plain with Format=Flowed.]]

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

[INS[
[CODE(MIME)[text/plain]] に適用される安全上の考察はすべて
[CODE(MIME)[format=flowed]] の [CODE(MIME)[text/plain]]
にも適用されます。
]INS]

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

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

*[DEL[8.]] [INS[9.]]  IANA Considerations
> [DEL[IANA is requested to add a reference to this specification in the Text/Plain Media Type registration.]] [INS[IANA has added a reference to this specification in the Text/Plain Media Type registration.]]

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

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

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

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

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

[CODE(MIME)[delsp]] 引数は [CODE(MIME)[format=flowed]]
を [[ASCII]] 間隔が稀にしか使われないか、まったく使われない言語・
[[符号化文字集合]]で使うために特に追加されました。
]INS]

* [DEL[10.]] [INS[11.]]  Acknowledgments
[DEL[
>   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
の [CODE(MIME)[[[text/paragraph]]]] 案の議論から出てきました。
Ian Bell, Steve Dorner, Brian Kelly, Dan Kohn, Laurence Lundblade,
Dan Wing の評論、注釈、提案、議論に特に感謝します。
]DEL]

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

[CODE(MIME)[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]] のメイル応用は (非西洋言語対応を除き)
非常に似た方法を使っていました。
]INS]

*[DEL[11.  References]] [INS[12.  Normative References]]

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

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

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

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

[INS[
* 13.  Informative References
]INS]

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

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

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

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

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

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

* [DEL[12.  Editor's]] [INS[Author's Address]]
>
[PRE[
Randall Gellens
QUALCOMM Incorporated
5775 Morehouse [DEL[Dr.]] [INS[Drive]]
San Diego, CA  92121[DEL[-2779]]
USA

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

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

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

>   This document and the information contained herein [DEL[is]] [INS[are]] provided on an
"AS IS" basis and [INS[THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY),]] THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIM[DEL[S]] ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

[INS[
* Intellectual Property
>   The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights.  Information on the procedures with respect to
rights in RFC documents can be found in BCP 78 and BCP 79.

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

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

*License

[3] 
[[RFCのライセンス]]

* メモ

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

Historical Legal Sensitive Parent: [Help / License]

Edit

Page

Page name(s)