As well, if you use Base32 from RFC4648 (letters A..Z and digits 2..7), to encode a 128 bit UUID, the 26 chararacters encoded will actually encode 130 bits. This means they encode 2 spare bits, and you can use them to avoid some characters in the first and last position in the 26.
If you want to avoid the X or digits in the first position (because it is used in many legacy apps), it's simple: make the first spare bit equal to 0 and put it in the highest order position of the 1st group of 5 bits (so the first encoded character will necessarily be a letter in A..P).
As well you can avoid the last character to be a digit in 2..7 by also inserting the second spare bit in the highest order position of the last group of 5 bits.
Now the 26 characters can be written in groups of 5 characters by hyphens (-).
You get header names like in the set from "Aaaaa-aaaaa-aaaaa-aaaaa-aaaaa-a:" to "P7777-77777-77777-77777-77777-p:" (you can use any capitalization you want for the letters) which are still relatively easy to read/write and possibly memorize (thanks to grouping and the choice of non ambiguous letters/digits), unique (randomly generated), and even shorter then some legacy "X-" header names like "X-Pepperfish-Transaction:", and none of these random header names will collide with legacy "X-" ones (different form) or with future RFC that will deprecate RFC2822 in its standard track (using human-significant keywords), and that still look in good format very legacy mail processors.
