Talk:PragmaExtensions - Revision history

MikeSmith: add note about the source of this document havin ``

2014-10-17T09:46:25Z

add note about the source of this document havin `<meta http-equiv="X-UA-Compatible" content="IE=EDGE" />`

← Older revision		Revision as of 09:46, 17 October 2014
Line 1:		Line 1:
			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 <var>x-dns-prefetch-control</var> and <var>x-ua-compatible </var> should not be removed? They do not meet the requirements for inclusion per the <abbr title="specification">spec.</abbr> at this stage:		Is there any reason that the entries <var>x-dns-prefetch-control</var> and <var>x-ua-compatible </var> should not be removed? They do not meet the requirements for inclusion per the <abbr title="specification">spec.</abbr> at this stage:
	<blockquote>Such extensions must use a name that is identical to an HTTP header registered in the Permanent Message Header Field Registry…</blockquote>		<blockquote>Such extensions must use a name that is identical to an HTTP header registered in the Permanent Message Header Field Registry…</blockquote>

Hixie at 17:32, 19 July 2012

2012-07-19T17:32:31Z

← Older revision		Revision as of 17:32, 19 July 2012
Line 54:		Line 54:

	I think that more reflects what's being done in this wiki page.		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.

Kennyluck: Add my comments to this boring debate. It seems that the phrase "theoretical purity" is just too popular among the WHATWG folks.

2012-07-19T07:09:23Z

Add my comments to this boring debate. It seems that the phrase "theoretical purity" is just too popular among the WHATWG folks.

← Older revision		Revision as of 07:09, 19 July 2012
Line 45:		Line 45:

	I agree, it's not particularly worse. They're both terrible.		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:

			# 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]"
			# 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 at 19:54, 9 July 2012

2012-07-09T19:54:08Z

← Older revision		Revision as of 19:54, 9 July 2012
Line 31:		Line 31:
	----		----
	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 <abbr title="specification">spec.</abbr> 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.		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 <abbr title="specification">spec.</abbr> 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.

Theimp at 22:15, 3 July 2012

2012-07-03T22:15:07Z

← Older revision		Revision as of 22:15, 3 July 2012
Line 29:		Line 29:
	----		----
	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.		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 <abbr title="specification">spec.</abbr> 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.

Annevk at 21:39, 3 July 2012

2012-07-03T21:39:33Z

← Older revision		Revision as of 21:39, 3 July 2012
Line 27:		Line 27:
	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 <abbr title="Internet Assigned Numbers Authority">IANA</abbr> Permanent Message Header Field Registry, ''in turn'', makes the		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 <abbr title="Internet Assigned Numbers Authority">IANA</abbr> Permanent Message Header Field Registry, ''in turn'', makes the
	<abbr title="Hypertext Markup Language">HTML</abbr> <abbr title="specification">spec.</abbr> inconsistent with reality. The only way to reconcile this contradiction is to remove the <abbr title="Internet Assigned Numbers Authority">IANA</abbr> Permanent Message Header Field Registry requirements from the <abbr title="Hypertext Markup Language">HTML</abbr> <abbr title="specification">spec.</abbr>, 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 <abbr title="World Wide Web Consortium">W3C</abbr> to be at least as “annoying” as the <abbr title="Internet Engineering Task Force">IETF</abbr>.		<abbr title="Hypertext Markup Language">HTML</abbr> <abbr title="specification">spec.</abbr> inconsistent with reality. The only way to reconcile this contradiction is to remove the <abbr title="Internet Assigned Numbers Authority">IANA</abbr> Permanent Message Header Field Registry requirements from the <abbr title="Hypertext Markup Language">HTML</abbr> <abbr title="specification">spec.</abbr>, 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 <abbr title="World Wide Web Consortium">W3C</abbr> to be at least as “annoying” as the <abbr title="Internet Engineering Task Force">IETF</abbr>.
			----
			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 at 10:02, 3 July 2012

2012-07-03T10:02:50Z

