ietf-822
[Top] [All Lists]

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

2002-02-01 12:16:24

actually, it doesn't indicate that there is no spec (I've seen a 
spec for X-Face)

Where might I find this spec? Certainly not in any registry at IANA 
that I know about.

No, I'm sure it's not there, and it's been probably 15 years since
I've seen it.  But I did see something of a specification one time
for the format and how to encode it in a header, included with
some software libraries that could generate faces from other 
images and patch exisiting mail programs to display the things.

If you want to find the spec I saw my best guess was that it was
in the faces package in comp.sources.unix - you might find it
in google's usenet archive.

but it is a good first-order indication that the field is not a de 
facto standard.

Later on, you write:

2. it is perfectly reasonable to document X- Fields that are 
deployed, because it's almost always useful to document existing 
practice.

We're talking about protocol here. A "first-order indication" is the 
equivalent of an educated guess. 

I could quibble about that, but let me take another direction:

Anytime an X- field is widely used, there's inherently a fair amount of 
guessing going on.  The guy who came up with the field is guessing
that it will work well in a wide variety of environments - most of
which he cannot be experienced with - and that it won't cause harm.
He's also guessing that the same field name isn't used by others.
Other folks who use it are guessing about how the field works and what 
it contains, whether there are varying implementations, etc.

I suspect you and I would agree that such guesswork can be dangerous 
and detrimental to interoperability.  I believe that such guesswork
should be discouraged, and that folks who are generating new header
fields need to get those fields reviewed (and when applicable, their 
definitions published) before widely deploying them.  Of course if 
they do that, then they don't need to use X- fields.

Also, sometimes the designer of the new field specifically intends
the field for private use only - because it's inherently specific
to a particular kind of software or because he/she *knows* it's not 
suitable or ready for general use.  X- is a useful way to indicate this.

It should not take any guessing: 
Let's say that down the road an X- field gets used for something 
that, at the time, seems very unimportant. In the future, it turns 
out that the field is vitally important to interoperation because 
bunches of people start using it. 

But those folks are *already* guessing because they're using an X-
field - usually without *any* documentation about what it contains 
or how it works.  When we've got something that is "important to 
interoperation" and undocumented, that's a serious problem, because 
there will almost certainly be variation in the way that it's implemented.  

Now, the current state of affairs 
is that it *cannot* be a standard, by definition. We could, of 
course, document it in an Informational RFC. However, an implementor 
who comes along and sees this important X- field, having the 
"first-order indication" takes an educated guess that this *isn't* a 
de facto standard, tries to wing it in his implementation, gets it 
wrong, and screws it up royally. (This does occasionally happen with 
things that are standards too, but you're pretty much encouraging it 
in this case.)

Again, I have no problem with a registry documenting X- fields.
So if the registry existed the implementor could check to see if there
were any documentation on the X- field before trying to "wing it".
In other words, the decision to stop searching for the spec and to 
"wing it" wouldn't be based on the presence of "X-", it would be based 
on the fact that it wasn't listed in the registry.

But even with the registry documenting the field, the fact that a 
field is an X- field should still give the implementor a clue that 
the field might have been been widely deployed before it was 
documented, that such documentation as is available might not fully 
describe variations found in practice, and that the original implementor 
might have screwed it up royally, and that perhaps it shouldn't be 
propagated at all.  Because trying to retroactively document a protocol 
is at least as dangerous as trying to "wing" the implementation - 
perhaps moreso, since the bugs in the document may propagate more 
widely than those in a single protocol implementation.

(I know of at least one attempt to document a protocol in an Informational
RFC that botched the description of that protocol in several ways, 
and as a result, has significatly degraded interoperability of that
protocol.  (RFC 1179 - LPD))

Now you might argue that the registry could contain bits that say:
"this field was widely deployed without review" or "this field was 
widely deployed before it was publicly documented" or "this field 
was documented by observing how it worked, not by the guy who 
designed it".  And those might be good things.  

But X- would still be useful, because it's sometimes a good thing
to clearly indicate in the field name  "you probably shouldn't be 
using this!"  And I'd argue that such indication is appropriate
for any field which is deployed without prior review.   The guy
who designed the field can't reliably determine by himself whether 
his field is going to be good for other people to use, so the 
default assumption needs to be that it shouldn't be used by other people.

