Re: CfC: Subresource Integrity (SRI) to Last Call?

On Thu, Apr 23, 2015 at 9:51 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Wed, Apr 22, 2015 at 3:48 PM, Joel Weinberger <jww@chromium.org> wrote:
> > FWIW, it would not be difficult for Chrome to switch back to the ni:///
> > syntax, so I don't think we should make that a blocker on using it.
>
> As per
> https://lists.w3.org/Archives/Public/public-webappsec/2015Jan/0200.html
> and other emails I wrote on the subject I'm opposed to switching back.
> URLs add a layer of abstraction to the processing model that is not
> warranted and for which there is no precedent. The precedent worth
> following here is CSP and HTML's existing approach to syntax within
> attributes.
>

That's because this isn't a URL, it's a URI (at least not without an
authority component). As such, it's completely opaque to Web browsers.

While `integrity` isn't limited to HTML, there's plenty of precedent for
using URIs outside use as network identifiers in HTML, namely the `rel` and
`xmlns` attributes, and the `profile` media type property.

Also the rel="profile" link relation type in RFC 6906 [1]:

      Notes: Profile URIs are primarily intended to be used as
      identifiers, and thus clients SHOULD NOT indiscriminately access
      profile URIs.


In any event, Web browsers shouldn't need to care, the syntax is arbitrary
to them.

Cheers,

Austin.

[1] https://www.ietf.org/rfc/rfc6906.txt