W3C home > Mailing lists > Public > public-appformats@w3.org > December 2007

RE: Comments on: Access Control for Cross-site Requests

From: Close, Tyler J. <tyler.close@hp.com>
Date: Mon, 31 Dec 2007 18:12:20 +0000
To: Ian Hickson <ian@hixie.ch>
CC: "public-appformats@w3.org" <public-appformats@w3.org>
Message-ID: <C7B67062D31B9E459128006BAAD0DC3D10C4E3A3@G6W0269.americas.hpqcorp.net>

Hi Ian,

I think the WG should spend some more time considering these statistics before making the core design decision for the recommendation.

The rest of my response is all the way at the bottom of this email, after your quoted email...

Ian Hickson wrote:
> On Fri, 21 Dec 2007, Close, Tyler J. wrote:
> >
> > It seems like we should have numbers about the upgrade cycle for the
> > dominant client, Internet Explorer, before it is reasonable
> to draw any
> > conclusions. The same reference you used for Firefox and
> Opera reports
> > the following for IE:
> >
> > IE6: 40.24%
> > IE7: 36.84%
> >
> > And that's for the *total browser market*, not of IE's share of the
> > market.
> I don't think it would be fair on Microsoft to use these numbers here;
> they have been having uptake problems in general with their software
> recently and so I wouldn't really consider this
> representative of client
> upgrade trends in general. I don't see any reason to believe
> that uptake
> of a new version of IIS would be faster than a new version of
> IE in the
> current climate -- in fact IIS is more tied to OS releases
> than IE, so by
> your own arguments that makes IE more likely to rev faster than IIS.
> Anyway, that's why I didn't look at the numbers for
> Microsoft's products
> released in the last couple of years. I should have mentioned
> that in my
> last e-mail.
> > The other issues you raise seem more like social ones. I
> think it makes
> > sense to reach out to the Apache developers to get their
> opinion on this
> > decision before going with the much more complicated design.
> I'll leave that decision up to the spec's editor; I just
> wanted to provide
> numbers to back up the earlier claim I made.
> > I think the WG must be absolutely certain that requiring a
> server change
> > will delay adoption of the feature for years, before accepting these
> > costs. I still suspect the server deployment time will be
> hidden by the
> > client deployment time.
> In my opinion the data says otherwise.

It's surely unsound to argue an opinion is rooted in the data after dismissing 77% of the data. In such a scenario there's a significant danger that one is simply choosing the data that fits the argument. For example, another plausible interpretation of this data is that Firefox and Opera have attracted a disproportionate number of early adopters compared to Internet Explorer. Consequently, what you're actually measuring is the adoption rate of early adopters compared to the mass market. Assuming this WG is creating a recommendation for the whole market, and not just the early adopters, the data for the whole market must be considered.

I think the above argument is also only tangential to the orginal argument I was making, that creation of a policy language to be enforced by clients is unnecessary complexity. If it is true that servers are unable to be configured to respond in a customized way to a request to "OPTIONS *", and upgrading them to do so will take too long, then a different syntax for making a request with these same semantics can be chosen. The important thing is to co-locate the policy enforcement with the policy creator. There is a simple design here, one that also enables early use by early adopters. There's no need for the complexity in the WG's first draft of the recommendations.

Received on Monday, 31 December 2007 18:14:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:50:08 UTC