Primary Services
Suite Creation Suite Component
Ref Form Ref Type



Navigating RFCs:
Internet Technology Document Suites


What is the set of current documents with the technical details of a particular service? Answering this question can be daunting, especially when the service has a long history, filled with formal changes, enhancements, errata notes and esoteric lore. This Document Suite wiki provides a home for collaborative, on-going efforts at recording such information about popular Internet capabilities. An Internet service is described by a collection of specification and support documents, along with informal commentary to guide development, deployment, operations and use. This collection forms a Technology Document Suite. Occasionally there is an attempt to develop a document that, itself, describes the current set of documents for a service. These are rare and incomplete efforts, helpful but insufficient, and quickly obsolete. As a wiki, the current effort permits on-going, incremental revision to track the evolution of a service.


This is a wiki, under development. It is currently maintained as an html page, and will be converted to wiki form when the structure and style of its contents begin to stabilize. As a proof of concept, this initial exercise needs to develop a thorough handling of a few, interestingly-complex and interestingly-different examples for well-established services.

D. Crocker <> (Last update: 23-May-2012 7:08 AM )

The term "service" is meant as a high-level, integrated reference, such as "the Web", email, or IP. Some services are quite broad and have subordinate services. Ultimately, a service's document Suite can consist of many parts, covering:

The wiki table entries describe distinct sub-services or functions within an integrated service. Citations are not limited to RFCs. Reference to web sites, wikis, books, other standards, or any reference that is helpful is encouraged.


There will be a mailing list for this; in the interim, please send questions, comments and suggestions to:

Dave Crocker <>

Almost any interesting service comprises a set of specifications. This means that the service will need a subordinate Suite table.

The major challenge in developing a service Suite appears to be choosing what to list in the "Components column". The rows formed by these choices present the primary conceptual organization of the service. The second challenge is determining when to define subordinate Suites (in the third column). This establishes a hierarchy to the service structure. These choices need to match both the way the technology specifications have been written and the likely manner of using specifications needed by implementers and operators.


A document Suite is of the general form:

Example:  Ultimate Widget Suite







A service for the exchange of ultimate widgets


  • Format (Meta-Form - RFCdef)
  • Registration (Fields - RFCghi)
  • Registration (IANA)

Each widget has fields that are individually defined.

Field registration might be better to put in the Fields Suite?


  • Protocol (RFCjkl)
  • Registration (Port 000 - IANA)

Perhaps there should be a pointer to the TCP or UDP Suite?



MIB for widgets


This wiki was prompted by a Slashdot article which has also prompted graphically-oriented work by Ray Bellis that is used in this wiki. The set of Internet technical documents has become complex and confusing. The problem of guiding new readers to a correct and coherent set of these documents is overdue for attention.


Table Legend

A table specifies one or more services, or one or more components of a service. It is organized to list a series of components by row. For each entry, the documents that apply to everything related to that entry are listed in the References column. Constituent entries are listed in the neighboring Suite column.

Suite Component

Each row of a Suite table specifies an entry for a service component.

Technology Service Components: The name of the service or component. A service provides a complete capability. To be useful, a component must be incorporated into a service. One service can be incorporated into another. Note that organization of the entries within a Suite serves as a principle summary of the organization of the capability being described by the Suite.
References: Direct citations to documents, online sites or the like for discussion, overview, foundation, guidance, or even complete specification. (See the References list, below.) Notationally, for a Suite branch -- a Suite and its sub-Suites -- this specifies leaves..
Sub-Suites: References to subordinate tables. These list sets of components that are related to the (superior) service or component. Notationally, this specifies transit links down the Suite branch.

In addition to technical specification documents, a number of other types of documents and sources of information are common. An entry should include whatever citations are helpful and label them however appropriate. For the types of citations that are common, standardized labeling will help the reader to more easily understand the table.

To that end, here is a suggested form to citations and some common labels to use:


These are some common types of references. It will help to converge on regular terminology for these types and to make references generally follow a consistent form.


A reference should be one of the forms:

