W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

ACTION-337: Review of access element

From: Thomas Roessler <tlr@w3.org>
Date: Sat, 2 May 2009 13:31:12 +0200
Message-Id: <AB6842B8-8508-4995-B4AE-629867ABB3A4@w3.org>
To: public-webapps WG <public-webapps@w3.org>
I'm looking at:
   dated 29 April 2009

1. What does "access to network resources" mean?  Does this refer to  
the use of inline resources, stylesheets, images, XMLHttpRequest, form  
submissions, some of these, all of these?  More precisely, does this  
apply to (a) causing GET requests (inline resources,  
stylesheets, ...), (b) reading the results of GET requests (XHR), (c)  
causing POST requests (forms, XHR)?

2. The use of "URI" as an attribute name is misleading, since the  
value of that attribute is actually a pattern.

3. The formal description of the attribute's value space is defined by  
reference to the valid URI token (or IRI token) productions in RFCs  
3986 and 3987.  Works for me (TM).

Unfortunately, some additional considerations apply for IRI  
references:  The mapping between arbitrary Unicode character sequences  
and A-labels ("xn--...") turns out to be sufficiently brittle that the  
only host name sequences you want to use are U-labels (the subset of  
non-ASCII labels for which ToUnicode and ToASCII round-trip).   
Comparison of IDNs is defined on the level of the A-label ("xn--"),  
and shouldn't occur on the Unicode level. Take a look at the latest  
POWDER drafts for another WG that recent grappled with the problem.   
Also, be clear what kinds of normalization is applied to the path and  
query string components before comparison.  How do you deal with %  
encoding?  (Again, see POWDER -- they're doing the right thing in  
their latest iteration.)

4. How do you deal with trailing slashes?

5. What is the use case for the wildcard mechanism?  As I noted before  
[*], the wildcard mechanism makes it fairly easy to scan large network  
segments by inventing host names on the fly.  I'd prefer to simply  
drop that mechanism for the moment and keep things really simple for  
v1.  If that's not an option, can we please define separate attribute  
names for patterns that imply access to the entire network and  
patterns that imply access to resources at a single host name only?

*) http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0204.html

Happy to talk more about this on next Thursday's call; I believe that  
this discharges ACTION-337.

Thomas Roessler, W3C  <tlr@w3.org>

Received on Saturday, 2 May 2009 11:40:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:53 UTC