Wouldn't it have been better for all involved to not make any 
assumptions about the relative worth of a header field just by 
looking at its name, but rather to have a registry which every 
implementor can simply look at, check the references for the field, 
see what it's syntax and semantics are supposed to be, look at its 
relative worth ("most important field since To:" vs. "stupidest idea 
anyone ever came up with"), and have a good chance of doing the right 
thing?

Is it any better to make assumptions about the "relative worth" of the
field based on how frequently it appears?   As far as I can tell,
X- is indeed a better indicator of "relative worth" than frequency
of appearance. I know of several widely used nonstandard fields that 
are either garbage or brain-damaged, but I know of only one or two
X-fields that are even useful for general implementation, and none of
them are of vital importance.

I think it will be difficult for the registry to contain much 
information about relative worth.   At best we could say one
of three things:

"no consensus" on relative worth
"consensus that it's so bad it should be deleted"
"consensus that it shouldn't be used"
"consensus that it's good"

but there would probably often need to be some caveats even on "good"

I think there is too much tendency on the part of many implementors 
to try to implement any field that 'looks useful'.  We used to call 
this creeping featurism, but I've also heard it called 'header 
disease'.

If we had a registry, an implementor could quickly and easily look up 
a field and see if it really is useful.

It's not clear - because people will not necessarily agree on the 
utility of a field, and getting a clear indication of "usefulness" 
would essentially require getting consensus on that - and this
assumes we know how the header is supposed to work.  And without
a requirement to reach a consensus on "usefulness", the registry
would provide a means of circumventing the standards process.

If there's a need for a Priority header field perhaps we should 
define one (or use the RFC 1327/X.400 one as it seems to be 
reasonable) rather than trying to promote an existing field that 
seems to have been used differently by different MUAs.

1. If we had a registry at the time, we would have noticed that there 
was already an "Importance" field in 1327 and used that. In fact, now 
most MUAs send both (because older versions still depend on 
X-Priority).

2. Most MUAs get X-Priority correct. If we had the ability to 
standardize it, less folks would have screwed it up. If there wasn't 
this idea that X- fields were a good thing, we wouldn't have used 
X-Priority in the first place and it likely would have been 
standardized.

I think we're getting too hung up on "X- is good / X- is bad".
We're focusing on what's bad about X- and ignoring the things that
are good about it.  I think we can partially fix your problem 
with "X-" by allowing those fields to be documented in a registry.

But the only way to fix the real problem - which is that people
deploy protocol extensions without documenting them or getting
review on them - is to get people to document and get review on
protocol extensions *before* they get deployed.  I fail to see how
abolishing X- will encourage that.
 
1. we're better off having a visual convention that indicates that a 
field wasn't reviewed and/or standardized before use, than not 
having such a convention - because this separates the experimental 
and private-use fields from standard fields, and in practice the 
presence of X- tends to mean that the field isn't well thought-out.

A registry alone would serve the same purpose without causing 
implementors to try to guess using the "first-order indications".

Again, I think it will be very difficult for the registry to provide 
a fair indication of quality.

however, there's nothing wrong with standardizing a new field and 
having that standard recommend UA behavior regarding generating the 
X- field that preceeded it.

Maybe we don't belong to the same standards organization:

- In the IETF, deployment traditionally *precedes* standardization. 

That is a myth.  Offhand, I can't think of a single example of a protocol 
that was standardized in the same form that it was initially deployed, 
and usually for good reasons.  There are nearly always serious 
problems with the first version of a protocol, because the folks who
designed that version were doing so in a vacuum, and didn't think about
some important aspect of deploying the protocol in the full diversity
of the Internet.

Now a well-designed protocol - especially one designed to be extensible -
might be able to be standardized with very few changes, and/or in a way
such that the standardized protocol interoperates with the pre-standard
version.  But this varies a lot from one protocol to another, and it's
hard to predict in advance whether you can do it with any particular
protocol.  In general, it's completely unrealistic to design and deploy a 
protocol and expect it to be standardized by IETF as-is.  That doesn't 
stop vendors from trying, but it doesn't work very often.

First we see if something works in the world, then we write down what 
does work. Only in more drastic cases (like IPv6) do we reverse that 
process. That's what separates us from the ISO and the like.

That's simply not true.  Yes, we benefit from prototypes or experience 
with an existing protocol whenever we can.  And we often use an existing
protocol as a starting point for a standards-track protocol.  But the
vast majority of the time we don't standardize the protocol that was
previously deployed - we standardize some variant of it that we think
will work better for the entire Internet than the deployed version.

- In the IETF, we have repeatedly learned that once something is 
widely deployed, you are forced to retain backward compatibility in 
order to retain interoperability. Standardizing a new field that 
obsoletes an X- field fails that test miserably.

The compatibility issues are different for every protocol and every
protocol extension.  Sometimes you can get good backward compatibility,
sometiems you can't.  But whether the field name begins with an "X-"
or not is pretty much irrelevant to whether you can implement a protocol
extension that is worthy of standardization (meeting the 2026 requirements) 
while still retaining compatibility with pre-standard implementations.

In any event, in this discussion, we've had 5 people talking in
addition to one of the 3 authors. I'd like to hear from anyone else
who supports Keith's view here, because if there's noone else, it's
starting to seem like we have rough consensus.

I didn't see any CC's to the list on this message, so I've sent this
reply to you personally.  But I can't see how we have rough consensus
when we don't even have a concrete proposal yet, and when it's not 
even clear what question is being asked.

And I would far rather we reach consensus by respecting and understanding
each other's concerns than by just trying to isolate me.

If we're just talking about the desirability of a registry, I suspect 
we do have rough consensus - I haven't seen anybody say that a 
registry is inherently a bad idea or that it shouldn't accept X- fields.

I've expressed some concerns about potential for misuse of the registry,
specifically the need to keep it from being used as a way to "stake a 
claim" on a header name or the meaning thereof, or as a way to create
"vanity" header fields.  That doesn't preclude having a registry at all, 
but it does indicate the need for some care.

As for the desirability of X- fields, we might not have to reach 
consensus on this in order to decide what should go into a registry. 

Keith