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

From: Sam Roberts <[email-masked]>
Date: Sat, 5 Feb 2000 10:25:29 -0500 (est)

In the final draft will there be an appendix with a list of all
rules, as in Appendix D of RFC822? It's kind of handy as a
reference.

And what about Appendix B, Simple Field Parsing, or is it deemed
redundant? I guess I can parse the header as being a series of
optional-fields, then parse them more specifically later.

I also was looking for a description of the X- for extension fields
that will never conflict with the names of standard fields. Did
it dissappear, or have I missed it?

Sam

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

---

From: Pete Resnick <[email-masked]>
Date: Sat, 5 Feb 2000 11:50:37 -0600

>rules, as in Appendix D of RFC822? It's kind of handy as a

One other person asked for this. It wouldn't be hard to add. It's a 
little late in the game, and personally I'm not that fond of making 
this document even longer. I will take direction from the chair or 
the ADs.

>optional-fields, then parse them more specifically later.

Again, a little late in the game. I don't do too much in the way of 
advice for implementing a parser in this document, except for the 
stuff in section 2.

>it dissappear, or have I missed it?

It disappeared. Three reasons:

1. The syntax for X- fields is satisfied by optional-field.
2. This document has no discussion of registration of field names. 
Another document (which has been on hold for a while, but hopefully 
will make its way out soon) discusses that issue, which could include 
info on "field names which don't conflict with any registered field 
names". However:
3. X- fields cause known interoperability problems. This is simply 
because X- fields show up, people other than their creator try to 
parse them, sometimes use them without sticking to the semantics and 
syntax originally intended (because they by definition cannot be 
documented), etc. A name starting with X- doesn't do anything to help 
you experiment with a field if it leaks onto the net at large. Better 
to choose a field name you like, and once you get it out there, 
register it.

There was some back and forth about this topic some time ago. The 
current lack of text is the result.

pr
-- 
Pete Resnick <mailto:[email-masked]>
Eudora Engineering - QUALCOMM Incorporated
Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102

---

From: Keith Moore <[email-masked]>
Date: Sat, 05 Feb 2000 14:38:36 -0500

> to choose a field name you like, and once you get it out there, 

there are folks who strongly disagree with this idea.

the problem isn't with the X- convention, it is with the idea that
you can create a new field in isolation and not cause interoperability
problems.  this problem exists whether or not you use the X- convention
for your new field name.  the X- convention cannot solve the problem,
but it can serve as a warning to others - don't expect this field 
to be used consistently from one implementation to another.

nor can you solve the problem by registering the field after you've
already deployed it.  

there's a large body of experience that indicates that defining
data models, in a way that allows large-scale interoperation, is 
quite difficult and doing it successfully requires cooperation
of many people with diverse experience.  this is no less true 
just because the data model is one that describes attributes of an 
email message.  

Keith

p.s. I can see the bumper sticker now:

"X- fields do not cause interoperability problems,
people gratuitously adding extensions cause interoperability problems"

---

From: Keith Moore <[email-masked]>
Date: Sat, 05 Feb 2000 15:15:15 -0500

> if people do gratuitously add extensions, X- fields don't help.

disagree.  they help in a subtle way, but making it clear that 
this is a gratuitously added extension.

> Ergo, X- is a waste of everyone's time, and we'd all be better off
> without it accidentally going off and harming someone....

nope, your major premise is false.

Keith

---

From: Robert Elz <[email-masked]>
Date: Sun, 06 Feb 2000 07:01:09 +1100

Date:        Sat, 05 Feb 2000 14:38:36 -0500
    From:        Keith Moore <[email-masked]>
    Message-ID:  <[email-masked]>

  | p.s. I can see the bumper sticker now:
  | 
  | "X- fields do not cause interoperability problems,
  | people gratuitously adding extensions cause interoperability problems"

Like the one it is derived from, superficially true...

If no-one was to add (private/gratuitous) extensions, X- fields would
not be needed.

kre

---

From: Keith Moore <[email-masked]>
Date: Sun, 06 Feb 2000 12:28:06 -0500

> But they don't make that clear at all.   There are already so many
> well entrenched extensions with "X-" names, that it is clear to
> anyone who looks that no conclusion can be drawn about a header based
> upon its field name. 

"anyone" is a big category, and it's difficult to make accurate
statements about them.  Folks who are familiar with RFC 822 will
realize that X- headers can never be registered, so they're 
guaranteed to not be extensions that have reached widespread agreement.
As for the rest, it seems to me that "anyone" looking at message 
headers would be likely to regard the X- ones as useless cruft...
and they would not be far wrong.  (the ones that are not useless
cruft are either write-only or dangerous...those in the latter
category should on some occasions be deleted)

Keith

---

From: Pete Resnick <[email-masked]>
Date: Sun, 6 Feb 2000 12:16:33 -0600

On 2/6/00 at 12:28 PM -0500, Keith Moore wrote:

>statements about them.

Agreed. Similarly:

>Folks who are familiar with RFC 822 will realize that X- headers can 
>never be registered, so they're guaranteed to not be extensions that 
>have reached widespread agreement.

