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

Re: [Integrity] typos with ni URIs

From: Anne van Kesteren <annevk@annevk.nl>
Date: Tue, 20 Jan 2015 19:33:29 +0100
Message-ID: <CADnb78h5EASzf__3wzP-rWHz5hO4DAwq4_772b234nLu8KhKTA@mail.gmail.com>
To: Brad Hill <hillbrad@gmail.com>
Cc: Brian Smith <brian@briansmith.org>, Martin Thomson <martin.thomson@gmail.com>, Mike West <mkwst@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, "Manger, James" <James.H.Manger@team.telstra.com>
On Tue, Jan 20, 2015 at 7:17 PM, Brad Hill <hillbrad@gmail.com> wrote:
> I'm not trying to be unfair.  I understand this is not cost-free.  I just
> wonder - yes, we're the first to find a use for this particular syntax.  It
> looks cheaper now to just do a microformat that meets our needs.  (though
> there is probably some cost in defining additional attributes and their
> processing, e.g. if multivalued, etc.) But what about the next use case for
> something like a ni:/// URL?  And the third, and fourth?  Are we confident
> that browsers are never going to accept a hash-based-identifier where today
> they accept a URL?

They can just reuse the existing microsyntax, no? Given that this is
process this URL and then process this microsyntax and the proposal is
to have "process this microsyntax", I'm fairly certain the latter is
going to win out each time. (Note also that URL parsers are not
interoperable at the moment and some will e.g. normalize "%67" to "g"
and others won't. And RFC 3986 allows either so you'd have to add that
too. Has that been done?)

> Or alternately, is there harm in treating RFC6920 as a
> microsyntax-in-URL-drag and not using the URL parser on it in this usage?
> As such it is slightly more complex than needed when viewed in isolation,
> but at least it would not impose (premature) costs on the URL parser.

At that point you are essentially forking. (And we would be forking
already, since that requires RFC 3986 and we don't have that.)

Received on Tuesday, 20 January 2015 18:33:52 UTC

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