Re: Adding another way to point to "levels" to debug.getinfo and friends

[Sean Conner <sean@...>]

It was thus said that the Great Daurnimator once stated:
> 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:
> 
> This document generalizes from the experience of the email and SIP
> 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.  Quoting a bit more:

	Creators of new parameters to be used in the context of application
	protocols:

	1.  SHOULD assume that all parameters they create might become
	    standardized, public, commonly deployed, or usable across
	    multiple implementations.

	2.  SHOULD employ meaningful parameter names that they have reason
	    to believe are currently unused.

	3.  SHOULD NOT prefix their parameter names with "X-" or similar
	    constructs.

	Note: If the relevant parameter name space has conventions about
	associating parameter names with those who create them, a parameter
	name could incorporate the organization's name or primary domain
	name (see Appendix B for examples).

and later on:

	... 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].

  So 6dd39dca-34a1-4d0c-b1eb-30481b7ec7a8 would be a perfectly cromulent
header name to use for private experimentation.

  -spc (Although it looks really weird ... )