← Older revision		Revision as of 10:02, 3 July 2012
Line 1:		Line 1:
	Is there any reason that the entries <var>x-dns-prefetch-control</var> and <var>x-ua-compatible </var> should not be removed? They do not meet the requirements for inclusion per the <abbr title="specification">spec.</abbr> at this stage:		Is there any reason that the entries <var>x-dns-prefetch-control</var> and <var>x-ua-compatible </var> should not be removed? They do not meet the requirements for inclusion per the <abbr title="specification">spec.</abbr> at this stage:
	<blockquote>Such extensions must use a name that is identical to an HTTP header registered in the Permanent Message Header Field Registry…</blockquote>		<blockquote>Such extensions must use a name that is identical to an HTTP header registered in the Permanent Message Header Field Registry…</blockquote>
			----
	Hixie: If they are implemented by software, the solution is to fix the IANA registry, not this one.		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.		Theimp: When that's done, they can be re-added.
			----
	Hixie: That's putting theoretical purity before pragmatic documentation of interoperability.		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 <abbr title="Internet Assigned Numbers Authority">IANA</abbr> Permanent Message Header Field Registry, as they are to edit this wiki. Document it there first, as required by the <abbr title="Hypertext Markup Language">HTML</abbr> <abbr title="specification">spec.</abbr> By all means, please document everything — but follow the standards process and begin at the beginning; not at the end.		Theimp: No, it's not. Anyone is as free to propose additions to the <abbr title="Internet Assigned Numbers Authority">IANA</abbr> Permanent Message Header Field Registry, as they are to edit this wiki. Document it there first, as required by the <abbr title="Hypertext Markup Language">HTML</abbr> <abbr title="specification">spec.</abbr> 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.		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 <abbr title="Internet Assigned Numbers Authority">IANA</abbr> 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 <abbr title="Internet Assigned Numbers Authority">IANA</abbr> registered extensions only, as it says in the <abbr title="specification">spec.</abbr> Or, if you think that the requirement that registration in the <abbr title="Internet Assigned Numbers Authority">IANA</abbr> Permanent Message Header Field Registry shouldn't exist, then why not propose changes to the <abbr title="Hypertext Markup Language">HTML</abbr> <abbr title="specification">spec.</abbr> 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.		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 <abbr title="Internet Assigned Numbers Authority">IANA</abbr> 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 <abbr title="Internet Assigned Numbers Authority">IANA</abbr> registered extensions only, as it says in the <abbr title="specification">spec.</abbr> Or, if you think that the requirement that registration in the <abbr title="Internet Assigned Numbers Authority">IANA</abbr> Permanent Message Header Field Registry shouldn't exist, then why not propose changes to the <abbr title="Hypertext Markup Language">HTML</abbr> <abbr title="specification">spec.</abbr> 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.

Line 17:		Line 17:

	The <abbr title="Hypertext Markup Language">HTML</abbr> <abbr title="specification">spec.</abbr> says that those wishing to “document reality” have the onus of ensuring that their extensions are first documented with the <abbr title="Internet Assigned Numbers Authority">IANA</abbr> before they begin documenting it here. I mean, if there is so little respect for the <abbr title="specification">spec.</abbr> 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 <abbr title="Hypertext Markup Language">HTML</abbr> or not. There are places to document such things; but this is not such a place.		The <abbr title="Hypertext Markup Language">HTML</abbr> <abbr title="specification">spec.</abbr> says that those wishing to “document reality” have the onus of ensuring that their extensions are first documented with the <abbr title="Internet Assigned Numbers Authority">IANA</abbr> before they begin documenting it here. I mean, if there is so little respect for the <abbr title="specification">spec.</abbr> 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 <abbr title="Hypertext Markup Language">HTML</abbr> 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 <abbr title="Internet Assigned Numbers Authority">IANA</abbr>-related requirements from the <abbr title="Hypertext Markup Language">HTML</abbr> <abbr title="specification">spec.</abbr>
			;“see [[IETF]]”: Well, in my dealings, I haven't found the <abbr title="Internet Engineering Task Force">IETF</abbr> any worse than, say, the <abbr title="World Wide Web Consortium">W3C</abbr> 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 <abbr title="specification">spec.</abbr>? In fact, if that's a valid argument, then why is there a <abbr title="specification">spec.</abbr> at all?

	~~Anne:~~ IANA is ~~annoying~~, ~~see [[IETF]]~~. ~~No need~~ to ~~abide by processes that are full of hurt~~.		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 <abbr title="Internet Assigned Numbers Authority">IANA</abbr> Permanent Message Header Field Registry, ''in turn'', makes the
			<abbr title="Hypertext Markup Language">HTML</abbr> <abbr title="specification">spec.</abbr> inconsistent with reality. The only way to reconcile this contradiction is to remove the <abbr title="Internet Assigned Numbers Authority">IANA</abbr> Permanent Message Header Field Registry requirements from the <abbr title="Hypertext Markup Language">HTML</abbr> <abbr title="specification">spec.</abbr>, 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 <abbr title="World Wide Web Consortium">W3C</abbr> to be at least as “annoying” as the <abbr title="Internet Engineering Task Force">IETF</abbr>.

