WHATWG Wiki - User contributions [en]

PragmaExtensions

2012-07-03T22:15:30Z

Theimp: Reverted edits by Annevk (talk) as agreed on the PragmaExtensions/Talk page

This page lists the allowed extension values for the http-equiv="" attribute of the <meta> element in HTML. For the detailed registration requirements, [http://www.whatwg.org/html#concept-http-equiv-extensions see the specification].

{|
! Keyword
! Brief description
! Specification
|-
| PICS-Label
| Labels that help content advisory software protect children from potentially harmful material [[http://www.fosi.org/icra/ more]]
| [http://www.w3.org/TR/REC-PICS-labels/ PICS Label Distribution Label Syntax and Communication Protocols]
|}

[[Category:Registries]]

Talk:PragmaExtensions

2012-07-03T22:15:07Z

Theimp:

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>
----
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 <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.
----
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.
----
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?

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>.
----
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.

Talk:PragmaExtensions

2012-07-03T10:02:50Z

Theimp:

Talk:PragmaExtensions

2012-07-02T08:09:29Z

Theimp:

Talk:PragmaExtensions

2012-07-02T03:14:44Z

Theimp:

PragmaExtensions

2012-07-02T03:14:39Z

Theimp: Please register X-UA-Compatible with the IANA if you wish to add it to this registry, as required per the HTML5 spec.

Talk:PragmaExtensions

2012-04-04T03:20:07Z

Theimp:

PragmaExtensions

2012-04-04T03:18:38Z

Theimp: Removed entries for x-dns-prefetch-control and x-ua-compatible which are currently ineligible for inclusion

This page lists the allowed extension values for the http-equiv="" attribute of the <meta> element in HTML5. For the detailed registration requirements, [http://www.whatwg.org/html#concept-http-equiv-extensions see the specification].

{|
! Keyword
! Brief description
! Specification
|-
| PICS-Label
| Labels that help content advisory software protect children from potentially harmful material [[http://www.fosi.org/icra/ more]]
| [http://www.w3.org/TR/REC-PICS-labels/ PICS Label Distribution Label Syntax and Communication Protocols]
|}

[[Category:Registries]]

Talk:PragmaExtensions

2012-03-22T00:13:24Z

Theimp: Question about removing invalid entries.