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 18:17:53 +0000
Message-ID: <CAEeYn8it57Ed5yXC03SyCwE4ojR+++Ovwm+ktBvuLH7zOz-CSw@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
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>
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?

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.



On Tue Jan 20 2015 at 10:05:25 AM Anne van Kesteren <annevk@annevk.nl>
wrote:

> On Tue, Jan 20, 2015 at 6:51 PM, Brad Hill <hillbrad@gmail.com> wrote:
> > "not invented here".
>
> That seems unfair. As far as I know we don't currently use URLs for
> anything other than fetching and navigating throughout the web
> platform. We do have a fair amount of trivial microsyntaxes for other
> tasks, especially in HTML.
>
> It is also not like we get any leverage out of using URLs here as this
> is essentially a microsyntax layered on top of a URL. We first have to
> parse it as a URL, then I guess we have to check that there is no host
> component (not possible per current URL parser definition by the way),
> then we have to split the path component in various ways and do checks
> on the query. Did you define processing for what happens if there is a
> fragment there or username and password information?
>
>
> --
> https://annevankesteren.nl/
>
Received on Tuesday, 20 January 2015 18:18:21 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:09 UTC