I am half-way through the action resolution. Here are the provisional results. a) The registration of header fields at IANA follows a procedure specified by the IETF (RFC 3864). Fields can be registered as provisional or permanent. Provisional fields are relatively easy to register. Permanent ones require them to be based on a published standard. b) Provisional fields can only be of type "provisional", whereas permanent ones can be "historic", "obsoleted", "experimental". Fields are attached to a protocol. c) The IETF draws the attention towards avoiding synonyms with different semantics, and prohibits reusing existing MIME fields for a different purpose, but is silent on having fields with different names but the same semantics. d) So far, I could not find trace of a definition of or good practices about X-* fields. It appears that this is an established practice, not a standard. If anybody is wiser, let me know (preferably with a reference). e) It seems possible to rely upon the registration procedure of 3864 to retract a field. So for the moment, there is no information about 1. registering or not X-* fields; 2. having a registered nnn field deployed in parallel with a X-nnn field with the same semantics; 3. deprecating fields, whether of the form X-* or not. However, during my searches I discovered that a lively discussion took place around just those topics (What are X-* fields exactly? How to obsolete fields?) in the IETF mailing lists, in the context of the revision of RFC2822 to RFC5322. I intend to look further and to ask the IETF about the above subject. If I get an answer rapidly, I could present the final word in one week. E.CasaisReceived on Tuesday, 20 January 2009 14:21:16 UTC
This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:53 UTC