Non-Normative Synonyms in RFCs
draft-hansen-nonkeywords-non2119-01
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Expired & archived
|
|
|---|---|---|---|
| Authors | Tony Hansen , Dave Crocker | ||
| Last updated | 2011-07-11 (Latest revision 2011-07-03) | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
Specifications can contain normative keywords, as defined in RFC 2119, to signify requirements, permission or prohibitions. They include MUST, SHOULD and MAY, which are commonly spelled in all CAPITALS (but need not be). These words can also be used for non- normative purposes. However when used within an RFC this is confusing, given their typical use as normative vocabulary, even when they do not formally have normative import. Several words and phrases are specified in this document for non- normative purposes as alternatives to the normative vocabulary of RFC 2119. Authors who follow these guidelines do NOT need to incorporate any declaration at the beginning of their document.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)