RFC 6919 "Further Key Words for Use in RFCs to Indicate Requirement Levels" 日本語訳 「RFCで要求レベルを表すために使われるキーワードの追加」 Independent Submission R. Barnes Request for Comments: 6919 S. Kent Category: Experimental BBN ISSN: 2070-1721 E. Rescorla Read The Fuckin' Manual, Inc. 1 April 2013 RFCで要求レベルを表すために使われるキーワードの追加 概要 RFC 2119 は仕様の必要条件を表すために使うキーワードの標準セットを定義します。 多くのIETFドキュメントにおいてこれらの言葉が仕様の必要条件のニュアンスを正確に捉えられていないことが分かりました。 このドキュメントでは、必要条件のシナリオの代わりを示すのに使える追加のキーワードを定義します。 これらのガイドラインに従う著者は、ドキュメントの始めあたりにこのフレーズを組み込む必要があります。 このドキュメントにおけるキーワード「MUST(BUT WE KNOW YOU WON'T)(必要だがしてくれないだろう)」 「SHOULD CONSIDER(考慮すべきである)」「REALLY SHOULD NOT(本当にすべきでない)」「OUGHT TO(のはず)」 「WOULD PROBABLY(たぶんそうだろう)」「MAY WISH TO(だといいなぁ)」「COULD(かもしれない)」 「POSSIBLE(ありえる)」「MIGHT(してもよい)」は、RFC6919に述べられているように解釈されるべきである。 このメモの位置付け このドキュメントはインターネット標準Track仕様ではありません。 検査や実験的な実装、評価のために公表されています。 このドキュメントはインターネットコミュニティのための実験的なプロトコルを定義します。 これは、他のいかなるRFCストリームに関係なく、RFCシリーズに貢献をしています。 RFC Editor は自らの裁量でこのドキュメントを公開することを選択しました。 そして、実装や展開においてのその価値に関して何らかの声明を出すことはありません。 RFC Editorによって公表の承認をされたドキュメントはインターネット標準のいかなるレベルの候補でもありません。 RFC5714のセクション2を見てください。 このドキュメントの現在の状況、正誤表 フィードバックの提供の仕方の情報については、http://www.rfc-editor.org/info/rfc6592 で得られるでしょう。 http://www.rfc-editor.org/info/rfc6919. このドキュメントはBCP78とこのドキュメントの公表日に実施されているIETFドキュメントに関するIETF信託の法律条項 (http://trustee.ietf.org/license-info) の適用を受けます。 それらにこの文章に関する権利と制限が記述されていますので、慎重にこれらの文章を確認してください。 目次 1. MUST(BUT WE KNOW YOU WON'T) すべきである(しかしされないだろう). .3 2. SHOULD CONSIDER 考慮すべきである. . . . . . . . . . . . . . . . .3 3. REALLY SHOULD NOT 本当にすべきでない. . . . . . . . . . . . . . .3 4. OUGHT TO のはず. . . . . . . . . . . . . . . . . . . . . . . . . 4 5. WOULD PROBABLY たぶんそうだろう. . . . . . . . . . . . . . . . . 4 6. MAY WISH TO だといいなぁ. . . . . . . . . . . . . . . . . . . . .4 7. COULD かも知れない. . . . . . . . . . . . . . . . . . . . . . . .4 8. POSSIBLE ありえる . . . . . . . . . . . . . . . . . . . . . . . .5 9. MIGHT かも知れない. . . . . . . . . . . . . . . . . . . . . . . .5 10. セキュリティ問題. . . . . . . . . . . . . . . . . . . . . . . . .5 11. 参照. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 11.1. 参照する参考文献. . . . . . . . . . . . . . . . . . . . . . 5 11.2. 有益な参考文献. . . . . . . . . . . . . . . . . . . . . . . 5 1. MUST(BUT WE KNOW YOU WON'T) すべきである(しかしされないだろう) このフレーズ 「MUST(BUT WE KNOW YOU WON'T) すべきである(しかしされないだろう)」は、これらのメカニズムを実際に実装するのはとても面倒なだが、公式のレビュー条件において必要とされる条件を示すのに使われる。 (例えば、セキュリティメカニズムの強制的な実装) このフレーズは括弧の中が省略された形でよく使われます。 また括弧部分は文体としての理由から後に文章から削除されるかも知れません。 括弧が存在する場合、著者はなぜ実装者がこの指示に従わないだろうかという理由を括弧内で示す"べき"である。 下記の例では、原文では括弧が削除されているRFC6120の場合において、適切な括弧を示します。 例えば : 「認証のためのみであれば、サーバとクライアントはSASL Salted Challenge Response 認証メカニズムをサポート"すべき"である」 [SCRAM] -- 特に、SCRAM-SHA-1 とSCRAM-SHA-1-PLUS 変数 [(しかし、TLSライブラリがチャネルバインディングインフォメーションを取り出せないのでしないと分かっています。) [RFC6120] 2. 考慮すべきである フレーズ「考慮すべきである」は、仕様の著者は何か実装すべきと思ってはいるが、それが何なのか分かっていないことを意味します。 例えば : 「For example: "Applications that take advantage of typed links should consider the attack vectors opened by automatically following, trusting, or otherwise using links gathered from HTTP headers." [RFC5988] 3. REALLY SHOULD NOT 本当にすべきでない フレーズ「REALLY SHOULD NOT 本当にすべきでない」は、どこかの重要なベンダーがまだやっているために、「MUST NOT すべきではない」とはいえないことを意味します。 例えば : 「このコマンドは本当に使うべきではない」[RFC0493] 4. OUGHT TO のはず フレーズ「OUGHT TO のはず」は、実装の挙動が明らかに正しいも同然なので実証は必要ないという楽観的な主張を伝えます。 例えば : For example: "If a decision might affect semantic transparency, the implementor ought to err on the side of maintaining transparency unless a careful and complete analysis shows significant benefits in breaking transparency." [RFC2616] 5. WOULD PROBABLY たぶんそうだろう フレーズ「WOULD PROBABLY たぶんそうだろう」は、与えられた状況において合理的な実装がするであろうことを著者が期待していることを意味します。 実装が合理的あることについては必要性がありません。 This phrase is also a good example of an aspect of English grammar that is often useful in specification writing, namely the passive-aggressive voice, which provides a meaning in between the active and the passive voice. For example: "A SMTP client would probably only want to authenticate an SMTP server whose server certificate has a domain name that is the domain name that the client thought it was connecting to." [RFC3207] 6. MAY WISH TO だといいなぁ フレーズ「MAY WISH TO だといいなぁ」は、ある人たちに訴えかけるかも知れない振る舞いを示すが、他の人たちにとってはばかげた不必要とみなされる振る舞いを示します。 このフレーズはドキュメントの承認において一層遅れることを避けるために頻繁に使用されます。 For example: "Verifiers MAY wish to track testing mode results to assist the Signer." [RFC6376] 7. COULD かも知れない. フレーズ「COULD かもしれない」は、信頼あるいは安全なオペレーションのために重要なヒントを提供するために、強い要求ではないものの、著者が可能性の存在を表現するための方法を提供します。 要求の不足は、ベンダー製品の差分を許容します。 例えば、「例えばタイマーを使うなどの実装はこの競合条件を緩和することができるかも知れない」 [RFC6733] 8. POSSIBLE ありえる . The phrase "POSSIBLE" describes what some of the working group members thought of as an edge case that will never happen, but in practice allows the protocol to work at the most fundamental level. For example: "It is also possible for the server to send a completion response for some other command (if multiple commands are in progress), or untagged data." [RFC3501] 9. MIGHT かも知れない. フレーズ「MIGHT かも知れない」は、製品の差分を助長するために、故意に秘密の方法で要求を伝えます。 (参照. 上記「COULD かも知れない」). For example: "In the case of audio and different "m" lines for different codecs, an implementation might decide to act as a mixer with the different incoming RTP sessions, which is the correct behavior." [RFC5888] 10. セキュリティ問題 伝統的にIETFのドキュメントのセキュリティ要件はRFC 2119[RFC2991]の要求単語と上記で使用したフレーズとの混合で表現されてきています。 RFC2119のキーワードは、脅威と緩和が明確でよく定義されている場合において有用です。 このドキュメントでのキーワードは、脅威モデルがあいまいで緩和が曖昧あるいは不都合な場合に適用することができます。 11. 参照 11.1. 参照する参考文献 [RFC2119] Bradner, S., 「RFCにおいて要求レベルを示すために使用されるキーワード」", BCP 14, RFC 2119, March 1997. 11.2. 有益な参考文献 [RFC0493] Michener, J., Cotton, I., Kelley, K., Liddle, D., and E. Meyer, "GRAPHICS PROTOCOL", RFC 493, April 1973. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002. [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003. [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, June 2010. [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011. [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, September 2011. [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, "Diameter Base Protocol", RFC 6733, October 2012.