[28] 仕様書における助動詞は、その文が適合性の要件を記述していることと、 その種別を表しています。

[52] 例えば、「img 要素には src 属性を指定しなければなりません」という文は、 助動詞 なければなりません (MUST) が使われていますから、 適合するためには「img 要素には src 属性を指定」することが要求されることを表しています。

[53] このような助動詞のない文は、事実の文などと呼ばれ、 要件ではなく単なる説明に過ぎません。

[88] いくつかの流儀がありますが、 インターネットでは RFC 2119 方式が広く採用されています。

仕様書

助動詞の一覧

[29] 要件を表す助動詞

意味

[48] 助動詞は、その文が当該仕様においてどのような意味を持つかを表すものです。 例えば「○○しなければならないMUST」とあればそれが必須の条件であることを表し、 それに従わないのは仕様違反です。 「○○しても構わないMAY」とあればそれが認められる動作 (の1つ) であることを表しています。 詳細は各助動詞の項

[49] 仕様の記述に利用する助動詞の選択や位置付けは、標準化団体や仕様書によって異なっています。 Web を含むインターネット関連技術の仕様書の多くは、 RFC 2119 が規定する助動詞を採用しています。しかしその中でも、 WHATWG 等の近代的な Web 関連の仕様書は助動詞を用いた規定の記述を徹底しているのに対し、 IETF は事実の文を用いた規定を多用し助動詞は限定的にしか用いないといった様式の違いがあります。

RFC 2119 キーワード

[95] RFC 2119 (BCP 14) Key words for use in RFCs to Indicate Requirement Levels は、 要件を表すキーワードRFC 2119キーワード (助動詞) を定義する RFC です。

[96] 適合性を記述するための共通の言語として、 IETF の文書に限らず、 W3C や WHATWG のような他の標準化団体の仕様書、 Web 関連を中心とする私的な仕様書など含め広く用いられています。 厳密な意味の仕様書の他に、 標準開発の要件を表す文書や標準化団体の憲章のような関連文書でも使われることがあります。

[102] 次のキーワードが定義されています >>2, >>22。

[112] RFC 2119 キーワード

[114] Infra Standard は、 このうち must, must not, should, may のみ使うべきencouragedencourageとしています >>22。

[115] 実際 Web 系の仕様書はそのような傾向にあり、 Infra Standard はそれを追認するものです。 IETF の仕様書の多くも、 SHALL や SHALL NOT はあまり使っていません。後述 (>>90) の通り、 shall は ISO/IEC 系と交わる分野で使われがちのようです。

大文字と小文字

[109] RFC 2119 は、大文字の助動詞を定義しています。

[103] に出版され RFC 2119 を更新する RFC 8174 は、 すべて大文字のものだけが RFC 2119 キーワードであり、 小文字のものは通常の英語の意味だ >>11 と明確化しています。

[106] RFC 2119 は IETF 以外の標準化団体や企業の仕様でも広く採用されています。 IETF 以外では、むしろ「RFC 2119 のキーワードを小文字で使う」 のような規定になっていることが多いです。可読性が理由とされています。

[113] 適合性の規定であることを強調するために可読性を落としても敢えて大文字を使うことには意味があると思いますが、 ネイティブの英語読者にとっては大文字率が高い文章は違和感が強いのでしょうか。

[107] RFC 8174 制定時には当然小文字の用法にも IETF は気づいていたはずですが、 何の言及もしていません。あくまで IETF の仕様書のための規定なので、 他でどう使われていようが知ったことではないという認識なのでしょうか。 あるいはそうした用法を好ましく思わない人達により制定されたのでしょうか。

[105] RFC 2119 出版後 RFC 8174 出版まで数十年、 特に大きな問題になっておらず、 IETF ではすべて大文字、 IETF 外では小文字が多い、という状態で安定しているように見えましたが。。。

[104] WHATWG の仕様書の多くや現代的な W3C の仕様書の多くが参照している WHATWG の Infra Standard は、 RFC 8174 の制定を受けて、 RFC 8174 を無視して小文字で表記できると意図的違反を規定しています >>22。

