This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
"4.2.5.4 Other pragma directives" restricts the set of allowed values in http-equiv: "Extensions to the predefined set of pragma directives may, under certain conditions, be registered in the WHATWG Wiki PragmaExtensions page. [WHATWGWIKI] 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] Pragma directives corresponding to headers describing metadata, or not requiring specific user agent processing, must not be registered; instead, use metadata names. Pragma directives corresponding to headers that affect the HTTP processing model (e.g. caching) must not be registered, as they would result in HTTP-level behavior being different for user agents that implement HTML than for user agents that do not. Anyone is free to edit the WHATWG Wiki PragmaExtensions page at any time to add a pragma directive satisfying these conditions. Such registrations must specify the following information: Keyword The actual name being defined. The name must match a previously-registered HTTP name with the same requirements. Brief description A short non-normative description of the purpose of the pragma directive. Specification A link to the specification defining the corresponding HTTP header. Conformance checkers must use the information given on the WHATWG Wiki PragmaExtensions page to establish if a value is allowed or not: values defined in this specification or listed on the aforementioned page must be accepted, whereas values not listed in either this specification or on the aforementioned page must be rejected as invalid. Conformance checkers may cache this information (e.g. for performance reasons or to avoid the use of unreliable network connectivity)." Problems: #1: Validity depends on the current content of the Wiki registry. I'd like to see proof that conformance checkers are actually going to implement this. #2: There is no registration procedure. If anybody can add, can anybody remove as well? #3: The whole concept is in conflict with HTML4, which delegated the contents of http-equiv directly to the related IETF specs #4: The registry procedure on the referenced Wiki page is out-of-sync with the spec text, it claims "...Such extensions are limited to previously-registered HTTP headers defined in an RFC, ..." #5: The specification link on the registry page refers to a different document outside the W3C spec, so not the HTML5 spec. #6: It's not clear at all that requiring an entry in the permanent registry is required.
Please file one bug per issue. > #1: Validity depends on the current content of the Wiki registry. I'd like to > see proof that conformance checkers are actually going to implement this. I do not have such proof at this time. > #2: There is no registration procedure. If anybody can add, can anybody remove > as well? Sure. I would expect a community to form around this wiki page (and the others) to maintain the integrity of the registry, removing registrations that aren't used, add others that people have forgotten to add, etc. I'd be happy to set up a mailing list if anyone wanted one to form such a community around. > #3: The whole concept is in conflict with HTML4, which delegated the contents > of http-equiv directly to the related IETF specs Indeed. That didn't work. > #4: The registry procedure on the referenced Wiki page is out-of-sync with the > spec text, it claims "...Such extensions are limited to previously-registered > HTTP headers defined in an RFC, ..." Please feel free to edit it. It's a wiki. :-) > #5: The specification link on the registry page refers to a different document > outside the W3C spec, so not the HTML5 spec. The WHATWG and W3C work together on HTML. You will have to get over your problem with this if you are to work constructively with the HTML working group. > #6: It's not clear at all that requiring an entry in the permanent registry is > required. If you think it would be better to allow registrations from the temporary registry I'm happy to change the spec. In general the idea is to strongly discourage the use of http-equiv at all, so I don't really see a problem with requiring that only established headers be used here. Since multiple issues were conflated into one bug, I'm resolving this as INVALID. This is not a formal editor's response; please split any specific issues into separate bugs so that they can be dealt with according to the working group process.
(In reply to comment #0) > #1: Validity depends on the current content of the Wiki registry. I'd like to > see proof that conformance checkers are actually going to implement this. validator.nu already implements something similar for the cases of registered language subtags and registered character encoding names. It reads in and parses the current contents of the IANA registries for those (http://www.iana.org/assignments/language-subtag-registry and http://www.iana.org/assignments/character-sets) and then validates lang and charset attribute values against those. The same kind of mechanism its using for those could also be used for validating http-equiv attribute values.
(In reply to comment #2) > (In reply to comment #0) > > #1: Validity depends on the current content of the Wiki registry. I'd like to > > see proof that conformance checkers are actually going to implement this. > > validator.nu already implements something similar for the cases of registered > language subtags and registered character encoding names. It reads in and > parses the current contents of the IANA registries for those > (http://www.iana.org/assignments/language-subtag-registry and > http://www.iana.org/assignments/character-sets) and then validates lang and > charset attribute values against those. The same kind of mechanism its using > for those could also be used for validating http-equiv attribute values. Mike, thanks for the feedback. My concern is that we have conformance requirements that nobody is aware of because validator.nu isn't checking them - this essentially applies to all WhatWG-Wiki-based registries. I'd like to find out what's keeping the validator.nu developers from implementing these checks (well, besides workload). Is checking these registries more complex than checking IANA registries?
(In reply to comment #3) > My concern is that we have conformance requirements that nobody is aware of > because validator.nu isn't checking them - this essentially applies to all > WhatWG-Wiki-based registries. I'd like to find out what's keeping the > validator.nu developers from implementing these checks (well, besides > workload). Is checking these registries more complex than checking IANA > registries? Validator.nu doesn't support the wiki registries, because during the entire existence of the registries, a shadow of doubt has hung over the registries. It hasn't been clear if it is worthwhile to implement support for a particular registry mechanism if the registry is going to be shot down or delegated to the IANA by the HTML WG in due course. This bug report is part of the problem. Not it seems that the reasoning is circular, so perhaps I should just go ahead and implement support for the registries to break the cycle.
(In reply to comment #4) > Validator.nu doesn't support the wiki registries, because during the entire > existence of the registries, a shadow of doubt has hung over the registries. It > hasn't been clear if it is worthwhile to implement support for a particular > registry mechanism if the registry is going to be shot down or delegated to the > IANA by the HTML WG in due course. > > This bug report is part of the problem. Not it seems that the reasoning is > circular, so perhaps I should just go ahead and implement support for the > registries to break the cycle. I agree that we should work on breaking that cycle. I don't think anybody has proposed to move *all* registries to IANA. For instance, it's not clear why they would care about meta/@name. Optimally, the W3C would provide something comparable (or even tell us to delegate to IANA). For now, I'd be happy if we could make sure - that the actual registration procedures are defined in the spec, not in a Wiki, - that the Wiki instances actually reference the proper spec, - that checking the registry contents actually is implementable, or alternatively, discuss whether use of unregistered values actually should be a conformance problem.