Re: [cors] Status

Here is an update on my last status messsage.

On Mon, 09 Feb 2009 21:43:54 +0900, Anne van Kesteren <annevk@opera.com>  
wrote:
> [...]
>
> 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.

Since this did not happen I tried doing the remaining work myself.


>    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.

I will close this issue unless someone speaks up by next Friday.


> 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.)

I will close this issue unless someone speaks up by Friday.


> 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?

This is now addressed in the specification. I will therefore close this  
issue unless someone speaks up by Friday.


> 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.

I will close this action unless someone speaks up by Friday.


> 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.

Since this action does cannot possibly stop progress on CORS I will leave  
this up to Art. (If someone is of the opinion that it can stop process on  
CORS please speak up by Friday.)


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

This has been closed already.


> 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.

This is an open issue in the draft with text commented out. If we go to  
Last Call and there is no reasonable progress on the RFC ID I will put the  
text back in. After all, we already provisionally registered the header  
through this WG.


> 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?

I have done this now.


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

There were a few considerations that did not fit anywhere else.


> 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.

I proposed drafting a Web Terminology Fundamentals specification for this  
work on the private list. If there is agreement on that I will start  
working on it. As mentioned, where these terms are defined should not  
impact CORS in any way.


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

Received on Wednesday, 25 February 2009 08:58:33 UTC