UniMsg: editorial

The technical content of the spec looks fine as far as I can tell, but 
it's a little obscured by editorial matters.

I can see why something that looks just like current CORS specs is 
convenient to the WebApps WG reviewers,
but for a wider audience, consider an introduction such as:

--------
Introduction

Web applications increasingly seek to combine resources from multiple 
administrative domains. Consider the case of content from 
customer.example.org sending a request (via a script, a form, etc.) to a 
resource specified by service.example.com. For the protection of 
service.example.com, user agents enforce a /Same Origin Policy (SOP)/ 
that prohibit this message exchange. To enable the message exchange, 
service.example.com would need some means to opt-out of this protection.

The main goals of this specification are:

   1. Provide a means for resources to allow cross-origin messaging.
   2. Provide a means for clients to engage in origin independent
      messaging without the danger of Cross-Site-Request-Forgery (CSRF)
      and similar attacks.

We introduce an HTTP response header that allows a resource to opt-out 
of SOP protection for a given HTTP response in order to meet the first 
of these goals.

To understand the second goal, consider an attack case, in which 
service.example.com wants the request delivered to a resource that 
customer.example.org has permission to use but service.example.com does 
not. ...
--------

Also, in the abstract, I hate "This document...". How about "Uniform 
messaging is a mechanism..." in place of "This document defines a 
mechanism..."?

Re the use of "SOP" to stand for "Same Origin Policy," I have a hard 
time not reading it as "Standard Operating Procedure." I don't have a 
suggested fix.

Re "the familiar CSRF attack," I'd appreciate a citation at 1st use of 
the term. Likewise "HTTP response splitting vulnerabilities."

Also, re "virtue of being the same subset supported by the HTML form 
element"; that's not derived from HTML specs, is it? That's just 
well-known lore about how HTML is implemented? A citation would be 
nifty, though I can imagine there isn't a good one.

The anthropomorphism in "content sending a request" and "resources 
should add a header" rubs me the wrong way. I suppose I don't mind 
thinking of resources as agents, but maybe "content specifies a request"?

I don't grok "If the permissions needed for a POST are provided in 
response to a GET, ..." . Help?

Also.. "When placing permissions ..." confused me; 
s/permissions/credentials/?

typo? "Ensure not the reveal" should be "... to reveal"?


for reference:

Uniform Messaging, Level One
Editor's Draft 21 November 2009
Editors:
    Tyler Close (Google)
    Mark Miller (Google)
http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/att-0931/draft.html

-- 
Dan, writing from a machine not yet outfitted with a .sig