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

Oops, didn't realise I was replying to the private list. Why do we have a 
private list again? Anyway, here's the comments I sent to the private list 
earlier this week.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

---------- Forwarded message ----------
Subject: Re: [waf] minutes from 9 January 2008 Voice Conf
From: Ian Hickson <>
To: Arthur Barstow <>
Cc: member-appformats WG <>
Date: Thu, 10 Jan 2008 09:06:16 +0000 (UTC)

On Wed, 9 Jan 2008, Arthur Barstow wrote:
>    <tlr>
>    [9]
>    AccessControl-Requirements-20070108.html
>       [9]
> att-0010/AccessControl-Requirements-20070108.html
>    JS: req 3.2 is vague to me too
>    <tlr> +1
>    JS: perhaps it should be removed
>    <scribe> ACTION: Hickson elaborate on requirement 3.2 [recorded in
>    [10]]
>    <trackbot-ng> Created ACTION-149 - Elaborate on requirement 3.2 [on
>    Ian Hickson - due 2008-01-16].

First, let me note that I do not accept this action item, or the other 
one, which were assigned to me without my being present. Please don't 
commit me for things without asking me first.

Having said that, I've no idea what I meant by 3.2. I recommend we remove 
it, as JS suggested.

>    ... req 3.4 - I agree with the Ed Note; not clear what this is and
>    we need clarification
>    JS: perhaps 3.4 is better described as a UC rather than a
>    requirement
>    TLR: I tend to agree
>    ... as currently written its too fuzzy
>    JS: regarding 3.4, we need to formulate the goal somehow
>    <scribe> ACTION: Hickson submit a clarification and elaboration of
>    req 3.4 to the mail list [recorded in
>    [14]]
>    <trackbot-ng> Created ACTION-153 - Submit a clarification and
>    elaboration of req 3.4 to the mail list [on Ian Hickson - due
>    2008-01-16].

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

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 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       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Friday, 11 January 2008 11:30:42 UTC