ietf-822
[Top] [All Lists]

Re: X-* header fields (Was: Getting 2822 to Draft)

2004-01-05 11:08:48


In <01L4Z0G3HR1W0134RS(_at_)mauve(_dot_)mrochek(_dot_)com> 
ned+ietf-822(_at_)mrochek(_dot_)com writes:

On 1/3/04 at 11:00 AM -0500, Al Costanzo wrote:

1. Unnecessary: We now have IANA registration services. We could very
simply create an IANA registry of e-mail field names.

This is already underway and the document specifying it -
draft-klyne-msghdr-registry-06.txt - has been discussed on this list. I note 
in
passing that it doesn't distinguish X- fields as being in any way special
either.

Yes, I am surprised that people have been going over issues which the
Klyne draft has already resolved. I think it will be best to get that
draft adopted as a BCP and the IANA register created before starting
serious work on 2822-bis. But I hope that will have happened within
months, if not sooner.

I agree 100%. The current status of the registry draft is that it has
completed last call and has been discussed by the IESG. There were
two discuss votes on the specification and the authors have posted
as revised version that hopefully addresses the issues that needed to 
be addressed. However, there were a couple of concerns it isn't clear
how to address so the document remains under discussion.

An interesting question is whether or not 2822bis should reference this
registry, assuming the specification for it is approved in the near future
(which I hope it will be).

Yes, I think it should. There is a corresponding place in the Usefor draft
where it discusses X-headers (and when not to use them), and the wording
there would be much simpler if it could just point to the Klyne BCP.

OK.

Then, if you
wanted to create a new field, you just fill out the registration form
and you're not only guaranteed that you won't interfere with
published standard fields, you're also guaranteed that nobody else
would use the field you chose in an incompatible way. And you
wouldn't have to have a name that started with "X-".

2. Problematic: Some folks thought it was nice to have "X-*" fields
for completely private use. But history teaches us that inevitably
"X-*" fields *will* leak out onto the rest of the Internet. As
several people in this thread have pointed out, we now have some
"X-*" fields that are in widespread use. Sometimes, people use them
very interoperably and they have served a fabulous purpose.
Sometimes, they don't get used interoperably. It would be great if we
could publish some standards to make sure that they do get used
interoperably. But guess what: We can't! It is forbidden by RFC 822
to publish any standard for a field name that beings with "X-". No
matter how widespread the use, no matter how useful the field is, it
can not be standardized *by definition*. That decreases
interoperability on the Internet.

I agree with this as well.

Bur I don't. What you say is that X-headers are for human readers only -
essentially they give the possibility for creating lots of extra
Comment-headers. But you also say that they may also be used for protocol
purposes ONLY where there is prior agreement between sender and recipient.

I see nothing in the previous discussion having anything to do with whether
the fields are used by humans or programs. The issue of whether or not
something is standardizable has nothing to do with who the eventual
consumer is.

That is not so improbable as it sounds. If my ISP is kind enough to put
all my mail through Spamassassin and record the result in the form:

    X-Spamassassin-Score: sssss

then I can use that header as a filter to send high scoring messages to a
special box, or even to /dev/null. Essentially, there is an agreement
(unwritten) between the ISP and myself that the header will appear and
that I can rely on that format.

Sure, there are loads of examples of both sorts of X- fields (and both
sorts of non-X- fields for that matter).

                                Ned