- From: Adam Barth <w3c@adambarth.com>
- Date: Wed, 26 Jun 2013 09:54:52 -0700
- 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. Adam
Received on Wednesday, 26 June 2013 16:55:52 UTC