[111] WHATWG や W3C でよく使われている仕様書生成ツールには参考部分で助動詞が使われているものをエラーとして検出するような機能がついています。 要件を表す RFC 2119助動詞はそれ以外の用途で使うべきではないと考えられており、 従って助動詞以外の意味で使われることは皆無です。 それが敢えて大文字化しなくても良いという理由の1つになっています。 特別な意味を持たない一般語として小文字の利用を認める IETF の RFC 8174 の方針は混乱の元でしょう。

[128] RFC 8174 以前に出版された RFC には、大文字のみ助動詞と解釈することを明記する事例がありました >>129。 RFC 8174 出版以前から、それにつながる認識を持つ人々が IETF 内に存在したということでしょう。

  • [129] RFC 7518 - JSON Web Algorithms (JWA), https://tools.ietf.org/html/rfc7518#section-1.1

RFC 6919 キーワード

[130] RFC 6919 は4月1日のRFC で、 いくつかの助動詞を規定していました >>33。

[134] 4月1日に出版されたことからわかるように、 本来は RFC 2119 をもじったただのネタだったはずです。 ところが、 この RFC を引用して助動詞を使う仕様書がいくつかあります。 そうした仕様書の著者が、 ネタをネタとして使っているのか、 それとも勘違いして本気で使っているのか、 判断しづらいのです。 (ネタだとわかっているとしても、 判断しづらい文脈で使っている以上、 ネタとして成立していないのですが...)

[133] この RFC の状態は、 EXPERIMENTAL とされています >>33。 なぜ情報提供でないのか不明です。 4月1日発行であっても、 ある程度は本気だったりするのでしょうか。

[136] 各キーワードは、 それを実際に使っている過去の RFC を引用しつつ、 皮肉交じりの定義が与えられていました。 (もちろん過去の RFC は RFC 6919 の定義する大文字キーワード表記にはなっていません。)

[135] RFC 6919 キーワード

