Re: [WARP] Last Call comments (1)

On Sep 15, 2009, at 21:12 , Marcin Hanclik wrote:
> I do not think they are so different.

Frederick is correct in his interpretation of the intent of the  
specification: they are meant to be different.

> <feature> points to anything, we can still build the interpretation.

But it is meant and intended for APIs. We could extend it for a  
zillion things, e.g.:

   <feature uri='http://example.com/widgets/icon'>
     <param name='src' value='/icons/myapp.svg/>
   </feature>

But I don't believe that that would be helpful.

> I think it can be disputable what <access> is for.
> WARP says:
> " A network resource is a retrievable resource of any type that is  
> identified by a URI that has a DNS or IP as its authority."
>
> Then, how to fit e.g. sms: or tel: schemes into this context?

This limitation is *exactly* what <access> was designed for. If you go  
back to the (long) discussions that the WG had before WARP was  
birthed, you'll see this. Basically, at this point in time there are  
two options: define a complete security policy model that would cover  
everything that can be done, or address a trivial 80/20.

There was clear agreement that the first option is DAP's  
responsibility. We thought about not doing anything at all, but that  
option was rejected because we're already seeing different approaches  
(Opera widgets, BONDI, JIL — they all have different things there).

So the resolution was to go with the simple 80/20 approach that  
handled the common "accessing a web resource or REST API" case in a  
boolean fashion, did describe what happened to content that is  
expected to behave in a Web fashion, but didn't go anywhere that would  
risk trampling on DAP's territory.

Schemes such as sms and tel are definitely out of scope for this  
simple approach. Even if they weren't they would *still* be out of  
scope for <access> because they aren't network resources. You can't  
make an XHR request to sms:, it is meaningless to have <img  
src='tel:...'/>. These are therefore rejected immediately — just  
because it has a scheme doesn't mean it's a network resource, those  
are two completely separate things.

Now there could be a policy for accessing SMS or phone from within an  
API, for instance one that would limit to only one phone number, or  
perhaps to a given price limit (per minute, per SMS), or a frequency,  
or a maximal total cost per month. But none of that is related to  
<access>.

> @subdomains makes also little sense for those schemes.

That's because those schemes make little sense for <access>. You're  
finding faults that are there because you're expecting it to address  
use cases that aren't there.

> Apart from DNS/IP issues, I assume that some Web "resources" are not  
> meant to be retrievable, e.g. POSTing a form uses URI to send  
> information to, and not to retrieve a resource.

Actually POST is perfectly allowed to retrieve an entity (and often  
does) so long as the response status isn't 204.

> If we would like the spec to be future-/scheme-proof, we could  
> prepare the model based on actual schemes, as e.g. suggested in my  
> below email.

I don't think that that is a good idea. This specification addresses  
the requirements of today. When and if we need to add new schemes, we  
can do so. The intent is that WARP is a simply, stop-gap solution to  
address today's interoperability issues at the level of requirement  
which they have. When we need more power, the expectation is that DAP  
will have provided it, that we'll be able to express <access> in DAP  
terms, and that DAP will provide the extensibility mechanism.

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

Received on Thursday, 17 September 2009 14:12:21 UTC