exploration of non-web intent providers

As a member of the now closed Home Network Task Force, I am as
interested in non-web intent providers as web intent providers.
This is a scenario for a non-web intent provider, complete with
discovery of devices.

----------------

Device1 is a PC with a browser running on it.
The browser on Device1 is the Intents Registry and Dispatch entity.
Device1 is UPnP capable.

Device2 is a UPnP-enabled device providing a service, e.g. a DLNA
AVTransport service.

The task is to register an intent allowing Device2 to provide the
Media AVTransport service, then to invoke the intent.

----OPTION 1: Device2 is the leader.

Device2 comes up, discovers Device1 as Intents Registry and Dispatch

REQ1: Device1 MUST advertize itself as Intents Registry and
Dispatch in order to be discoverable by Device2.

REQ2: Device2 MUST have a way to request Device1 to register intents.

Device2 prepares one or a set of intent registrations and one or a set
of intent service pages.

Device2 publishes service pages on its own http server (part of the UPnP 
spec).

Device2 communicates to Device1 to register the intents.

Then appropriate intents have been registered, with implementations
provided by service pages sitting on Device2.

Device1 receives an intent invocation, selects the intent registered by
Device2, loads the corresponding service page, and the service page
deals with the UPnP communication with Device2, such as sending a
"setTransportURI" or "play" action.

----OPTION 2: Device1 is the leader.

Device1 comes up, launches the browser. Something on Device1 discovers
Device2 and recognizes it as an Intent Provider.

REQ3: Device2 MUST advertize itself as Intent Provider in order to
be discoverable by Device1.

Device1 gets the service description of the (e.g. AVTransport) service
running on Device2 as part of the discovery exchange.

Device1 processes the service description, creating one or a set of
intent registrations and one or a set of intent service pages.

REQ4: Device1 MUST have an http server to put the service pages.

Then appropriate intents have been registered, with implementations
provided by service pages sitting on the http server of Device1,
service pages which use UPnP service on Device2.

Device1 receives an intent invocation, matches it to one of the
intents registered by Device2, loads the corresponding service page,
and the service page  deals with the UPnP communication with Device2,
such as sending a "setTransportURI" or "play" action.

----------------

Please comment.

Assuming both options are relevant,  requirements are:

REQ1: Device1 MUST advertize itself as Intents Registry and
Dispatch in order to be discoverable by Device2.

REQ2: Device2 MUST have a way to request Device1 to register intents.

REQ3: Device2 MUST advertize itself as Intent Provider in order to
be discoverable by Device1.

REQ4: Device1 MUST have an http server running somewhere to put the
registration and service pages.


To satisfy these requirements, I wrote the following proposal.
Maybe the group will decide that this is out of scope for this TF, or
even out of scope of W3C, but if we want interoperability, some text
like this needs to be in a standard somewhere.

-----------------

Proposal: Addition of a section as follows.

Section. Use of Web Intents with UPnP

Subsection.1 Intent Registry and Dispatch

A User Agent implementing both Web Intents Registry and Dispatch and
UPnP MUST advertize itself as a UPnP service with a type
"urn:w3c:web-intents:registry-and-dispatch:1".

The SCPD of that service is:
<scpd xmlns="urn:schemas-upnp-org:service-1-0">
<specVersion>
<major>1</major>
<minor>0</minor>
</specVersion>
<actionList>
<action>
<name>registerIntent</name>
<argumentList>
<argument>
<name>*action*</name>
<direction>in</direction>
<relatedStateVariable>s1</relatedStateVariable>
</argument>
<argument>
<name>*type*</name>
<direction>in</direction>
<relatedStateVariable>s2</relatedStateVariable>
</argument>
<argument>
<name>*href*</name>
<direction>in</direction>
<relatedStateVariable>s3</relatedStateVariable>
</argument>
<argument>
<name>*title*</name>
<direction>in</direction>
<relatedStateVariable>s4</relatedStateVariable>
</argument>
<argument>
<name>*disposition*</name>
<direction>in</direction>
<relatedStateVariable>s5</relatedStateVariable>
</argument>
</argumentList>
</action>
</actionList>
<serviceStateTable>
<stateVariable><name>s1</name><dataType>string</dataType></stateVariable>
<stateVariable><name>s2</name><dataType>string</dataType></stateVariable>
<stateVariable><name>s3</name><dataType>string</dataType></stateVariable>
<stateVariable><name>s4</name><dataType>string</dataType></stateVariable>
<stateVariable><name>s5</name><dataType>string</dataType></stateVariable>
</serviceStateTable>
</scpd>

Upon reception of the action "registerIntent", the User Agent SHALL do the
same processing as if it had loaded an intent tag with attributes according
to the action arguments.

Subsection.2 Intent Provider

A UPnP device that implements a UPnP Service which needs to be usable
through the Web Intents mechanism MUST advertize an additional UPnP
Service of type "urn:w3c:web-intents:provider:1".

The SCPD of that service is:
<scpd xmlns="urn:schemas-upnp-org:service-1-0">
<specVersion>
<major>1</major>
<minor>0</minor>
</specVersion>
<serviceStateTable>
<stateVariable><name>dummy</name><dataType>string</dataType></stateVariable>
</serviceStateTable>
</scpd>

Note: if the user agent advertizes itself as a UPnP service, it
implements UPnP, and thus has an HTTP server and REQ4 is satisfied.

Note: the SCPD requires a serviceStateTable, which cannot be empty,
hence the dummy state variable...

Best regards
JC

-- 
JC Dufourd
Directeur d'Etudes/Professor
Groupe Multimedia/Multimedia Group
Traitement du Signal et Images/Signal and Image Processing
Telecom ParisTech, 37-39 rue Dareau, 75014 Paris, France
Tel: +33145817733 - Mob: +33677843843 - Fax: +33145817144