[137] MUST (BUT WE KNOW YOU WON'T) は、 正式には必要だけど実際上は不便なことを表す、 とされており、括弧書きは文末に移動したり、 省略してしまったりしてもいい、 とされていました。 >>33 つまりただの MUST もこれに該当するということです。

[138] SHOULD CONSIDER は、 実装が何かするべきだと著者は考えているものの、 何かとは何かを著者は知らないことを表します。 >>33

[139] REALLY SHULD NOT は、 危険なのに重要な事業者が行っているため禁止できないことを表します。 >>33

[140] OUGHT TO は、 明らかに道徳的に正しい挙動なので具体化する必要はないだろうという楽観的な判断を表しています。 >>33

[141] WOULD PROBABLY は、 合理的な実装はそうしてほしいという著者の期待を表します。 ただし実装が合理的でなければならないとの要件はありません。 >>33

[142] MAY WISH TO は、 必要と思っている人達と不要と思っている人達がいる挙動を表します。 文書の承認を遅らせないために使われることがあります。 >>33

[143] COULD は、 信頼できる安全な操作のために重要かもしれないヒントを示すべく、 しかし固まった要件の形にはしないで、 可能な手段を提示するものです。 要件としないことで事業者は差別化できます。 >>33

[144] POSSIBLE は、 絶対に起きない境界事案だと思っている作業部会メンバーがいるものの、 実はプロトコルが機能するための極めて基礎的なことを表します。 >>33

[145] MIGHT は、 要件を意図的に見えづらく記述して製品の差別化を図るものです。 >>33

[131] Mixed Content, https://w3c.github.io/webappsec-mixed-content/#requirements-user-controls が 「REALLY SHOULD NOT」 を Note 内で使っています。 Note なので適合性には影響しないものです。 どこまで本気なのかよくわかりません。 危険なオプションを提供せざるを得ない現状への嘆きをこめて仕込んだネタのようなものと解するべきでしょうか。

[132] CSS Writing Modes Level 4, , https://drafts.csswg.org/css-writing-modes/#typeset-upright が規定本文で 「the UA may wish to [RFC6919] (but is not expected to) 」 と書いています。

助動詞濃度

IETF スタイル

[118] IETF の仕様書では、助動詞の使用頻度はそこまで高くなく、 ここぞというところで強調するために使う傾向が見受けられます。 といっても昔に比べると今は使用頻度が高くなっている印象があります (要出典)。

[42] RFC 2119 は、助動詞は注意して利用するべきもので、特に、 相互運用性にほんとうに必要な場合や、有害な可能性のある行為を制限する場合にのみ用いなければならない >>41、 とりわけ、相互運用性のために必要でない限り特定の実装法を要求するために使ってはいけない >>41 としていました。

[110] RFC 8174 はRFC 2119キーワードの利用は義務ではなく、 キーワードを使っていない文事実の文だからといって規定の一部ではなくなるわけではない >>11 と補足しています。

[124] IETF の仕様書や古い Web の仕様書などでは、 助動詞を使っていない事実の文のように見えても要件となることを意図したと思われる文があちこちに散りばめられていたりするので、 慎重に行間を読む力が求められます。

[125] HTML4 Test Suite の開発では、 HTML4 仕様書中に助動詞の明記された要件がわずかしかないことが問題となりました。 HTML4

Web 標準スタイル

[108] Hixie 以後の Web 技術の仕様書では、 助動詞のない事実の文は規定の一部であっても (それ単独では) 適合性に影響しないという理解が一般的になっています。 近年の Web標準の仕様書ではかなり助動詞の利用頻度が高くなっています。

[119] 大文字が可読性に影響するから云々というのは、 こうした文化の違いもあるのでしょう。

[120] WA1 など Hixie 時代の仕様書は、 過剰かと思わせるくらいに徹底的に、 適合性に影響する規定に助動詞を使っていました。 「構文は○○でなければならない」、 「アルゴリズムは○○しなければならない」 とほとんどの文で助動詞が使われていました。

[121] 2010年代後半頃からの Web標準の流儀では、 「入口」となる規定にのみ助動詞を使い、 その一部を構成する定義は事実の文として記述するスタイルに変わってきています。

[122] 例えば、 「○○するには、アルゴリズムを実行しなければならない」、 「アルゴリズムは、○○する」 といった具合です。

アルゴリズムの適合性の記述

[34] HTML Standard などでは、アルゴリズムを記述する際に、 その各手順で要件の度合いを繰り返し記述せずに、アルゴリズムの紹介文で一度だけ助動詞を使うスタイルが採用されています >>35。

  • [35] HTML Standard ( 版) http://www.whatwg.org/specs/web-apps/current-work/#conformance-requirements

[36] 例えば、

To eat an orange, the user MUST:

  1. Peel the orange.
  2. Separate each slice of the orange.
  3. Eat the orange slices.

... のようなアルゴリズムの規定は、

To eat an orange:

  1. The user MUST peel the orange.
  2. The user MUST separate each slice of the orange.
  3. The user MUST eat the orange slices.

... のように展開できます >>35。

[50] あるいは、「○○する手順とは△△である。」と事実の文の形でアルゴリズムの定義を述べ、 呼び出し元で「○○する手順を実行しなければならない」とすることもよくあります。 アルゴリズムがアルゴリズムを呼び出す場合には事実の文の形の定義ばかりのように見えることも多いですが、 最終的な呼び出し元までたどれば必ず助動詞が使われているはずです。

適合性の主語

[37] 要件を表す文章は、その行為を行うもの (人やソフトウェア) を主語として記述することもあれば、生成物の状態を主語として記述することもあります。 どちらの方法で記述されるかは、編集者の好みのスタイルや文脈などに依存するもので、 深い意味はありません。

[38] 例えば、「著者は、 div 要素を p 要素の子供としてはなりません。」と「p 要素は、 div 要素を子供として持ってはなりません。」 は、同じ意味です。

[40] HTML Standard はこのような適合性の主体について言及しています >>39。 他の仕様書でも、明示的に説明していることはあまりありませんが、同じように解釈されています。
  • [39] HTML Standard ( 版) http://www.whatwg.org/specs/web-apps/current-work/#conformance-classes

適合性に寄与しない助動詞の利用

[73] 適合性を記述する助動詞を規定以外の注記や例示などで用いることは、 読者の混乱を招く好ましくないことだと考えられています。 にも関わらず、しばしば助動詞が用いられていて、たまに誰かが気づいて修正したりしています。 (それだけ英語話者にとっては日常的な語句である助動詞でうっかり使ってしまうのでしょう。)

[74] 例えば、「名前では姓を省略するべきではありません。 例: 山田太郎を太郎と書くべきではありません。」は、例示中に助動詞を使っています。 これは「名前では姓を省略するべきではありません。 例: 山田太郎を太郎と書くのは好ましくありません。」のように書いた方が良いとされています。

[51] Infra Standard は、非規定部分では RFC 2119キーワードは使えない >>22 としています。 実際にはこの禁を破った仕様書が少なくなく、都度修正されています。

[116] 加えて、RFC 2119キーワードを避けた代替表現として次のものが挙げられています >>22。

[117] ただの助動詞

[146] 他に ought to などもそのような趣旨で使われています。

[147] ところで適合性としてしなければならない、するべきだ、 というのとは違った「推奨」「したほうがいい」 とは一体何を意味するのでしょうか。 要件でない (= 従わなくてもいい) ことを要求する価値はあるのでしょうか。 RFC 6919 キーワードにはこうした代替表現を揶揄する意味もあるようです。

国家・国際規格

[89] 国際規格・国家規格ではインターネットとは違った流儀の助動詞が使われています。

[90] ただインターネットに関係する分野の国際規格で RFC 2119 が使われたり、国際規格系の流れを汲む標準化団体が shall を多用した RFC 2119 方式を使ったり、 インターネット系の仕様書が翻訳JISになったりと、 両者が混じり合う場面もあります。

ISO/IEC の助動詞

[44] ISO/IEC 国際標準で使う助動詞は、 ISO/IEC Directives で規定されています。

[45] 次の助動詞があります >>43。

  • shall
  • shall not
  • should
  • should not
  • may
  • need not
  • can
  • cannot

  • [43] ISO/IEC Directives ( 版) http://www.iec.ch/members_experts/refdocs/iec/isoiec-dir2%7Bed6.0%7Den.pdf#page=70

JIS における規定

[31] 文章の末尾 要求事項の記述は、その内容が指示・要求、禁止、推奨若しくは許容のいずれであるか、又は単なる情報としての記述であるかを明確に区別しなければならない。

要求事項の文章の末尾は、その意味の区別によって、表3のようにする。 (以上 JISZ8301:2000 7. d) )

