At 02:07 PM 1/30/02 -0500, Keith Moore wrote:
and no Provisional field be added to the registry without
either IETF consensus or IESG approval.
... but folks who have expressed an interest in the provisional registry
aspects have argued that not allowing a reasonably full coverage all
headers, good and bad, would weaken the informative purpose of the
provisional registry.
I am assuming that either IESG or a consensus process will approve
additions to the registry for the "informative" purpose of documenting
pre-existing practice. Jacob Palme's documents would make a good
starting point for this. The trick is to document existing practice
without making it too easy to stake a claim for poorly chosen headers
that don't exist yet.
I guess I'm having difficulty buying into your (apparent) premiss here,
that the existence of a provisional registry will initiate a land-grab for
header names.
That's not quite what I'm worried about - it's more that the existence
of such a registry would effectively confer legitimacy on nonstandard
field names (even if the document defining the registry specifically
said otherwise) - both by making such field names more visible and by
establishing a "claim" to particular field names.
I really should back off and see what other people think, but there's one
more viewpoint I'd like to offer: it could be argued that the existence of
an open registry would have the opposite effect; i.e. it could encourage
developers with half-baked ideas to come together, pool their thoughts and
come up with something more fully-baked?
If the registry did have that effect, it would be a Good Thing. But the
only way that I can see to have this effect is to encourage people to
get consensus on specifications for new fields before they are defined,
and especially, before they are widely deployed.
Once there are deployed implementations that use a header field in
a particular way, it's usually too late to fix what's wrong with it.
To emphasize this, I'd be tempted to add something to the provisional
registry disclaimer, along the lines of:
[[[
Registration as a Provisional Message Header does not imply any kind
of endorsement by the IETF, IANA or any other body.
The existence of any provisionally registered header name does not
represent any kind of claim or priority for a corresponding entry
in the normative registry.
]]]
I think the disclaimer is appropriate, but I don't think it solves the
problem. Visibility of the fields in the registry will have the effect
of conferring legitimacy even if there is such a disclaimer.
Mulling some more, I do see a potential problem that you may be alluding
to, and have another thought. Allowing provisional registration of non X-
headers might be seen as tacitly acknowledging that it's OK to use them
without standardization, regardless of what the protocol spec may say.
That's close to my concern
How about changing the rules for provisional registration to allow all
comers for header field names beginning with X-, and require IETF consensus
or IESG approval for anything else? (I'd need to check that this has the
desired effect for HTTP and News.)
That would be fine with me.
Keith