W3C home > Mailing lists > Public > public-appformats@w3.org > January 2008

Re: ISSUE-18: Is JSONRequest an acceptable alternative to the current model? [Access Control]

From: Anne van Kesteren <annevk@opera.com>
Date: Fri, 04 Jan 2008 23:52:51 +0100
To: "Close, Tyler J." <tyler.close@hp.com>
Cc: "WAF WG (public)" <public-appformats@w3.org>
Message-ID: <op.t4fgidwa64w2qv@annevk-t60.oslo.opera.com>

On Fri, 04 Jan 2008 23:25:26 +0100, Close, Tyler J. <tyler.close@hp.com>  
wrote:
> So, strictly speaking, the above is not true. It is not possible to  
> simply place a JSON file on a server and in so doing make it available  
> for cross-domain requests using the proposed XMLHttpRequest extension.

Indeed, you would have to use an HTTP header.


> I believe that this WG has stated that this minimal level of control  
> over the server is one of the required deployment scenarios; but that  
> functionality is only supported for XML.

Currently, yes. We might revise this in future versions based on feedback.


> Similarly, the JSONRequest proposal only supports this functionality for  
> JSON. Both proposals can tunnel other Content-Types within their  
> supported Content-Type.

You failed to reply to the XSLT and XBL remarks that the JSON thingie does  
not address. These are important use cases. The access control proposal  
can also be used for the server sent events protocol as proposed by HTML5.  
JSONRequest would again fail to address that use case.


>> * Having multiple network APIs seems like a bad idea.
>
> The two proposals have made opposite choices on fundamental design  
> decisions, such as: where policy is enforced, whether or not cookies are  
> sent, and whether or not interoperation with existing resources is  
> supported.

We got feedback that sending cookies and authentication data is *very*  
important.


> Any one of these choices could prove significant to adoption. For  
> example, some developers may require better support for other  
> Content-Types; whereas some organizations may be reticent to allow  
> installation of browsers that may interoperate with existing web  
> resources in unanticipated ways.

The access control proposal does not interoperate with existing web  
content in unanticipated ways. The policy is *opt-in*.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
Received on Friday, 4 January 2008 22:50:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:56:21 UTC