"Parsing" is undefined (broken link) about webappsec-referrer-policy

[annevk]

FWIW, typically the editor's draft is in a better state than whatever is published on TR/. It's hard to find counter examples.

[mikewest]

The language shifted since publication. The editor's draft at https://w3c.github.io/webappsec-referrer-policy/#parse-referrer-policy-from-header is up to date (and correct, so far as I can tell).

@wseltzer, @hillbrad: Our /TR snapshots could probably point to a snapshot of Fetch at the time of publication (e.g. https://fetch.spec.whatwg.org/commit-snapshots/e4cf6c44dc946689189ddde123c127d7ab86d17b/). WDYT?

[aidantwoods]

Editors draft LGTM in that section!

I'll leave this open to keep a pin in pointing to snapshot versions of referenced material to avoid these broken links in future, but feel free to close (since the later version doesn't have this issue).

---

Minor comment from me on pointing to the fetch snapshot: a candidate recommendation (as far as I know) encourages early implementors to try it out, but the snapshot they'll be linked to categorically discourages implementation. I know that the candidate recommendations aren't ready, but they're not meant to discourage attempting an implementation either (again, as far as I know). Might be a little confusing to have the original spec saying "hey try this out", but links then end up saying "do not implement this".

[mikewest]

I'll leave this open to keep a pin in pointing to snapshot versions of referenced material to avoid these broken links in future, but feel free to close (since the later version doesn't have this issue).

I expect this bug to be resolved when @jeisinger and @estark37 publish a "proposed recommendation" of this spec, as it's a pretty trivial fix that doesn't seem to introduce any IPR issues. @wseltzer can confirm. I think we're just blocked on having two independent implementations of some of the more esoteric referrer policies at this point. So, soonish?

Minor comment from me on pointing to the fetch snapshot: a candidate recommendation (as far as I know) encourages early implementors to try it out, but the snapshot they'll be linked to categorically discourages implementation.

There's a disconnect between the publishing model at the W3C and the "living standard" model used for documents like Fetch. Given that the W3C wants to publish (and gather IP commitments to) stable/static documents, pointing to snapshots of external dependencies seems reasonable, as those are guaranteed to remain stable over time.

Stability, though, is not an end in itself. Fetch is actively maintained, bugs are fixed, confusing bits are refactored, etc. Discouraging folks from using older versions of that spec seems reasonable, for the same reasons that we discourage folks from using old versions of shared software libraries. shrug Ubuntu's LTS has good reasons for including OpenSSL 1.0.whatever, even though that project has moved on to 1.1.whatever (and would encourage upgrades from the former to the latter).

In general, I would personally recommend reading the editors' draft rather than the long-term snapshot. There are good reasons that the formal recommendation exists, but equally good reasons to move past it when trying to understand the behavior we expect browsers to implement. :)

[aidantwoods]

Stability, though, is not an end in itself. Fetch is actively maintained, bugs are fixed, confusing bits are refactored, etc. Discouraging folks from using older versions of that spec seems reasonable

Can't disagree with this – and indeed this may be a reason not to link to the snapshot (since it's always advisable to check a later version with bug-fixes)? Though obviously looking at a more recent version of Fetch in this case is exactly what caused the bug 😉, so looking ahead won't always give you a compatible document.
I suppose the best solution to all this is just to take a peek at the editors draft if such ambiguities occur – not sure if there would be a good way of automating an advisory to do that for the case of broken links?

In general, I would personally recommend reading the editors' draft rather than the long-term snapshot. There are good reasons that the formal recommendation exists, but equally good reasons to move past it when trying to understand the behavior we expect browsers to implement. :)

I can't reference the editors draft with quite the same weighting as the candidate recommendation 😉 but in general, I think I may try to make a habit of additionally reading over the editors draft (at least for personal understanding) when digging into the specifics

[estark37]

Closing this out since AFAICT there's nothing to be done in this spec except publish a PR?