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

FWIW (NAL..)

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)
JM2P

Paul                            VPOP3 - Internet Email Server/Gateway
support(_at_)pscs(_dot_)co(_dot_)uk                     http://www.pscs.co.uk/