December 4, 2013

Convergence Wreaks Havoc with TLA/FLA Alphabet Soup

Thumbnail image for SAT-for-TechNotes.jpg
Want to communicate clearly?  Then you better make sure that your TLAs (two, or usually three, letter acronyms), FLAs (four letter acronyms) and xFLAs (extended four letter acronyms are lined up).  Of course, this can get even more obtuse as we have compound TLAs and FLAs, like combining two TLAs TCP/IP (Transmission Control Protocol and Internet Protocol).  And before I start getting flamed (how's that for showing my age?) about whether nLAs are acronyms or abbreviations, I'll stipulate that it's a mixture.

It's been a little over two years since Jim Metzler and I wrote our final WAN newsletter for Network World. In that newsletter, titled "Convergence: The Final Frontier," we noted that convergence was happening on a number of levels and it would continue until formerly disparate worlds became one.

As noted in that newsletter, "In the early and mid-2000s, Jim and Steve conducted literally several hundred seminars in which we shared a simple slide. It was a Venn diagram that had three circles representing the LAN, the WAN, and applications. Each of the three circles had an intersecting area, with a central portion that represented the confluence of all three. And we stated in each seminar that only when all three facets became indistinguishable would we see true convergence."

We often used the meaning if TLAs and FLAs as examples of how these multiple worlds have totally different meanings for the same acronym/abbreviation.  "MAC" is a great example, and you could immediately tell whether a person was a "voice person" or a "data person" by whether it meant "Moves, Adds, and Changes" or the "Media Access Control" address in Ethernet.

We recently had an occurrence of a similar amount of confusion where the applications world is converging with communications.  Someone recently wrote in a paper "As a result, their products do not generally support the latest Internet Engineering Task Force (IETF) remote function calls (RFC) specifications for SIP or particular vendor-specific SIP implementations."

Webtorials community member Neill Wilkinson of Aeonvista saw this and noted "That's a bit of blooper!  It somewhat reduces the credibility of the paper.  "Remote Function Calls." Really???"

Yep.  A blooper indeed.  But after we chuckle, let's also look at the story behind the blooper.

First of all, as journalists, we are often asked to "spell out all acronyms."  This is a good idea in general, but there are many cases where the meaning is so specific to a particular field that it can be reasonably assumed that the reader knows what the acronym/abbreviation means.  For instance, MPLS seldom needs to be spelled out as "Multiprotocol Label Switching."  MPLS is simply known as MPLS.  However, sometimes rules are applied whether needed or not.

This is a particularly interesting example, though.  Of course, an IETF RFC refers to a "Request for Comment."  And a RFC in itself is the specification, although it certainly doesn't sound like it to a person who understands the English language. It's just that "everybody knows" that a RFC is a spec.  So the sentence should have read "As a result, their products do not generally support the latest Internet Engineering Task Force (IETF) specifications for SIP or particular vendor-specific SIP implementations."

In defense of the hapless author, there are actually two relevant points.  The first is that in plain English, the idea of SIP specifications having "remote function calls" actually makes sense.  Indeed, a lot of what SIP "does" is exactly to pass along information to set up a call, hence it being "Session Initiation Protocol."  The only problem is that this is not what RFC means in this particular context.

But to further add to the confusion, there is a common use of the TLA "RFC" meaning exactly "Remote Function Call."  In SAP software, according to Wikipedia, "Remote Function Call is the proprietary SAP AG interface for communication between a SAP System and other SAP or third-party compatible system over TCP/IP or CPI-C connections."  

OK.  So since we're into TLAs, did you ever wonder what SAP stands for?  Kind of like at one point IBM was International Business Machines?  According to at least one source "SAP the company was founded in Germany in 1972 by five ex-IBM engineers. In case you're ever asked, SAP stands for Systeme, Andwendungen, Produkte in der Datenverarbeitung which - translated to English - means Systems, Applications, Products in Data Processing."

So now we have completed the "circle of confusion" with regard to convergence of applications and telecommunications protocols.  You can tell whether a person is a SAP programmer or a SIP geek by what they think "RFC" means.


When I saw you mention "MAC" I thought you were going to mention the cryptographic Message Authentication Code and the DSP Multiply and ACcumulate as well.
I once purposely used the three acronyms (including the Ethernet MAC) in a single sentence to see if people would notice).


One acronym with three meanings in one sentence... Super! Please post it, and let's see if anybody else can use three - or four!

Part of the pedant in me picks up these things. I teach a number of technical courses (MPLS, TCP/IP, IMS, VoIP, SIGTRAN, OSP, BGP)... See what I did right there.... We all use them (acronyms) over and over everyday - its just the language of the industry we're involved in.

So who can't say a complete sentence now without some acronyms creeping in?.... Surely that's actually the only language engineers (like me) now speak? I think it started much further back - in the 70s for me, as a radio ham - I was known as G1GBJ....... Not to mention the 'ol CB Radio lingo "10-4 good buddy what's your 10-20?"- derived from police radio "speak".

We've all been speaking "code" for longer than possible most of us either remember (or possible care to remember?).

Teaching means you've got be acutely aware of what each acronym means to your audience. As a practitioner you become accustomed to using acronyms "in context" and we "assume" a certain meaning... Hey but that's just all part of the rich tapestry of the Comms and CompSci industry.

Thanks for the mention and a great summary of the fun we have ;).


Get E-News and Notices via Email




I accept Webtorials' Terms and Conditions.

Featured Sponsor Microsites

Recent Tweets



Please note: By downloading this information, you acknowledge that the sponsor(s) of this information may contact you, providing that they give you the option of opting out of further communications from them concerning this information.  Also, by your downloading this information, you agree that the information is for your personal use only and that this information may not be retransmitted to others or reposted on another web site.  Please encourage colleagues to download their own copy after registering at  Continuing past this point indicates your acceptance of our terms of use as specified at Terms of Use.

Webtorial® is a registered servicemark of Distributed Networking Associates. The Webtorial logo is a servicemark of Distributed Networking Associates. Copyright 1999-2015, Distributed Networking Associates, Inc.