Changes policy vs non-browser implementations

[jyasskin]

In the IETF last-call review of draft-ietf-httpbis-compression-dictionary, which has normative references to Fetch and URL Pattern, a few reviewers have been concerned about IETF documents linking to living standards, at least one on the grounds that

In the HTTP API space, there are many user agents that are not browsers, that will need to implement URL Pattern and that specification could change at any time. — Darrel Miller

These reviewers have generally been placated by pointing to https://whatwg.org/working-mode#changes or https://whatwg.org/faq#change-at-any-time indicating that the specifications do not "change at any time", but I think they'd be right to remain a little concerned. In particular, the editors know to check with browser implementations and to file implementation bugs against browsers, but if a non-browser implements, say, URL Pattern, as part of implementing compression dictionaries, I don't think the URL Pattern editors have any reliable way to know that they need to check with an extra party, and they don't generally have contact information or a link to the bug tracker for that implementation.

We should find some way for non-browser implementations to register to be included in the usual changes process. We might also need to help editors figure out how to evaluate "strong implementer objections" from various kinds of implementers, although we can probably cross that bridge when we come to it.

[annevk]

Have they reached out?

This hasn't really been a problem for Fetch, HTML, and URL which have non-browser implementations that participate in the community, contribute tests, and are even tracked through the respective specification's PR template.

Perhaps the SG could codify some of this, but having this kind of cooperation occur naturally as part of having shared goals seems more sustainable.