[dispatch] Re: Proposal for New Work: OODA-HTTP — Adaptive Security Framework for HTTP/HTTPS

[John C Klensin <[e-mail]>]

--On Friday, July 4, 2025 08:49 +0200 Mark Nottingham
<mnot=[e-mail]> wrote:

> Just to clarify - 6648 deprecates x- for protocol elements no
> matter what the intent of the authors or the status of the document
> -- because intent and status can change, and are hard to predict.


TL;DR summary: Hmm...  As I read it, and, as explained below, as it
has been widely interpreted in subsequent work, 6648 does not
"deprecate" X- (or at least its use).  What is deprecates is such use
with any special interpretation of "X-" or ("X"), case independent,
in parameters or similar values. 

Details:

RFC 6648 "deprecates the convention" (quote from the Abstract) that
"X-" designates something special, i.e., that it is an unstandardized
parameter (or other name).  Several other protocols developed after
it was published have interpreted it for over a decade as "A leading
'X-' (or simply 'X') has no special status" rather than as "Leading
'X-' is not allowed".  That interpretation may be inconsistent with
at least some readings of Section 3, bullet 3 of 6648 but is
consistent with Section 4, bullets 1, 4, 5, and 6.   

For updates, and probably extensions/ forks to existing protocols,
the second paragraph of Section 5 (Security Considerations) is
probably key (and, unlike the provisions of Sections 3 and 4 is a
"MUST NOT", not a "SHOULD".  Section 6 (IANA Considerations) fairly
explicitly allows updates to protocols that specified "X-" as a
convention about standardization status to remove that interpretation.

That small confusion is further emphasized in Appendix A, which says 
	'However, use of the "X-" prefix in email headers was
	effectively deprecated between the publication of [RFC822] in
	1982 and the publication of [RFC2822] in 2001 by removing the
	distinction between the "extension-field" construct and the
	"user-defined-field" construct'
If "deprecated" in that context is interpreted as "Use of 'X-' is
forbidden, the statement is simply false because removing the
distinction simply made "X" another character rather that prohibiting
its use.    What that change deprecates is giving an "X-" construct
any special meaning.

I think it is safe to say that RFC 6648 prohibits the use of "X-" in
new work to denote a distinction about standardization and local use.
It is also safe to say that, given history that 6648 does a good job
of explaining, that the use of "X-" in new work is probably dumb, but
6648 itself does not turn that into a prohibition.

best,
   john



>> On 3 Jul 2025, at 7:36 pm, Dale R. Worley <[e-mail]>
>> wrote:
>> 
>> Ted Hardie <[e-mail]> writes:
>>> ...  This is a BCP
>>> recommending against the use of X- headers and similar constructs.
>>> ...
>> 
>>> On Thu, Jul 3, 2025 at 2:45 AM Rachid Bouziane
>>> <[e-mail]> wrote:
>>>> ... (via the X-OODA-Action header) ...
>> 
>> I am not an expert on security work, but I've worked with IETF
>> protocols and their extensions for many years, including fretting
>> about whether/when to use "X-" headers.  In the OODA-HTTP context,
>> since you want it to be WG work, and thus ultimately an RFC, any
>> headers defined by the RFC definitely *should not* have "X-"
>> because the headers will be standardized.  After all, the only
>> meaning of "X-" is "this is not a standard header and I want to
>> make sure nobody mistakes it for one".
>> 
>> Dale
>> 
>> _______________________________________________
>> dispatch mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 
> _______________________________________________
> dispatch mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]