RE: [WARP] Last Call comments (1)

Hi Robin,

I am further trying to align the syntax and semantics of WARP.

>>The design was based on:
>>...
>>  - enabling boolean access to URIs
>>...
As in the previous emails, I assume that WARP should more underline the "retrievable" character of the network RESOURCE.
Then mailto: should not be mentioned at all (or mentioned as not in scope for WARP, bad example due to non-retrievability etc). Then the following sentence:

"However, a user agent may grant access to certain URI schemes (e.g., mailto:) without the need of an access request if its security policy considers those schemes benign."

could be rephrased e.g. to:

"It is out of the scope of this specification how schemes other than http, https and interfaces other than XmlHttpRequest access the network".

Similarly I assume that e.g. <a> element is out of the scope, this could entail that openURL from widget interface would be excluded as well (aka my previous email).

Thanks,
Marcin

Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanclik@access-company.com

-----Original Message-----
From: Robin Berjon [mailto:robin@berjon.com]
Sent: Thursday, September 17, 2009 4:41 PM
To: Marcin Hanclik
Cc: Marcos Caceres; public-webapps@w3.org
Subject: Re: [WARP] Last Call comments (1)

On Sep 8, 2009, at 11:00 , Marcin Hanclik wrote:
> As stated in my original email, one of the targets is that <access>
> is not an obstacle for DAP.

The design was based on:

  - not restricting DAP's ability to define a security policy
  - enabling boolean access to URIs
  - having pattern matching that covers most cases
  - making sure that web content that works outside of a widget can
work inside a widget

> It is currently undefined how the related access control will be
> done and we would probably want to avoid the situation that <access>
> is deprecated once DAP is ready with their model.

Quite the contrary. If all goes well DAP's security policy will be
available within a couple years, and after that we'll need another
year before it ships as presumably it'll have some degree of
complexity. That's all fine but the problem that we have today is that
people are shipping implementations with support for something a lot
like <access> but that are not compatible. Just off the top of my head
I know that Opera has their own stuff (which was the original
proposal), BONDI has <network-access> which is different, JIL has
something of their own with different default rules, and Microsoft has
a widget engine using <access> from the December 2008 PC draft.

What WARP does is that it provides the strictly minimal solution that
will make interoperability possible before DAP finishes its work,
while adhering to its fundamental design principles. If it gets
obsoleted, superseded, set on fire in public displays of wrath, or
trampled by a horde of arctic hippopotami on MDMA then great. The
primary goal is to gain 3 years of interoperability which we need to
have. A complementary goal is that since we want content created
conforming to WARP today to be valid forever is that the policies that
WARP enables should be expressible using whatever DAP comes up with,
so that <access> can be defined as simply a syntactical shortcut to DAP.

In other words it is future-proof *because* it is simple. It's
extensible (if we need to, which I don't think we should) because it's
XML (and because its processing model is intended for that).

--
Robin Berjon - http://berjon.com/




________________________________________

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.

Received on Thursday, 17 September 2009 16:05:19 UTC