At 12.02 +0000 01-10-03, Charles Lindsey wrote:
I think the intention of this registry should be to supersede the function
of RFC 2076 and its extensions.
I agree! I would not like to have to continue to
maintain RFC 2076 if a header registry exists.
At 12.52 -0400 01-10-03, Keith Moore wrote:
It would be nice if there were a standards-track document that clearly
said: header "FOO" is bogus and you should neither generate it nor use it.
RFC2076 today specifically says that certain headers
are discouraged, mainly because of several existing
incompatible uses. If the new registry is to replace
RFC2076, it must cater also for specifically
non-recommended headers.
At 19.00 +0100 01-10-03, Graham Klyne wrote:
OTOH, this does not prevent some other protocol from reusing the same
name, possibly with modified syntax, parameters, etc, but hopefully for
some related purpose. For example, RFC 2616 does some markedly different
things with its Content-Type header (but well within the spirit of MIME).
Hopefully, there will be just one *defining* RFC.
You have a counterexample yourself, "Date:" which has
different syntax in mail and http.
At 20.28 +0000 01-10-05, Charles Lindsey wrote:
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
I guess some combination of these may be needed, and there are doubtless
other possibilities.
A user of the registry would certainly get most help if one
search of the registry will suffice to find all information
about a particular header name. This means that there
should be one search point from which you can find them
all. Possibly, this search point could have
checkboxes to indicate that you only want to search for
standardised or only for HTTP or only for discouraged
headers. But in that case, the default should be that all
these checkboxes are checked.
At 16.52 -0500 02-01-30, Keith Moore wrote:
> 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.
I do not think that is possible. If people feel the need
for a header, they will implement it, even if there is no
consensus. Take for example my suggestions for translation
headers. You did yourself recommend, if I remember rightly,
that we should implement it and get experience with it
before asking to have it made into a standard. This is
closely related to "experimental" standards and is the way
IETF often work: Implement first, make a standard
afterwards. Pros: The standard will be based on practical
experience. Cons: A badly designed header may inadvertently
get wide implementation.
At 10.40 +0000 02-01-31, Charles Lindsey wrote:
This matter has recently been discussed extensively on the USEFOR WG. The
opinion seems to be that X-headers are more trouble than they are worth
(especially if they come into widespread use and widely deployed software
contains code that recognises them). It is also noted that RFC 2822 no
longer distinguishes them as a special case.
i agree! X-headers cause more problems than they solve.
At 15.23 -0500 02-01-31, Keith Moore wrote:
Offhand I cannot think of a single read/write X- field that has become a
de facto standard, but I can think of several X- fields that are really
bad ideas and which should never have been deployed even in a single
implementation. But at least they're easily distinguished from other fields.
OTOH, most of the poorly designed fields that have gained wide deployment
don't start with X-.
X-priority is widely used and has become a de-facto standard.
--
Jacob Palme <jpalme(_at_)dsv(_dot_)su(_dot_)se> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/