[91] JIS Z 8301:2000 表3 要求事項の文章の末尾
意味の区別末尾に置く語句備考国際規格での対応英語
指示又は要求・・・(し)なければらならない。, ・・・する。, ・・・とする。, ・・・による。規格に適合するためには、厳密にこれに従い、これから外れることを認めない。shall 同類: is to・・・, is required to・・・, it is required that・・・, has to・・・, only ・・・ is permitted, it is necessary・・・
禁止・・・(し)てはならない。, ・・・(し)ない。〃shall not 同類: it is not allowed [permitted] [acceptable] [permissible]・・・, is required to be not・・・, is required that・・・be not, is not be・・・
推奨・・・することが望ましい。, ・・・するのがよい。このほかでもよいが、これが特に適しているとして示す。又はこれが好ましいが、必要条件とはしない。should 同類: it is recommended that・・・, ought to・・・
緩い禁止・・・しないほうがよい。これは好ましくないが、必ずしも禁止しない。should not 同類: it is recommended that・・・not, ought not to・・・
許容・・・(し)てもよい。, ・・・差し支えない。規格の立場に立って、これを許すことを示す。may 同類: is permitted, is allowed, is permissible
不必要・・・する必要がない。, ・・・しなくてもよい。〃need not 同類: it is not required that・・・, no・・・is required

助動詞による適合性の用語

[150] RFC 4329 は次のような語を定義しています。 >>151

要求度を表す助動詞のマーク付け

[7] QA Framework: Specification Guidelines http://www.w3.org/TR/2005/REC-qaframe-spec-20050817/#consistent-style-tech

この W3C の仕様書のための指針では、 RFC 2119 の助動詞を使用し、それをマーク付けして明確にすることを勧めています (が具体的な方法には触れず、 >>8 を参照しています)。

[13] 今のところ xml2rfc (RFC 2629 の言語) で助動詞をマーク付けする方法はないみたいです。 (名無しさん 2005-11-11 05:20:45 +00:00)

WHATWG proposes class=ct and anne uses it in CSSOM draft.

