One document matched: draft-saintandre-2119bis-00.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc compact="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>

<rfc category="bcp" docName="draft-saintandre-2119bis-00" ipr="trust200902" obsoletes="2119">

  <front>
    <title abbrev="Conformance Terms">Conformance Terms to Indicate Requirement Levels</title>

    <author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street>1899 Wyknoop Street, Suite 600</street>
          <city>Denver</city>
          <region>CO</region>
          <code>80202</code>
          <country>USA</country>
        </postal>
        <phone>+1-303-308-3282</phone>
        <email>psaintan@cisco.com</email>
      </address>
    </author>

    <date month="August" day="29" year="2011"/>

    <area>General</area>
    <keyword>Internet-Draft</keyword>

    <abstract>
      <t>In many protocol specifications and related documents, special conformance terms (e.g., the uppercase words "MUST", "SHOULD", and "MAY") are often used to signify requirement levels.  This document defines these conformance terms and describes how they are to be interpreted in documents produced within the Internet Standards Process.  If approved, this document obsoletes RFC 2119 and changes its status to Historic.</t>
    </abstract>
  </front>

  <middle>

    <section title="Introduction" anchor="introduction">
      <t>In many protocol specifications and related documents, special conformance terms (e.g., the uppercase words "MUST", "SHOULD", and "MAY") are often used to signify requirement levels.  This document defines these conformance terms and describes how they are to be interpreted in documents produced within the Internet Standards Process <xref target='BCP9'/>.  If approved, this document obsoletes RFC 2119 and changes its status to Historic.</t>
      <t>The discussion venue for this document is the <ietf@ietf.org> mailing list, for which archives and subscription information are available at <https://www.ietf.org/mailman/listinfo/ietf>.</t>
      <t>[[ NOTE TO RFC EDITOR: Upon publication, please remove the foregoing sentence. ]]</t>
    </section>

    <section title="Definitions" anchor="defs">
      <section title='MUST' anchor='defs-must'>
        <t>This term means that the feature or behavior is an absolute requirement of the specification, so that an implementation has an unconditional obligation to implement the feature or to behave as defined.  The terms "SHALL" and "REQUIRED" are equivalent to "MUST".</t>
      </section>
      <section title='MUST NOT' anchor='defs-mustnot'>
        <t>This term means that the feature or behavior is an absolute prohibition of the specification, so that an implementation has an unconditional obligation to not implement the feature or to not behave as defined.  The term "SHALL NOT" is equivalent to "MUST NOT".</t>
      </section>
      <section title='SHOULD' anchor='defs-should'>
        <t>This term means that the feature or behavior is a limited requirement of the specification, so that an implementation has a conditional obligation to implement the feature or to behave as defined, unless there is a strong, explicitly described reason not to do so in particular circumstances.   Those who implement the specification or deploy conformant technologies need to understand and carefully weigh the full implications of violating the requirement before doing so.  The term "RECOMMENDED" is equivalent to "SHOULD".</t>
      </section>
      <section title='SHOULD NOT' anchor='defs-shouldnot'>
        <t>This term means that the feature or behavior is a limited prohibition of the specification, so that an implementation has a conditional obligation to not implement the feature or to not behave as defined, unless there is a strong, explicitly described reason to do so in particular circumstances.  Those who implement the specification or deploy conformant technologies need to understand and carefully weigh the full implications of violating the prohibition before doing so.  The term "NOT RECOMMENDED" is equivalent to "SHOULD NOT".</t>
      </section>
      <section title='MAY' anchor='defs-may'>
        <t>This term means that the feature or behavior is truly a matter of preference.  One implementation can choose to implement the feature or behavior whereas another implementation can choose not to, without any resulting harm to interoperability.  An implementation that does not implement the feature or behavior needs to interoperate with another implementation that does do so, although perhaps with reduced functionality.  Likewise, an implementation that implements the feature or behavior needs to interoperate with another implementation that does not do so (except, of course, with respect to the defined feature or behavior).  The term "OPTIONAL" is equivalent to "MAY".</t>
      </section>
    </section>

    <section title="Usage" anchor="Usage">
      <t>The conformance terms defined in this document ought to be used judiciously.  In particular, the absolute and limited requirements and prohibitions ought be used only to specify features and behaviors that are necessary for interoperability, or to forbid features and behaviors that have the potential to cause significant harm.  For example, such terms are not to be used to impose a particular method on implementers if the method is not necessary for interoperability.</t>
      <t>When it is not appropriate to use the conformance terms, authors can use a variety of alternative words and phrases, such as: "need to", "has to", or "mandatory" instead of "MUST"; "ought to", "strongly encouraged to", or "suggested" instead of "SHOULD"; and "might", "can", or "discretionary" instead of "MAY".  To prevent confusion, authors are strongly encouraged to use these alternative words and phrases instead of the lowercase versions of the conformance terms whenever possible, and to use the conformance terms only in their uppercase versions.</t>
    </section>

    <section title="Boilerplate" anchor="boilerplate">
      <t>In order for the requirements force of the conformance terms to apply, authors who follow the guidelines specified herein need to incorporate this sentence near the beginning of their documents:</t>
      <t><list style='empty'><t>The following conformance terms are to be interpreted as described in RFC &rfc.number;: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".</t></list></t>
      <t>[[ NOTE TO RFC EDITOR: Upon publication, please change "&rfc.number;" to the number assigned to this document. ]]</t>
    </section>

    <section title="Security Considerations" anchor="security">
      <t>The conformance terms defined in this document are frequently used to specify features and behaviors that have security implications.  The effects on security of not implementing a "MUST" or a "SHOULD", or of doing something the specification says "MUST NOT" or "SHOULD NOT" be done, can be very subtle.  Authors are strongly encouraged to elaborate the security implications of not conforming to requirements and recommendations, since many implementers do not have the benefit of the experience and discussion that produced the specification.</t>
    </section>

    <section title="IANA Considerations" anchor="iana">
      <t>This document requests no actions of the IANA.</t>
    </section>

    <section title="Acknowledgements" anchor="acks">
      <t>This document borrows text from <xref target='RFC2119'/>; Scott Bradner, the author of that document, is gratefully acknowledged.</t>
    </section>

  </middle>

  <back>

    <references title="Informative References">

<reference anchor='BCP9'>
<front>
<title abbrev='Internet Standards Process'>The Internet Standards Process -- Revision 3</title>
<author initials='S.' surname='Bradner' fullname='Scott O. Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country></postal>
<phone>+1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year='1996' month='October' />
<abstract>
<t>This memo documents the process used by the Internet community for the standardization of protocols and procedures.  It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process.  It also addresses the intellectual property rights and copyright issues associated with the standards process.</t></abstract></front>
<seriesInfo name='BCP' value='9' />
<seriesInfo name='RFC' value='2026' />
<format type='TXT' octets='86731' target='http://www.rfc-editor.org/rfc/rfc2026.txt' />
</reference>

<reference anchor='RFC2119'>
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year='1997' month='March' />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
   In many standards track documents several words are used to signify
   the requirements in the specification.  These words are often
   capitalized.  This document defines these words as they should be
   interpreted in IETF documents.  Authors who follow these guidelines
   should incorporate this phrase near the beginning of their document:
<list>
<t>
      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
      "OPTIONAL" in this document are to be interpreted as described in
      RFC 2119.
</t></list></t>
<t>
   Note that the force of these words is modified by the requirement
   level of the document in which they are used.
</t></abstract></front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='http://www.rfc-editor.org/rfc/rfc2119.txt' />
<format type='HTML' octets='17491' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5777' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>

    </references>

  </back>

</rfc>