Re: [cors] Status

In short, I agree with all actions below.

I do have some implementation feedback regarding redirects, but I'll
start a separate thread on that.

/ Jonas

On Wed, Feb 25, 2009 at 12:57 AM, Anne van Kesteren <annevk@opera.com> wrote:
> 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 17:39:09 UTC