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
