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.