Network Working Group M. Farah
Request for Comments: nnnn T.I.A.
WCP: FFFFFFF2 1 April 2000
Obsoletes: 2119
Category: Worst Current Practice
New meaning of Keywords for use in RFCs to Indicate Requirement Levels
draft-farah-new-keywords-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This document specifies an Internet Worst Current Practices for the
Internet Community, and does not request discussion and suggestions
for any improvements whatsoever. Distribution of this memo is
unlimited.
ABSTRACT
This memo defines an experimental protocol -called UGGC- that serves as
an encrypted counterpart to HTTP.
Introduction
The author of this document believes the current meaning of keywords
to indicate requirement levels are ill-defined, as they have been the
direct source of several headaches and many many hours of extra work.
This document defines new meanings for these keywords, and thus
obsoletes RFC 2119.
Oddly, 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, even
after it becomes obsolete.
9. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the
definition of the specification SHOULD be as closely followed as the
implementor cares, or is able to grasp, or as the time, energy and
other constraints permit.
8. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the
definition of the specification SHOULD be avoided by the implementor,
as long as it won't cause too much trouble programming-time-wise,
money-wise or mood-wise.
7. SHOULD This word, or the adjective "RECOMMENDED", mean that there
MAY exist particular items to implement as the specification
definition states, as long as the implementor wants to, and there's
no noticeable use of expensive resources (e.g. it won't take more
than a few minutes to add).
6. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED", mean the
very same as "SHOULD" or "RECOMMENDED", respectively.
5. MAY This word, or the adjective "OPTIONAL", mean that an item is
completely expendable and that the implementor MUST ignore it.
Vendors MUST NOT mention it and users MUST NOT complain about it.
Farah Experimental [Page 1]
New meaning of Keywords for use in RFCs 1 April 2000
4. Guidance in the use of these Imperatives
Imperatives of the type defined in this memo MUST be used generously
(specially the word "MAY"). In particular, they MUST be used
everywhere the grammar allows.
3. Security Considerations
These terms are frequently used to specify behavior with security
implications. They SHOULD NOT be used again, EVER. The effects on
security of implementing definitions the way this document proposes
are not subtle at all. Document authors SHOULD take the time to find
proper synonyms for the former meanings of the keywords in
discussion.
2. Acknowledgments
The completely unfair yellings this author had to take from all his
fifteen former bosses (whose names deserve not be recorded here),
plus him being fired as many times, resulted in a terrible bitterness
and resentment feeling that proved to be a huge motivation into
writing this document.
1. Author's Address
Miguel Farah
Regina Pacis 1305 (Providencia)
Santiago, Chile
phone - +56 2 205 2208
email - miguel@webhost.cl
Farah Experimental [Page 2]