* * * * * Experimental headers are no longer experimental 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 > To: Lua mailing list > 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 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 [10] https://www.ietf.org/rfc/rfc6648.txt Email Sean Conner at sean@conman.org .