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

I think an even more urgent question is, how much of the design is 
POWDER and AC going to share. I see very little value in sharing just 
the URI-matching syntax, so we need to figure out if there are more 
things that can be shared to know if we should bother with it at all.

/ Jonas

Arthur Barstow wrote:
> 
> Thanks for the update Phil.
> 
> Regarding the value of the {include,exclude}UriPatter properties, one of 
> the open questions for the Read Access spec [1] is essentially "should 
> *.foo.com match foo.com?". The lastest draft says "no" thus must use one 
> rule for *.foo.com and another rule for foo.com.
> 
> Mozilla's Jonas Sicking summarized the issue, providing a list of both 
> the Pros and Cons [2].
> 
> We are particularly interested in your feedback on this question (e.g. 
> use cases, evidence of past precedence, etc.).
> 
> Art
> ---
> 
> [1] <http://www.w3.org/TR/2007/WD-access-control-20070618/>
> [2] 
> <http://lists.w3.org/Archives/Public/public-appformats/2007Jul/0002.html>
> 
> 
> On Jul 13, 2007, at 9:47 AM, ext Phil Archer wrote:
> 
>> Just a quick further response to this.
>>
>> The POWDER face to face meeting discussed the issue at our face to 
>> face meeting this week (member-only minutes at [1]) and resolved* 
>> "That we create a new RDF predicate that will support the kind of 
>> wildcard-based URI pattern matching used by the WAF Group in their 
>> Enabling Read Access document."
>>
>> The plan is to:
>>
>> 1. Rename the existing URI Pattern predicates to include/exclude UriRegEx
>>
>> 2. Create a new RDF predicate of include/exclude UriPattern and use 
>> the WAF wild-card syntax. We'll extend it a little to enable control 
>> over paths as well, so that *example.com/foo* means that the path must 
>> begin with /foo on any subdomain of example.com if it's to be in the set.
>>
>> 3. We'll add this to the XSD document we're working on. This will soon 
>> be converted into a working draft but for now can be seen, very 
>> unofficially, at [2].
>>
>> Does this sound right to you? By all means ping me directly rather 
>> then continue on the public lists if you prefer.
>>
>> Phil.
>>
>> [1] http://www.w3.org/2007/07/09-powder-minutes.html (member only)
>> [2] http://www.dicom.uninsubria.it/~andrea.perego/powder/?doc=xsd
>>
>> * As most group members are European and the meeting was in 
>> Washington, the number of people present wasn't high. Therefore, all 
>> resolutions were taken at the f2f are subject to giving the remainder 
>> of the group time to review the resolutions.
>>
>> Phil Archer wrote:
>>> cc. POWDER public list.
>>> Hi all,
>>> I'm glad Art responded to this so quickly as the original mail was 
>>> caught in my spam filter from which I've just retrieved it.
>>> Mea culpa - I was unaware of the Enabling Read Access work. I will 
>>> make sure that the POWDER WG considers it fully and that we report 
>>> back (we have a face to face meeting on Monday so we can do this 
>>> quickly).
>>> Meanwhile, we have moved on significantly since the April blog entry 
>>> referred to. Yes, we do support Perl regular expressions but we don't 
>>> rely on them. Actually, we warn against their use for most scenarios, 
>>> precisely because of the same reasons Art cites, preferring instead 
>>> to use simple string matches against URI components. Unless something 
>>> goes horribly wrong, the member only document at [1] will be a first 
>>> public working draft on Monday and this is all set out there.
>>> It would be easy to include a wild card pattern - indeed, there's an 
>>> example of exactly that in the extension mechanism section (which 
>>> refers to Google's URL pattern format which also looks similar to the 
>>> one in the WAF document).
>>> Clearly, there should be a common approach, or at least a fully 
>>> compatible one. I notice that Opera is in both groups. Chaals, Anne - 
>>> I hereby nominate you as coordinators!
>>> Phil.
>>> [1] http://www.w3.org/2007/powder/Group/powder-grouping/20070709.html
>>> Arthur Barstow wrote:
>>>> [[ ++ 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 Tuesday, 17 July 2007 20:42:04 UTC