Being external to it all, i.e. just reading the mailing-list with the
spec-title mentioned just about everytime, it clearly seems like a
good move to me: that specs starts to taste interesting whereas,
before, it seemed to be unrelated to my tasks!
;-)
paul
Le 13-janv.-09 à 17:50,
On Mon, 20 Oct 2008 17:32:03 +0200, Nikunj Mehta nikunj.me...@oracle.com
wrote:
The headers defined in this specification must be registered with IANA.
See permanent [1] managed by IETF under RFC 3864 [2]. Ideally, this
specification would have gone to IETF, but it looks like this WG has
Hi,
On Jan 13, 2009, at 11:50 AM, ext Anne van Kesteren wrote:
I know some people (e.g. Ian) don't like the idea, but it seems the
name Access Control for Cross-Site Requests confuses people,
especially the Access Control part:
http://www.w3.org/2001/tag/2008/12/10-minutes#item03
On Wed, 14 Jan 2009 14:28:49 +0100, Arthur Barstow art.bars...@nokia.com
wrote:
It's been over a year since we last changed the name of this spec so I
guess it's about time we renamed it again :-):
[[
Authorizing Read Access to XML Content Using the ?access-control?
Processing
Below is the draft agenda for the January 15 Widgets Voice Conference
(VC).
Inputs and discussion on the agenda topics before the meeting is
encouraged.
Logistics:
Time: 24:00 Tokyo; 17:00 Helsinki; 16:00 Paris; 15:00 London; 10:00
Boston; 07:00 Seattle
Duration = 60 minutes
Zakim
Hi Marcos,
I have (still) a couple of concerns about the localization section of
Widgets Packaging Configuration Last Call WD of 20081222.
/1/ Is the following statement in [1] as it should be?
Author requirements: Localized folders must be at the root of the widget (a
localized folder not at
Suggestion for http://dev.w3.org/2006/waf/widgets/#the-widget-element
When the value is missing or invalid, the widget user agent will
assume the value 300.
And perhaps reference
http://dev.w3.org/2006/waf/widgets/#step-3-set-the-configuration-defaults
Was wondering how you came up with
I wanted to let the WG members know that we have completed our support for
Access-Control in IE8 for the Simple Cross-Site Access Request. We support the
Access-Control-Allow-Origin: * wildcard as we did in Beta 2 but in the next
public release of IE8, our Release Candidate, we have also added
I do agree the title is important and support either of the
proposed new titles (preference goes with Resource). One question
I have here is whether Domain would be more accurate than Origin.
Domain does not capture significance of the scheme and port, while
Origin does. I'm updating the
On Wed, 14 Jan 2009 19:53:42 +0100, Jonas Sicking jo...@sicking.cc wrote:
What do other people think?
If we really think they should be different (and at least Adam Barth
suggests that might not be needed) I would really like to rename this
header to make it consistent with the rest of
On Wed, 14 Jan 2009 17:52:50 +0100, Alex Russell a...@dojotoolkit.org
wrote:
I do agree the title is important and support either of the proposed
new titles (preference goes with Resource). One question I have here
is whether Domain would be more accurate than Origin.
Domain does not
Thomas Roessler wrote on 1/12/2009 8:02 PM:
Having the CSRF-Origin defined in an RFC or another separate spec is a
good idea independently of whether or not it ends up being the same
header that's used for cross-site XHR.
If someone wants to form an Origin BOF at the next IETF meeting in
On Wed, 14 Jan 2009 20:36:12 +0100, Bil Corry b...@corry.biz wrote:
Jonas Sicking wrote on 1/14/2009 12:53 PM:
The problem I think is that the current name, 'Origin', is extremely
generic and so it's likely to cause confusion once we get other
headers containing origins.
That said, I do
On Wed, Jan 14, 2009 at 11:45 AM, Anne van Kesteren ann...@opera.com wrote:
On Wed, 14 Jan 2009 20:36:12 +0100, Bil Corry b...@corry.biz wrote:
Jonas Sicking wrote on 1/14/2009 12:53 PM:
The problem I think is that the current name, 'Origin', is extremely
generic and so it's likely to
On January 14, 2009 11:45 AM, Anne van Kesteren [mailto:ann...@opera.com] wrote:
On Wed, 14 Jan 2009 20:36:12 +0100, Bil Corry b...@corry.biz wrote:
Jonas Sicking wrote on 1/14/2009 12:53 PM:
The problem I think is that the current name, 'Origin', is extremely
generic and so it's likely to
On Tue, 13 Jan 2009, Jonas Sicking wrote:
On Tue, Jan 13, 2009 at 5:09 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 13 Jan 2009, Jonas Sicking wrote:
It's not just POST that we need to worry about, ideally we should
cover the GET case as well. Or at least it's quite likely that we
Feels like URL vs. URI to me, which for the 80% case is simply bike-
shedding. I appreciate that there is a question of specificity and
that your clarification is more correct...but is that a good enough
reason to do it?
Regards
On Jan 14, 2009, at 11:14 AM, Anne van Kesteren wrote:
On
On Wed, 14 Jan 2009 23:25:43 +0100, Alex Russell a...@dojotoolkit.org
wrote:
Feels like URL vs. URI to me, which for the 80% case is simply bike-
shedding.
To be honest, I never quite understood the difference between those two.
The difference between a domain and an origin however, is
On Jan 14, 2009, at 3:45 PM, Bil Corry wrote:
Adrian Bateman wrote on 1/14/2009 3:18 PM:
I actually don't think that the generic name is a problem as long
as the
CSRF solution uses a different name for a different meaning. The
value really
is an Origin and could potentially be used for
Cameron McCormack:
The question then is whether we want to include it. I don’t see how it
would be beneficial for anyone to redistribute one of the interface
files if it has been changed incompatibly, so I guess I don’t see the
need for it.
Some further off-list discussion regarding general
On Jan 14, 2009, at 5:32 PM, Bil Corry wrote:
Maciej Stachowiak wrote on 1/14/2009 6:14 PM:
Why does the CSRF defense header need to change on redirect?
Because to the site on the far end, it would appear the request came
from somewhere it didn't, effectively hiding the real source of
21 matches
Mail list logo
