Subject: Re: RFC822's Appendix D, and X- fields

From: Sam Roberts <[email-masked]>
Date: Sun, 6 Feb 2000 22:08:07 -0500 (est)

Previously, you (D. J. Bernstein) wrote:
> Sam Roberts writes:
> > I also was looking for a description of the X- for extension fields
> > that will never conflict with the names of standard fields.
> 
> If you're trying to avoid conflicts, contribute to my list of names at
> http://cr.yp.to/immhf/index.html. The X- prefix really doesn't help.

I'm not intending to commit another x- header on the world, I just noticed
it missing, and wondered why. Apparently there's some debate about its
usefulness...

FWIW, my impression from RFC822 was that the IETF was essentially reserving
all names that did not start with x- for itself so that it could standardize
them later, if required, and not have to fight some "field squatter" for
the rights to it.

Absolutely nothing can prevent people from putting their own
user-defined fields in messages, but at least you can tell them to
use X-*, so that if there is ever deemed a need to standardize a new
field name (the MIME-*, for example) there's less chance that the name was already
being used. I also thought that if an X- field became widely enough used,
it's syntax might be considered for standardization.

And that's my 0.002 $US.

Sam
 
--
Sam Roberts, sroberts at uniserve dot com, www.emyr.net/Sam

---

From: Dave Crocker <[email-masked]>
Date: Mon, 07 Feb 2000 07:38:33 +0100

>them later, if required, and not have to fight some "field squatter" for

No.   NO.   NO!!!

This is exactly the wrong interpretation.

The strength of my response come from a) having tried to write the 822 text 
very carefully avoid this interpretation, and b) having it be clear for 
years that the text wasn't adequate.  In other word, my reaction isn't even 
slightly directed at you personally.

The intent was to protect a private space, not reserve a public one.

>it's syntax might be considered for standardization.

That was the theory.  As noted, this benefit has not been meaningful and it 
has been countered by rather the rather serious downside of not being able 
to standardize "private" conventions that have become public de facto 
standards.

d/

=-=-=-=-=
Dave Crocker  <[email-masked]>
Brandenburg Consulting  <www.brandenburg.com>
Tel: +1.408.246.8253,  Fax: +1.408.273.6464
675 Spruce Drive,  Sunnyvale, CA 94086 USA

Gong Xi Fa Cai   /  Selamat Tahun Baru Cina

---

From: Keith Moore <[email-masked]>
Date: Mon, 07 Feb 2000 10:12:35 -0500

> As noted, this benefit has not been meaningful and it 

Please cite an example of a read/write X- field that would have been
standardized had it not began with X-.

(granted, X-Face is useful, but I seriously doubt it would have
met the rough consensus requirement for standardization in its
current form, with or without the X-.  In other cases where
people have proposed additional fields to identify the author
of the message, they've been shot down as not being sufficiently
general.)

The X- prefix isn't the reason that these extension fields haven't 
been standardized.  The reason that these fields haven't been 
standardized is that they weren't subject to community input and
therefore didn't work well enough for enough people.

Keith

---

From: Dave Crocker <[email-masked]>
Date: Mon, 07 Feb 2000 22:59:44 +0100

>standardized had it not began with X-.

I don't know what you mean by read/write, but X-mailer is an easy example 
of a field that should have been standardized.  I suspect that others can 
come up with more.

