Re: [waf] minutes from 9 January 2008 Voice Conf (fwd)

Hi Ian,

>
> The use case is providing XML data to remote hosts on hosting systems
that
> provide no server-side control.

Here is a page on use cases: http://en.wikipedia.org/wiki/Use_case

I would like to see a sentence of two about the nature of the hosting
system(s) (i.e., open/public services such as Google Maps vs secure
services such as a bank transaction system), the kinds of requests that are
expected, whether there is a need to login to the server (or a key as in
the case of Google Maps), whether the server maintains session, whether the
server uses cookies, things like that. Not a treatise. Just a few
paragraphs each for a few use cases. Here is a skeleton for one possible
use case.

-- A web developer is creating a new application that combines his
company's data with data from two 3rd party web services hosted on other
domains, one which responds to search queries and another that provides a
mapping widget. (Google and Yahoo are examples of companies that provide
these sorts of web services.) His server environment supports LAMP (Linux,
Apache, MySQL, PHP) and his application retrieves data out of a MySQL data
using PHP, which generates the HTML content for his web page. His web
application uses Ajax techniques to communicate with his server in the
background without causing screen refreshes. Both the web application and
the Ajax-based web services that support his web application are written in
PHP. To access the 3rd party services, he must first receive a data acccess
key from the service provider. (One time action accomplished by filling out
a simple web form.) His own application maintains a session, but the 3rd
party services do not.
In today's world, without Access Control, because of the browser
same-domain policy, the web developer has to use the dynamic SCRIPT tag to
retrieve JSON content, but this approach has shortcomings because
...(???)...
With the Access Control standard, once the vast majority of users have
upgraded to browsers such that support Access Control, then the web
developer can use Access Control techniques instead of the dynamic SCRIPT
tag. This is better for the web developer and the end user because
...(???)...
(Variations: Instead of LAMP, the web developer could use other server
technologies such as Java, Perl, Microsoft server technologies, ColdFusionm
and other database technologies than MySQL.) --

Incidentally, I don't understand "no server-side control". Certainly
someone has to write some logic (PHP, Java, Perl, whatever) that examines
the request and serves data back in the response. There has to be come
control on the server.

>
> The requirement is that it must be possible to grant cross-domain read
> access to resources of at least one data format on presently deployed
> server software without changing configuration, without requiring any
> additional server-side scripting, and without requiring any retooling on
> the author's side.
>
>
> On a broader note, it is unclear to me why we are still discussing
> requirements. We have a perfectly fine specification, we should go ahead
> and publish it and move on. We already have two specifications that are
> dependent on the current design (XBL2 and XMLHttpRequest2).

I have been saying that I am having a hard time understanding what
workflows Access Control is attempting to address, and therefore have
requested that at least a few paragraphs appear somewhere that lists the
primary target use cases. I realize this is a tough pill to swallow within
a WG that feels that they have already finished the spec.

Regarding requirements, I have stated that they would help also, but I
recognize that that's yet another tough pill to swallow. I consider use
cases more important because that will help me and others provide better
feedback on the specification because we will have a better understanding
of what workflows are being addressed. Without such information, I can only
guess what scenarios are the most important, and given current information,
I am hazarding guesses, and based on those guesses, I have tentatively
concluded that JSONRequest is a better approach.

Jon


>
> I don't even understand the problems that have been raised. As far as I
> can tell nobody has raised any real problems with the current design; the

> OPTIONS suggestion seems to be based purely on theoretical concerns of
> spec purity, and the concerns of the client having the last say appear to

> miss the point of the technology (which is entirely about preventing
> information leakage and protecting against new attack vectors on the
> client while enabling features that clients have previously blocked).
>
> Why have we not gone to LC and CR already? Can we please stop running
> around in circles and move forwards?
>
> I suggest that those who wish a radically different model to the one in
> the current proposal instead write an alternative specification and move
> that specification forwards through the REC track, and let the market
> decide which technology is better.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>