Talk:PragmaExtensions

Note: The source of this very document itself you're now reading contains `<meta http-equiv="X-UA-Compatible" content="IE=EDGE" />`.

---

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.

---

Anne: We can update HTML and will probably do so in due course. Cannot solve all the problems directly though and solving registry-related problems is pretty low on the priority list.

---

Theimp: if that's the course that you're going to take, then that's fine. I'll file a bug now. But until that is done, the wiki should not have any unregistered entries. We wouldn't want the spec. to be inconsistent with reality, after all. And as it's a low priority, it doesn't matter that some tiny bits of reality are less documented than they could be, for a little while.

---

Hixie:

You wrote "why is it a problem for proponents of unregistered extensions to attempt to register them with the IANA Permanent Message Header Field Registry?"

It's not. Please, be my guest. Nobody is stopping anyone from registering things with IANA.

You wrote: "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?"

I expect we will change this in due course, it's just not the highest priority problem with the spec right now.

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

I agree, it's not particularly worse. They're both terrible.

---

kennyluck: If the real reason why the WHATWG HTML spec isn't matching the practice as used in this WHATWG wiki page is because updating this part of the spec isn't important, then please just say so (and I agree with that, I just happen to read this part of the spec and found that the wiki page and the spec are not matching each other). Talking about "theoretical purity" and whether IANA or W3C is annoying here doesn't make sense. The spec and the wiki page are both under the name WHATWG.

My suggestion:

1. Remove the paragraph "Such extensions must use a name that is identical to an HTTP header registered in the Permanent Message Header Field Registry, and must have behavior identical to that described for the HTTP header. [IANAPERMHEADERS]"
2. Add the sentence ", but he/she must register the name as an HTTP header, if not already being one, in the Permanent Message Header Field Registry in a reasonable time frame. [IANAPERMHEADERS]" after "Anyone is free to edit the WHATWG Wiki PragmaExtensions page at any time to add a pragma directive satisfying these conditions." and we leave "reasonable time frame" undefined.

I think that more reflects what's being done in this wiki page.

---

Hixie: I expect to make a more thorough change than that. I expect to do it in the medium-term future. It needs some care about thought, and right now it's not a priority compared to the other things on the pile.