W3C home > Mailing lists > Public > public-webappsec@w3.org > June 2013

Re: policy-uri proposal (ACTION 97)

From: Adam Barth <w3c@adambarth.com>
Date: Wed, 26 Jun 2013 09:54:52 -0700
Message-ID: <CAJE5ia_Qc8BRxYuooNr8UZ2S1v4AiEbJjuDpEk4nji5mxfuxwg@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Daniel Veditz <dveditz@mozilla.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Wed, Jun 26, 2013 at 3:12 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Wed, Jun 26, 2013 at 5:15 AM, Adam Barth <w3c@adambarth.com> wrote:
>> On Tue, Jun 25, 2013 at 2:38 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
>>> :-( It seems -uri is also used for the JSON resource. So if we only
>>> add it as alias it would not solve that, though we could avoid
>>> introducing more -uri in 1.1 I suppose. It really blows we don't use
>>> the correct term consistently.
>> I suspect the issue is that different people have different opinions
>> about which term is more correct.  :)
> Sure, but given the precedent of url(), type=url, document.URL,
> WebSocket.url, EventSource.url, new URL(), ... URI is just the wrong
> term for web-exposed names.

I feel like you're picking a choosing your examples.  As a counter
example, document.documentURI uses the term "URI".

Look, I understand that this is a point of disagreement between you
and the IETF.  The IETF says that "URI" is the proper term (e.g.,
RFC3986).  If we were working from a blank slate, I'd probably support
matching the DOM API's use of the term URL, but we're not working from
a blank state.  CSP 1.0 is already a CR, and many folks have already
implemented the specification on both the client and the server.
Changing terminology now would torture these folks for little benefit.

On Wed, Jun 26, 2013 at 3:18 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> I'm kind of surprised nobody else caught this. Unfortunately I can't
> solely review all the new features as they are developed.

People did notice which term CSP uses, but they were people with
opposite beliefs from you on this topic.  Sadly, we have to use one
term or another, and we'll get embroiled in this debate whichever one
we choose.

>> Do we have to change the 1.0 spec and the compliant implementations at
>> this late date?
> Again, if we can that'd be great.

I don't think the benefits of doing so are worth the costs.

Received on Wednesday, 26 June 2013 16:55:52 UTC

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