RFC 6919

Further Key Words for Use in RFCs to Indicate Requirement Levels 💖

Okay bestie, this one is a Independent Submission 🎀 (so it's its own contribution to the RFC Series, not an IETF stream thing). It's in the Experimental category 🧪, with ISSN 2070-1721, and it's written by Richard Barnes and Stephen Kent (both at BBN) plus Eric Rescorla (RTFM, Inc.). It's dated 1 April 2013 👀 iykyk. It doesn't mark itself as obsoleting or updating any other RFC, so it's just vibing on its own ✨

Abstract ✨

Okay so RFC 2119 gave us a standard set of key words for describing requirements in a spec, and honestly the IETF crowd kept running into the same problem: those words just can't capture the nuanced vibes of certain requirements 😭 This document adds new key words for those alternative scenarios. If you're following these guidelines, you should drop this phrase near the start of your document:

The key words "MUST (BUT WE KNOW YOU WON'T)", "SHOULD CONSIDER",
"REALLY SHOULD NOT", "OUGHT TO", "WOULD PROBABLY", "MAY WISH TO",
"COULD", "POSSIBLE", and "MIGHT" in this document are to be
interpreted as described in RFC 6919.

Status of This Memo 🌸

This document is not an Internet Standards Track specification. It's published for examination, experimental implementation, and evaluation, so think of it as a test drive 🚗

It defines an Experimental Protocol for the Internet community. It's a contribution to the RFC Series that's independent of any other RFC stream. The RFC Editor picked it for publication at their discretion, and they make zero claims about whether it's good for implementation or deployment 💅 Documents approved for publication by the RFC Editor aren't candidates for any level of Internet Standard, see Section 2 of RFC 5741.

For the current status, any errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc6919 🧚

Copyright Notice 🦋

Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date of publication. Please read these carefully, bestie, because they spell out your rights and restrictions for this document 📜

Table of Contents 💜

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. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
11. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
  11.1.  Normative References . . . . . . . . . . . . . . . . . . . 5
  11.2.  Informative References . . . . . . . . . . . . . . . . . . 5

1. MUST (BUT WE KNOW YOU WON'T) 🙈

So this phrase, "MUST (BUT WE KNOW YOU WON'T)", is for requirements that have to be there to pass formal review criteria (think mandatory-to-implement security mechanisms) even though implementers are never actually going to build them, because they're too inconvenient 😩

People usually drop the parenthetical and just say the short version. You can also slide the parenthetical later in the sentence if it reads better. If you do include it, authors MUST give a reason in the parenthetical for why they know implementers won't follow the instruction, like the example (BUT WE KNOW YOU WON'T). Here's a case from RFC 6120 where the original text skipped the parenthetical, and this is the version with a proper one added 💅

For example: "For authentication only, servers and clients MUST
support the SASL Salted Challenge Response Authentication Mechanism
[SCRAM] -- in particular, the SCRAM-SHA-1 and SCRAM-SHA-1-PLUS
variants [(BUT WE KNOW YOU WON'T, because your TLS library doesn't
support extracting channel binding information)]."  [RFC6120]

2. SHOULD CONSIDER 🤔

"SHOULD CONSIDER" is the vibe of the authors thinking implementations should do something, but they honestly aren't sure what 🫠

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" is for dangerous behaviors that some important vendor still does anyway, which is why we couldn't make it a MUST NOT 😤

For example: "This command really should not be used" [RFC0493]

4. OUGHT TO 🌈

"OUGHT TO" is an optimistic statement about an implementation behavior that's just clearly morally right, so it doesn't need any proof 🫶

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" shows what the authors expect a reasonable implementation to do in a given case. Fair warning though, there's no requirement that implementations actually be reasonable 😭

This phrase is also a great example of a grammar trick that's super handy in spec writing: the passive-aggressive voice, which lands somewhere between active and passive 💅

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" flags a behavior that some people find appealing but others think is ridiculous or unnecessary. It's also super popular for dodging extra delay when a document gets approved 🙈

For example: "Verifiers MAY wish to track testing mode results to
assist the Signer."  [RFC6376]

7. COULD ✨

"COULD" lets spec authors name existential possibilities, giving a hint that might be critical to reliable or secure operation without making it a hard requirement. Because there's no requirement, vendors get to stand out from each other 💜

For example: "An implementation could mitigate this race condition,
for example, using timers."  [RFC6733]

8. POSSIBLE 🦋

"POSSIBLE" is what some working group members called an edge case that will never happen, but that still lets the protocol 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" sneaks a requirement in on purpose, which helps products stand out (see "COULD" above, obviously) 🫣

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. Security Considerations 🔥

Okay, this section is serious business 😭 Traditionally, security requirements in IETF documents have been written with a mix of the requirement words from RFC 2119 [RFC2119] and the phrases above. The RFC 2119 key words are mostly useful when the threats and mitigations are clear and well defined. The key words in this document are for when the threat model is ambiguous and the mitigations are unclear or inconvenient. Stay safe out there, bestie 🛡️

11. References 🌸

11.1. Normative References

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

11.2. Informative References

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

Authors' Addresses 💖

Richard Barnes
BBN
1300 N 17th St
Arlington, VA  22209
US

EMail: rlb@ipv.sx


Stephen Kent
BBN
10 Moulton St
Cambridge, MA  02138
US

EMail: kent@bbn.com


Eric Rescorla
RTFM, Inc.
2064 Edgewood Drive
Palo Alto, CA  94303
US

EMail: ekr@rtfm.com