RFC3676 日本語訳
3676 The Text/Plain Format and DelSp Parameters. R. Gellens. February 2004. (Format: TXT=42441 bytes) (Obsoletes RFC2646) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Gellens Request for Comments: 3676 Qualcomm Obsoletes: 2646 February 2004 Category: Standards Track
Gellensがコメントのために要求するワーキンググループR.をネットワークでつないでください: 3676 クアルコムは以下を時代遅れにします。 2646 2004年2月のカテゴリ: 標準化過程
The Text/Plain Format and DelSp Parameters
テキスト/明瞭な形式とDelSpパラメタ
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright(C)インターネット協会(2004)。 All rights reserved。
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.
この仕様は、Text/明瞭なメディアタイプで使用されるために、2つのパラメタ(形式とDelSP)を確立します。 これらのパラメタがあるとき、引きずっている空白は流れる線を示すのに使用されます、そして、正準な引用文のインディケータは、引用された線を示すのに使用されます。 これは事実上、正常なText/明瞭ですが、優れたラッピング/流れに備えて以来の、より古い実現で正常なText/明瞭で、引用するとして現れるコード化をもたらします。
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.
このドキュメントは、RFC2646で指定されたもの、「テキスト/明瞭な形式パラメタ」に取って代わって、ASCII空間が使用されていない言語/コード化文字集合を収容するか、またはめったに現れないようにDelSpパラメタを加えます。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in this Document . . . . . . . . . . . . . . 2
3. The Problem . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Paragraph Text. . . . . . . . . . . . . . . . . . . . . 3
3.2. Embarrassing Line Wrap . . . . . . . . . . . . . . . . 3
3.3. New Media Types . . . . . . . . . . . . . . . . . . . . 4
4. The Format and DelSp Parameters . . . . . . . . . . . . . . . 5
4.1. Interpreting Format=Flowed. . . . . . . . . . . . . . . 6
4.2. Generating Format=Flowed . . . . . . . . . . . . . . . 7
4.3. Usenet Signature Convention . . . . . . . . . . . . . . 9
4.4. Space-Stuffing . . . . . . . . . . . . . . . . . . . . 9
1. 序論。 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. このDocument. . . . . . . . . . . . . . 2 3のコンベンションUsed。 問題. . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1。 パラグラフテキスト。 . . . . . . . . . . . . . . . . . . . . 3 3.2. 線包装. . . . . . . . . . . . . . . . 3 3.3を当惑させます。 ニューメディアは.4 4をタイプします。 形式とDelSpパラメタ. . . . . . . . . . . . . . . 5 4.1。 解釈形式=は流れました。 . . . . . . . . . . . . . . 6 4.2. 形式=を発生させるのは.74.3に流れました。 Usenet署名コンベンション. . . . . . . . . . . . . . 9 4.4。 スペースを詰める.9
Gellens Standards Track [Page 1] RFC 3676 Text/Plain Format and DelSp Parameters February 2004
Gellens標準化過程[1ページ]のRFC3676テキスト/明瞭な形式とDelSpパラメタ2004年2月
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
4.5. .94.6を引用します。 デジタル署名と暗号化. . . . . . . . . . . 11 4.7。 例。 . . . . . . . . . . . . . . . . . . . . . . . 12 5. 相互運用性。 . . . . . . . . . . . . . . . . . . . . . . 12 6. ABNF。 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. 故障モード. . . . . . . . . . . . . . . . . . . . . . . . 14 7.1。 余白不正. . . . . . . . . . . . 14 8を引きずります。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 15 9。 IANA問題. . . . . . . . . . . . . . . . . . . . . 15 10。 国際化問題. . . . . . . . . . . . . 15 11。 承認. . . . . . . . . . . . . . . . . . . . . . . 15 12。 引用規格。 . . . . . . . . . . . . . . . . . . . . 16 13. 有益な参照。 . . . . . . . . . . . . . . . . . . . 16 付録A: RFC2646.18作者のアドレスからの変化。 . . . . . . . . . . . . . . . . . . . . . . . . 19 完全な著作権宣言文。 . . . . . . . . . . . . . . . . . . . . 20
1. Introduction
1. 序論
Interoperability problems have been observed with erroneous labelling of paragraph text as Text/Plain, and with various forms of "embarrassing line wrap". (See Section 3.)
相互運用性問題はText/平野としてのパラグラフテキストの誤ったラベル、および様々なフォームの「恥ずかしい線包装」で観測されました。 (セクション3を見てください。)
Attempts to deploy new media types, such as Text/Enriched [Rich] and Text/HTML [HTML] have suffered from a lack of backwards compatibility and an often hostile user reaction at the receiving end.
ニューメディアを配備する試みは、[リッシュ]をTextなどのようにタイプしたか、または豊かにしました、そして、Text/HTML[HTML]は犠牲者に後方にの不足から互換性としばしば敵対的なユーザ反応を受けました。
What is required is a format which is in all significant ways Text/Plain, and therefore is quite suitable for display as Text/Plain, and yet allows the sender to express to the receiver which lines are quoted and which lines are considered a logical paragraph, and thus eligible to be flowed (wrapped and joined) as appropriate.
何があるか、必要であることで、すべての重要な方法であるa形式がText/明瞭である、したがって、Text/平野として表示にかなり適していますが、送付者がどれとして台詞が引用されて、どの線が論理的なパラグラフと、その結果、適任であると考えられるか流れたか(包装されて、接合される)を受信機に適切な状態で言い表すのを許容します。
2. Conventions Used in this Document
2. このDocumentのコンベンションUsed
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].
“MUST"、「必須NOT」がキーワードが、「必要でした」、“SHOULD"、「」 「5月」は「RFCsにおける使用が要件レベルを示すキーワード」[キーワード]で説明されるように本書では解釈されることになっているべきです。
The term "paragraph" is used here to mean a series of lines which are logically to be treated as a unit for display purposes and eligible to be flowed (wrapped and joined) as appropriate to fit in the display window and when creating text for replies, forwarding, etc.
「パラグラフ」という用語は、表示目的のためにユニットとして扱われて適任に、論理的に、ディスプレイ・ウィンドウといつが適合するように適宜流れていたかという(包装されて、接合されます)ことである一連の線を意味するのに回答、推進などのためのテキストを作成しながら、ここで使用されます。
Gellens Standards Track [Page 2] RFC 3676 Text/Plain Format and DelSp Parameters February 2004
Gellens標準化過程[2ページ]のRFC3676テキスト/明瞭な形式とDelSpパラメタ2004年2月
3. The Problem
3. 問題
The Text/Plain media type is the lowest common denominator of Internet email, with lines of no more than 998 characters (by convention usually no more than 78), and where the carriage-return and line-feed (CRLF) sequence represents a line break (see [MIME-IMT] and [MSG-FMT]).
Text/明瞭なメディアタイプはインターネットメールの最小公分母です、998未満のキャラクタ(通常コンベンションによる78がない)の線と復帰と改行(CRLF)系列がどこにラインブレイクを表すかで([MIME-IMT]と[MSG-FMT]を見てください)。
Text/Plain is usually displayed as preformatted text, often in a fixed font. That is, the characters start at the left margin of the display window, and advance to the right until a CRLF sequence is seen, at which point a new line is started, again at the left margin. When a line length exceeds the display window, some clients will wrap the line, while others invoke a horizontal scroll bar.
通常、前フォーマットされたテキストとしてしばしば固定字体でテキスト/平野を表示します。 すなわち、キャラクタは、ディスプレイ・ウィンドウの左のマージンで始まって、CRLF系列が見られるまで、右に達して、復帰改行はそのポイントで始動されます、再び左のマージンで。 行長がディスプレイ・ウィンドウを超えていると、何人かのクライアントが線を包装するでしょう、他のものは水平なスクロールバーを呼び出しますが。
Text which meets this description is defined by this memo as "fixed".
この記述を満たすテキストがこのメモで「修理される」と定義されます。
Some interoperability problems have been observed with this format:
いくつかの相互運用性問題がこの形式で観測されました:
3.1. Paragraph Text
3.1. パラグラフテキスト
Many modern programs use a proportional-spaced font, and use CRLF to represent paragraph breaks. Line breaks are "soft", occurring as needed on display. That is, characters are grouped into a paragraph until a CRLF sequence is seen, at which point a new paragraph is started. Each paragraph is displayed, starting at the left margin (or paragraph indent), and continuing to the right until a word is encountered which does not fit in the remaining display width. This word is displayed at the left margin of the next line. This continues until the paragraph ends (a CRLF is seen). Extra vertical space is left between paragraphs.
多くの現代のプログラムが、比例して区切られた字体を使用して、パラグラフ中断を表すのにCRLFを使用します。 必要であるとしてディスプレーされていた状態で起こって、ラインブレイクは「柔らかいです」。 CRLF系列が見られて、新しいパラグラフがそのポイントで始められるまで、すなわち、キャラクタはパラグラフに分類されます。 各パラグラフは、表示されて、左のマージン(または、パラグラフインデント)で始まって、単語が遭遇するまで、右に続くことです残っている表示幅をうまくはめ込まない。 次の線の左の橋でこの言葉を表示します。 パラグラフが終わるまで(CRLFは見られます)、これは続きます。 余分な垂直なスペースはパラグラフの間に残されます。
Text which meets this description is defined by this memo as "flowed".
この記述を満たすテキストがこのメモで「流れる」と定義されます。
Numerous software products erroneously label this format as Text/Plain, resulting in much user discomfort.
多数のソフトウェア・プロダクトは誤ってText/明瞭であって、結果になるとしての相当なユーザ不快でのこの形式をラベルします。
3.2. Embarrassing Line Wrap
3.2. 恥ずかしい線包装
As Text/Plain messages are quoted in replies or forwarded messages, each line gradually increases in length, eventually being arbitrarily hard wrapped, resulting in "embarrassing line wrap". This produces text which is, at best, hard to read, and often confuses attributions.
Text/明瞭なメッセージは回答で引用するか、またはメッセージを転送するのに従って、各線が徐々に長さが増します、包装されて、結局任意に困難であることで、「恥ずかしい線包装」をもたらして。 これは、せいぜい読みにくいテキストを製作して、属性をしばしば混乱させます。
Gellens Standards Track [Page 3] RFC 3676 Text/Plain Format and DelSp Parameters February 2004
Gellens標準化過程[3ページ]のRFC3676テキスト/明瞭な形式とDelSpパラメタ2004年2月
Example:
例:
>>>>>>This is a comment from the first message to show a
>quoting example.
>>>>>This is a comment from the second message to show a
>quoting example.
>>>>This is a comment from the third message.
>>>This is a comment from the fourth message.
>>>>>>、これは>が例を引用するのを示す最初のメッセージからのコメントです。 >>>>>は、>が例を引用するのを示すために2番目から通信しますaが、論評する。 >>>>は3日から通信しますaが、論評する。 >>>は4日から通信しますaが、論評する。
It can be confusing to assign attribution to lines 2 and 4 above.
上の2と4の線に属性を割り当てるのは紛らわしい場合があります。
In addition, as devices with display widths smaller than 79 or 80 characters become more popular, embarrassing line wrap has become even more prevalent, even with unquoted text.
さらに、表示幅が79か80のキャラクタが、よりポピュラーになるよりわずかの装置として、恥ずかしい線包装はさらに一般的になりました、引用を終わっているテキストがあっても。
Example:
例:
This is paragraph text that is
meant to be flowed across
several lines.
However, the sending mailer is
converting it to fixed text at
a width of 72
characters, which causes it to
look like this when shown on a
PDA with only
30 character lines.
これはパラグラフテキストです、すなわち、流れることが意味されて、数個が立ち並んでいます。 しかしながら、送付郵送者は72のキャラクタの幅で固定テキストにそれを変換しています。(PDAの上に30個のハイライト線だけで示されると、それはそれで、これに似ています)。
3.3. New Media Types
3.3. ニューメディアタイプ
Attempts to deploy new media types, such as Text/Enriched [Rich] and Text/HTML [HTML] have suffered from a lack of backwards compatibility and an often hostile user reaction at the receiving end.
ニューメディアを配備する試みは、[リッシュ]をTextなどのようにタイプしたか、または豊かにしました、そして、Text/HTML[HTML]は犠牲者に後方にの不足から互換性としばしば敵対的なユーザ反応を受けました。
In particular, Text/Enriched requires that open angle brackets ("<")
and hard line breaks be doubled, with resulting user unhappiness when
viewed as Text/Plain. Text/HTML requires even more alteration of
text, with a corresponding increase in user complaints.
テキスト/平野として見なされると、特に、豊かにされたText/は、開いている角ブラケット("<")と困難なラインブレイクが結果として起こるユーザ不幸で倍にされるのを必要とします。 テキスト/HTMLはユーザ苦情の対応する増加に伴うテキストのさらに多くの変更を必要とします。
A proposal to define a new media type to explicitly represent the paragraph form suffered from a lack of interoperability with currently deployed software. Some programs treat unknown subtypes of TEXT as an attachment.
明らかに成文パラグラフを表すためにニューメディアタイプを定義するという提案は現在配備されたソフトウェアで相互運用性の不足に苦しみました。 いくつかのプログラムが添付書類でTEXTの未知の血液型亜型を扱います。
Gellens Standards Track [Page 4] RFC 3676 Text/Plain Format and DelSp Parameters February 2004
Gellens標準化過程[4ページ]のRFC3676テキスト/明瞭な形式とDelSpパラメタ2004年2月
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.
何があるか、望まれていて、すべての重要な方法であるa形式がText/明瞭である、したがって、Text/平野として表示にかなり適していますが、送付者が、どの線が流れると(包装されて、接合されます)論理的なパラグラフに、このようにして考えることができるかを受信機に適宜言い表すのを許容します。
4. The Format and DelSp Parameters
4. 形式とDelSpパラメタ
This specification defines two MIME parameters for use with Text/Plain:
この仕様はText/平野との使用のための2つのMIMEパラメタを定義します:
Name: Format
Value: Fixed, Flowed
以下を命名してください。 値をフォーマットしてください: 修理されて、流れます。
Name: DelSp
Value: Yes, No
以下を命名してください。 DelSp値: はい、いいえ
(Neither the parameter names nor values are case sensitive.)
(どちらも大文字と小文字を区別していませんパラメタが、命名して、評価する。)
If Format is not specified, or if the value is not recognized, a value of Fixed is assumed. The semantics of the Fixed value are the usual associated with Text/Plain [MIME-IMT].
Formatが指定されないか、または値が認識されないなら、Fixedの値は想定されます。 Fixed価値の意味論はText/平野[MIME-IMT]に関連している普通です。
A Format value of Flowed indicates that the definition of flowed text (as specified in this memo) was used on generation, and MAY be used on reception.
FlowedのFormat値は、流れるテキスト(このメモで指定されるように)の定義が世代のときに使用されて、レセプションで使用されるかもしれないのを示します。
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/明瞭な内容タイプのパラメタであるので満足している転送コード化が使用したいずれも流れるテキストの処理と無関係であることに注意してください。
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が指定されないか、または値が認識されたa値でない、いいえは想定されます。 FlowedのFormat値のないDelSpの使用は未定義です。 指定されたコネがFormat=が流れたText/平野以外のTextの満足しているタイプであったならメッセージ、DelSp SHOULD NOTを作成するとき。 無視されましたが、中古のコネがFormat=が流れたText/平野以外のTextの満足しているタイプであったならメッセージ、DelSp SHOULDを受けるとき。
This section discusses flowed text; section 6 provides a formal definition.
このセクションは流れるテキストについて論じます。 セクション6は公式の定義を提供します。
Section 5 discusses interoperability.
セクション5は相互運用性について論じます。
Note that this memo describes an on-the-wire format. It does not address formats for local file storage.
このメモがワイヤの形式について説明することに注意してください。 それはローカルファイル格納にどんなアドレス形式もしません。
Gellens Standards Track [Page 5] RFC 3676 Text/Plain Format and DelSp Parameters February 2004
Gellens標準化過程[5ページ]のRFC3676テキスト/明瞭な形式とDelSpパラメタ2004年2月
4.1. Interpreting Format=Flowed
4.1. 解釈形式=は流れました。
If the first character of a line is a quote mark (">"), the line is
considered to be quoted (see Section 4.5). Logically, all quote
marks are counted and deleted, resulting in a line with a non-zero
quote depth, and content. (The agent is of course free to display
the content with quote marks or excerpt bars or anything else.)
Logically, this test for quoted lines is done before any other tests
(that is, before checking for space-stuffed and flowed).
線の最初のキャラクタが引用符(">")であるなら、線が引用されると考えられます(セクション4.5を見てください)。 非ゼロ引用文の深さ、および内容で線をもたらして、すべての引用符が、論理的に、数えられて、削除されます。 (エージェントはもちろん自由に引用符、抜粋バーまたは他の何かがある内容を表示できます。) 論理的に、いかなる他のテストの前にも引用された線のためのこのテストをします。(それがそう、以前、チェックする、スペースで詰められて流れる、)
If the first character of a line is a space, the line has been space-stuffed (see Section 4.4). Logically, this leading space is deleted before examining the line further (that is, before checking for flowed).
線の最初のキャラクタがそうなら、スペース、線はスペースによって詰められています(セクション4.4を見てください)。 さらに線を調べる前に、論理的に、この主なスペースは削除されます。(それがそう、以前、チェックする、流れ、)
If the line ends in a space, the line is flowed. Otherwise it is fixed. The exception to this rule is a signature separator line, described in Section 4.3. Such lines end in a space but are neither flowed nor fixed.
線がスペースに終わるなら、線は終わります。流れました。 さもなければ、それは固定されています。 この規則への例外はセクション4.3で説明された署名区切り線です。 そのような線は、スペースに終わりますが、どちらも流れて、修理されなかったということです。
If the line is flowed and DelSp is "yes", the trailing space immediately prior to the line's CRLF is logically deleted. If the DelSp parameter is "no" (or not specified, or set to an unrecognized value), the trailing space is not deleted.
そして、線がそうである、流れ、「はい」、行CRLFが論理的に削除される前すぐに、DelSpは引きずっているスペースです。 DelSpパラメタが「いいえ」(または、認識されていない値に指定しないか、またはセットしない)であるなら、引きずっているスペースは削除されません。
Any remaining trailing spaces are part of the line's content, but the CRLF of a soft line break is not.
どんな残っている引きずっている空間も行内容の一部ですが、柔らかいラインブレイクのCRLFは一部であるというわけではありません。
A series of one or more flowed lines followed by one fixed line is considered a paragraph, and MAY be flowed (wrapped and unwrapped) as appropriate on display and in the construction of new messages (see Section 4.5).
1つの固定線が支えた一連の1つ以上の流れる線はパラグラフであると考えられて、あるかもしれない、適宜流れる、(包装されて、開けられます)ディスプレー、そして、新しいことの構造が通信させる(セクション4.5を見ます)コネ。
An interpreting agent SHOULD allow for three exceptions to the rule that paragraphs end with a fixed line. These exceptions are improperly constructed messages: a flowed line SHOULD be considered to end the paragraph if it is followed by a line of a different quote depth (see 4.5) or by a signature separator (see 4.3); the end of the body also ends the paragraph.
SHOULDがパラグラフが固定線で終わるという規則への3つの例外のために許容する解釈しているエージェント。 これらの例外は不適切に組み立てられたメッセージです: aは流れました。異なった引用文の深さ(4.5を見る)の線か署名分離符がそれを支えているなら(4.3を見てください)パラグラフを終わらせるために考えられて、SHOULDを裏打ちしてください。 また、ボディーの先はパラグラフを終わらせます。
A line consisting of one or more spaces (after deleting a space acting as stuffing) is considered a flowed line.
1つ以上の空間(詰め物として機能するスペースを削除した後の)から成る線は流れる線であると考えられます。
An empty line (just a CRLF) is a fixed line.
人影のない線(まさしくCRLF)は固定線です。
Note that, for Unicode text, [Annex-14] provides guidance for choosing at which characters to wrap a line.
[別館-14]がユニコードテキストのためにどのキャラクタで線を包装するのを選ぶかための指導を提供することに注意してください。
Gellens Standards Track [Page 6] RFC 3676 Text/Plain Format and DelSp Parameters February 2004
Gellens標準化過程[6ページ]のRFC3676テキスト/明瞭な形式とDelSpパラメタ2004年2月
4.2. Generating Format=Flowed
4.2. 形式=を発生させるのは流れました。
When generating Format=Flowed text, lines SHOULD be 78 characters or shorter, including any trailing white space and also including any space added as part of stuffing (see Section 4.4). As suggested values, any paragraph longer than 78 characters in total length could be wrapped using lines of 72 or fewer characters. While the specific line length used is a matter of aesthetics and preference, longer lines are more likely to require rewrapping and to encounter difficulties with older mailers. (It has been suggested that 66 character lines are the most readable.)
流れるFormat=テキストを作るとき、78のキャラクタ、または、より背の低くて、含んでいるいずれかが引きずっている余白であったならSHOULDを裏打ちして、また、どんなスペースも含んでいるのは詰め物の一部として加えました(セクション4.4を見てください)。 提案された値として、全長における78のキャラクタがそうすることができたよりどんなパラグラフ長い間も、72か、より少ないキャラクタの線を使用することで包装されてください。 長さが使用した特定の線が美意識と好みの問題ですが、より長い線は、再包装するのが必要であり、より年取った郵送者における困難により遭遇しそうです。 (66個のハイライト線が最も読み込み可能であると示唆されました。)
The restriction to 78 or fewer characters between CRLFs on the wire is to conform to [MSG-FMT].
ワイヤの上のCRLFsの間の78か、より少ないキャラクタへの制限は[MSG-FMT]に従うことです。
(In addition to conformance to [MSG-FMT], there is a historical need that all lines, even when displayed by a non-flowed-aware program, will fit in a standard 79- or 80-column screen without having to be wrapped. The limit is 78, not 79 or 80, because while 79 or 80 fit on a line, the last column is often reserved for a line-wrap indicator.)
([MSG-FMT]への順応に加えてすべて立ち並ぶ歴史的な必要性はいます、aから表示すると非、意識していた状態で流れる、プログラム、包装される必要はなくて、意志が規格79か80コラムのスクリーンをうまくはめ込みました。 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. A soft line break is a SP CRLF sequence.
流れるテキスト、発生しているエージェント機密を作成するとき、それは作成して、差し込みは必要であるとして'柔らかい'ラインブレイクです。 柔らかいラインブレイクは単語などの自然なラッピングポイントで加えられます。 柔らかいラインブレイクは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つのテクニックがあります。 RFC2646によって確立されたより古いテクニックは、スペースの発生の後にCRLFを挿入することによって、柔らかいラインブレイクを作成します。 このテクニックで、空間が既に起こるところで柔らかいラインブレイクは可能であるだけです。 これであるときに、テクニックは使用されていて、DelSpパラメタはSHOULDです。使用されてください。 使用されるなら、「いいえ」にそれを設定しなければなりません。
The newer technique, suitable for use even with languages/coded character sets in which the ASCII space character is rare or not used, creates a soft line break by inserting a SP CRLF sequence. When this technique is used, the DelSp parameter MUST be used and MUST be set to "yes". Note that because of space-stuffing (see Section 4.4), when this technique is used and a soft line break is inserted at a point where a SP already exists (such as between words), if the SP CRLF sequence is added immediately before the SP, the pre-existing SP becomes leading and thus requires stuffing. It is RECOMMENDED that agents avoid this by inserting the SP CRLF sequence following the existing SP.
より新しい言語/コード化文字集合のためにさえASCII間隔文字がまれであるか、または使用されていない使用に適したテクニックは、SP CRLF系列を挿入することによって、柔らかいラインブレイクを作成します。 このテクニックが使用されているとき、DelSpパラメタを使用しなければならなくて、「はい」に設定しなければなりません。 スペース詰め物(セクション4.4を見る)のために、このテクニックが使用されていて、SP CRLF系列がSPの直前加えられるなら柔らかいラインブレイクがSPが既に存在するポイント(単語などの)で挿入されるとき、先在のSPが、主になって、その結果、詰めるのを必要とすることに注意してください。 エージェントが既存のSPに続いて、SP CRLF系列を挿入することによってこれを避けるのは、RECOMMENDEDです。
Generating agents MAY use either method within each Text/Plain body part.
エージェントを発生させると、方法はそれぞれのText/平らな身体の部分の中で使用されるかもしれません。
Gellens Standards Track [Page 7] RFC 3676 Text/Plain Format and DelSp Parameters February 2004
Gellens標準化過程[7ページ]のRFC3676テキスト/明瞭な形式とDelSpパラメタ2004年2月
Regardless of which technique is used, a generating agent SHOULD NOT insert a space in an unnatural location, such as into a word (a sequence of printable characters, not containing spaces, in a language/coded character set in which spaces are common). If faced with such a word which exceeds 78 characters (but less than 998 characters, the [SMTP] limit on line length), the agent SHOULD send the word as is and exceed the 78-character limit on line length.
どのテクニックが使用されているかにかかわらず、発生しているエージェントSHOULD NOTは不自然な位置にスペースを挿入します、単語(空間が一般的である言語/コード化文字集合における空間を含まない印刷可能なキャラクタの系列)などのように。 78のキャラクタ(しかし、998未満のキャラクタ、行長における[SMTP]限界)を超えているそのような単語が直面されているなら、エージェントSHOULDは行長でそのままで知らせを送って、78キャラクタの限界を超えています。
A generating agent SHOULD:
発生しているエージェントSHOULD:
o Ensure all lines (fixed and flowed) are 78 characters or fewer in
length, counting any trailing space as well as a space added as
stuffing, but not counting the CRLF, unless a word by itself
exceeds 78 characters.
o すべての線(修理して、流れる)がそれほど長さが78のキャラクタであることを確実にしてください、また、CRLFを詰めますが、数えないとして加えられたスペースにどんな引きずっているスペースもみなして、それ自体で単語が78のキャラクタを超えていない場合。
o Trim spaces before user-inserted hard line breaks.
o ユーザによって挿入された強硬路線が壊れる前に空間を整えてください。
A generating agent MUST:
発生しているエージェントはそうしなければなりません:
o Space-stuff lines which start with a space, "From ", or ">".
o スペースものがスペースでどの始めを裏打ちするか、「」 ">"から。
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、発生として見なされると美しくより嬉しいエージェントが、">"の直前包装するのを避けるかもしれない、「」 スペースから。
(See Sections 4.4 and 4.5 for more information on space-stuffing and quoting, respectively.)
(スペース詰め物に関する詳しい情報と引用に関してそれぞれセクション4.4と4.5を見てください。)
A Format=Flowed message consists of zero or more paragraphs, each containing one or more flowed lines followed by one fixed line. The usual case is a series of flowed text lines with blank (empty) fixed lines between them.
流れるFormat=メッセージはゼロか、より多くのパラグラフから成ります、それぞれ1つの固定線が支えた1つ以上の流れる線を含んでいて。 普通のケースはそれらの間には、空白(空の)の固定線がある一連の流れるテキスト線です。
Any number of fixed lines can appear between paragraphs.
いろいろな固定線がパラグラフの間に現れることができます。
When placing soft line breaks in a paragraph, generating agents MUST NOT place them in a way that causes any line of the paragraph to be a signature separator line, because paragraphs cannot contain signature separator lines (see Sections 4.3 and 6).
置く柔軟路線がパラグラフを使いならすとき、エージェントを発生させると、彼らはパラグラフのどんな線も署名区切り線であることを引き起こす方法で置かれてはいけません、パラグラフが署名区切り線を含むことができないので(セクション4.3と6を見てください)。
[Quoted-Printable] encoding SHOULD NOT be used with Format=Flowed unless absolutely necessary (for example, non-US-ASCII (8-bit) characters over a strictly 7-bit transport such as unextended [SMTP]). In particular, a message SHOULD NOT be encoded in Quoted- Printable for the sole purpose of protecting the trailing space on flowed lines unless the body part is cryptographically signed or encrypted (see Section 4.6).
[引用されて印刷可能な] SHOULD NOTをコード化して、絶対に必要でない場合(例えば、「非-広げ」られるような厳密に7ビットの輸送[SMTP]の上の非米国のASCII(8ビット)キャラクタ)流れたFormat=と共に使用されてください。 特定のaメッセージSHOULD NOTでは、身体の部分が暗号でサインされるか、またはコード化されない場合(セクション4.6を見てください)流れる線の引きずっているスペースを保護する唯一の目的のために印刷可能なQuotedでコード化されてください。
Gellens Standards Track [Page 8] RFC 3676 Text/Plain Format and DelSp Parameters February 2004
Gellens標準化過程[8ページ]のRFC3676テキスト/明瞭な形式とDelSpパラメタ2004年2月
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=の意図が流れた、ユーザエージェントを純粋で、生のText/明瞭(少しも解読のない)として見なされると非不愉快な流れるテキストは発生させることになっていることができます。 Quoted印刷可能の使用はこれを妨げます、そして、Format=が注いだ原因がエンドユーザによって拒絶されますように。
4.3. Usenet Signature Convention
4.3. Usenet署名コンベンション
There is a long-standing convention in Usenet news which also commonly appears in Internet mail of using "-- " as the separator line between the body and the signature of a message. When generating a Format=Flowed message containing a Usenet-style separator before the signature, the separator line is sent as-is. This is a special case; an (optionally quoted or quoted and stuffed) line consisting of DASH DASH SP is neither fixed nor flowed.
また、メッセージのボディーと署名の間の区切り線として「--」を使用するインターネット・メールに一般的に現れるUsenetニュースにおける長年のコンベンションがあります。 署名の前にUsenet-スタイル分離符を含む流れるFormat=メッセージを発生させるとき、そのままで区切り線を送ります。 これは特別なそうです。 DASH DASH SPから成る(任意に引用されるか、または引用されていて詰められる)の線はどちらも修理して、流れなかったということです。
Generating agents MUST NOT end a paragraph with such a signature line.
エージェントを発生させると、パラグラフはそのような署名欄で終わってはいけません。
A receiving agent needs to test for a signature line both before the test for a quoted line (see Section 4.5) and also after logically counting and deleting quote marks and stuffing (see Section 4.4) from a quoted line.
受信エージェントは、引用された線(セクション4.5を見る)のためのテストの前と引用された線から引用符と詰め物(セクション4.4を見る)を論理的に数えて、削除した後にも署名欄がないかどうかテストする必要があります。
4.4. Space-Stuffing
4.4. スペース詰め物
In order to allow for unquoted lines which start with ">", and to protect against systems which "From-munge" in-transit messages (modifying any line which starts with "From " to ">From "), Format=Flowed provides for space-stuffing.
形式=は流れました。">"から始まる引用を終わっている線を考慮して、システムに対して「munge」からのトランジットにおけるどのメッセージを保護するか、(いずれもどの始めを裏打ちする変更、「」、「>、」、)、スペースで詰めるのに提供します。
Space-stuffing adds a single space to the start of any line which needs protection when the message is generated. On reception, if the first character of a line is a space, it is logically deleted. This occurs after the test for a quoted line (which logically counts and deletes any quote marks), and before the test for a flowed line.
スペース詰め物はメッセージが発生するとき保護を必要とするどんな線の始まりにもシングルスペースを加えます。 レセプションに関して、線の最初のキャラクタがそうであるなら、スペースであり、削除されて、それは論理的にそうです。 これは引用された線(どんな引用符も論理的に数えて、削除する)と、流れる線のためのテストの前にテストの後に起こります。
On generation, any unquoted lines which start with ">", and any lines which start with a space or "From " MUST be space-stuffed. Other lines MAY be space-stuffed as desired.
または、世代のときにいずれも">"から始まる線、およびスペースから始まるどんな線にも引用を終わらせた、「」 必須から、スペースで、詰められてください。 他の線はスペースによって同じくらい必要な状態で詰められるかもしれません。
(Note that space-stuffing is conceptually similar to dot-stuffing as specified in [SMTP].)
(スペース詰め物が概念的に[SMTP]の指定されるとしてのドット詰め物と同様であることに注意してください。)
4.5. Quoting
4.5. 引用
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 ">"
Formatでは、=は流れて、正準な引用文のインディケータ(または、引用符)は1個以上の近い角ブラケット(">")のキャラクタです。 引用文のインディケータから始まる線は引用されていると考えられます。 ">"の数
Gellens Standards Track [Page 9] RFC 3676 Text/Plain Format and DelSp Parameters February 2004
Gellens標準化過程[9ページ]のRFC3676テキスト/明瞭な形式とDelSpパラメタ2004年2月
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.
線の始めのキャラクタは引用文の深さを指定します。 また、引用される流れる台詞が特別な取り扱いを必要とするかもしれない、ディスプレー、そして、新しいメッセージにコピーされたいつ?。
When creating quoted flowed lines, each such line starts with the quote indicator.
引用された流れる線を作成するとき、そのような各線は引用文のインディケータから始まります。
Note that because of space-stuffing, the lines
>> Exit, Stage Left
and
>>Exit, Stage Left
are semantically identical; both have a quote-depth of two, and a
content of "Exit, Stage Left".
線のスペース詰め物、>>Exit、Stage Left、および>>Exitのために、Stage Leftが意味的に同じであることに注意してください。 両方には、2の引用文深さ、および「出てください、そして、左を上演してください」の内容があります。
However, the line
> > Exit, Stage Left
is different. It has a quote-depth of one, and a content of
"> Exit, Stage Left".
しかしながら、線>>Exitであり、Stage Leftは異なっています。 それには、1の引用文深さ、および「>出口、上手」の内容があります。
When generating quoted flowed lines, an agent needs to pay attention to changes in quote depth. All lines of a paragraph MUST be unquoted, or else they MUST all be quoted and have the same quote depth. Therefore, whenever there is a change in quote depth, or a change from quoted to unquoted, or change from unquoted to quoted, the line immediately preceding the change MUST NOT be a flowed line.
引用された流れる線を発生させるとき、エージェントは、引用文の深さの変化に注意を向ける必要があります。 パラグラフのすべての線に引用を終わらせなければならないか、彼らは、すべて引用されて、同じくらいに深さを引用させなければなりません。 したがって、引用を終わられるのから引用されるのに引用を終わるか、または変化するように引用文の深さの変化、または引用されるのからの変化があるときはいつも、すぐに変化に先行する線は流れる線であるはずがありません。
If a receiving agent wishes to reformat flowed quoted lines (joining and/or wrapping them) on display or when generating new messages, the lines SHOULD be de-quoted, reformatted, and then re-quoted. To de- quote, the number of close angle brackets in the quote indicator at the start of each line is counted. To re-quote after reformatting, a quote indicator containing the same number of close angle brackets originally present are prefixed to each line.
受信エージェントが、(それらを接合する、そして/または、包装します)がディスプレーされていることを再フォーマットの流れる引用された線に願うか、または新しいメッセージ、反-引用されて、再フォーマットされて、次に再引用された線SHOULDを発生させるとき。 反-引用文に、それぞれの線の始めの引用文のインディケータにおける、近い角ブラケットの数は数えられます。 再フォーマットした後の再引用文、同じくらい含む引用文のインディケータに、元々の現在の近い角ブラケットの数は各線へ前に置かれています。
On reception, if a change in quote depth occurs on a flowed line, this is an improperly formatted message. The receiver SHOULD handle this error by using the 'quote-depth-wins' rule, which is to consider the paragraph to end with the flowed line immediately preceding the change in quote depth.
レセプションでは、引用文の深さの変化が流れる線の上に起こるなら、これは不適切にフォーマットされたメッセージです。 受信機SHOULDは、引用文の深さの変化に先行しながらパラグラフがすぐに流れる線で終わると考えることである'引用文の深さ勝利'規則を使用することによって、この誤りを扱います。
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が深層を引用するのを保証しなければならないときはいつも、線が、より初期であることは流れました、そして、(スペースに終わりません)そこの流れる線にSHOULDに当たる受信機がパラグラフの最終ラインとしてそれを扱います。
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を示す'#')の以下の系列を考えてください:
Gellens Standards Track [Page 10] RFC 3676 Text/Plain Format and DelSp Parameters February 2004
Gellens標準化過程[10ページ]のRFC3676テキスト/明瞭な形式とDelSpパラメタ2004年2月
> 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?#
>、なんじ、とてもひどいスポンジ状のめまいがする目をした無作法*>reeky小妖精皮膚をした鳩卵!*<。--- 問題---素朴な飾り綱腹をしたミルク肝をした*>>陰気な夢想活動していない頭の短い尾!#>のThouの誤った愚かさで堕落しているspleenyの>>よろめき熟している*>>>は猫いらずに「非-口輪をかけ」ました!#>>>>Henceforth、コード化スタイルは厳密にであることです。<>>、なんじ、大文字だけの使用を含んでいて、実施された*>>>>; #>>>>>Iが>>が最近流行に合わせるコード化*>>>において固守の不足に気付いた、#>>>>>>Any苦情?#
The second line ends in a soft line break, even though it is the last line of the one-deep quote block. The question then arises as to how this line is to be interpreted, considering that the next line is the first line of the two-deep quote block.
セカンドラインは柔らかいラインブレイクに終わります、それが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.
1つの引用されて、流れるセクションであるとみなされながら、最初の2における結果引用文深さ勝利に従って処理されるとを超えた例のテキストは立ち並んでいます、1の引用文の深さで。 3番目と4番目の線は2の引用文の深さがある引用されて、流れるセクションになります。
A generating agent MUST NOT create this situation; a receiving agent SHOULD handle it by giving preference to the quote depth.
発生しているエージェントはこの状況を作成してはいけません。 SHOULDが引用文の深さに優先を与えながらそれを扱う受信エージェント。
4.6. Digital Signatures and Encryption
4.6. デジタル署名と暗号化
If a message is digitally signed or encrypted it is important that cryptographic processing use the same text for signature verification and/or decryption as was used for signature generation and/or encryption. Since the use of format=flowed allows text to be altered (by adding or removing line breaks and trailing spaces) between composition and transmission, and between reception and display, interoperability problems or security vulnerabilities may arise if originator and recipient do not both use the on-the-wire format for cryptographic processing.
メッセージがデジタルにサインされるか、またはコード化されるなら、暗号の処理が署名世代、そして/または、暗号化に使用された署名照合、そして/または、復号化に同じテキストを使用するのは、重要です。 形式=の使用が流れたので、テキストが構成とトランスミッションの間で変更されるのを(ラインブレイクと引きずっている空間を加えるか、または取り除くことによって)許容して、創始者と受取人が暗号の処理にともにワイヤの形式を使用しないなら、レセプションと表示か、相互運用性問題かセキュリティの脆弱性の間に起こるかもしれません。
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.
形式=の間の相互作用の含意が流れて、使用形式=がサインされたそして/または、コード化されたメッセージに関連して流れる前に、どんな特定の暗号の過程も、暗号の処理の詳細によって、理解されるべきです。
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]が、「cleartext署名が計算されるとき、どんな行の終わりのどんな引きずっている空白(空間、およびタブ、0×09)も無視されます」と指定することに(セクション7.1で)注意してください。
Gellens Standards Track [Page 11] RFC 3676 Text/Plain Format and DelSp Parameters February 2004
Gellens標準化過程[11ページ]のRFC3676テキスト/明瞭な形式とDelSpパラメタ2004年2月
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.
したがって、それは、トランジットで形式=が流れたと言い足すために、通常のバニラPGP([OpenPGP-MIME]でない)が修理された形式=へのヘッダーがメッセージにサインしたのが可能であり、検出されるこの添加なしで任意の引きずっている間隔文字を言い足すでしょう。 これはそれの支持された形式=が流れたクライアントによる記事の表現を変えるでしょう。
Therefore, the use of [OpenPGP] with format=flowed messages is strongly discouraged. [OpenPGP-MIME] is recommended instead.
したがって、流れる形式=メッセージがある[OpenPGP]の使用は強くお勧めできないです。 [OpenPGP-MIME]は代わりにお勧めです。
4.7. Examples
4.7. 例
The following example contains three paragraphs:
以下の例は3つのパラグラフを含んでいます:
`Take some more tea,' the March Hare said to Alice, very
earnestly.
'撮影それ以上の紅茶'、非常に本気でアリスに言われた3月のHare。
`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.'
Hatterは、'あなたは、LESSを取ることができないと言っています'と言いました: 'MOREを取るのは無より非常に簡単です'。
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.'#
3月のHareは、'それ以上の紅茶を取ってください'と本気でアリス、まさしくその*に言いました。##アリスは、怒っているトーンで'私には、何もまだありません'と返答して、'*したがって、私はさらに取ることができません'。##Hatterは、'あなたは、LESSを取ることができないと言っています'と言いました: 'それは無よりMOREを取りやすいまさしくその*です'、#
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.#
>>>はそれ以上の紅茶を取ります。#>>Iには、何もまだありません、したがって、私はさらに取ることができません。#取ることができないあなたがLESS、それのまさしくその小休止を言っている>が無より*>MOREを取る、#
5. Interoperability
5. 相互運用性
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
流れる線が修理されるのから区別できない線にすぎないので、Format=が流れたと認めないソフトウェアが正常なText/平野(それらが何であるかということである)として流れる線を扱います。 したがって、形式=は流れました。
Gellens Standards Track [Page 12] RFC 3676 Text/Plain Format and DelSp Parameters February 2004
Gellens標準化過程[12ページ]のRFC3676テキスト/明瞭な形式とDelSpパラメタ2004年2月
interoperates with older clients, although flowed lines will have trailing white space inserted.
流れる線で引きずっている余白を挿入するでしょうが、より年取ったクライアントと共に共同利用します。
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=を扱うかが流れて、スペース詰め物が逆にされるということであり、その結果、メッセージが変わりがなく見えるなら。 流れるFormat=意志を意識していないエージェントはもちろん少しのスペース詰め物も元に戻しません。 または、いくつかの線の上に主なスペースがある状態で流れるその結果、Format=メッセージが現れるかもしれない、(スペース、引用文のインディケータでない">"から始めるもの、「」、) スペースで詰めるのを必要とする線がめったに現れないで、非逆にされたスペース詰め物の美的な結果が最小限ので、これは重大な問題でないと予想されます。
If some lines begin with one or more spaces, the generating agent MAY space-stuff all lines, to maintain the relative indentation of the lines when viewed by clients which are not aware of Format=Flowed.
いくつかの線が1つ以上の空間、エージェント5月のスペースものがすべて裏打ちする発生で始まるなら、線の相対的な刻み目を維持するために、クライアントによって見られると、どれがFormat=を意識していないかは流れました。
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=はいで発生して、クライアントによって受け取られて、どれがFormat=を意識しているかが、流れますが、DelSpパラメタを知っていないというメッセージには、柔軟路線の取り外しが壊れた後に残っている余分な空白があるでしょう。 空間が一般的である言語/コード化文字集合におけるテキストを作るとき、したがって、発生しているエージェントはいつもDelSp=方法を全く使用するかもしれないというわけではありません。
Hand-aligned text, such as ASCII tables or art, source code, etc., SHOULD be sent as fixed, not flowed lines.
ASCIIテーブルや芸術、ソースコードなどのような手で並べられたテキストSHOULDは修理されるとして送られて、流れませんでした。線。
6. ABNF
6. ABNF
The constructs used in Text/Plain; Format=Flowed body parts are described using Augmented Backus-Naur Form [ABNF], including the core rules defined in Appendix A.
Text/平野の中で使用された構造物。 流れる身体の形式=部分は、Appendix Aで定義されたコア規則を含むAugmented BN記法[ABNF]を使用することで説明されます。
Note that the SP (space) and ">" characters are encoded according to the charset parameter.
charsetパラメタによると、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 ) /
流れるボディー=*(パラグラフ/固定線/sig-sep)パラグラフは1つの*流れる線の固定線と等しいです。 または、パラグラフのすべての線に引用を終わらせなければならない、。 同じ引用文の深さ流れる線=(流れる線流れる線qt/unqt)流れCRLF流れる線qt=引用文を持ってください、(詰め物、詰められて流れる、)、/、「非-物質」に流れる、)、流れる線unqtが等しい、(詰め物、詰められて流れる、)、/「非-物質」に流れる詰められて流れる=*テキスト炭「非-物質」に流れる=非spな引用文*テキスト炭固定線=固定線固定線qt/unqt固定線qtが引用文と等しい、(詰め物、詰められて修理される、)、/
Gellens Standards Track [Page 13] RFC 3676 Text/Plain Format and DelSp Parameters February 2004
Gellens標準化過程[13ページ]のRFC3676テキスト/明瞭な形式とDelSpパラメタ2004年2月
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
「非-物質」に修理される、) CRLF固定線unqt=(詰められて固定されたか「非-物質」に固定された) CRLF詰められて固定された=非sp unstuffedが固定された*テキスト炭=非spの引用文[*テキスト炭の非sp]sig-sep=[引用します[詰めます]]「--」SP CRLF引用符=">"引用文=1*引用符詰め物はSPと等しいです。 スペースで詰められて、世代加えられる、。 必要で、レセプション流動=SPで削除される。 CRLFの前のスペースは流れる線を示します。 DelSpがはいと等しいなら、スペースは世代のときに加えられました。 非レセプション非spの引用文=<NUL以外のどんなキャラクタ、CR、LF、SP、引用符>非sp=非spの引用文も/引用符テキスト炭=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=本体はいろいろなパラグラフ、固定線、そして/または、署名区切り線から成ります。 パラグラフは、少なくとも1つの流れる線を必要として、固定線によって終えられます。 パラグラフを終える固定線はパラグラフの一部です。 (テキストで説明されたこれへのいくつかの例外があります。)
Without at least one flowed line, there is a series of fixed lines, each independent. There is no paragraph.
少なくとも1つの流れる線がなければ、一連の固定線、各独立者がいます。 パラグラフが全くありません。
With at least one flowed line, there is a paragraph, and the received lines can be reformed and flowed to fit the display window size. This can only be done if the lines are part of a logical grouping, the paragraph.
少なくとも1つの流れる線で、パラグラフがあって、容認された線は、改革できて、表示ウィンドウサイズに合うように流れました。 線が論理的な組分け、パラグラフの一部である場合にだけこれができます。
Note that the definitions of flowed-line and sig-sep are potentially ambiguous: a signature separator line matches both, but is treated as a signature separator line and not a flowed line.
流れる線とsig-sepの定義が潜在的にあいまいであることに注意してください: 署名区切り線は、両方を合わせますが、流れる線ではなく、署名区切り線として扱われます。
7. Failure Modes
7. 故障モード
7.1. Trailing White Space Corruption
7.1. 引きずっている余白不正
There are systems in existence which alter trailing whitespace on messages which pass through them. Such systems may strip, or in rarer cases, add trailing whitespace, in violation of RFC 2821 [SMTP] Section 4.5.2.
引きずっている空白を変更する現存するシステムがそれらを通り抜けるメッセージにあります。 そのようなシステムが剥取られるかもしれませんか、またはもっともまれな場合には、RFC2821[SMTP]部4.5の.2を違反して引きずっている空白を加えてください。
Stripping trailing whitespace has the effect of converting flowed lines to fixed lines, which results in a message no worse than if Format=Flowed had not been used.
引きずっている空白が=がFormatであるなら流れたほど悪くないメッセージのその結果が使用されていなかった固定線に流れる線を変換しながら効果を持っているストリップ。
Gellens Standards Track [Page 14] RFC 3676 Text/Plain Format and DelSp Parameters February 2004
Gellens標準化過程[14ページ]のRFC3676テキスト/明瞭な形式とDelSpパラメタ2004年2月
Adding trailing whitespace to a Format=Flowed message may result in a malformed display or reply.
メッセージは奇形の表示か回答をもたらして、Format=への引きずっている空白が流れたと言い足すかもしれません。
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.
回避がしたがって、Formatを定義することであることが可能な1つは流れる線を示すのにどちらかか2つの引きずっている間隔文字を使用するために流れる線と等しいです、総行長が変であるように。 しかしながら、今日そのようなシステムへの不足を考える場合、それは加えられた複雑さの価値がありません。
8. Security Considerations
8. セキュリティ問題
Any security considerations which apply to Text/Plain also apply to Text/Plain with Format=Flowed.
また、Format=が流れて、Text/平野に適用されるどんなセキュリティ問題もText/平野に適用されます。
Section 4.6 discusses the interaction between Format=Flowed and digital signatures or encryption.
セクション4.6は流れてデジタルのFormat=署名か暗号化の間の相互作用について論じます。
9. IANA Considerations
9. IANA問題
IANA has added a reference to this specification in the Text/Plain Media Type registration.
IANAはText/明瞭なメディアType登録におけるこの仕様の参照を加えました。
10. Internationalization Considerations
10. 国際化問題
The line wrap and quoting specifications of Format=Flowed may not be suitable for certain charsets, such as for Arabic and Hebrew characters that read from right to left. Care needs to be taken in applying format=flowed in these cases, as format=fixed combined with [quoted-printable] encoding may be more suitable.
線包装とFormat=の仕様が流れたのを引用するのはあるcharsetsに適当でないかもしれません、左への権利から読むアラビアの、そして、ヘブライ人のキャラクタなどのように。 形式=を適用しながら中に入れるべき注意の必要性はこれらの場合で流れました、[引用されて印刷可能]のコード化に結合されていた状態で修理された形式=が、より適当であるかもしれないので。
The DelSp parameter was added specifically to permit Format=Flowed to be used with languages/coded character sets in which the ASCII space character is rarely used, or not used at all.
DelSpパラメタは、特に全くASCII間隔文字がめったに使用されない言語/コード化文字集合と共に使用されるために流れるか、または使用されないFormat=を可能にするために加えられました。
11. Acknowledgments
11. 承認
The DelSp parameter was developed during a series of discussions among a number of people, including Harald Alvestrand, Grant Baillie, Ian Bell, Steve Dorner, Patrik Faltstrom, Eric Fischer, Ned Freed, Alexey Melnikov, John Myers, and Pete Resnick.
DelSpパラメタは多くの人々での一連の議論の間、開発されました、ハラルドAlvestrand、グラントBaillie、イアン・ベル、スティーブ・デルナー、パトリクFaltstrom、エリック・フィッシャー、ネッド・フリード、Alexeyメリニコフ、ジョン・マイアーズ、およびピートレズニックを含んでいて。
Gellens Standards Track [Page 15] RFC 3676 Text/Plain Format and DelSp Parameters February 2004
Gellens標準化過程[15ページ]のRFC3676テキスト/明瞭な形式とDelSpパラメタ2004年2月
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.
RFC2646への修正と明確化とこのドキュメントの早めのバージョンは数人によって指摘されました、アダム・コステロ、ユッタDegener、トニー・ハンセン、サイモンJosefsson、ダン・コーン、Ragho Mahalingam、キース・ムーア、グレッグTroxel、およびダンWingを含んでいて。
I'm told that NeXT's mail application used a very similar mechanism (without support for non-Western languages) in 1992.
私はNeXTのメールアプリケーションが1992年に非常に同様のメカニズム(非西洋の言語のサポートのない)を使用したと言われます。
12. Normative References
12. 引用規格
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF
for Syntax Specifications: ABNF", RFC 2234,
November 1997.
エド[ABNF]クロッカー、D.、P.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997.
[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[MIME-IMT] Freed, N. and N. Borenstein, "Multipurpose
Internet Mail Extensions (MIME) Part Two: Media
Types", RFC 2046, November 1996.
解放された[MIME-IMT]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は2を分けます」。 「メディアタイプ」、RFC2046、1996年11月。
[Quoted-Printable] Freed, N. and N. Borenstein, "Multipurpose
Internet Mail Extensions (MIME) Part One: Format
of Internet Message Bodies", RFC 2045, November
1996.
[引用されて印刷可能な] N.とN.Borenstein、解放されていて、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
13. Informative References
13. 有益な参照
[Annex-14] Unicode Standard Annex #14, "Line Breaking
Properties"
<URL:http://www.unicode.org/unicode/reports/tr14/>
[別館-14]ユニコード規格別館#14、「線の壊れている特性」<URL: http://www.unicode.org/unicode/reports/tr14/ >。
[MSG-FMT] Resnick, P., Ed., "Internet Message Format", RFC
2822, April 2001.
[MSG-FMT] レズニック、P.、エド、「インターネットメッセージ・フォーマット」、RFC2822、4月2001日
[OpenPGP] Callas, J., Donnerhacke, L., Finney, H. and R.
Thayer, "OpenPGP Message Format", RFC 2440,
November 1998.
[OpenPGP] カラスとJ.とDonnerhackeとL.とフィニーとH.とR.セイヤー、「OpenPGPメッセージ・フォーマット」、RFC2440、1998年11月。
[OpenPGP-MIME] Elkins, M., "MIME Security with Pretty Good
Privacy (PGP)", RFC 2015, October 1996.
[OpenPGP-MIME] エルキンズ、M.、「プリティ・グッド・プライバシ(PGP)があるMIMEセキュリティ」、RFC2015、1996年10月。
Elkins, M., Del Torto, D., Levien, R. and J.
Roessler, "MIME Security with OpenPGP", RFC 3156,
August 2001.
エルキンズとM.とデルTortoとD.とレヴィエンとR.とJ.Roessler、「OpenPGPがあるMIMEセキュリティ」、RFC3156、2001年8月。
Gellens Standards Track [Page 16] RFC 3676 Text/Plain Format and DelSp Parameters February 2004
Gellens標準化過程[16ページ]のRFC3676テキスト/明瞭な形式とDelSpパラメタ2004年2月
[Rich] Resnick, P. and A. Walker, "The text/enriched MIME
Content-type", RFC 1896, February 1996.
[豊かな] レズニックとP.とA.ウォーカー、「テキスト/豊かにされたMIME文書内容」、RFC1896、1996年2月。
[SMTP] Klensin, J., Ed., "Simple Mail Transfer Protocol",
RFC 2821, April 2001.
[SMTP] Klensin、J.、エド、「簡単なメール転送プロトコル」、RFC2821、4月2001日
Gellens Standards Track [Page 17] RFC 3676 Text/Plain Format and DelSp Parameters February 2004
Gellens標準化過程[17ページ]のRFC3676テキスト/明瞭な形式とDelSpパラメタ2004年2月
Appendix A: Changes from RFC 2646
付録A: RFC2646からの変化
Substantive:
実名詞:
o Added DelSp parameter to handle languages and coded character sets
in which space is less common or not used.
o Updated text on generating and interpreting to accommodate the
DelSp parameter.
o Changed the limits of 79 or 80 to be 78 in conformance with RFC
2822.
o Added text on generating to clarify that the 78-character limit
includes trailing white space and stuffing.
o Changed sig-sep in ABNF to allow stuffing.
o Changed fixed-line to allow empty lines in ABNF.
o Added explanatory text following ABNF.
o Moved text from Abstract to new Introduction; rewrote Abstract.
o Moved interoperability text to new section, and updated.
o Clarified Security Considerations.
o Text on digital signatures now discusses that OpenPGP ignores
trailing white space.
o Mention Unicode Annex 14.
o Added mention of quoting to Abstract and Introduction.
o Deleted line analysis table.
o Added recommendations for OpenPGP and OpenPGP-MIME.
o Rewrote ABNF rules to remove most ambiguity and note remaining
case.
o Added note that c-t-e is irrelevant to flowed text processing.
o Added text indicating that end of data terminates a paragraph.
o Moved sig-sep out of fixed-line ABNF.
o Changed some SHOULDs to MUSTs (space-stuffing, quoted paragraphs).
o Added note to ABNF that space and ">" are encoded according to
charset.
o Mentioned exceptions in section on interpreting.
o Clarified and made consistent treatment of signature separator
lines.
o 言語を扱う付記されたDelSpパラメタとスペースがそれほど一般的でないコード化文字集合はRFC2822との順応に. 発生とDelSpパラメタ. o Changedが78になるように79か80の限界を収容するように解釈することに関するo Updatedテキストを使用しました; ABNF要約から新しいIntroductionまでのo Movedテキストに従って、はっきりさせる78キャラクタの限界が詰め物許容するためには固定線Changedが空にする○を許容するためにABNFで余白と詰め物o Changed sig-sepを引きずるのを含んでいる発生に関するo AddedテキストはABNF oでAddedの説明しているテキストを裏打ちします。 要約o Moved相互運用性テキストを新しいセクションに書き直して. デジタル署名でのClarified Security Considerations o Textが現在議論するOpenPGPがDeleted線分析テーブル OpenPGPとOpenPGP-MIME o Rewrote ABNF規則がほとんどのあいまいさを取り除いて、残っているケースに注意するというo Added推薦を要約とIntroduction oに引用しながら引きずっている余白Annex14o Addedが言及するo Mentionユニコードを無視する○をアップデートしました; o Addedは、c t eが流れるテキスト処理と無関係であることに注意します。データのその終わりを示すo AddedテキストがMUSTs(スペース詰め物、引用されたパラグラフ)charset oに従ってスペースと">"がコード化されるというABNFへのo AddedメモへのいくつかのSHOULDsが、解釈oのセクションの例外がはっきりさせたと言及した固定線ABNF o Changedからの. o Moved sig-sepをパラグラフで終えます、そして、一貫しているのに作られていて、署名分離符の処理は立ち並んでいます。
Editorial:
社説:
o Added mention of NeXT's mail application to Acknowledgments. o Updated Acknowledgments. o Updated [SMTP] reference to 2821. o Added Notices. o Split References into Normative and Informative. o Improved text wording in some areas. o Standardize on "quote depth", not "quoting depth". o Moved section on interpreting before section on generating. o Reworded non-normative "should"s. o Noted meaning of "paragraph".
o Acknowledgments○ Updated Acknowledgments2821 「引用の深さ」 発生「パラグラフ」のo非標準の“should"s.o Noted Reworded意味のセクションの前で解釈するところのo Moved部ではなく、NormativeとInformativeいくつかの領域に「引用文の深さ」の. o Standardizeを言い表すo Improvedテキストへのo Added Notices o Split Referencesのo Updated[SMTP]参照にNeXTのメールアプリケーションの言及を追加しました。
Gellens Standards Track [Page 18] RFC 3676 Text/Plain Format and DelSp Parameters February 2004
Gellens標準化過程[18ページ]のRFC3676テキスト/明瞭な形式とDelSpパラメタ2004年2月
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=を可能にするために加えられました。 初めは、クラッジについて拒絶され過ぎましたが、DelSpメカニズムは選択されました、異なったテクニックが多くで提案しました、とクライアントの中の最大限のインターオペラビリティのためにどれがこの仕様もRFC2646も支持しないか、そして、この仕様ではなく、RFC2646を支持するもの、およびこの仕様を支持するものを許容します。 このセットは、空間が一般的であり、それらが珍しい言語/コード化文字集合を扱うものが掛けられるか、または使用されません。
Author's Address
作者のアドレス
Randall Gellens QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121 USA
ランドル・Gellensのクアルコムの法人組織の5775モアハウス・Driveカリフォルニア92121サンディエゴ(米国)
Phone: +1 858 651 5115 EMail: randy@qualcomm.com
以下に電話をしてください。 +1 5115年の858 651メール: randy@qualcomm.com
Gellens Standards Track [Page 19] RFC 3676 Text/Plain Format and DelSp Parameters February 2004
Gellens標準化過程[19ページ]のRFC3676テキスト/明瞭な形式とDelSpパラメタ2004年2月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Gellens Standards Track [Page 20]
Gellens標準化過程[20ページ]
一覧
スポンサーリンク
