Editorial: Relationship to the Permissions Policy specification

[marcoscaceres]

closes #176
closes #177

@clelland, would you mind taking a look?
@equalsJeffH, I'm hoping this can address #177 too.

Hopefully this captures the delineation between the two specs correctly. I wonder if we should then add something over on the Permissions Policy spec to complement this?

---

Preview | Diff

[clelland]

@marcoscaceres, I must have missed this in my inbox (overagressive filters, I suppose) -- thanks for writing it up, though! It does a good job of capturing the interplay between the two specifications.

Would it make sense to have parallel text in the Permissions Policy specification as well?

[equalsJeffH]

Apologies for missing this, I was on leave across Aug 2021.

WRT:

Would it make sense to have parallel text in the Permissions Policy specification as well?

I think it would make sense have parallel text in the Permissions Policy specification. Note that there is issue #166 "Delineate relationship between Feature Policy and Permissions" wrt the Permissions Policy specification ;-)

WRT the text this PR added to the Permissions spec, it seems to be only implied that where a given feature is both a powerful feature, and is also subject to permissions policy, that the feature's "policy-controlled feature token" (as defined in the feature's specification), and in the Permissions spec's PermissionName enum (aka "Powerful features registry"), can be the same, but (I am guessing) do not have to be the same. Though, I am guessing that the intent is for them to be the same (I cannot quickly find an example where they are not the same). In any case, whatever the requirement is, it ought to be stated explicitly.

E.g., the strings "camera" and "microphone" are both defined as powerful feature names and are also declared as policy-controlled feature tokens (aka "strings").

Additionally, I find this statement in the text this PR added confusing:

The APIs and features in scope for the Permissions Policy specification go beyond those identified in this specification's PermissionName enum (e.g., "sync-xhr" and "gamepad").

...because: neither "sync-xhr" nor "gamepad" are permission names (i.e., enum values within PermissionName) -- so it is not obviously clear what using those policy-controlled feature tokens (aka "strings") as examples is intended to mean. Clarification would be good.