From: Greg Berigan (gberigan@cse.unl.edu)
Date: Thu Sep 04 1997 - 10:39:07 CDT
Jacob Palme <jpalme@dsv.su.se> wrote:
>Here is a suggestion for a new text about X-headers, to replace the
>present text in both draft-ietf-drums-msg-fmt and son-of-1036-revised.
>
> Headers not defined in this standard or other IETF standards SHOULD be
> ignored unless there is an understanding between the sender and
> recipient of how to handle particular such headers. If there is a need
> for an additional header for special purposes, for use between cooperating
> software which can handle the additional header, two methods are possible:
>
> Method 1: Register the new header with the IANA registry of e-mail
> headers. This involves a check that someone else is not using the
> same header for a different purpose, and can also involve a check
> if someone else already is using a header which you might use instead
> of inventing a new header. For more information, see
> draft-drums-MHRegistry-01.txt (to be replaced by a reference to the
> corresponding RFC).
>
> Method 2: Use a header, whose name begins with "X-".
>
> Advantage with method 1: If your new header is useful, it can in
> the future turn into a standard. "X-"headers cannot become standard.
> Because of this, "X-" is not suitable if your header might become
> generally useful.
>
> Advantage with method 2: No future standard will ever use your
> new header, so there is no risk for future collission with new
> standardized header. There is however still a risk for present
> or future collission with someone else who uses a header with the
> same "X-" name but for a different purpose. This risk is avoided
> with method 1.
Actually, I was thinking about this myself and thought that all
non-standard headers should (must) be X-headers, and that X-headers could
eventually progress from experimental headers to standard headers.
Software would be written to handle the after-market X-header and also that
same header without the X- prefix.
Similarly, persistent headers or P-headers would also continue to persist
across responses and would also eventually be promoted to prefixless
standard persistent headers. (Currently, the only persistent headers are
Subject, Newsgroups, Keywords, and References.) They would also persist as
X-P-headers (experimental persistent headers). Software should recognize
the header without the P- just as it should recognize it without the X-.
(Or should these be P-X-headers, the P-class of headers be generally
adopted by the standard, never losing the P- prefix?)
This `support for headers without the prefix' eases the upgrade path for
the early adopters in regards to incoming articles; they could have a
configuration option to alter whether they prefix the header or not.
(An example would be an X-P-Author-Tags header where posters put a standard
string they define for themselves--possibly based on their e-mail
address--in this header which, with a properly configured news server, can
be used to trace followups. It would have a smaller size than References
since no tag could appear more than once in the header. It is an X- since
it isn't in the standard. Additionally, to work it must persist across
messages much like References. Readers which know about P- headers but
don't know what Author-Tags has for content would pass this header
untouched into their message (much like Keywords). When Author-Tags gets
recognized as a standard header, the X- is dropped and, until wide adoption
of the header is attained, it exists as a P- header, still persistent.
Eventually the P- would be dropped and Author-Tags would be persistent on
its own without any prefix. The newsreaders that started using
X-P-Author-Tags would be coded to recognize the same header as
P-Author-Tags and Author-Tags.
Thoughts? Drawback: unless they are adopted into the standard, this makes
certain non-X-header after-market headers like Originator and
NNTP-Posting-Host illegal under the standard, requiring them to be prefixed
with X-. I think we would be better off keeping all non-standard headers
under the X- umbrella, whether or not they are suggested as new standard
headers. The above methods 1 and 2 seem to say that colliding with future
standard (X-less) headers is preferable to colliding with current
non-standard X-headers, generally deprecating the X- prefix entirely.