All, Back in December I volunteered (http://www.w3.org/2009/12/10-wam-minutes.html) to propose an alteration / supplement to WARP to permit widget access to resources on local networks with no managed DNS system. Such resources do not fit into the current WARP model of listing origins in the widget's configuration document unless those resources have IP addresses known in advance to the developer.
There are a very large number of such networks in use worldwide: I believe that the vast majority of home networks and many wireless networks fall into this category. The BBC is specifically concerned that the lack of distinction between local network resources and Internet resources in the current WARP model could prevent widgets from being able to access network resources served from media devices on home networks. Anyway, the specific proposal I would like to make is for another special value of the "origin" attribute of the "access" element in the widget configuration document called "link-local" or similar, an associated special value in the access-request list and an associated processing rule that says that when the "link-local" value is specified, the user agent should grant access to network resources on the same subnet(s) as the user agent. I haven't gone into more technical detail in this email because I suspect that there will be sufficient disagreement with the general principles laid out above to generate a productive discussion. A few points, though: 1. I think that the definition of a subnet in IP versions 4 & 6 is sufficient to allow a meaningful definition of "link-local". 2. Users are likely to want control over which specific networks a widget is granted access to, rather than just a blanket "yes" or "no" permission to access whatever local network(s) to which the host may be connected when the widget is running. I don't think that this is something that can or should be dealt with in the configuration of widgets. I believe that good user experiences can be constructed to give the user that control, but I won't go into detail unless somebody asks me to. 3. I would expect most *useful* widgets that can access local network resources to need some kind of ability to browse the local link for resources to access. Again, I think that's out of scope for a WARP alteration/supplement; it's the sort of thing people use mDNS + DNS-SD or UPNP's SSDP for, but those aren't web protocols, and Robin's threatened to drag me into the DAP WG if I start talking about device APIs. 4. Clearly the "local network" and the "local link" are not necessarily the same thing. I'm proposing a solution targeting the latter because (a) it actually has a useful definition and (b) I believe it to be sufficient for the use cases I care about. I look forward to your comments and criticisms - in particular I would like to understand the holes that Arve says are opened by making a distinction between "local" and "remote" IP addresses. S
