W3C home > Mailing lists > Public > public-webappsec@w3.org > January 2015

Re: [Integrity] typos with ni URIs

From: Brad Hill <hillbrad@gmail.com>
Date: Tue, 20 Jan 2015 17:51:54 +0000
Message-ID: <CAEeYn8irRHmYpkRbYiGhkivf0F86vXEr4wN9OE_5Cnk2SOTRRA@mail.gmail.com>
To: Brian Smith <brian@briansmith.org>, Martin Thomson <martin.thomson@gmail.com>
Cc: Mike West <mkwst@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, "Manger, James" <James.H.Manger@team.telstra.com>
I don't see a lot of value in revisiting this decision at this point.  We
made the choice to avoid doing redundant work when there were additional
potential use cases on the table, which may yet re-emerge.  It doesn't seem
to have hampered the spec or experimental implementations significantly.
There's also general "ecosystem" value in re-use of specifications (and
reusable components built to support them) rather than proliferating new
microformats for substantially similar or identical use cases just because
"not invented here".

On Tue Jan 20 2015 at 9:39:03 AM Brian Smith <brian@briansmith.org> wrote:

> Martin Thomson <martin.thomson@gmail.com> wrote:
> > On 19 January 2015 at 13:40, Brian Smith <brian@briansmith.org> wrote:
> >> Note that this is a valid URL, where the scheme is the digest name and
> >> the path is the digest-value.
> >
> > Why go to the trouble of making it look like a URI?  A space separated
> > list of hash-colon-base64urlDigest tuples should suffice.  Give
> > content type its own attribute and avoid the bizarre delimiter.
> I had thought that making it conform to the URI syntax was needed in
> order for them to be usable in CSP source expressions. But, now I see
> that it seems like CSP's source list ABNF would not match any such URI
> without "://" in it, and the normative parsing/matching rules do not
> seem to actually require it to be a URI at all.
> Cheers,
> Brian
Received on Tuesday, 20 January 2015 17:52:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:44 UTC