In <p05001900b613064073f9(_at_)[130(_dot_)237(_dot_)150(_dot_)139]> Jacob Palme
<jpalme(_at_)dsv(_dot_)su(_dot_)se> writes:
Very strong requirements ^ Only headers from published IETF standards.
|
+ Only headers approved by a thorough vetting
| procedure.
|
+ Only headers accepted by a vetting procedure
| similar to that for new Content-Types.
|
Very lenient requirements v All reasonable proposals accepted.
Arguments for strong requirements: Avoid badly defined headers
to get into the registry.
Arguments against strong requirements: New headers would not get
into the registry, because of the difficulty in getting them
registered. And no large harm is done by adding a header which
never succeeds, there are lots of synonyms to use. For example,
suppose the registry register a badly defined "Obsoletes", IETF
can then define a better defined header, and call it "Replaces"
or "Supersedes". The badly designed header can stay in the
registry, possibly with a note saying that its use is not
recommended.
I think you just follow existing IANA practice. You get them to set up a
"booking" mechanism that reserves the name of some header on a temporary
basis while an RFC is being prepared. I believe you can already get
provisional port number allocations in this way.
But the main and permanent registry should only hold headers than have
appeard in standards-track or experimental protocol published RFCs.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Email: chl(_at_)clw(_dot_)cs(_dot_)man(_dot_)ac(_dot_)uk Web:
http://www.cs.man.ac.uk/~chl
Voice/Fax: +44 161 437 4506 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