Kent discusses PEM, PSRG, IAB, RFC, SRI, OSI, LAN, UA, MTA, POP, TCP, IP, SMTP, UI, MIME, X400, X500, BITNET, UUNET, RFC 822, RFC 821, RFC 1423, CCITT, X509, ISO, MIC, CRL, ASCII, ANSI, MD5, RSA, DEK, DES, CBC, CA, IPRA, DCA, RFC 1422, MIC-ONLY, and MIC-CLEAR, definitions of which can be found in the paper. Unless you have a compelling need to understand sentences such as “This data base is coordinated among the IRPA and the PCAs and will contain CRLs issued by the IRPA, all PCAs and all CAs,” you might try to find a more expository paper.

The paper is hard to read because of all of the abbreviations and acronyms, of which the quoted sentence is unfortunately not an extreme example. Some people should probably read the paper, but it appears to be written for the cognoscenti. I read it, I think I understood it, but I am not now sure how informed I am.

The paper is also interesting in that it contains a full-page encrypted message example from RFC 1421. Clearly the format was designed by some common carrier that bases revenue on the amount of bandwidth consumed. It appears that the two-line encrypted message takes about 40 lines of Privacy-Enhanced Mail (PEM) protocol data. I agree that the same 40 lines would support a 200-line encrypted message; the example message is just an unfortunate choice and gives the wrong impression.

There ought to be some limit on the amount of jargon one is permitted to include in papers for publication. With most of the abbreviations unfamiliar to readers other than those working with the subject every day, a full crib sheet of abbreviations used on a particular page should be published on each page. That way a reader could refresh his or her memory as many times as needed regarding what each abbreviation means. In the words of the paper, it needs a much better UI (user interface).