The RFC Archive
 The RFC Archive   RFC 5513   « Jump to any RFC number directly 
 RFC Home
Full RFC Index
Recent RFCs
RFC Standards
Best Current Practice
RFC Errata
1 April RFC



IETF RFC 5513

IANA Considerations for Three Letter Acronyms

Last modified on Wednesday, April 1st, 2009

Permanent link to RFC 5513
Search GitHub Wiki for RFC 5513
Show other RFCs mentioning RFC 5513







Network Working Group                                          A. Farrel
Request for Comments: 5513                            Old Dog Consulting
Category: Informational                                   1 April 2009


             IANA Considerations for Three Letter Acronyms

 Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

 Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

 Abstract

   Three Letter Acronyms (TLAs) are commonly used to identify components
   of networks or protocols as designed or specified within the IETF.  A
   common concern is that one acronym may have multiple expansions.
   While this may not have been an issue in the past, network
   convergence means that protocols that did not previously operate
   together are now found in close proximity.  This results in
   contention for acronyms, and confusion in interpretation.  Such
   confusion has the potential to degrade the performance of the
   Internet as misunderstandings lead to misconfiguration or other
   operating errors.



Farrel                       Informational                   PAGE 1 top


RFC 5513 TLAs April 2009 Given the growing use of TLAs and the relatively small number available, this document specifies a Badly Construed Proposal (BCP) for the management of a registry of TLAs within the IETF, and the procedures for the allocation of new TLAs from the registry. 1. Introduction A Three-Letter Acronym (TLA) is a popular form of abbreviation usually based on the initial letters of a three-word term. A formal definition of a TLA is provided in Section 2. TLAs are particularly popular within the Internet community where they serve as abbreviations in the spoken and written word. As their popularity has grown, the measure of the value of an RFC (q.v.) is not only its successful implementation, interoperability, and deployment, but also the number of TLAs included in the text. For example, the Transmission Control Protocol (itself a TLA - TCP) [RFC 793] is extremely successful. The specification contains no fewer than 20 distinct TLAs (although it should be noted that some are simple abbreviations rather than proper acronyms). On the other hand, the Internet Stream Protocol Version 2 [RFC 1819] is ambiguously referred to using the TLA ST2, and also as STII which is clearly not a TLA. Further, the STII specification contains only 12 distinct TLAs, and it should be no surprise that STII has been far less successful than TCP. A common concern amongst diligent protocol implementers is that one acronym may have multiple expansions. While this may not have been an issue in the past, network convergence means that protocols that did not previously operate together are now found in close proximity. Not only does this result in contention for acronyms, and confusion in interpretation of specification, it also leads to many wasted hours trying to select appropriate and suitably-unique names for variables within source code implementations. Such confusion has the potential to degrade the performance of the Internet as misunderstandings lead to coding errors, compilation failures, misconfiguration, and other operating errors. Furthermore, it should be noted that we are rapidly approaching World Acronym Depletion (WAD). It has been estimated that, at the current rate of TLA allocation, we will run out by the end of September this year. This timescale could be worsened if there is the expected growth in demand for mobile acronyms, IP-TLAs, and TLA-on-demand. According to the definition provided in Section 2, there are 36**3 - 10**3 = 45656 TLAs in total. This number will so easily be depleted that we must institute some policy for conservation. Farrel Informational PAGE 2 top

RFC 5513 TLAs April 2009 The Internet Assigned Numbers Authority (IANA, helpfully, a four- letter acronym - although note that a four-letter acronym is an FLA and hence is, in its own way, a TLA) maintains registries of names and numbers for use within the Internet in order to avoid duplicate allocation of one of those names or numbers and the consequent confusion and failed interoperability that would arise. It is, therefore, wholly appropriate that the IANA should manage the assignment and use of TLAs within the Internet. This document specifies a Badly Construed Proposal for the management of a registry of TLAs within the IETF, and the procedures for the allocation of new TLAs from the registry. 1.1. RFC Editor Terminology List It is worth observing that the RFC Editor currently maintains a list of common terms, abbreviations, and acronyms. While this list is highly useful for the construction of documents, it does not provide unambiguous interpretation of acronyms. 2. Formal Definition of TLA Acronym - a word made up of the initial letters of the words in a phrase. For example, IETF is an acronym formed from the first letters of the phrase International Essential Tremor Foundation [URL-IETF]. Three Letter Acronym (TLA) - an acronym comprising exactly three letters. For example, RFC is a TLA formed of the first letters of the phrase Rugby Football Club [URL-CARDIFF]. For our usage, we also allow digits within a TLA. Thus, P2P is an acronym meaning Purchase to Pay [URL-P2P]. The digits 2 and 4 are specially used by clever people who have noticed that, when spoken, they sound like the words 'to' and 'for'. Whether this is helpful may be left as an exercise for the user considering the brief conversation, below. A - Do you use the Internet Streams Protocol? B - Yes. Do you use ST, too? A - No, I use ST2. B - That's interesting. C uses ST2, too. A - I have a car horn application called Toot-toot. B - Really? Do you use ST2 to Toot-toot, too? Farrel Informational PAGE 3 top