"Guaranteed" is a big assurance too. I am a "folk" familiar with RFC 
822, and I can assure you that X-Face and X-Mailer *are* extensions 
that have reached widespread agreement, much though RFC 822 would 
like to delude itself into believing they have not.

>headers would be likely to regard the X- ones as useless cruft...

Useless cruft is certainly in the eye of the beholder.

>the ones that are not useless cruft are either write-only or dangerous...

It is the repeated long term existence of the latter which leads us 
to believe that X- headers are not the appropriate mechanism to deal 
with this issue. What makes them dangerous is that people insist on 
using them, labeled with an X- or not.

pr

---

From: Keith Moore <[email-masked]>
Date: Sun, 06 Feb 2000 13:15:26 -0500

> No, not at all.  All that is known is that they started out without
> widespread agreement, nothing at all about the current status.   It is
> not at all beyond all possibility that an initially locally invented X-
> header becomes so widespread that it is properly documented and effectively
> standardised - perhaps even in an RFC.

RFC 822 says this will not happen.  IMNSHO It is not within the scope of 
DRUMS to change that.  Nobody has shown that any harm is done by not 
allowing registration/standardization of X- headers.    In the past
20 years not a single read/write X- header has been produced that is
worthy of standardization.  This is a non-issue.

Keith

---

From: Keith Moore <[email-masked]>
Date: Sun, 06 Feb 2000 13:36:41 -0500

X-Mailer is write-only, so it really doesn't matter.
X-Face is useful, but if it were standardized it would probably not 
survive in its current form, either with or without the X-

> using them, labeled with an X- or not.

I don't see how discarding the X- convention actually helps the
situation, and it would appear to make it worse.

I would be quite happy to see a stronger labelling convention, one
that distinguished between fields that had community review
and approval (perhaps standardization) and those that did not.  but to 
me that looks like strengthening the X- convention rather than 
discarding it.

Keith

---

From: Robert Elz <[email-masked]>
Date: Sun, 06 Feb 2000 17:21:28 +1100

Date:        Sat, 05 Feb 2000 15:15:15 -0500
    From:        Keith Moore <[email-masked]>
    Message-ID:  <[email-masked]>

  | disagree.  they help in a subtle way, but making it clear that 
  | this is a gratuitously added extension.

But they don't make that clear at all.   There are already so many
well entrenched extensions with "X-" names, that it is clear to
anyone who looks that no conclusion can be drawn about a header based
upon its field name.   The "X-" might suggest that the header was once
a gratuitously added extension, but that label gives no clue at all as
to how long ago that was.

kre

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Sun, 06 Feb 2000 12:19:12 -0800

>to how long ago that was.

 From talking to IMC members who have "only" been developing mail apps for 
five years, I gotta agree with kre on this. I've had at least two 
developers tell me that they thought x- was for experimental headers and 
that as some point someone in the IETF would bless it and it could be used 
forever.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Keith Moore <[email-masked]>
Date: Sun, 06 Feb 2000 18:08:57 -0500

> that as some point someone in the IETF would bless it and it could be used 

okay, but why does it follow that we should encourage such delusions?

if these folks can't be bothered to actually READ RFC 822, I don't know  
we can impart clues to them.

Keith

---

From: Robert Elz <[email-masked]>
Date: Mon, 07 Feb 2000 04:55:54 +1100

Date:        Sun, 06 Feb 2000 12:28:06 -0500
    From:        Keith Moore <[email-masked]>
    Message-ID:  <[email-masked]>

  | Folks who are familiar with RFC 822 will
  | realize that X- headers can never be registered, so they're 
  | guaranteed to not be extensions that have reached widespread agreement.

In any case, this debate has been had before, nothing said now is likely
to get any kind of consensus to change what is currently in the draft,
so I would suggest that we just forget it.

kre

---

From: Jacob Palme <[email-masked]>
Date: Wed, 23 Feb 2000 17:13:05 +0100

As a basis for the discussion about X-fields, here is a list of all
the non-standardized header fields in my collection of header
fields at http://www.dsv.su.se/jpalme/ietf/mail-headers/mail-headers.html

Apparently-to
Content-Alias
Content-Class
Content-Conversion
Content-Features
Content-Length
Content-SGML-Entity
Encoding
Errors-To
Fax
Fcc
For-Approval
For-Comment
For-Handling
List-Digest
List-ID
List-URL
Mail-System-Version
Mailer
Organisation
Originating-Client
Originator
Originator-Info
Phone
Precedence
Registered-Mail-Reply-Requested-By
Replaces
Return-Receipt-Requested
Return-Receipt-To
Read-Receipt-To
Speech-Act
Status
Supersedes
Telefax
Translated-By
Translation-Of
X-Confirm-Reading-To
X-Envelope-From
X-Envelope-To
X-Face
X-List-Host
X-Listserver
X-Mailer
X-MIME-Autoconverted
X-Newsreader
X-No-Archive
X-OriginalArrivalTime
X-Priority
X-Sender
X-UIDL
X-URI
X-URL
X-X-Sender
X400-Content-Return

As you can see, there are considerably more such fields which
do not start with "X-" than those who do, so whatever your
opinion is about the "X-" convention (I am against it),
most people defining new headers are not obeying the convention.

-- 
Jacob Palme <[email-masked]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/