Re: [Powerbox] A RESTful proposal for Web enabling devices

On Fri, Feb 19, 2010 at 10:48 AM, Tyler Close <tyler.close@gmail.com> wrote:

> Mark Miller, Marc Seaborn and myself have created a draft proposal for
> a RESTful approach to addressing the design challenges this WG is
> working one.


Re-post of comments sent privately before this draft was publicized:

Overall I like this design a lot.  It is very similar to something that had
been brewing in my head for awhile.  I think you did a good job of limiting
the scope of the document to avoid defining protocol details that do not
need to be specified, thus giving implementations freedom to make their own
technical choices.

I have a number of comments on specific issues:

*Interactive Providers*

Your spec allows for "interactive providers" which can interact with the
user at the time the grant is made.  To accomplish this, the provider
provides an entity body in its reply to the requisition request, in addition
to the Location header, and the user agent must present this entity to the
user.  I guess the idea is that the user then interacts with this page, and
the interactions modify the resource at the already-provided URL.

This seems a little awkward, since it means that the provider must know the
resource URL before any interaction has occurred.  What if the provider is
some sort of search engine over resources which themselves may be hosted by
different domains?  The provider would then have to proxy requests to those
other domains.  Also, there's a possibility of race conditions if the
customer page obtains the resource URL before it is ready to be used.

Is there some way we can allow the URL of the provided resource to be filled
in *after* the provider has had a chance to interact with the user?

How about this:  If the response to a provision request does not contain a
Location header, then the response body is presented to the user.  The body
should be some sort of dynamic page.  The powerbox will use postMessage() to
send a message to this page requesting the resource URL -- the purpose of
this message is simply to give the page a reference to the powerbox window,
so that it can reply later.  Once the page has determined the URL via
interaction with the user, it replies with a postMesage() back to the
powerbox window containing the URL.

*Type of provided resource*

How does the provider say what kinds of resources it provides?  You mention
that the requisition may have an "accept" attribute, but I don't see any way
for the powerbox to determine what kind of resources a provider provides
until after the resource has been provided.  Did I miss something?

This seems important in order to allow the powerbox to present a list of
relevant providers for a given request, so that the user is not presented
with choices that won't actually work.

*"Overloading" class*

I don't think we should use "class" to indicate the type of resource
requested.  I understand that the "class" attribute is not owned by CSS and
in fact many systems use it for different things.  However, what happens if
someone needs to apply a CSS class to their <input> element?  How do they
make sure their CSS class is not mistaken for an interface type?  Why is the
"accept" attribute not good enough?

I think if we're going to use "class" here, we must treat it similarly to
the way CSS treats it: a single element can have any number of classes
(delimited by spaces), and these end up acting like tags/labels (in the Web
2.0 sense) -- essentially a sparsely-populated infinite set of boolean
values.  Given that this is a global namespace used for many different
things, we would need to add some standard prefix to classes that are type
names in order to avoid conflicts.  For example, "accepts-".  So you'd have:

  <input type="file" accept="video/*"

 class="some-style accepts-com.example.BetterBroadcast
accepts-org.w3c.Broadcast"
    alt="Video for your profile page">

Here, you accept two different kinds of broadcast interface (maybe
BetterBroadcast is a subclass of Broadcast, even), and "some-style" is
unrelated to accept types (probably a CSS class).

But again, it seems to me that this is what the accept attribute is supposed
to do.

  <input type="file" accept="protocol/broadcast+json,video/*"
    class="some-style" alt="Video for your profile page">

Here I'm imagining that we create a new MIME group for two-way protocols, as
opposed to existing MIME types which describe static files.  So our <input>
here accepts a live video feed implementing protocol/broadcast+json and also
accepts static (pre-recorded) video file uploads.

I don't think it makes sense to describe a two-way protocol using any
existing MIME type, so your examples which use "video/*" as the MIME type
for such a resource don't make sense to me.

*Metadata*

I assume that if a GET request is issued to an installed provider URL, it
will send back a human-usable page describing the resource.  Should we make
that explicit, so that the powerbox can offer these URLs as links if the
user wants more info?

*Membranes*

In section 6 you say:  "The user-agent MUST assign this URL to the
corresponding requisition control's value attribute."

I am worried that this wording prohibits the UA from setting up any sort of
revocable forwarder[1].  Can we change the wording to allow this?  I'm not
sure exactly what to say -- the UA must provide a URL which is "functionally
equivalent" to the original, for some definition of "functionally
equivalent" (e.g. the URL may be a proxy to the real URL).  A key point is
that web apps MUST NOT try to identify the provider based on the URL -- if
they must know the provider's identity, they will need to actually send a
UMP request to ask.

This would allow the powerbox to set up a revocable forwarder around every
resource, and to log activity occurring on that resource, which would allow
it to implement the resource management UI I was hoping to provide.

I recognize that it would be impossible to create a perfect membrane[2] --
the customer and provider will always be able to conspire to form a direct
link.  However, I'd argue that in almost all cases, at least one of the two
will be "on the user's side" and thus will not engage in such conspiracy.
 (Of course, setting up a membrane at all (as opposed to just a forwarder)
would require the powerbox to understand the protocol being used, but that's
implementation details.)

[1]
http://wiki.erights.org/wiki/Walnut/Secure_Distributed_Computing/Capability_Patterns#Revocable_Capabilities
[2]
http://wiki.erights.org/wiki/Walnut/Secure_Distributed_Computing/Capability_Patterns#Membranes

*Prototyping*

I think your spec (including my above changes) can be implemented entirely
with a local web server, HTML5-era standards, Javascript, and greasemonkey
(to inject the Javascript).  Do you agree?  If so, that's great, as it will
make it much easier to prototype.