[TAG] New Registry; Strategy for Updates?

[slightlyoff]

From TAG review

This spec introduces a new registry of names. What is the strategy for maintaining consistency between the Permissions API registry and naming and the feature names in this spec?

Related: we acknowledge that registry maintainence is an unresolved issue in the platform. We're going look into development of a unified solution for many specs and will ping back here if we make progress.

[raymeskhoury]

There has been some agreement that Permissions in the Permissions API registry should be a subset of features in Feature Policy. I'm not sure what the best way to enforce that is though?

[clelland]

I mentioned this in #69, but I'll restate here -- I'd love to avoid introducing a new registry if possible. With the exception of "fullscreen" and "allowpaymentrequest", which require special handling for compat reasons, I've tried to avoid mentioning any specific features in the normative text of the spec.

The features are all mentioned in an appendix, which I think should eventually just be collected from references in other specs. If other specs can define xyz to be a policy-controlled-feature, declare its default allowlist and define its behaviour when enabled and disabled, they should be able to do that by reference to this spec, and then this spec doesn't have to be the authoritative source for all features. Is such a thing possible?

[clelland]

Ping @slightlyoff, @raymeskhoury -- Do you think that what we have is sufficient, or is an actual registry unavoidable here?

[raymeskhoury]

I'm not actually sure on the spec side. Conceptually it seems ok to me not to have a registry though.

[clelland]

Ping @slightlyoff -- is this issue okay to close now?

[annevk]

Is such a thing possible?

If there's no order-dependent processing of any kind that could work, but it makes reviewing rather hard as it's unclear what's being controlled.

And note if you ever add an API you'll likely have to add all of them due to enums and such.

[equalsJeffH]

see also: w3c/permissions#177 "Clarify/resolve relationship of PermissionName enum values to Feature Identifier values"