Skip to content

Spec should not specify behavior of other specs in Editors Draft status (i.e., Reporting API) #6933

@pes10k

Description

@pes10k

(this issue was the result of a PING privacy review: w3cping/privacy-request#47)

The draft currently defines interactions with the Reporting API which is currently in Editors Draft status, has open privacy issues on it, and has not had wide or horizontal review yet.

I do not think the HTML spec should define interactions with the Reporting API, or other proposals in a similar status, for several reasons (I'm mentioning Reporting API below bc its the one i noticed, but I think the following points are general):

  • coupling the HTML spec to a draft Reporting API proposal constraints the ability to address privacy (and other) issues in the Reporting API when it comes up for review
  • without at least some surrounding annotation, it'd give the reader of the HTML living standard the impression that the behavior in the Reporting API proposal is in a similar status as the HTML spec (living standard, and so unlikely to make breaking changes, etc), when that is not the case (at least in the eyes of W3C process)

Again this point may apply to other specs and proposals referenced in the HTML Standard. If so, i think this concern applies equally there too

Metadata

Metadata

Assignees

No one assigned

    Labels

    privacy-needs-resolutionIssue the Privacy Group has raised and looks for a response on.topic: cross-origin-embedder-policyIssues and ideas around the new "require CORP for subresource requests and frames and etc" proposaltopic: cross-origin-opener-policyIssues and ideas around the new "inverse of rel=noopener" header

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions