Kai Henningsen wrote:
blilly(_at_)verizon(_dot_)net (Bruce Lilly) wrote on 04.01.04 in
<3FF7C6B5(_dot_)40108(_at_)verizon(_dot_)net>:
Pete Resnick wrote:
This has absolutely *no* effect on implementations of
the protocol.
There is a minor effect. A user-defined field (per 822 definition) can
be recognized as such by examining the
first two octets of the field name, which is quite efficient. While
there exist efficient methods of identifying
fields (e.g. http://www.gnu.org/directory/gperf.html), they are not
quite *as* efficient as a two-octet (case-
insensitive) comparison.
This seems an incredibly silly reason to be for or against the concept.
Is *isn't* "a reason to be for or against the concept." It is an example
of an
effect on implementation to counter the claim of "absolutely *no* effect
on implementations".
An issue not mentioned above is migration of X- fields to a formal
definition following
successful experimental use. That obviously entails a name change.
However name changes
are not uncommon, e.g. refer to the MIXER RFCs, which define a number of
fields whose
names have changed. That merely means that parsers need to recognize
one name as a
synonym for another.
Or in other words, it means that interoperation with the installed base is
broken. Presumably that installed base is nontrivial, or else there would
have been no need to standardize. ("merely"?!)
Yes, "merely". As noted, parsers already need to be able to cope with
name changes:
Obsoletes (RFC 1327) -> Supersedes (RFC 2156)
Content-Identifier (RFC 1327) -> X400-Content-Identifier (RFC 2156)
Expiry-Date (RFC 1327) -> Expires (RFC 2156)
etc., and
X-Accept-Language (MUA usage) -> Accept-Language (RFC 3066)