[100] XML Syntax for XQuery 1.0 (XQueryX) (2007-01-19 07:17:16 +09:00 版) http://www.w3.org/TR/2007/REC-xqueryx-20070123/#xqx_conformance

RFC 2119 を参照しつつ再定義

[27] Transforming RFC2629-formatted XML through XSLT ( 版) http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#extensions

[92] HTML Standard は昔一瞬だけ助動詞をマーク付けしてたのですが、 可読性に難ありということでやめちゃいました。

[101] この SuikaWiki の記事では、しなければならないのように強調とリンクにより表記しています。

[148] SWML には専用の要素があります。 専用の要素の追加以前に書かれたところでは、 強調とリンクで表現されています。

[70] SuikaWiki Markup Language (SWML) () https://suikawiki.github.io/spec-swml/spec/#conformance-keywords

その他

[123] かつて XHTML1 は (なぜか) 独自に助動詞を定義していました。 MUST など各項を参照。

[155] PowerPoint プレゼンテーション - 20230623-nagai-v1.1.pdf, , https://dnsops.jp/event/20230623/20230623-nagai-v1.1.pdf#page-12

[156] >>155 「重要度」2段階 ×「緊急度」2段階に「MUST」「SHOULD」「RECOMMENDED」「MAY」 を割り当てている。「SHOULD」と「RECOMMENDED」が別の意味であることに注意。

関連

[32] 助動詞以外の用語は適合性

歴史

[93] IRC logs: freenode / #whatwg / 20100322 ( 版) http://krijnhoetmer.nl/irc-logs/whatwg/20100322

[16] XSPF Version 1 http://xspf.org/xspf-v1.html#rfc.section.2.3.2.p.1

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document MUST NOT be interpreted as described in [RFC2119]. In this document these should be interpreted to mean that something shouted is important. XSPF is not a standards track document, it is an ad-hoc project by a group of individuals. Developers may, however, find that [RFC2119] is a useful source anyway.

ワロスwwwwwwww (名無しさん 2006-08-21 12:37:11 +00:00)

[26] 一歩先のWeb標準 ♯1 | Webデザイナー・クリエイター > アイデアノート | withD (2007-04-28 11:35:15 +09:00 版) http://wd.dsp.co.jp/web/idea/2159.html

RFC 2119 の用語を使っているかのように見えるが、 実のところそうではない。

最初の「必須レベル」は、DTD(XHTML™ 1.1 - Second Editionから、XML Schemaという選択肢も加わりました)によって明示的に文法が定義されていますので、プログラムを使った文法の検証(validate)が可能です。

とかかなりあやしいことが書かれている。 (名無しさん 2007-04-28 02:49:23 +00:00)

[46] ( 版) http://www.etsi.org/deliver/etsi_ts/103200_103299/103285/01.01.01_60/ts_103285v010101p.pdf

In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and

"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of

provisions).

"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.

[54] Editorial: refactor to depend on the Infra Standard (domenic著, ) https://github.com/whatwg/html/commit/4ac633e08c2c9430853fc8322943bc2438ed36a3

[55] Editorial: start using the Infra Standard (annevk著, ) https://github.com/whatwg/encoding/commit/a26f76889bf393999e9caad84a3647ab09c39e09

[56] Editorial: start using the Infra Standard (annevk著, ) https://github.com/whatwg/fetch/commit/9ba4e78e5cb5fc1132f89d7e344cd2c2e1950c67

[57] Editorial: leave ASCII case-insensitive to Infra (annevk著, ) https://github.com/whatwg/html/commit/5f3f27bfdf0e0139f6cf5f22508f37710d917c00

[58] Editorial: make use of the Infra Standard (annevk著, ) https://github.com/whatwg/dom/commit/bb2890beed2be14d2f7633ec89e2bbb88ec7fdcd

[59] Editorial: use the Infra Standard (annevk著, ) https://github.com/whatwg/fullscreen/commit/06ae8faa6335bfdcc5c9d9e643c0cb797efbc9d9

[60] RFC 7992 - HTML Format for RFCs () https://tools.ietf.org/html/rfc7992#section-9.9

This element marks up words like MUST and SHOULD [BCP14] with an HTML <span> element with the CSS class "bcp14".

