Re: Simple approach for <access>

On Thu, Mar 26, 2009 at 6:04 PM, Robin Berjon <robin@berjon.com> wrote:
> Hi,
>
> in the same spirit of the resolution that we made with L10N based on the
> principle that we define something simple now and add more complex stuff
> once developers have described real-world issues that we don't address, I
> would like to propose a similarly simple approach for <access>.
>
> I think there are three primary use cases which we genuinely need to
> address:
>
>  - a widget that access a single source, or a small set of sources (e.g.
> three servers for a mashup, or http and https on the same);
>  - a widget like the above, but the service uses multiple subdomains to
> distribute its load (e.g. web42.example.org, web2017.images.example.org...);
>  - a widget that has to access pretty much any HTTP resource (e.g. an RSS
> reader).
>
> There are possibly cases in which we might want to allow a widget to access
> ports 8042 through to 8077, and 99, 1010, 2017, on some combinations of
> gopher and sftp for all of dahut.fr, dahut.org, and dahut.com but I don't
> think that those fall in the 80%.
>
> So here goes (not in spec-ese):
>
> """
> The <access> element is used to restrict a widget's access to a limited set
> of network resources. In the absence of an <access> element, all access to
> network resources is forbidden.
>
> The <access> element has a single @href attribute the content of which is an
> IRI-like string. The access opening that is specified by that string is
> defined as follows:
>
>  - the scheme component MUST be present, and access is granted only for that
> scheme; and
>  - the host component MUST be present. If it begins with "*." then the host
> that follows the "*." is granted access to, as well as all of its
> lower-level domains; otherwise access is only granted for that domain; and
>  - if the port component is absent, it is considered to be specified to be
> the default for the provided scheme. Access is granted only to that port;
> and
>  - if the path and query string component is present, then access is granted
> for any path and query string that starts with the specified string. It is
> treated as an opaque string, no attempt must be made to map to potential
> directories on the remote server; and
>  - if a fragment component is specified, it must be ignored.
> """
>
> I think that the above, once tightened up for proper spec wording, gives us
> our basic three use cases (given that one can easily specify a handful of
> <access> elements) at a minimal cost. Derived on the above, once we see
> which paths are trodden and what people complain about (and we can rely on
> complaints to reach us) we can extend the element to provide it with much
> more granular matching (simply by giving it children or other attributes
> that override href). The point here is not to make it perfect, but to make
> it good enough to ship.
>
> Comments?
>

This seems to be inline with where we were heading. Please go forth
and spec it and re-post the the text here.

Kind regards,
Marcos


-- 
Marcos Caceres
http://datadriven.com.au

Received on Tuesday, 14 April 2009 10:21:39 UTC