doc: Add RFC documents

1 files changed, 339 insertions, 0 deletions

diff --git a/doc/rfc/rfc6919.txt b/doc/rfc/rfc6919.txt
new file mode 100644
index 0000000..0147176
--- /dev/null
+++ b/doc/rfc/rfc6919.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Independent Submission                                         R. Barnes
+Request for Comments: 6919                                       S. Kent
+Category: Experimental                                               BBN
+ISSN: 2070-1721                                              E. Rescorla
+                                                              RTFM, Inc.
+                                                            1 April 2013
+
+
+    Further Key Words for Use in RFCs to Indicate Requirement Levels
+
+Abstract
+
+   RFC 2119 defines a standard set of key words for describing
+   requirements of a specification.  Many IETF documents have found that
+   these words cannot accurately capture the nuanced requirements of
+   their specification.  This document defines additional key words that
+   can be used to address alternative requirements scenarios.  Authors
+   who follow these guidelines should incorporate this phrase near the
+   beginning of their 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 is
+   published for examination, experimental implementation, and
+   evaluation.
+
+   This document defines an Experimental Protocol for the Internet
+   community.  This is a contribution to the RFC Series, independently
+   of any other RFC stream.  The RFC Editor has chosen to publish this
+   document at its discretion and makes no statement about its value for
+   implementation or deployment.  Documents approved for publication by
+   the RFC Editor are not a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6919.
+
+
+
+
+
+
+
+
+
+Barnes, et al.                Experimental                      [Page 1]
+
+RFC 6919                  Further RFC Key Words             1 April 2013
+
+
+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) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barnes, et al.                Experimental                      [Page 2]
+
+RFC 6919                  Further RFC Key Words             1 April 2013
+
+
+1.  MUST (BUT WE KNOW YOU WON'T)
+
+   The phrase "MUST (BUT WE KNOW YOU WON'T)" is used to indicate
+   requirements that are needed to meet formal review criteria (e.g.,
+   mandatory-to-implement security mechanisms), when these mechanisms
+   are too inconvenient for implementers to actually implement.
+
+   This phrase is frequently used in a contracted form in which the
+   parenthetical is omitted.  The parenthetical may also be moved later
+   in the sentence for stylistic reasons.  If the parenthetical is
+   present, authors MUST provide a reason why they know implementors
+   will not heed this instruction in the parenthetical, as in the
+   example (BUT WE KNOW YOU WON'T).  In the below example, we show a
+   case from RFC 6120 where the original text omitted the parenthetical,
+   and we have indicated an appropriate parenthetical.
+
+   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
+
+   The phrase "SHOULD CONSIDER" indicates that the authors of the
+   specification think that implementations should do something, but
+   they're not sure quite 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
+
+   The phrase "REALLY SHOULD NOT" is used to indicate dangerous
+   behaviors that some important vendor still does and therefore we were
+   unable to make MUST NOT.
+
+   For example: "This command really should not be used" [RFC0493]
+
+
+
+
+
+
+
+
+
+
+
+Barnes, et al.                Experimental                      [Page 3]
+
+RFC 6919                  Further RFC Key Words             1 April 2013
+
+
+4.  OUGHT TO
+
+   The phrase "OUGHT TO" conveys an optimistic assertion of an
+   implementation behavior that is clearly morally right, and thus does
+   not require substantiation.
+
+   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
+
+   The phrase "WOULD PROBABLY" indicates the authors expectation about
+   what a reasonable implementation is likely to do in a given case.
+   There is no requirement for implementations to be reasonable.
+
+   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
+
+   The phrase "MAY WISH TO" indicates a behavior that might seem
+   appealing to some people, but which is regarded as ridiculous or
+   unnecessary by others.  This phrase is frequently used to avoid
+   further delay in approval of a document.
+
+   For example: "Verifiers MAY wish to track testing mode results to
+   assist the Signer."  [RFC6376]
+
+7.  COULD
+
+   The phrase "COULD" provides a way for specification authors to
+   articulate existential possibilities, in order to provide a hint that
+   might be critical to reliable or secure operation, but without a hard
+   requirement.  The lack of a requirement allows for vendor product
+   differentiation.
+
+   For example: "An implementation could mitigate this race condition,
+   for example, using timers."  [RFC6733]
+
+
+
+
+
+Barnes, et al.                Experimental                      [Page 4]
+
+RFC 6919                  Further RFC Key Words             1 April 2013
+
+
+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
+
+   The phrase "MIGHT" conveys a requirement in an intentionally stealthy
+   fashion, to facilitate product differentiation (cf. "COULD" above).
+
+   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
+
+   Traditionally, security requirements in IETF documents have been
+   expressed with a mixture of requirements words from RFC 2119
+   [RFC2119] and the phrases used above.  The key words in RFC 2119 are
+   principally useful when threats and mitigations are clear and well
+   defined.  The key words in this document can be applied when the
+   threat model is ambiguous, and mitigations are unclear or
+   inconvenient.
+
+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.
+
+
+
+Barnes, et al.                Experimental                      [Page 5]
+
+RFC 6919                  Further RFC Key Words             1 April 2013
+
+
+   [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
+
+
+
+
+
+
+Barnes, et al.                Experimental                      [Page 6]
+