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 one scenario as an example.

-- A web developer is developing a application which combines data from two
web services, such as a data feed from the US Census and a mapping widget
(e.g., Google or Yahoo). Without Access Control, because of the browser
same-domain policy, the web developer has to use the dynamic SCRIPT tag
with JSON content, but this approach has shortcomings because .... But once
the vast majority of users have upgraded their browsers such that they have
a browser with Access Control inside, then the web developer can use Access
Control techniques instead of the dynamic SCRIPT tag. --

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.   `._.-(,_..'--(,_..'`-.;.'
>