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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf