[cors] Status

Last week I have been cleaning up CORS with respect to the normative  
definitions and various algorithms. I will summarize those changes in a  
separate e-mail. I'm now trying to figure out how to deal with the  
remaining bits of work.

I would very much appreciate it if people involved in CORS (and other  
interested parties of course) can read through this e-mail and share their  
thoughts. The sooner the better.


   http://www.w3.org/2008/webapps/track/products/7

ISSUE-13 "Opting into cookies" it seems this is part of the specification  
now in the form of the Access-Control-Allow-Credentials header and  
credentials flag.

ISSUE-25 "Revocation of cached access grants" as I stated in July 2008  
(e-mail is referenced from the issue) you can revoke cache entries by  
simply not allowing the actual request to pass. (Part of this issue became  
ISSUE-30.)

ISSUE-30 "Should spec have wording to recognise that User Agents may  
implement further security beyond the spec?"  
http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0048.html  
has suggested additional restrictions user agents may impose. I'm thinking  
that should be a normative subsection of the processing model. Makes sense?

ACTION-11 "Draft scenarios for AC + various host specs" the use cases  
section in the specification has some scenarios. Given @font-face and  
media elements I could add some more there I suppose if that is desired.

ACTION-148 "Try to find an Editor for the Access Control Primer document"  
I do not think this is worth the time of the WG to be honest. Tutorials  
for using CORS are already appearing on the Web. E.g.  
https://developer.mozilla.org/En/HTTP_access_control Having one that is  
vetted by the WG seems like something that demands more resources than we  
have.

ACTION-192 "Submit an input that will result in closing Issue #21" that is  
a Widgets issue.


The Origin header needs to become something that can be referenced. Should  
I keep the definition in the draft meanwhile? Currently it is commented  
out.


The security section currently mostly makes redundant requirements  
(incorrect, it should be non-normative) and requirements that are better  
moved to the processing model. I thought of maybe introducing a processing  
model for servers so that the requirements on them become a bit more  
clear. And the the user agent and server processing model share the syntax  
section for header definitions on writing and parsing. Does that make  
sense?

Not sure what happens to the security section after that. Ideas?


The terms case-sensitive, ASCII case-insensitive, and converting a string  
to lowercase would ideally be defined in a separate document all kinds of  
specifications can reference. Although it should be pretty clear from the  
definitions already, that would strengthen they are indeed identical and  
can be implemented with the same function. This is just a minor thing  
though and does not really affect CORS in any way.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Monday, 9 February 2009 12:44:36 UTC