- From: Eduardo Robles Elvira <edulix@agoravoting.com>
- Date: Sat, 20 Sep 2014 18:05:17 +0200
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
On Sat, Sep 20, 2014 at 3:02 PM, Julian Reschke <julian.reschke@gmx.de> wrote: > On 2014-09-20 14:07, Eduardo Robles Elvira wrote: >> >> Hello everyone: >> >> I'd like to first bring to your attention the benefits of a digest uri >> scheme. There have been proposals in that direction at IETF [0]. It's > > I think this led to <http://tools.ietf.org/html/rfc6920>. > >> ... > > Best regards, Julian Hello Julian: Thanks for the information. I'm sorry I haven't read all the related standards. That< makes me have some ideas to solve problems that, as it turns out, have already been solved - and with a better and more generic solution than the one I proposed. That makes me look like a fool but I don't worry about that, because it means the Internet is well architected :-). I don't want to create too much noise in the list though. The RFC6920 you mention defines a .well-known URI ni suffix that creates a better solution to the problem I was referring to. May I ask, are browser-vendors planning to support .well-kwnon URI ni suffix in their browsers so that if I click in a .well-known ni URI, it loads *and checks its integrity*, or currently the idea is just to give the minimal RFC6920 support needed to make SRI work (i.e. make ni URIs work only as subresources' metadata)? Regards, -- Eduardo Robles Elvira @edulix skype: edulix2 http://agoravoting.org @agoravoting +34 634 571 634
Received on Saturday, 20 September 2014 16:06:15 UTC