Here is an update on my last status messsage.
On Mon, 09 Feb 2009 21:43:54 +0900, Anne van Kesteren <ann...@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/>
