Re: [push-api] Clarify subscription relationships, lifecycle, and uniqueness. (#112)

>        </p>
>        <p>
> -        <a title="user agent">User agents</a> MAY support prearranged trust relationships that do
> -        not require such per-request user interfaces.
> +        When a permission is revoked, all <a title="push subscription">push subscriptions</a>
> +        created with that permission MUST be terminated.
> +      </p>
> +      <p>
> +        When a <a>service worker registration</a> is unregistered, any associated <a>push
> +        subscription</a> MUST be terminated.
> +      </p>
> +      <p>
> +        The <a>subscription id</a> of a terminated <a>push subscription</a> MUST never be reused
> +        for a new <a>push subscription</a>.

Perhaps concisely clarify *why* this is the case? (Persistent identifiers.)

I imagine that an implementer reading the specification will initially consider the semantics of the push service that will service their implementation. If that service generates a subscription Id based on some kind of hardware Id, it's not unrealistic to expect naive re-use. Hence why giving some context may be useful.

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/push-api/pull/112/files#r24024899