Keeping with the theme of not forcing everyone to learn how to be a full-stack engineer in a 48-hour period, today's drop continues to focus on the fundamentals. While you were encouraged to go outside last weekend (and, hopefully, a few folks have become life-long sky/star-gazers after reading last week's edition), this weekend you'll be cozied up wherever your glowing rectangle(s) take you as you dig into the wild, wild world of Internet standards. Specifically, we'll

• introduce the Internet Engineering Task Force (IETF) Request for Comments (RFCs)

• explain how to get involved in RFC creation/management

• drop some fun/cool/useful RFCs you may or may not already be aware of

• suggest some IETF RFC working groups you may want to consider either joining, or at least tracking

  Subscribe

IETF & The RFC Creation Process

The Internet Engineering Task Force (IETF) is a community of individuals and organizations working to develop and promote standards for the internet. One of the primary outputs of the IETF is a series of documents called Request for Comments (RFCs). These RFCs are documents that describe how various aspects of the internet work. They can describe protocols for sending and receiving email, for accessing web pages, for routing network traffic, and scads of other things. RFCs can be thought of as the "rule book" for how the internet operates, and they are used by software developers, network administrators, and other folks who need to understand how the internet works. The RFC Series includes documents produced by the IETF, the Internet Architecture Board (IAB), the Internet Research Task Force (IRTF), and independent submitters. All RFCs are published by the RFC Editor, which is the authoritative source for retrieving RFCs.

New RFCs are created through a process of collaboration and review by the IETF community. Anyone can propose a new RFC, and the process begins by submitting a draft document. The draft document is then reviewed by the appropriate Working Group within the IETF, which is a group of individuals who specialize in a particular area of internet technology.

The Working Group provides feedback and suggestions for revisions to the draft document, and the author(s) of the draft document make updates based on this feedback. This process continues until the Working Group feels that the document is ready to be considered for publication as an RFC. Once the Working Group has completed its review, the draft document is sent to the IETF's Internet Engineering Steering Group (IESG) for final approval. The IESG ensures that the document meets the standards and guidelines set forth by the IETF and approves the document for publication as an RFC.

Managing The Plethora of RFCs Out There

RFCs are living, (often, fire-)breathing documents, which means that they can be updated and revised as needed. The IETF community is responsible for managing existing RFCs and ensuring that they remain accurate and up-to-date. If a new technology or protocol is developed that requires changes to an existing RFC, the process for creating a new RFC is followed. The Working Group responsible for the relevant technology or protocol will create a new draft document, which will go through the same review process as a new RFC.

Once the new RFC has been approved and published, the old RFC is updated to reference the new RFC. This ensures that anyone who is using the old RFC is aware of the updates and can make any necessary changes to their systems.

Joining An RFC Working Group

If you're interested in getting involved in the development of internet standards, joining an RFC Working Group is a great way to do so. There are many Working Groups within the IETF that focus on different areas of internet technology, so you can choose a group that aligns with your interests and expertise.

To become involved in an RFC Working Group, you'll need to join the IETF community. This can be done by registering for an IETF meeting or by participating in IETF mailing lists and online forums. Once you're a member of the community, you can begin to participate in Working Group discussions and contribute to the development of new RFCs.

You should 100% get involved in one! (says the dude who is not on any, presently 👀)

Reading RFCs & Featured (Funny) RFCs.

I'm not going to spend a ton of time in this section, as the IETF has a great guide for this. They cover everything.

I'll ask you to start reading RFCs by reading the very first one, as it'll be a trip down memory lane for some who are familiar with ARPA Network (predecessor to the terrible thing that is the modern internet).

Then, I'll ask you to fire up your RSS feed reader and add this feed [direct XML] which will always contain the most recent RFC activity.

Next, I shall beg thee to fire up this one to show that not all RFCs are dull, boring, walls of text. In fact, why stop at that one?

• RFC1097 ↠ Telnet subliminal-message option, B. Miller, 4/1/1989, 3pp.

• RFC1121 ↠ Act One - The Poems, J. Postel, L. Kleinrock, V. Cerf, B. Boehm, D. Waitzman , 9/1/1989, 6pp.

• RFC1149 ↠ A Standard for the Transmission of IP Datagrams on Avian Carriers, D. Waitzman, 4/1/1990, 2pp.

• RFC1216 ↠ Gigabit Network Economics and Paradigm Shifts, P. Kunikos, P. Richard, 3/30/1991, 4pp.

• RFC1217 ↠ Memo from the Consortium for Slow Commotion Research (CSCR), V. Cerf, 4/1/1991, 5pp.

• RFC1300 ↠ Remembrances of Things Past, S. Greenfield, 2/1/1992, 4pp.

