Re: Explicitly identifying "permissions" as a definition type

To be clear, then, you're talking about having a definition type where the
target is the literal string used in headers, like 'geolocation' or
'screen-wake-lock' ? (As opposed to a definition for the behaviour or
access being permitted)

I think that makes sense, and should help avoid language like "This spec
defines a policy-controlled feature identified by the token 'foo'" and "is
allowed to use the policy-controlled feature identified by the token
'foo'", and replace it with "<dfn>foo</dfn>" and "allowed to use foo".

Ian

On Thu, Feb 10, 2022 at 4:34 PM Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Wed, Feb 9, 2022 at 8:13 PM Marcos Caceres <marcos@marcosc.com> wrote:
> > For example, the token string "geolocation" can be used by both the in
> different ways by different technologies:
> >
> >  * Permissions-Policy HTTP header
> >  * iframe's allow= attribute, where HTML checks if a document is
> "allowed to use" token string.
> >  * In the Permissions spec, when .query() is called, it checks if the
> feature identified by the token string is supported.
> >  * And so on...
> >
> > I'd like propose that we elevate these token strings from being a
> "concept" type to an explicit "permission" definition type.
>
> So long as it is indeed common to use the exact same string in all the
> situations, then yeah, I've got no problem with a new definition type.
>
> ~TJ
>
>