{Reference type} ( {label - {citation} )
{Reference type} ( {label} )
{Reference type} ( {citation} ) 


Reference Type: See the following table, to characterize difference style of documents and information
Label: Any short string of text that will help the reader to distinguish among a set of related references. Often this should be a terse form of the document title or description of its contents. Sometimes, this information and the citation are merged,
Citation: The information needed to retrieve the information, optionally encoded as a citation label and associated URL. For example, the RFC number and a link to the RFC archive.


Foundation (RFC5598)
Registration (Port 587 - IANA)
Registration (Header Fields - RFC4021)


Activity: A service is usually created through independent community effort that begins before standardization, to formulate community need, and continues afterwards, to promote adoption and enhancement. This entry refers to the independent website that represents such an effort.
Standards: The web page associated with standards-oriented effort for this service. For this wiki, this will usually be the IETF working group page. Note that more than one standards organization can be involved in a service, such as to provide component capabilities.

Free-form consideration of a topic.

Overview: Any document that provides a summary tutorial about the service
Bellis: A citation for a graph that depicts the set of documents related to this service.
Ray Bellis (Nominet) has developed a tool which formulates a visual representation of related RFCs, per his discussion.
Yellow nodes are active documents and gray are historic. Curved corners are specification standards; sharp corners are operational.
Foundation: Specifies the an ecompassing view of the service, with aframework, model, roadmap, architecture or the like, for a services's components, their relationships and interactions (protocols).
History: Discussion of the background and experiences with the service.
Parent link: (Just being diligent, here.) Complex service Suite structures might warrant pointing from a subordinate Suite to its parent, to help the reader recover context.

Protocol: Specification of a networking protocol
Format: Specification of the syntax and/or semantics of data
Register: For a protocol to become a service, it needs access registration, which specifies how to reach the service, from among an extensive suite of services. An example is a TCP port number. This entry points to the registration specification for this service.
MIB: Specification for a Management Information Base for the associated protocol.
Profile: Tailored use of the service.

Develop A discussion about activities that aid in the creation of interoperable implementations.
Operations: The document provides discussion and possibly recommendations concerning efforts to install and run the service.
Reference: Open source, reference implementation software.
Author: Contact information for person or role that created the Suite


Suite Creation

This section provides suggestions about the process of creating a new Suite. Since this wiki is still under initial development, the guidance is, at best... nascent. To the extent that you see flaws in the guidance, please treat that insight as the most valuable part of your effort and communicate it to others working on the wiki. At the least, please send a note to Dave Crocker.

NOTE:   Although the wiki is intended for implementers and other adopters of a service, it might also prove useful for creators of the service. That is, it is worth exploring whether to create a Suite during the early stages of specification and standardization. A possible benefit is the terse, integrated view of the service that a Suite provides but is not typically provided elsewhere.

Component Sequence

A Suite organizes and lists a combination of citations and sub-Suite pointers. It is formed as a series of rows, with the focus of the row being defined by the left-most column. That column defines the different "components" of the Suite. Obvious choices for guiding the organization of a list of components are:

Architectural parts: how its design is structured
Functional parts or Roles: how it is implemented
Phases of processing: how its use can be divided into steps

The organization of a Suite can offer a reader important insight to the nature and details of a service. So, choosing the right organization can take some effort. Sometimes it will help to combine these approaches, such as a Suite organized by Function that then calls on Suites organized along architectural or processing lines, as in DNS Role and DNS Technology.

NOTE: In most cases, simply listing protocol names as the sequence of Suite component labels is likely to be the least helpful approach. Use the protocol name for the citation or Suite reference. For the component label, consider using text that describes the nature, purpose or function being supplied.

Competing Suites

Because the organization of components in a Suite imparts a particular perspective on a service, it is possible that an alternative – and equally reasonable – perspective will lead to an alternative organization of components. It is also possible that it will not be obvious which perspective is superior for use in the wiki. It is even possible that it will never be possible to make the choice.

That's ok. Make two, competing Suites! The wiki makes this easy and the ultimate winner – if one ever is determined – can be left to the crucible of actual use.

In fact, the competition can turn out to be complementary, with one perspective using the other. Take a look at DNS Role versus the "subordinate" DNS Tech Suites.

Reference vs. Sub-Suite

The choice between listing a series of citations in the References portion of a component entry, versus defining a sub-Suite, seems to depend on the complexity created by the set of citations. If there is salient information to be supplied by creating the organization of a sub-Suite, or if the set of citations is simply too complex for a single References cell, then do use a sub-Suite. On the other hand, sub-Suites mean increasing the complexity of the Suite hierarchy. Less hierarchy is preferred.

Reference Form

A reference contains 2-4 bits of information. The two that are required are the 'type" of the reference and the pointer to it. The type of a citation tells the reader what the citation is generally useful for. This is the first field because it appears to be the most useful to an implementer trying to filter among a set of references. The pointer gets them to it. One optional field is text that will help the reader distinguish among a set of closely-related citations, as well as provide them with a popular tag that others will use to refer to the citation. The other optional field distinguishes between the human form of a citation and the online form.

For RFC citations, It is probably best to refer to the version, since this also lists context around the document, including errata and process history.

Include vs. Exclude

The goal of this wiki is to provide potential implementers with the information they need now. In general, this means that deprecated or historical information typically should not be included. A particular example would be specifications that have become obsolete. Obvious exceptions will be documents that are deemed essential for a current implementer to understand, in spite of the document's formal status. However, the goal of the wiki means that it is just as important to exclude extraneous information, as it is to include essential information, lest an implementer waste time tracing down unproductive references.

A Typical Suite Creation Sequence

Even a relatively complex service will require only a few hours to complete an initial version of a Suite. An approach that seems to be relatively efficient is:

  1. List relevant documents.  This gets incrementally better as the effort proceeds, of course. So the first round should be extensive but does not have to be 100% complete.
  2. Try to loosely organize the documents into meaningful sets. Examples to review - email, dns, ldap.
  3. Develop labels for those sets of documents that explain why they make sense as a group.
  4. Organize the sets into Suite rows and sub-Suites.
  5. Iterate.  Reviewing tends to produce new insights about how things should be put together.


Table of Suites: Primary Internet Services

(Note how many services still need to have Suites supplied. Please take that as an intivation!)


Data Format and Packaging


  • Email
  • XMPP/Jabber

World Wide Web

  • HTTP


  • VCal

Voice over IP (VOIP)

  • SIP




  • NTP

File Transfer

  • FTP
  • SFTP

Terminal Access

  • Telnet





Reliable Stream

  • TCP

Unreliable Datagram

  • UDP


  • SCTP
  • RTP
  • DCCP




  • IPv4
  • IPv6


  • DHCP

Domain Name Service


  • IP over ...



  • BGP


  • OSPF
  • IS-IS



  • S/MIME
  • OpenPGP
  • SASL


Network Management

  • SNMP



  • Tao
  • Structure


  • Standardization
  • Operation

Document Conventions

  • ABNF
  • Security


  • Format


Email Suite






  • Foundation (Architecture - RFC5598)



Note that IMF is at this level, but MIME is subordinate, given the design of its role in email. Note that it should also be subordinate in the Web tree.

Does the header warrant its own Suite?

Mail Submission

Posting new mail into the handling system.

Is Submission strictly a profile of ESMTP? No doubt, "SMTP" needs to be a Suite. Perhaps several, such as old SMTP versus ESMTP?

Mail Relaying

  • Registration (Port 25 - IANA)

Infrastructure transmission of mail.

Note that the SMTP "protocol" specification is used for two different services. Do relaying and Submission need different Suites?

Mail Access


User access to a Message Store for reading and managing received messages.

This probably needs to be changed to a "mail access Suite" and a subordinate table. I'm not yet clear whether the components column should invoke a Suite if there is more than one entry.

  • Specification (Delivery - RFC3461)
  • Specification (Disposition - RFC3798)
  Sending notices back to originators about the outcomes of message delivery or receipt.

Mailing List Managers



Mail Gateways

  • X.400
  • Facsimile (iFax)
  • Voicemail (VPIM)

A gateway provides access to non-email devices or services.

VPIM and iFax are both profiles of email and gateway services to non-email devices. Not sure how to class such things.


  • Voice Mail Profile (VPIM)
  • Facsimile Profile (iFax)
  • Lemonade

Profiles are tailored uses of email.

VPIM and iFax are both profiles of email and gateway services to non-email devices. Not sure how to class such things.

Internationalized Mail (EAI)
  • Foundation (Framework - RFC4952)
  • Foundation (Framework - RFC4952)
  • Internationalization (eai RFC4952[bis))


MIME Content Suite





MIME Format

  • Format (RFC2045)
  • Format (Non-ASCII Text - RFC2047)
  • Extensions: Character Sets, Languages, and Continuations (RFC2231)
  • Develop (Conformance - RFC2049)
  • Critical Content Parameter (RFC3459)
  • Registration (Procedures - RFC4289) (Header Fields - RFC4021)

Structured and type-labeled data.

Media Types


Media feature capabilities -- facilities assumed to be available for the message content to be properly rendered or otherwise presented -- as a combination of simple media feature tags


Deployment & Operations







  • ODA
  • Fax
  • Postscript



Message Security Suite





Content Protection & Authentication Validation


  • OpenPGP
  • S/MIME


Responsible Agent

  • Domain Keys Identified Mail - (DKIM)

Attach authorized domain name to a message, indicating an identity taking 'some' responsibility for the message.


SMTP Suite





Simple Mail Transfer Protocol

Infrastructure relaying mechanism


  • Protocol (SMTP Authentication)
  • Protocol (SMTP/TLS - RFC2487)
  • Protocol (Sender Policy Framework (SPF) - RFC4408)



SMTP Extensions Suite





Core Extensions   Incremental, optional enhancements to basic SMTP service

Mailing List


Verify addresses

Pull-based Relay ("turn")


Receiver-initiated pickup

Data Encoding

  • Protocol (8BITMIME -[RFC-ietf-yam-rfc1652bis-03.txt)
  • Protocol (Binary MIME - RFC3030)
  • Protocol (UTF8SMTP - RFC5336)

More than basic 7-bit ASCII

Security & Management

  • Protocol (STARTTLS - RFC3207)
  • Protocol (AUTH - RFC4954)
  • Protocol (SUBMITTER - RFC4405)
  • Protocol (Message Tracking (MTRK) - RFC3885)



Submission (Posting - Port 587)

  • Protocol (Remote Content (BURL)- RFC4468)
  For posting new mail, rather than relaying existing mail.


IMAP Suite





Internet Message Access Protocol (IMAP)

  • TCP
Remote mailbox access


POP Suite





  • TCP
Remote mail downloading


DKIM Suite





Domain Keys Identified Mail (DKIM) - General



DKIM authenticates the domain name of a responsible agent associated with a message. The Deployment doc includes an architectural framework for trust-related email processing.



The profile is guidance for using a subset of DKIM signing options.

Signer Practices


Publishing a signed-name linkage to the From: field.

Mailing List Considerations




  • Specification (Name owner - draft-kucherawy-dkim-reporting.txt)
  • Specification (Consumer -authentication-results)

Sending performance and error data to the owner of a DKIM-related domain name; and
Passing the output of DKIM (or other authentication process) to a process that will use the results.


Facsimile Suite





Basic iFax


Facsimile over email

Full iFax Suite




VPIM Suite








Voice messaging



EAI Suite





Email Address Internationalization




DNS Role Suite







Domain Name mapping service

Authoritative Server

  Holds the definitive (authoritative) information

Recursive Server

  only receives requests from stub resolvers; re-queries and caches answers

Stub Resolver

  Typically a code library pseudo-server

Forwarding Server

  Proxies queries between one network and another

DNS Core Tech Suite






Domain Name Service Core

  • UDP
  • TCP

Legacy core

Transport Extensions

  • TCP

Enhanced core

DNSSEC   Data security

DNS Authoritative Tech Suite





Zone Update and Transfer



Security   Transport security

DNS Name Tech Suite





Name Handling    








DNS Data Security:
"a set of extensions to DNS, which provide:
a) origin authentication of DNS data,
b) data integrity, and
c) authenticated denial of existence."

  • Format (Resource Records - RFC 4034)
  • Protocol (Core Modifications - RFC 4035)
  • Protocol (Resolver Support (DO bit) - RFC 3225)
  • Protocol (NSEC records - RFC 4470)
  • Protocol (Anchor Updates Anchors - RFC 5011)
  • Protocol (NSEC3 records - RFC 5155)







LDAP Suite







Lightweight Directory Access Protocol


  • TCP





Data Components