ietf-822
[Top] [All Lists]

Re: I-D ACTION:draft-klyne-msghdr-registry-02.txt

2002-02-03 08:35:07

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.

It's hard for me to believe that neither the IESG nor the RFC Editor
was willing to publish a spec for an LMTP extension.  Granted, a
registry might be even better, but if other registries are any
indication, we'll probably still publish specifications as RFCs 
and just put pointers to the RFCs in the registry.  I think it's a
stretch to say "there was no venue".
 
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.

I would agree that "standards only" raises the bar too high.  But 
"anything that has a specification" sets the bar too low.

There needs to be some way of determining whether putting that field name
in the registry will benefit the community.  It could be IESG approval,
it could be a consensus process,  or it could be something else.  
Ideally the process would encourage people to not only publish their
specifications but also to get review on them and to revise them 
(or discard them) in light of such review.

But regardless, registering anything with a spec is simply too dangerous.

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.

It's too late - there are already too many variations in use between
different protocols.  Furthermore it seems inevitable that when one
protocol uses another protocol's fields that the semantics of that
field are likely to change slightly - simply because the context in
which the field is used is different than before.  

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.

Header fields don't just describe content.

Keith