- From: Arthur Barstow <art.barstow@nokia.com>
- Date: Tue, 17 Jul 2007 12:49:28 -0400
- To: ext Phil Archer <parcher@icra.org>
- Cc: public-appformats@w3.org, Public POWDER <public-powderwg@w3.org>
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 16:56:34 UTC