Annevk at 18:44, 2 July 2012

2012-07-02T18:44:56Z

← Older revision		Revision as of 18:44, 2 July 2012
Line 17:		Line 17:

	The <abbr title="Hypertext Markup Language">HTML</abbr> <abbr title="specification">spec.</abbr> says that those wishing to “document reality” have the onus of ensuring that their extensions are first documented with the <abbr title="Internet Assigned Numbers Authority">IANA</abbr> before they begin documenting it here. I mean, if there is so little respect for the <abbr title="specification">spec.</abbr> 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 <abbr title="Hypertext Markup Language">HTML</abbr> or not. There are places to document such things; but this is not such a place.		The <abbr title="Hypertext Markup Language">HTML</abbr> <abbr title="specification">spec.</abbr> says that those wishing to “document reality” have the onus of ensuring that their extensions are first documented with the <abbr title="Internet Assigned Numbers Authority">IANA</abbr> before they begin documenting it here. I mean, if there is so little respect for the <abbr title="specification">spec.</abbr> 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 <abbr title="Hypertext Markup Language">HTML</abbr> 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 at 08:09, 2 July 2012

2012-07-02T08:09:29Z

← Older revision		Revision as of 08:09, 2 July 2012
Line 11:		Line 11:

	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.		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 <abbr title="Internet Assigned Numbers Authority">IANA</abbr> 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 <abbr title="Internet Assigned Numbers Authority">IANA</abbr> registered extensions only, as it says in the <abbr title="specification">spec.</abbr> Or, if you think that the requirement that registration in the <abbr title="Internet Assigned Numbers Authority">IANA</abbr> Permanent Message Header Field Registry shouldn't exist, then why not propose changes to the <abbr title="Hypertext Markup Language">HTML</abbr> <abbr title="specification">spec.</abbr> 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 <abbr title="Internet Assigned Numbers Authority">IANA</abbr> 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 <abbr title="specification">spec.</abbr> writers' prerogative. But until either the <abbr title="Internet Assigned Numbers Authority">IANA</abbr> Permanent Message Header Field Registry is updated, or the <abbr title="specification">spec.</abbr> 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 <abbr title="Hypertext Markup Language">HTML</abbr> <abbr title="specification">spec.</abbr> says that those wishing to “document reality” have the onus of ensuring that their extensions are first documented with the <abbr title="Internet Assigned Numbers Authority">IANA</abbr> before they begin documenting it here. I mean, if there is so little respect for the <abbr title="specification">spec.</abbr> 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 <abbr title="Hypertext Markup Language">HTML</abbr> or not. There are places to document such things; but this is not such a place.

Hixie at 03:23, 2 July 2012

2012-07-02T03:23:38Z

← Older revision		Revision as of 03:23, 2 July 2012
Line 9:		Line 9:

	Theimp: No, it's not. Anyone is as free to propose additions to the <abbr title="Internet Assigned Numbers Authority">IANA</abbr> Permanent Message Header Field Registry, as they are to edit this wiki. Document it there first, as required by the <abbr title="Hypertext Markup Language">HTML</abbr> <abbr title="specification">spec.</abbr> By all means, please document everything — but follow the standards process and begin at the beginning; not at the end.		Theimp: No, it's not. Anyone is as free to propose additions to the <abbr title="Internet Assigned Numbers Authority">IANA</abbr> Permanent Message Header Field Registry, as they are to edit this wiki. Document it there first, as required by the <abbr title="Hypertext Markup Language">HTML</abbr> <abbr title="specification">spec.</abbr> 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.