RFC 5513 TLAs April 2009 Note, however, that an acronym made up entirely of digits might be frowned upon. Lastly, we must consider case-sensitivity. Although acronyms often include upper or lowercase letters, no assumptions should be made about the interpretation of the acronym based on the case of its letters, so that both QOS and QoS clearly refer to the Queen of the South football club [URL-QOS] and [URL-QoS]. 2.1. A Note on Vocalization Acronyms are often articulated as words in spoken text. This can be helpful in generating a cosy feel or a marketing buzz around a concept that offers a less-favorable reality. For example, Claws and Teeth (CAT) can be pronounced "cat" making it seem quite cuddly. Other acronyms are always spelled out in order to avoid accidental misinterpretation or litigation. For example, do not refer to your neighbor's Daughter or Granddaughter as anything other than their D-O-G. But care should be taken with vocalization, as well. It will be noted that some letters have more syllables than the words they are used to represent. In these cases, acronyms are to be avoided. Thus, the world wide web must never be assigned the acronym WWW. Finally, a word of caution about attempting to pronounce acronyms as words. This can lead to serious injury for the inexperienced unless they happen to be native speakers of Czech. Do not try to say XML in front of your mother-in-law, and don't attempt to talk about Open Office dot Org in polite company. 3. Backward and Forward Compatibility It should be obvious to most RFC readers (MRRs) that TLAs are already widely used in Internet specifications. This work is not intended to unnecessarily invalidate existing RFCs, although where such invalidation is necessary or desirable, this work can be used for that purpose. In order to support existing documents, IANA is required to search all existing RFCs for every existing acronym usage (EAU), but may filter that search to exclude non-TLAs. It will be noted that, as a result of that search, many duplicate meanings will be discovered. For example, "OAM" will be found in a large number of RFCs, yet its meaning may be as diverse as "on a mission", "order of Australia medal", and "orbital angular momentum". Farrel Informational PAGE 4 top

RFC 5513 TLAs April 2009 This contention is best resolved by the judgement of Solomon -- each acronym usage will be allocated its share of the letters currently in use. If there are three uses of an acronym, they will get one letter each; two existing uses would get one-and-a-half letters each; etc. 4. IANA Considerations 4.1. New Registry The Internet TLA Registry (ITR) should track the following information: - TLA - Unique interpretation - Defining RFC 4.2. Reserved Values Certain key values are reserved. That is, they are allocated in the registry by this document and may not be used for any other purpose. Acronym Expansion Reference --------+-------------------------------------+----------- TLA Two Letter Acronym [RFC 5513] TBD Two Be Deleted [RFC 5513] RFC Ready for Compost [RFC 5513] PoS Not particularly good [RFC 5513] VPN Very possibly no use [RFC 5513] TCP Totally bad proposal [RFC 5513] USA Universal Source of Acronyms [RFC 5513] NBG This document [RFC 5513] BCP Badly construed proposal [RFC 5513] 4.3. Allocation Policy IANA shall apply the following allocation policies according to [RFC 5226]. Experimental Use All TLAs of the form XX* where * is any letter or digit. First Come First Served All TLAs of the form X**, Y**, or Z** where * is any letter or digit. Excepted from this are the TLAs of the form XX* as above. IETF Review All other TLAs. Farrel Informational PAGE 5 top

RFC 5513 TLAs April 2009 5. Security Considerations Many security algorithms are identified by TLAs. It is a clear requirement that someone implementing, for example, MD5 should be understood to have encoded the well-known Maybe-Decrypted- Deciphered-Decoded-Disambiguated-and-Degraded algorithm, and not any other security algorithm with the same acronym. 6. Acknowledgements I would like to thank the MPLS-TP design team for holding seemingly endless meetings during which the need for this document became apparent. Thanks to Daniel King for noticing that this document is a BCP. 7. References 7.1. Normative References [RFC 5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 7.2. Informative References [RFC 793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC 1819] Delgrossi, L., Ed., and L. Berger, Ed., "Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+", RFC 1819, August 1995. [URL-IETF] International Essential Tremor Foundation, http://www.essentialtremor.org/ [URL-CARDIFF] Cardiff Rugby Football Club, http://www.cardiffrfc.com/ [URL-P2P] eProcumentStotl@nd, http://www.eprocurementscotland.com/Home/ePS- Service/P2P [URL-QOS] Queen of the South Football Club, http://www.qosfc.com/ [URL-QoS] Queen of the South Football Club, ahttp://www.qosfc.com/ Farrel Informational PAGE 6 top

RFC 5513 TLAs April 2009 Author's Address Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk Farrel Informational PAGE 7 top

IANA Considerations for Three Letter Acronyms RFC TOTAL SIZE: 13931 bytes PUBLICATION DATE: Wednesday, April 1st, 2009 LEGAL RIGHTS: The IETF Trust (see BCP 78)


RFC-ARCHIVE.ORG

© RFC 5513: The IETF Trust, Wednesday, April 1st, 2009
© the RFC Archive, 2024, RFC-Archive.org
Maintainer: J. Tunnissen

Privacy Statement