Re: Couple comments on Subresource Integrity

Regarding explicit specification of content-type, consider if we eventually
decided to use the hash identifiers for retrieving things from some type of
content-addressable-storage.  The browser might have the correct bits
laying around, but they may have been delivered over a non-HTTP mechanism
or the original headers may not have been preserved.

Using a standard format also is how we start to build an ecosystem around
these ideas.  In the future you might be able to use a local CDN that
allows ni:// urls to be used like magnet links, etc.

I'd rather reference a 20 page spec that's done and add a new algorithm to
the already-established registry than re-invent 10 or even 5 pages inline
with this one unless there are good reasons not to use the existing spec.
 Saving a few bytes hasn't convinced me yet.


On Tue, Mar 25, 2014 at 5:40 AM, Devdatta Akhawe <dev.akhawe@gmail.com>wrote:

> > The 6920 format adds verbosity, parsing, and having to read a 20-page
> > (?!) doc.  What's the benefit?
>
> I am curious: are these the only concerns you have with using the RFC 6920?
>
> One benefit of having content type as separate meta-data is the
> browser can send that and only that in the "accept" header. Regardless
> of whether the format is RFC6920 or not, I do think this is useful.
>
> I agree that reading a 20 page doc for something so simple is kinda
> ridiculous: at first glance, there do seem to be things in it that are
> unnecessary for the SRI use-case. But, at first glance---maybe others
> are able to come up with scenarios where those things are useful too.
>
> thanks
> Dev
>
>