W3C home > Mailing lists > Public > www-tag@w3.org > July 2007

Re: Aligning grouping of resources in POWDER and WAF Access Control.

From: Arthur Barstow <art.barstow@nokia.com>
Date: Fri, 6 Jul 2007 10:52:00 -0400
Message-Id: <4143E46F-A739-412B-8A0E-D3AC968EA7A8@nokia.com>
Cc: Phil Archer <parcher@icra.org>, www-tag@w3.org
To: "ext Williams, Stuart (HP Labs, Bristol)" <skw@hp.com>, public-appformats@w3.org

[[ ++ public-appformats - the mail list the WAF WG uses for its  
technical discussions ]]

Stuart - thanks for raising this issue. I have not discussed this  
issue with the WAF WG nor the WAF Public Community but here is *my*  
take on the syntax issue.

We discussed using regular expression syntax instead of just star. I  
recognize there would be some advantages to using the richer syntax  
but we decided to follow the KISS principle here, particularly given  
the negative side effects of incorrect syntax (e.g. accidentally  
giving access to a domain that should not have access). [I assume  
here the probability of incorrect syntax is higher with regular  
expressions than just star but I have no real data to back my  
assumption.]

It also appears our decision is consistent with the decision made in  
the P3P spec [1].

WAF WG & Community - please see the issue the TAG raises below.

Regards,

Art Barstow
---

[1] <http://www.w3.org/TR/P3P/#ref_file_wildcards>


On Jul 6, 2007, at 10:16 AM, ext Williams, Stuart (HP Labs, Bristol)  
wrote:

> Art, Phil,
>
> In response to a request from the WAF-WG [1] to review "Enabling Read
> Access to Web Resources" [2] the TAG is concerned to ensure that there
> is good alignment between your WGs wrt the specification of resource
> sets.
>
> We observe that [2] involves the specification of 'allow' and 'deny'
> sets of resources (which in this case happen to be the origins of
> scripted behaviours executed by user agents). There is some resonance
> between [2] and POWDER work on grouping resource sets by address. We
> believe that there is or should be some common interest in the
> specification of such resource sets between your WGs.
>
> Given that web masters are the likely authors of configuration
> information for both script access controls (as in [2]) and for
> content-labeling (a POWDER application) and that both involve making
> assertions about sets of resources (allow/deny assertions v assertions
> about the nature of web content) we believe that there should be at
> least some conceptual coherence and ideally some syntactic  
> coherence in
> the way that both POWDER and WAF-WG approach the description of  
> sets of
> resource that are the subject of such assertions.
>
> For example, consider the scenario in which the author of a resource
> identified by http://www.sales.example.com/strategy.html wishes to  
> allow
> cross-domain access from any resource identified by an example.com  
> URI.
>
> Per [2], this set is specified with a pair of 'access items' as:
>
> 	http://*.example.com
> 	https://*.example.com
>
> Whereas using the 'PERL regexp' based approach being considered by
> POWDER (option 5 at [3]), the same set is specified as:
>
>    ^https?://[^:/?#]+\.)*example\.com/
>
> We think having two similar-but-different mechanisms to achieve the  
> same
> goal should be avoided if at all possible.
>
> We would be interested to hear from you whether you think there is any
> possibility of seeking considerably more alignment between the work of
> your two groups, so that where their requirements overlap there is at
> least cross-reference, and at best sharing of terminology, operational
> semantics and perhaps even syntax.
>
> Best regards
>
> Stuart Williams
> for W3C TAG
> --
> [1] http://lists.w3.org/Archives/Public/www-tag/2007Jun/0114.html
> [2] http://www.w3.org/TR/2007/WD-access-control-20070618/
> [3]
> http://www.w3.org/blog/powder/2007/04/27/ 
> meeting_summary_26_27_april_200
> 7
> --
> Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks
> RG12 1HN
> Registered No: 690597 England
Received on Friday, 6 July 2007 14:52:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:46 GMT