>(granted, X-Face is useful, but I seriously doubt it would have

OK, thank you.  That's another one.

>current form, with or without the X-.  In other cases where

Don't know why you doubt it, but at any rate that sort of cocnlusion is 
very far down the analytic path -- and remember that one starts down the 
ath for this sort ofspecification because the specification has ALREADY 
shown some success -- and that path is terminated prematurely by the X- 
standardization prohibition.

>been standardized.  The reason that these fields haven't been

Just by way of countering your certitude I'll note a strong "why bother to 
pursue it?" effect that is guaranteed by the X- prohibition.  Even when one 
of these fields gets popular, no one has any incentive to pursue it.

To the extent that the counter to my counter is "sure, just re-create the 
field with an acceptable name" the counter**3 is that, in reality, requires 
starting over, in reality.  That is, no chance to take advantage of the 
incrementally built installed base.

>therefore didn't work well enough for enough people.

Huh?  It sounds as if you are saying that all acceptable specifications 
must be the result of a design-by-committee process.  That's quite 
different from the everyone-reviews-it/few-develop-it approach that is more 
typical in the IETF.

At any rate, we are talking about fields that become candidates for 
standardization by having succeeded in obtaining an interesting installed 
base.  Ca n't get a better recommendation than that.

d/

=-=-=-=-=

Gong Xi Fa Cai   /  Selamat Tahun Baru 
Cina

---

From: Keith Moore <[email-masked]>
Date: Mon, 07 Feb 2000 17:50:19 -0500

> of a field that should have been standardized.  I suspect that others can 

X-mailer is essentially write-only.  User agents don't read it (I hope).
and I don't see why it needs to be standardized.  similar fields in
other protocols (like HTTP) have widely been abused.
 
> OK, thank you.  That's another one.

and again, I don't think it would have been standardized in its current form.

> shown some success 

not necessarily.  proof of concept is useful, but backward compatibility
is not always an appropriate goal.  it depends on cost and benefit
of backward compatibility vs. doing things "right".

at any rate, even RFC 822 does not preclude using header field names
that don't start with X-.  

> of these fields gets popular, no one has any incentive to pursue it.

if the field really serves a useful purpose, it can be standardized without
the X- prefix.   I can't think of an X- field which is so useful that 
this seems likely to happen, but it is theoretically possible.

> incrementally built installed base.

but we don't have a single case where the installed base is significant.
(how many messages actually *use* X-Face ?)

> different from the everyone-reviews-it/few-develop-it approach that is more 

no, that's not what I said.  I said that data models, in order to be
successful, tend to need input from a wide variety of sources.
Ad hoc extensions typically don't fit this rule.  And if you go to the
trouble to get wide input for your proposed extension, it's not that
hard to get it published in an RFC.  You only need X- when you're
shipping code that does something without really having researched
it first.

> base.  Can't get a better recommendation than that.

disagree strongly.  most of the protocols I can think of that were 
widely deployed before having adequate public review and comment
have serious problems - usually with security or privacy or scalability.

installed base indicates that there's interest and demand and proof-of-
concept.  but it's not sufficient grounds for IETF endorsement, and
for good reason.

Keith

---

From: Dave Crocker <[email-masked]>
Date: Tue, 08 Feb 2000 17:06:56 +0100

>X-mailer is essentially write-only.  User agents don't read it (I hope).

They don't read "Received" either.  But it's quite useful.

>and again, I don't think it would have been standardized in its current form.

And you are entitled to your opinion.  My opinion is different.  I'm 
entitled to mine...

However there is a long way between such opinions and social fact.  My 
concern is that we not prevent potential standards by a mechanism that has 
a chilling effect, that is, a disincentive for pursuing the matter.

>is not always an appropriate goal.  it depends on cost and benefit

Occasionally it is good not to have backward compatibility.  At other times 
it is quite good to have it.  The history of email standards work has been 
to try to pay attention and conform with accepted practise, where practical.

A priori prevention of backward compatibility, independent of the item 
under discussion, is not only inappropriate.

Let's not confuse sometimes with always.  An argument that is valid for 
sometimes is not necessarily relevant to an action that holds always.  X- 
always imposes a standardization barrier.

>at any rate, even RFC 822 does not preclude using header field names that 
>don't start with X-.

Technically you are correct.  Practically you are not.  As we saw in one 
recent note, people have taken the X- mechanism to mean that non-X- header 
names are reserved for the standards process.

In other words, people choose an X- name.  They think they have to.

>this seems likely to happen, but it is theoretically possible.

The current mechanism has worked against an incremental adoption 
process.  It requires always starting from scratch, as soon as there is any 
interest in the header.  That artificially raises the entry barrier for 
pursuing header standardization.  It is just the sort of systemic barrier 
that has a chilling effect.

>(how many messages actually *use* X-Face ?)

Assuming that no one provides counter examples, I'll note that your 
observation exactly matches a chilling effect.

The presence of this extra barrier to adoption could be, itself, the cause 
for the lack of such cases.

>Ad hoc extensions typically don't fit this rule.  And if you go to the

data models?  I thought we were talking about new headers.

It's important we not impose a set of requirements that makes large 
specifications and small specifications all require large efforts.

>hard to get it published in an RFC.  You only need X- when you're

As we all know, getting something published is the start of the effort, not 
the end.  People have to write the software and other people need to start 
using it.

For grass-roots header creation efforts, the effect of the X- naming 
convention is to ensure that we take fully operational grass-roots use and 
throw it all out.  That loses market "pull" momentum.

>have serious problems - usually with security or privacy or scalability.

It occurs to me that those failings also apply to most of the application 
protocols that HAVE had adequate public review and comment over the last 25 
years...

At any rate I will again note that whether it is good or appropriate to go 
through a re-design process for a proposed standard, it is NOT appropriate 
to impose an artificial, structural barrier that imposes the re-design 
requirement on everyone all the time.

Such an artificial constraint reminds me of the reaction some people had to 
TCP header prediction.  That implementation enhancement allowed 
ethernet-based TCP implementations to go from  a maximum of 2.5Mbps up to 
full wire speed.  Some people said that header prediction should be 
outlawed, since it was not a good thing for one user to consume all of an 
ethernet.

d/

=-=-=-=-=

---

From: Keith Moore <[email-masked]>
Date: Tue, 08 Feb 2000 15:38:23 -0500

what you call chilling effects and what I might call strategically
placed bars are sometimes useful.  some people think that the IETF
process imposes a chilling effect because people have to meet
certain requirements to get their work declared as standards.
they're entitled to their opinions.

in case it has escaped you, message headers are a data model
for describing electronic correspondence.

I stand by my statement that none of the X- fields that exist
would be standardized as-is - and that the vast majority of extension
fields (whether X- or not) that have been created are things that 
we would be better off without.  Even if X-Face should be standardized
as-is, that is one example of a good X- field as compared to dozens
of examples of extension fields that do harm.   So as far as I can
tell X- has on balance been beneficial, even if it has impaired the
ability of X-Face to be accepted.

As a test case, somebody could write up X-Face as an I-D and ask for 
a Last Call for Proposed.  see if it flies or if people want to have 
a separate header for that purpose, use a different image format, etc.  
Include a section on X-Face vs. Face - how X-Face violates the RFC 
822 rule and that it's in some sense up to IESG to decide whether to 
override that rule. also include a note that X-Face already exists and 
folks who support faces might want to be able to read such things even 
if they don't generate them.

The see whether the field-body gets passed as-is or not.

and I'll trust that folks won't lobby to pass the header as-is
just to prove me wrong about X-

(i'll not be on IESG by then, so I won't be in the decision loop)

Keith

p.s. personally if we were going to standardize a face field,
I'd prefer putting it in an encoded-word if in the header,
or as a tagged mime body part.  the former seems cleaner because
you can attach a face to any header address (not just that of the
author).  but there's precedent for the latter in VPIM spoken-name 
and vCard attachments. 

I don't think the backward compatibility issue is terribly significant 
in this case because I don't see too many messages with X-Face headers 
in them.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 09 Feb 2000 07:16:11 +0100

>placed bars are sometimes useful.  some people think that the IETF

1.  Sometimes is not always.  X- is always

2.  For all of your concern about examples, what are the examples of 
BENEFITS from the artificial X- barrier?

>certain requirements to get their work declared as standards.

This isn't about meeting standards.  Those requirements are well enforced 
through other mechanisms.  This is about ALWAYS requiring starting over, 
and therefore losing all install-base momentum.  Always.

In effect you are insisting on a syntactic barrier for enforcing a policy 
barrier.  Overloading functions that way should be permitted only in the 
face of compelling requirement and a good ability to demonstrate that the 
requirement needs to be enforced that way.

d/

=-=-=-=-=

---

From: Robert Elz <[email-masked]>
Date: Wed, 09 Feb 2000 20:02:57 +1100

Date:        Tue, 08 Feb 2000 15:38:23 -0500
    From:        Keith Moore <[email-masked]>
    Message-ID:  <[email-masked]>

  | I stand by my statement that none of the X- fields that exist
  | would be standardized as-is

Keith, you've missed the point - X-Face is standardised.   It
isn't written down in an RFC, which is a pity, as figuring out
how to generate, or use, it is much harder (and hence it isn't
as well supported as it might otherwise be).  But it is clearly
standardised.

Whether or not if one was starting out with an objective of sticking
mini-images in mail headers one would do it the way it has been done
is a quite different, and totally irrelevant, question.

  | Even if X-Face should be standardized
  | as-is, that is one example of a good X- field as compared to dozens
  | of examples of extension fields that do harm.  So as far as I can
  | tell X- has on balance been beneficial, even if it has impaired the
  | ability of X-Face to be accepted.

I fail to see the connection to X- here.   There have been quite a few
privately motivated extension headers added by various people.  The vast
majority of them, with X- names or not, have been something between
rubbish and disastrous.  The X- label hasn't made the slightest difference
that I can detect.   We have had Apparently-To (something between noise
and a problem) and Return-Receipt-To (something between a problem and
a disaster) without X- labels.   It is the unreviewd creation of new
features that causes the problems the label does nothing good at all.
The "advertise this header as rubbish" isn't much of an argument, better
is "any header not documented in an RFC should be prima facie treated as
rubbish" - this dertermination only applies to UA authors (it doesn't
matter much what the user sees in the headers) who can be expected to
have read the RFCs - and even if they miss one, no big deal, they
simply haven't implemente everything they could have, treating some
well defined header as rubbish.   Then if they can pick up on some
undocumented header as being useful, that can be implemented as well.
On the other hand the "we will never standardise a header starting with X-"
along with the hidden (maybe incorrect) assumption that all private
headers should be called X-* means that the incentive to document an X-
header is very very very low.   That's a harm.

In any case, as I said last time on this issue - there doesn't seem to be
anything here to me to even begin to motivate any change to what is in
msg-fmt-08 in this area - so let's all just drop it, and get back to
actually finalising that doc.

kre

---

From: "D. J. Bernstein" <[email-masked]>
Date: 12 Feb 2000 23:34:49 -0000

Keith Moore writes:
> the X- prefix.

Destroying compatibility with the installed base.

The same problem occurred with FTP when XCWD changed name to CWD. This
created immediate interoperability problems and unnecessary costs for
implementors. CWD should have been used in the first place.

> most of the protocols I can think of that were 

The IESG's protocol suite has even more serious problems. In fact, many
of us security people think that your model of protocol development
_encourages_ security problems. See

   http://www.counterpane.com/ipsec.pdf

for comments by Niels Ferguson and Bruce Schneier on this point.

---Dan