At 02:48 PM 2/2/2002 -0500, Keith Moore wrote:
My concern is for interoperability and reliability of Internet mail.
I'm not as concerned with labelling something "right" or
"wrong" as with encouraging behavior that makes email work better.
Indeed, that was exactly Larry's concern, too. He wanted to be able to
publish a specification but there was no venue for doing that.
If we're arguing about what the rules for extensions should be, I'll
recommend a set of rules that I think will help promote interoperability
and reliability.
Here are some thoughts on the matter:
Possible Goal(s)
----------------
A registry effort like the one under discussion can step through a
hierarchy of purposes. I believe the relevant levels are:
1. List standards for entries in the name space.
2. Associate a protocol specification with a unique entry in the name space.
3. Reserve a unique entry in the header name space.
#1 and #2 pertain to interoperability. #3 probably permits users to avoid
stepping on each other's independent activities, but it does not rise to
the level of facilitating interoperability.
I have never fully understood the view that only "standards" should listed
in an IANA registry effort. It seems to me that, in fact, interoperability
is the entire goal of the IANA registry, rather than the stricter political
correctness of only recognizing standards. Note that such a rigorous
criterion is not the requirement for becoming an RFC, for example.
draft-klyne-msghdr-registry
---------------------------
Hence I believe that draft-klyne-msghdr-registry should provide for 1.
standards-track headers, and 2. non-standards track headers for which
specifications are provided.
Oh. Gosh. That's what it does.
I'm not thrilled with the vocabulary choice of "provisional" for the
description of something registered under #2, since it implies a
tentativeness in the allocation and an eventual evaluation by the
assignment authority. But quibbling about specific vocabulary is, well,
quibbling.
Header Name/Semantics Uniqueness
--------------------------------
TCP and UDP have independent port numbering spaces. Theoretically, port 25
could have a different service, depending upon whether it is for UDP or for
TCP. Fortunately, folks were clever enough to combine assignments. I
suggest we do the same.
Registering header names that have different associated specifications,
depending upon which protocol service is being used, is highly
counterproductive. (I'd say "silly", but the role of inflammatory
contributor to this thread is well and truly taken, already.)
Content is content. A header of a given name should have the same
semantics and, where possible, the same syntax no matter what content
service it appears in.
d/
----------
Dave Crocker <mailto:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
tel +1.408.246.8253; fax +1.408.273.6464