In
<5(_dot_)1(_dot_)0(_dot_)14(_dot_)2(_dot_)20011006082240(_dot_)03864d60(_at_)joy(_dot_)songbird(_dot_)com>
Graham Klyne <GK-lists(_at_)ninebynine(_dot_)org> writes:
I think there are several mechanisms that could be used. Ones menmtioned
so far have included:
existence of an internet-draft
Designated Experts
registry of "bogus" headers
[...]
For an IANA registry, the criteria for IANA to apply have to be very clear
and straightforward. To my mind, that means limiting the conditions to one
stated in RFC 2434 unless there is a really compelling reason to do
something else.
Indeed, we want to work within RFC 2434 if we possibly can. But the
mechanisms provided there already provide quite a lot of flexibility.
For example, one might define a "status" field for a header (or perhaps a
header/protocol pair) with values such as:
standards track
experimental
provisional
deprecated
Inclusion of "standards track" in the register would be automatic, upon
publication of the RFC. Possibly "experimental also".
The other two would be on the authority of the "Designated Expert" (with
the appeals mechanism set out in RFC 2434). The designated expert would
have some rules to work to, for example that "provisional" would only
remain so long as a current internet-draft existed, and possibly only one
proposed by an established IETF Working Group. Not sure what rules would
apply to "deprecated", but several people have been saying we need such
entries for plainly "bogus" headers.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clw(_dot_)cs(_dot_)man(_dot_)ac(_dot_)uk Snail: 5
Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5