Re: Can a publication change over time?

Hi Baldur, 

An integrity check on resources is a powerful feature, as "a user agent will refuse to render or execute responses that fail an integrity check". It more powerful than simply checking a date of modification.
What is the use case in which the publication would be declared "broken"?

Laurent



> Le 27 juil. 2017 à 16:18, Baldur Bjarnason <baldur@rebus.foundation> a écrit :
> 
> Hi all,
> 
> The web community has been dealing with a similar problem for a long time. Namely, you can only make assertions of safety for specific versions of a resource. The solution that browsers are implementing is subresource integrity[1]. The npm community has also settled on the same algorithm as a solution for demonstrating the integrity of packages being installed[2].
> 
> The basic concept is that the referencing resource adds an integrity attribute to the references it makes to subresources. This integrity attribute tells the UA that the reference is intended to be to that specific version of the resource and no longer applies if the subresource has been updated.
> 
> As far as updating goes, the web community has for a very long time relied on a combination of various feed formats and PubSubHubbub (now called WebSub[3] in its W3C incarnation) as an update mechanism. I’m pretty sure that update mechanism is utterly and completely out of scope for the Publishing WG and possibly even out of scope for the W3C given that atom is an IETF specification.
> 
> [1]: https://www.w3.org/TR/SRI/
> [2]: https://docs.npmjs.com/files/package-lock.json
> [3]: https://websub.rocks
> 
> - best
> - Baldur Bjarnason
>  baldur@rebus.foundation
>