Re: comments on Cross-Origin Resource Sharing (CORS) of 3-Apr-2012

On Wed, 02 May 2012 02:20:26 +0200, =JeffH
<Jeff.Hodges@kingsmountain.com> wrote:
> The Security Considerations section is situated ahead of the meat of the
> spec, which makes it difficult to comprehend unless one skips ahead.

This is dealt with in a separate thread.


> The spec's exposition of its functionality would be greatly enhanced by
> at least one diagram, e.g. a "ladder" or "swimlane" protocol flow
> diagram.

If anyone can create one I am happy to include it.


> The spec abstract contains a specific technical example. It should have
> a more general overall description of the spec's problem space and
> approach, instead.

I think the abstract is fine. I can remove the example if people
prefer, but it should not become more elaborate.


> Should perhaps (boldly) define a new term for the notion of "an instance
> of an application from a foreign origin, executing in the user agent"
>   suggestion: web application client instance

Why? This specification is not about that.


> The examples are set off with the double vertical bar glyph along the
> left-hand edge -- however, they are not otherwise denoted explicitly as
> examples. The first time I read the spec, I hadn't before seen that
> example-denoting style and so was trying to read the para beginning with
> "If a resource author has a simple text resource..." as a logical
> continuation of the preceding paragraph and got pretty confused. I
> suggest the examples have at least a single line at the top (also set
> off using the double vertical bar glyph on the left) saying at least
> "For example: ".  E.g...
>
>    ||  For example:
>    ||
>    ||  If a resource author has a simple text resource....
>    ||

Yeah, I'm waiting for the W3C to establish some kind of style sheet
that hooks into the classes.


> The spec should define, or reference a definition of..
>
>   Ambient authority

Why? It should be pretty clear from the context what it is about.
Besides, it's only used non-normatively.


> overall detailed comments/questions:
> ------------------------------------
>
> The spec uses the terms "server" and "resource" almost but not quite
> interchangeably. There should be an exposition of what the terms mean
> and what the differences are between them, if these different terms must
> be used.  Could one of them, eg resource, be used consistently for both?
> Or is "server" needed in some particular places?  Also, the term
> "resource" is undefined in this spec.

It says in the terminology section that terminology is borrowed from
various other specifications. I'm not looking to redefine those.


> editorial items
> ---------------
>
> Section 5 Syntax -- perhaps should be divided up into two separate
> numbered subsections, one for response headers, the other for request
> headers. Also should have more whitespace in there in general, found it
> tough to visually parse.

I am not allowed to touch those style rules I think.


> "simple cross-origin request"
> -----------------------------
>
> Perhaps the definition for "simple cross-origin request" should simply
> be moved to be step 2 in section "7.1 Cross-Origin Request".

If you read the specification from top-to-bottom it is clear enough.
It's just a piece of the processing model.


> That definitely should be made more clear, and would have a salubrious
> effect across the specification, I expect.  Unfortunately, the behavior
> of "legacy" user agents in this regard is not clearly defined, except
> piecemeal in HTTP, and absent of security considerations.

It's actually clearly defined, if you read HTML, which is one of the
specifications CORS references.


-- 
Anne — Opera Software
http://annevankesteren.nl/
http://www.opera.com/

Received on Monday, 11 June 2012 12:03:12 UTC