Talk:PragmaExtensions

Is there any reason that the entries x-dns-prefetch-control and x-ua-compatible should not be removed? They do not meet the requirements for inclusion per the spec. at this stage:

Such extensions must use a name that is identical to an HTTP header registered in the Permanent Message Header Field Registry…

---

Hixie: If they are implemented by software, the solution is to fix the IANA registry, not this one.

---

Theimp: When that's done, they can be re-added.

---

Hixie: That's putting theoretical purity before pragmatic documentation of interoperability.

---

Theimp: No, it's not. Anyone is as free to propose additions to the IANA Permanent Message Header Field Registry, as they are to edit this wiki. Document it there first, as required by the HTML spec. By all means, please document everything — but follow the standards process and begin at the beginning; not at the end.

---

Hixie: No. The goal is to document reality. Reality is that these fields are used. It would be ridiculous to remove documentation just because the IANA list is out of sync with reality. If you think IANA should be updated, then by all means, be my guest.

---

Theimp: If the goal is to document reality, then why is it a problem for proponents of unregistered extensions to attempt to register them with the IANA Permanent Message Header Field Registry? That is the appropriate place to start documenting that particular facet of reality; not here. This is a place for documenting IANA registered extensions only, as it says in the spec. Or, if you think that the requirement that registration in the IANA Permanent Message Header Field Registry shouldn't exist, then why not propose changes to the HTML spec. that requires this? Either way, until one of those two conditions changes, “documenting reality” here is illegitimate — it might as well be documented on a vendor web page, for all it matters. What is ridiculous is setting a requirement through specification and then willfully ignoring that requirement — it completely destroys the credibility of the specification.

If the IANA Permanent Message Header Field Registry is out of sync with reality, then it implies that someone has been introducing unregistered fields into deployed products. Which is, of course, the vendor's own prerogative; but it doesn't mean that they comply with the relevant standards which prohibit this. And if the standards are to be updated to encompass these unregistered fields, then that is the spec. writers' prerogative. But until either the IANA Permanent Message Header Field Registry is updated, or the spec. says that it doesn't have to be consistent with it, that doesn't change the fact that inclusion here is not permitted, whatever the goal is. Call it ridiculous if you like; but that, too, is reality.

The HTML spec. says that those wishing to “document reality” have the onus of ensuring that their extensions are first documented with the IANA before they begin documenting it here. I mean, if there is so little respect for the spec. that vendors are free to ignore the requirements for adding extensions to this extension registry, then why shouldn't authors have the same lack of respect and ignore the same requirement to not use extensions not so registered? Either possibility negates the very purpose of this extension registry. And that purpose is to document those extensions which conform to the specification — not to document any and all possible extensions, valid HTML or not. There are places to document such things; but this is not such a place.

---

Anne: IANA is annoying, see IETF. No need to abide by processes that are full of hurt.

---

Theimp:

“IANA is annoying”

If there is consensus on that point, then it should be no trouble to remove the IANA-related requirements from the HTML spec.

“see IETF”

Well, in my dealings, I haven't found the IETF any worse than, say, the W3C in terms of accessibility and transparency of process.

“No need to abide by processes that are full of hurt”

If that is the case, then why is the requirement in the spec.? In fact, if that's a valid argument, then why is there a spec. at all?

If you are quite insistent that “documenting reality” is so critically important, then you must surely realize that allowing this wiki to be inconsistent with the IANA Permanent Message Header Field Registry, in turn, makes the HTML spec. inconsistent with reality. The only way to reconcile this contradiction is to remove the IANA Permanent Message Header Field Registry requirements from the HTML spec., which is an option that you can pursue right now, if it is sufficiently important to you. On the other hand, if there is some significant problem in doing that, then it follows either that “documenting reality” isn't so genuinely important after all; or else that perhaps you also find the W3C to be at least as “annoying” as the IETF.