X-headers

Some (though admittedly not all) of the problem could be mitigated if 
software authors were encouraged (not forced!) to have their programs:

  1) accept new X-headers both with and without the X-, and
  2) be configurable to send either, defaulting to "with".

If a given header gets approved, and registered without the X-, the 
software need not be changed and redeployed, or even reconfigured, to 
*accept* the new version.  Having it *send* the new version, would be a 
matter of configuration, hopefully simple.

As new versions of the software are written, support for the X-version 
could even be removed, preferably after some agreeable fairly long 
amount of time.  (A "deprecated" registry would certainly help there. 
That could be cluttered if ALL abandoned X-headers are listed, but it 
could be restricted to those that have been deprecated in favor of 
things that became official.)

The main problem I see is site admins too far behind the times to bother 
flipping the switch to send without an X-, nor upgrade to versions that 
don't support sending the X-.  Their users may send to sites that have 
upgraded to versions that no longer accept the X- version.  In this 
case, the header will not be recognized.

One could take at least approaches here.  First, one could simply say 
"X-headers are experimental, not to be relied upon, so who cares, tough 
luck, if it's that important to you, get your admin to flip the switch." 
  Second, it could be mitigated by simply having the software continue 
to accept the X- version, rather than deliberately removing X- support.

Your thoughts?

-Dave

-- 
Dave Aronson
"Specialization is for insects." -Heinlein
Work: http://www.davearonson.com/
Play: http://www.davearonson.net/

_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf