http://www.apple.com/ also has this. (I have suggested to the site maintainers to move it into http headers, however, I do not see a good reason for it to be invalid.)

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Did Not Understand Request
Change Description: no spec change
Rationale: How does this help users? What is the use case?

Use case can be found here:

  http://www.fosi.org/icra/

Evidence of browser support:

  http://blogs.msdn.com/ie/archive/2010/03/17/more-standards-documentation-available.aspx

Maciej hits the nail on the head: what reason is there for this markup, which is a documented standard, deployed on high profile web sites, and implemented by tools including at least one major browser, to be labeled non-conforming?

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Did Not Understand Request
Change Description: no spec change
Rationale: The provided links did not provide clear use cases.

Could you provide a simple statement explaining how PICS helps a user?

If PICS doesn't do anything useful, then it would be better to let the PICS community register the value using the existing registration mechanism rather than have the spec itself mention it, since having the spec mention it would give it undue support. (I agree that there's no reason to make it non-conforming, but that wasn't what I was suggesting. There are clearly implementations and deployed uses; that wasn't challenged either.)

(In reply to comment #4)
> 
> Status: Did Not Understand Request
> Change Description: no spec change
> Rationale: The provided links did not provide clear use cases.
> 
> Could you provide a simple statement explaining how PICS helps a user?
> 
> If PICS doesn't do anything useful, then it would be better to let the PICS
> community register the value using the existing registration mechanism rather
> than have the spec itself mention it, since having the spec mention it would
> give it undue support. (I agree that there's no reason to make it
> non-conforming, but that wasn't what I was suggesting. There are clearly
> implementations and deployed uses; that wasn't challenged either.)

I must confess that I do not understand this response.

It was not my intent to give PIC "undue" support, merely to make it conforming.  If there were an existing registration mechanism that would enable the markup that was already standardized, implemented, and deployed markup to be considered conforming, that would suffice for my needs.

However, I have failed to find such a mechanism.  Instead, I see "The http-equiv attribute is an enumerated attribute. The following table lists the keywords defined for this attribute.".  Only four keywords are defined, and PICS-Label is not one of them.

Nor is there a provision for defining new http-equiv attributes mentioned in the Extensibility section.  Nor is such mentioned in the whatwg wiki FAQ (which I recognize is not authoritative, but does tend to be helpful).

For the moment, I am not flipping the status back to REOPENed as I truly don't believe I've provided any additional information; but I will say that if there is an existing registration mechanism that enables this markup to be conforming, I will suggest that the specification make that clearer, and I will agree that that serves my purposes.

(In reply to comment #5)

> 
> For the moment, I am not flipping the status back to REOPENed as I truly don't
> believe I've provided any additional information; but I will say that if there
> is an existing registration mechanism that enables this markup to be
> conforming, I will suggest that the specification make that clearer, and I will
> agree that that serves my purposes.

http://dev.w3.org/html5/spec/Overview.html#other-pragma-directives

I agree with you though that this could be made more clear by referring to it in other sections of the spec.

(In reply to comment #6)
> (In reply to comment #5)
> 
> > 
> > For the moment, I am not flipping the status back to REOPENed as I truly don't
> > believe I've provided any additional information; but I will say that if there
> > is an existing registration mechanism that enables this markup to be
> > conforming, I will suggest that the specification make that clearer, and I will
> > agree that that serves my purposes.
> 
> http://dev.w3.org/html5/spec/Overview.html#other-pragma-directives
> 
> I agree with you though that this could be made more clear by referring to it
> in other sections of the spec.

OK, I'm testing out the registry (in the spirit of the current status of issue 27).  Should that work out, and modulo the editorial concerns about this extension mechanism not being readily discoverable in the current spec, and modulo any potential follow-on to issue-27 which moves this registration to another registration facility, I will agree that this extension mechanism serves my needs.