Re: [WARP] "uri" attribute is confusing

I agree that "pattern" implies that you could use regular expressions  
(or similar) - this would be a much more flexible way to handle  
access, but does have implications (e.g. no need for a 'subdomains'  
attribute).

In our system we will be using the access element to prompt the server  
admin to add entries to a whitelist for a proxy server - in this case  
a person is in the loop, and so its unlikely that anything nasty would  
be accepted. However in more automated cases I agree with  Marcin  
there would be complex security issues to address.

RE does however have the benefit of being very well known, with plenty  
of good implementations, and understood by developers (including those  
handling security issues).

S

On 1 Oct 2009, at 22:13, Marcin Hanclik wrote:

> Hi Dom, All,
>
> I am not convinced by the need to include the word "pattern" in the  
> name of the attribute taken the current WARP text.
> Specifically because the semantics of the value of the attribute is  
> more like namespace or just the leading part of the URI.
> Pattern would be ok, if e.g. we would use regular expression or  
> similar construct in the value of the attribute.
>
> On the other hand, I think that having some pattern mechanism (like  
> e.g. regular expression) would help in having better semantics of  
> the functionality currently proposed behind <access> element.
> The recent need to handle local network [1] could be probably  
> satisfied based on regular expression / pattern for IP address in  
> HTTP URI (related to the issue with subdomains as in [2]).
> The private IP address ranges [3] could be then possibly fine-tuned  
> if required by the application.
> Pattern mechanism could nicely complement (or maybe replace to some  
> extent?) my proposal from [2], however, we would risk it being too  
> complex (maybe very good for Perl people, but could blur the actual  
> value for an average RE reader; so we may discard this RE idea,  
> specifically because the security model should not be too complex  
> IMHO in order to be widely and successfully deployed).
> I assume that some pattern mechanism could be discussed in the light  
> of the recent comments on WARP and proposal to use POWDER (a bit too  
> rich also IMHO, but maybe some subset could be adopted).
>
> Thanks,
> Marcin
>
> [1] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0011.html
> [2] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0844.html
> [3] http://tools.ietf.org/html/rfc1918
>
> ________________________________________
> From: public-webapps-request@w3.org [public-webapps-request@w3.org]  
> On Behalf Of Dominique Hazael-Massieux [dom@w3.org]
> Sent: Wednesday, September 23, 2009 3:19 PM
> To: public-webapps@w3.org
> Cc: phila@w3.org
> Subject: [WARP] "uri" attribute is confusing
>
> Hi,
>
> The attribute "uri" on the <access> element in WARP is somewhat
> misleading - what it takes is more a URL pattern than a URI. I would
> suggest renaming it in "urlpattern" or just "pattern" (unless there  
> are
> already many implementations that rely on that attribute name).
>
> There may be lessons to be taken in designing these patterns from  
> POWDER
> http://www.w3.org/TR/2009/REC-powder-dr-20090901/ - although I suspect
> the POWDER expressivity needs are much greater than what is needed  
> here.
>
> Dom
>
>
>
>
> ________________________________________
>
> Access Systems Germany GmbH
> Essener Strasse 5  |  D-46047 Oberhausen
> HRB 13548 Amtsgericht Duisburg
> Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda
>
> www.access-company.com
>
> CONFIDENTIALITY NOTICE
> This e-mail and any attachments hereto may contain information that  
> is privileged or confidential, and is intended for use only by the
> individual or entity to which it is addressed. Any disclosure,  
> copying or distribution of the information by anyone else is  
> strictly prohibited.
> If you have received this document in error, please notify us  
> promptly by responding to this e-mail. Thank you.
>