• RFC1313 ↠ Today's Programming for KRFC AM 1313, Internet Talk Radio, C. Partridge, 4/1/1992, 3pp.

• RFC1437 ↠ The Extension of MIME Content-Types to a New Medium, N. Borenstein, M. Linimon, 4/1/1993, 6pp.

• RFC1438 ↠ Internet Engineering Task Force Statements Of Boredom (SOBs), L. Chapin, C. Huitema, 4/1/1993, 2pp.

• RFC1605 ↠ SONET to Sonnet Translation, W. Shakespeare, 4/1/1994, 3pp.

• RFC1606 ↠ A Historical Perspective On The Usage Of IP Version 9, J. Onions, 4/1/1994, 4pp.

• RFC1607 ↠ A View from the 21st Century, V. Cerf, 4/1/1994, 13pp.

• RFC1776 ↠ The Address is the Message, S. Crocker, 4/1/1995, 2pp.

• RFC1882 ↠ The 12-Days of Technology Before Christmas, B. Hancock, 12/1/1995, 5pp.

• RFC1924 ↠ A Compact Representation of IPv6 Addresses, R. Elz, 4/1/1996, 6pp.

• RFC1925 ↠ The Twelve Networking Truths, R. Callon, 4/1/1996, 3pp.

• RFC1926 ↠ An Experimental Encapsulation of IP Datagrams on Top of ATM, 4/1/1996, J. Eriksson, 2pp.

• RFC1927 ↠ Suggested Additional MIME Types for Associating Documents, C. Rogers, 4/1/1996, 3pp.

• RFC2100 ↠ The Naming of Hosts, J. Ashworth, 4/1/1997, 3pp.

• RFC2324 ↠ Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0), L. Masinter, 4/1/1998, 10pp.

• RFC2325 ↠ Definitions of Managed Objects for Drip-Type Heated Beverage Hardware Devices using SMIv2, M. Slavitch, 4/1/1998, 8pp.

• RFC2549 ↠ IP over Avian Carriers with Quality of Service, D. Waitzman, 4/1/1999, 6pp., updates RFC1149.

• RFC2550 ↠ Y10K and Beyond, S. Glassman, M. Manasse, J. Mogul, 4/1/1999, 14pp.

• RFC2551 ↠ The Roman Standards Process -- Revision III, S. Bradner, 4/1/1999, 37pp.

• RFC2795 ↠ The Infinite Monkey Protocol Suite, S. Christey, 4/1/2000, 20pp.

There are many more "fun" ones, but I'll leave that spelunking to you.

Serious RFC Business

You are a denizen of the internet, and you're reading this in a browser. Sure, you think you know how the web works, but do you really know? Challenge your assumptions by taking a look at the evolution of HTTP (and associated protocols) through the years.

And, since "it's always DNS" whenever there's an issue, perhaps take a look and see why?

Did you know the data format that powers the internet has some RFCs? (You'll notice the EVIL that is YAML is too daft to be part of the IETF RFC process). Take a good look at those JSON RFCs, since you may not realize there are even standards for efficiently "patching" JSON, then again, you may not have even known there is an HTTP PATCH verb.

If you're security-minded (or just have technical curiosity), reading RFCs can show you how a protocol (like, say, SSH) is supposed to work. In fact, many a server implementation for various protocols has been found to have weaknesses just by implementing an RFC-compliant client for it.

Not all RFCs require deep, technical expertise to read or care about. RFC8890 is a great example of this. Here's the abstract:

This document explains why the IAB believes that, when there is a conflict between the interests of end users of the Internet and other parties, IETF decisions should favor end users. It also explores how the IETF can more effectively achieve this.

Your Mission

Your mission is to fill up a mug of your favorite hot beverage (or cold, if you're somewhere that won't be dipping below 0°F like will be the case outside my abode this weekend), pick some protocol, technology, or cause (like RFC8890) you're interested in, dig into the RFCs surrounding it, and take the bold step of joining a working group. Here are a few to consider:

• Building Blocks for HTTP APIs

• HTTP

• Internet Area Working Group

• IPv6 Operations

• Web Authorization Protocol

• QUIC

Hit up the list of all active groups to see more (or start your own!).

If that sounds too intimidating (other humans can be scary beasts, at times), then take something you think you know well — perhaps HTTP! — and test your knowledge by looking through the evolution of the protocol and seeing what you may have missed.

Did I hear you say time is scarce for you this weekend? Then, consider your mission fulfilled if you just follow the aforementioned suggestion to add the "recent RFCs" feed into your favorite RSS reader and keep up with the latest developments.

FIN

To readers in the forthcoming frigid conditions: keep warm! ☮

Share