Re: ZIP-based packages and URI references within them, [widgets, uriBasedPackageAccess-61]

Hi Dan/TAG members,

On Tue, Nov 25, 2008 at 8:01 PM, Dan Connolly <connolly@w3.org> wrote:
> On Sat, 2008-11-22 at 20:54 -0800, Larry Masinter wrote:
>> Resolving the general topic of ZIP-based packages and URI references within them
>>  on the webapp mailing  list doesn't seem practical, because those
>>  who need to review the package/URI issue are likely not interested
>>  in wading through the mass of other email
>>  on other unrelated topics within WebAPP WG.
>
> In the recent join TAG/WebApps ftf session, I learned that
> a lot of that other stuff is not so unrelated.
>
> http://www.w3.org/2008/10/20-wam-minutes.html#item12
> (Marcos's slides are attached to those minutes thru
> a rather indirect route, so here's a more direct link:
> http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/att-0299/TPAC_URISchemes.pdf )
>
> Software installation security policy requirements seem to dominate,
> for the purpose of WebApp widgets. I was surprised to learn that
> URIs using the scheme they have in mind aren't actually written down in
> absolute form; they're sort of conjured up at run-time, and it
> can lead to security/privacy problems if anybody else learns
> about them. Are those requirements relevant to ebook scenarios?
>

This is not exactly true (but not exactly false, either:)). The
security/privacy problem you describe is a side effect of _one_ of the
potential URI schemes we discussed (the one where the scheme is
conjured up at runtime). But that is just one proposed scheme, and Web
Apps has not decided they want to go in any one direction! I'm still
hopeful we don't need a new URI scheme, but so far it seems we do.
Effectively, we have a clean slate and lots of good ideas. What I
showed in my TPAC presentation was that file:// had several security
and privacy concerns and those are the ones we want to avoid with the
new URI scheme. Also, file:// is not fully standardized nor is any
other package based URI scheme.

> Oh... perhaps they are... I see earlier in this thread:
> "I seem to recall that we used some sort of scheme during the processing
> of a Mars document but didn't persist it in the file."
>
> The scope of these names wasn't entirely clear to me in the
> ftf session; I heard some conflicting information.
> I gather the WebAPP WG continues to discuss their requirements.
>  http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0197.html
>

The Widgets Requirements [1] are now in Second Last Call (once we
resolve this URI issue, the requirements gathering phase will
effectively finish). I again ask the TAG for direct feedback on the
following URI-related requirements, which I have modified post the F2F
meeting.

To be clear, for Web Apps, there are 2 parts with regards to
formulating a new URI scheme:  1) an addressing scheme (essentially
paths as defined in the URI Generic Syntax spec, which allow authors
to address the resources they want to use within a package). And 2) a
URI scheme to which the addressing scheme resolves to at runtime for
the purposes of DOM normalization.

We make the distinction between 1) and 2) because we want authors to
only use 1) when authoring widgets... but I guess they could use 2) if
they really wanted to.

Here is the requirement for 1):

R6. Addressing Scheme
A conforming specification MUST recommend a hierarchical addressing
scheme that can be used to address the individual resources within a
widget resource from within a configuration document. The hierarchical
addressing scheme MUST be capable of expressing both absolute and
relative relationships between a resource and the containing widget
resource. In addition, the hierarchical addressing scheme MUST be
interoperable with resources that might also need to address other
resources within the widget resource (e.g., HTML documents, CSS
documents, JavaScript documents, etc.). The hierarchichal addressing
scheme SHOULD be one that Web authors would feel comfortable using or
to which they are already accustomed.

Motivation:
Ease of use, compatibility with other standards, current development
practice or industry best-practice, and security.

Rationale:
To make it easy for authors to address resources from the
configuration document or other relevant resources within the widget
package. For example, addressing a custom icon within a widget package
from the configuration document (e.g. <icon src="icons/cat.ico'/>).
Or, for example, addressing an image within a widget package from
within a HTML start file (e.g. <img src="/backgrounds/sky.png'>).

Here is the requirement for 2):

R36. Resolve Addressing Scheme to URI Scheme
A conforming specification MUST recommend that, at runtime, the
addressing scheme used by a resource that addresses another resource
within a widget package be resolved to some hierarchical URI scheme
for the purpose of DOM normalization. A conforming specification
SHOULD recommend or specify an appropriate URI scheme: That is, a URI
scheme that does not expose the underlying file system (if any) to the
instantiated widget. In addition, an instantiated widget MUST NOT be
able to address resources outside the widget resource via the URI
scheme (even if URI scheme allows it).The URI scheme MUST pertain to
individual widget instances, but it MAY potentially allow widgets to
address each other (for instance, when used in conjunction with
cross-widget communication).

Motivation:
Current development practice or industry best-practice,
interoperability, and security.

Rationale:
To allow resources to be resolved and normalized within DOM nodes. For
example, addressing a resource via an IRI reference (e.g. <img
src="images/bg.png'/> where the src attribute resolves to something
similar to "widget://engine/myWidget.wgt/images/bg.png" or
"http://localhost/myWidget.wgt/images/bg.png").

>> I don't understand why setting up a separate mail list/archive/issue
>> list on the
>> specific topic is a lengthy process, it mainly requires the will to
>> take the
>> need for coherence seriously.
>
> Setting up an archived mailing list isn't a lengthy process. Any W3C
> staff contact can fill in the relevant form and the systems guys
> usually turn them around within the day, if not within the week.
> The tricky bit is setting and managing expectations,
> figuring out the requirements, that sort of thing.
>

I've listed what our requirements are above. If they are unclear or
ambiguous in any way, please let us know. If other groups have
different requirements, then we sure would like to hear them. Web Apps
needs/is working on a solution to this URI problem and we are willing
to work with others towards a general solution. Seems to me that we
have all the right people here to make that happen.

> So I could set up a mailing list around the uriBasedPackageAccess-61
> TAG issue
>  http://www.w3.org/2001/tag/group/track/issues/61
>
> But I don't know that I could justify the time to drive the discussion,
> and last time I set up a mailing list for the community to talk about
> packaging, it didn't amount to much.
>  http://lists.w3.org/Archives/Public/www-xml-packaging/
>

This is because you were like 10 years ahead of your time! ;-) Dan, I
don't think it's necessary for you to drive the discussion (though
your input and experience is of great value). However, I would
appreciate if you (or some W3C staff member) would set up the list so
we can make an attempt to move forward. There are at least two serious
applications that need this URI scheme (widgets and possibly ODF), so
that gives us incentive and motivation to get the work done in a
timely manner.

Kind regards,
Marcos

[1] http://dev.w3.org/2006/waf/widgets-reqs/

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

Received on Wednesday, 26 November 2008 14:58:48 UTC