On the Lua Users email list [1] the topic of custom email headers came up. Back in the early days, RFC-822 [2] stated that:
Any field which is defined in a document published as a formal extension to this specification; none will have names beginning with the string "X-" …
“RFC-822: STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES [3]”
This also applies to headers starting with “x-” as Internet based text headers are case-insensitive.
Now given that RFC (Request For Comments)-822 has been obsoleted by RFC-2822 [4] and RFC-5233 [5] I thought I would check those out as well:
Fields may appear in messages that are otherwise unspecified in this document. They **MUST** conform to the syntax of an optional- field. This is a field name, made up of the printable US (United States)-ASCII (American Standard Code for Information Interchange) characters except SP (space) and colon, followed by a colon, followed by any text that conforms to the unstructured syntax.
The field names of any optional field **MUST NOT** be identical to any field name specified elsewhere in this document.
“RFC-5322: Internet Message Format [6]”
Hmm … nothing about “X-”. I replied that starting a non-standard header with “X-” was still a safe way to go, only for Cu nningham's Law [7] to kick into effect:
From: Daurnimator <XXXXXXXXXXXXXXXXXXXX>
To: Lua mailing list <lua-l@lists.lua.org>
Subject: Re: Adding another way to point to "levels" to debug.getinfo and friends
Date: Mon, 13 May 2019 11:55:07 +1000
> On Mon, 13 May 2019 at 09:03, Sean Conner <sean@conman.org> wrote:
> > In other RFC documents (too many to mention) private or experimental fields are usually labeled with "X-" (or "x-") so your best bet is to create a header name starting with "X-" to be safe.
>
Please stop using the X- prefix! See RFC 6648 [8]:
> > This document generalizes from the experience of the email and SIP (Session Initiation Protocol) communities by doing the following:
>
> 1. Deprecates the "X-" convention for newly defined parameters in application protocols, including new parameters for established protocols. This change applies even where the "X-" convention was only implicit, and not explicitly provided, such as was done for email in [RFC822].
>
Interesting. The “X-” standard for non-standard headers was to allow for experimentation without fear of conflicting with other headers, but the process of converting such headers to a standard header prove problematic. But RFC-6648 does cover the case when one doesn't want to standardize a header (or parameter):
… In rare cases, truly experimental parameters could be given meaningless names such as nonsense words, the output of a hash function, or Universally Unique Identifiers (UUIDs) [RFC4122 [9]].
“RFC-6648: Deprecating the "X-" Prefix and Similar Constructs in Application Protocols [10]”
What a wild idea!
[1] http://lua-users.org/lists/lua-l/
[2] https://www.ietf.org/rfc/rfc822.txt
[3] https://www.ietf.org/rfc/rfc822.txt
[4] https://www.ietf.org/rfc/rfc2822.txt
[5] https://www.ietf.org/rfc/rfc5322.txt
[6] https://www.ietf.org/rfc/rfc5322.txt
[7] https://en.wikipedia.org/wiki/Ward_Cunningham#Cunningham's_Law
[8] https://www.ietf.org/rfc/rfc6648.txt
[9] https://www.ietf.org/rfc/rfc4122.txt