You <span class="bcp14">MUST</span> be joking.

[61] これ MUST の利用例としておかしいだろ・・・

[62] Editorial: avoid "must", "should" etc. in notes (zcorpan著, ) https://github.com/whatwg/html/commit/fb7f7676f625a2ce43efbccc97f356d4811972b8

[63] Clarify that the conformance section is widely applicable (annevk著, ) https://github.com/whatwg/infra/commit/fc952b8110467bd4357cf9d3ce97d430117918ee

[64] Editorial: fix usage of RFC 2119 terms in non-normative notes (domenic著, ) https://github.com/whatwg/streams/commit/39265f49c57e1303f78b33a2014fd1b51c2acfa7

[65] Editorial: remove normative keywords from notes (annevk著, ) https://github.com/whatwg/dom/commit/4ba35d93cff40fd3d3137ed44e803df17296a8cd

[66] Editorial: remove "may" from statements of fact (annevk著, ) https://github.com/whatwg/html/commit/91aff6d3c94a40742192b05e9d7964d95cdaaa0a

[67] [css-images] Remove confusing RFC 2119 MUST from sentence to resolve … (LeaVerou著, ) https://github.com/w3c/csswg-drafts/commit/33ec302371a0a7b5422de682c2a259fb5252766a

[68] Editorial: avoid normative keywords in notes (annevk著, ) https://github.com/whatwg/notifications/commit/fb423c7e3c5e91ff33b11cb79eaaf6370246cff1

[69] Meta: use allow-2119 to silence Bikeshed (annevk著, ) https://github.com/whatwg/infra/commit/534146eccfd17f65118d314b714655b62533971f

[94] Add "willful violation", and willfully violate RFC 8174 (domenic著, ) https://github.com/whatwg/infra/commit/97e08e4137ebec70860c61f47992a40609d0b9fe

[75] Suggest alternate keywords for non-normative content (tobie著, ) https://github.com/whatwg/infra/commit/c9cf34165839b9a43dc0e85e5266351ef07497a5

[76] Editorial: add note about keyword suggestion for non-normative content by tobie · Pull Request #151 · whatwg/infra () https://github.com/whatwg/infra/pull/151

[77] RFC 7692 - Compression Extensions for WebSocket () https://tools.ietf.org/html/rfc7692#section-2

[78] RFC 7322 - rfc Style Guide () https://tools.ietf.org/html/rfc7322#section-4.8.2

[79] Editorial: Fix “should” in input/textarea domintro (sideshowbarker著, ) https://github.com/whatwg/html/commit/a1c7bf04c48117242dc67ec3eecc8960951c25c0

[80] Editorial: Fix “should” in input/textarea domintro by sideshowbarker · Pull Request #3168 · whatwg/html () https://github.com/whatwg/html/pull/3168

[81] Fix MUST/should incosistency (estark37著, ) https://github.com/w3c/webappsec-referrer-policy/commit/455b22cbd48aac776da73cba0688a3b3143d827c

[82] RFC2119 Styles · Issue #126 · w3c/tr-design () https://github.com/w3c/tr-design/issues/126

[83] Readability of RFC 2119 terms · Issue #1380 · w3c/respec () https://github.com/w3c/respec/issues/1380

[84] Meta: use new WHATWG boilerplate and license (domenic著, ) https://github.com/whatwg/compat/commit/f337512db215d4871c4035bd96aed6abd4721ffc

[85] Editorial: avoid normative keywords in domintro block (annevk著, ) https://github.com/whatwg/fetch/commit/78a8dcd9de92a34e1f16e9728784b77a033a654d

[86] Editorial: avoid normative keywords in domintro block by annevk · Pull Request #734 · whatwg/fetch () https://github.com/whatwg/fetch/pull/734

[126] Editorial: avoid normative keywords in domintro block (annevk著, ) https://github.com/whatwg/fetch/commit/78a8dcd9de92a34e1f16e9728784b77a033a654d

[127] Editorial: avoid normative keywords in domintro block by annevk · Pull Request #734 · whatwg/fetch () https://github.com/whatwg/fetch/pull/734

[149] RFC 2480 - Gateways and MIME Security Multiparts (, ) https://tools.ietf.org/html/rfc2480#section-2