[Top] [All Lists]

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

2004-01-06 02:30:10


My view on X- header fields is that they're a good thing if used properly - but there should probably be a registry for optional fields in the long term.

RFC 2822 section 3.6.8 leaves things wide open IMHO - I could legitimately, according to RFC 2822, create my own header field called 'Content-Type' and put anything I want into it - because the only restriction in RFC 2822 is "The field names of any optional-field MUST NOT be identical to any field name specified elsewhere in *this* standard." Content-Type isn't defined in RFC 2822, so I can use it..

If I want to create my own header for my own use (which happens) and I don't have an exhaustive knowledge of all the RFCs, it's quite possible I could inadvertently re-use a field name which already exists in a standard.

Also, I may use a custom field name which doesn't already exist, but then someone else comes along and makes a new standard using the same name but in a different way.

At the moment, there's no definitive way to avoid this, other than to use an X- header (Yes, I could use '<MTA Name>-header' - which I have no problem with - *if* this was 'standardised' as a way of defining custom headers)

If there was a 'registry' of headers where I could register either field names which I think would be useful to the community in general, or an MTA name which I could then append my own custom field names to, then I'd be happy.

But, until that happens, I think there needs to be a way you can GUARANTEE that a field name someone invents does not clash with a standard name. The X- headers achieve that aim IMHO.

(Also, a minor point, but possibly significant none-the-less. Moderately technical people who aren't email experts can generally accept that 'X-' headers are custom headers. Without this distinction they can assume they're standard. So, if an email parser can't parse, for instance, 'Status:' or 'Delivered-To:' headers, there can be user support issues because 'they're not custom headers, why can't your parser understand them?', whereas if they were X- headers this misunderstanding would be less likely, or if they are standardised properly, the parser could understand them)


Paul                            VPOP3 - Internet Email Server/Gateway

<Prev in Thread] Current Thread [Next in Thread>