Subject: RE: [REMOTEUI] Widex charter proposal draft

From: [email-masked]
Date: Fri, 2 Sep 2005 15:01:30 +0300

LRDP, which is the input document for the RUI BoF, describes the ui remoting protocol in terms of a transport protocol (e.g. BEEP) having uni-directional channels for exchanging ui synchronisation information formatted as XML messages. The document described that you can use the ui remoting protocol with several UI representations of user interfaces and several discovery and session setup mechanisms, but there were no several ui remoting protocols.

If the goal of this working group is to define a single mandatory to implement mechanism for synchronizing distributed XML DOM objects, then there should be a single transport protocol also.

Vlad

> -----Original Message-----
> From: ext Dave Raggett [mailto:[email-masked]]
> Sent: 02 September, 2005 11:57
> To: Stirbu Vlad (Nokia-TP-MSW/Tampere)
> Cc: [email-masked]; [email-masked]
> Subject: RE: [REMOTEUI] Widex charter proposal draft
> 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Fri, 2 Sep 2005 [email-masked] wrote:
> 
> > Well, I think that we agreed to have the protocol UI semantic 
> > independent and discovery and session setup mechanism independent. 
> > We haven't mentioned that the protocol should be transport 
> > protocol independent.
> >
> > In fact, the whole purpose of the working group is to define a 
> > single mandatory to implement protocol for synchronising XML DOM 
> > events.
> 
> So what's wrong with my suggestion that the charter covers defining 
> XML message formats and normative bindings to at least SIP, and 
> perhaps other protocols?
> 
> 
> - -- 
>   Dave Raggett <[email-masked]>  W3C lead for multimodal interaction
>   http://www.w3.org/People/Raggett +44 1225 866240 (or 867351)
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
> 
> iD8DBQFDGBPTb3AdEmxAsUsRAmmdAJ4kjgk8q9wfpCupNJl/YCuURXzktQCgziQt
> p9KnCBR4KNhvKPlF8TcPGkQ=
> =kMQ6
> -----END PGP SIGNATURE-----
> 

_______________________________________________
REMOTEUI mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/remoteui

---

From: Aki Niemi <[email-masked]>
Date: Fri, 02 Sep 2005 15:49:13 +0300

I think there is a terminology confusion here. I count UDP, TCP and a 
couple of others in the transport protocol category. Anyway, LRDP 
suggests a BEEP profile for transporting the remote UI data, but you 
could as well use SIP events (that itself runs over UDP or TCP).

In fact, defining the event package is really a trivial thing to do; 
SUBSCRIBE is used to initiate a RUI session, NOTIFYs carry the UI markup 
and PUBLISH is used to send in client stimulus.

The used widget markup language (i.e., MIME type) can be negotiated 
using the Accept header field in SIP. Then you can use any service 
discovery to find the SIP resource; an OPTIONS method will tell you 
using the Accept-Events field whether or not the node offers the UI events.

There can certainly be other such protocol bindings, but I agree that 
the SIP event package is a fine one to start with.

Cheers,
Aki

ext [email-masked] wrote:
> LRDP, which is the input document for the RUI BoF, describes the ui
> remoting protocol in terms of a transport protocol (e.g. BEEP) having
> uni-directional channels for exchanging ui synchronisation
> information formatted as XML messages. The document described that
> you can use the ui remoting protocol with several UI representations
> of user interfaces and several discovery and session setup
> mechanisms, but there were no several ui remoting protocols.
> 
> If the goal of this working group is to define a single mandatory to
> implement mechanism for synchronizing distributed XML DOM objects,
> then there should be a single transport protocol also.
> 
> Vlad
> 
> 
>> -----Original Message----- From: ext Dave Raggett
>> [mailto:[email-masked]] Sent: 02 September, 2005 11:57 To: Stirbu Vlad
>> (Nokia-TP-MSW/Tampere) Cc: [email-masked];
>> [email-masked] Subject: RE: [REMOTEUI] Widex charter proposal
>> draft
>> 
>> 
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>>> independent and discovery and session setup mechanism
>>> independent. We haven't mentioned that the protocol should be
>>> transport protocol independent.
>>> 
>> - -- Dave Raggett <[email-masked]>  W3C lead for multimodal interaction
>> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux)
>> 
>> p9KnCBR4KNhvKPlF8TcPGkQ= =kMQ6 -----END PGP SIGNATURE-----
>> 
> 
> 
> _______________________________________________ REMOTEUI mailing list
>  [email-masked]

---

From: Dave Raggett <[email-masked]>
Date: Fri, 2 Sep 2005 14:38:19 +0100 (BST)

I think we are in rough agreement, but this needs to be checked, and 
the charter needs to be elaborated to make explicit the assumptions 
we are working from. Right now, the draft charter while a good 
start, it is lacking in details.

The value in standards is when they are widely implemented, so it is 
important to align with market trends. Furthermore, for mobile and 
embedded devices where the resources are tightly constrained, it 
makes sense to build on top on a protocol that the device already 
needs for other purposes as it is hard to justify a new protocol 
stack. This currently makes BEEP less attractive than SIP and HTTP,
since unlike SIP and HTTP, BEEP is still fairly rare.

Another factor is the prevalance of NAT and firewalls. Consumers 
find it very difficult to configure their gateways to allow incoming 
requests. That makes it desirable to use approaches where the 
initial request is initiated by the client, and once the connection 
is established, messages can move through the gateway in both 
directions. SIP provides a good match to these needs, and that is
why I believe that we should provide bindings to SIP and to account
for how SIP can be used to establish the session via SDP. This is
not to preclude other approaches and I am very interested in you
can provide us with a case for these.

Many devices such as printers now support simple HTTP servers and
this is being taken advantage of when it comes to Web Services.
This allows devices to receive asynchronous messages, but doesn't
work well through consumer gateways. UPnP seems to be more about
identifying the services a device provides than a general means
for supporting remote user interfaces.

In the absence of a stronger candidate, SIP looks like a good
choice for us to adopt.

BTW I am on vacation this coming week and will be back on email
on Monday September 12th.

On Fri, 2 Sep 2005 [email-masked] wrote:

> LRDP, which is the input document for the RUI BoF, describes the 
> ui remoting protocol in terms of a transport protocol (e.g. BEEP) 
> having uni-directional channels for exchanging ui synchronisation 
> you can use the ui remoting protocol with several UI 
> representations of user interfaces and several discovery and 
> session setup mechanisms, but there were no several ui remoting 
> protocols.
>
> If the goal of this working group is to define a single mandatory 
> to implement mechanism for synchronizing distributed XML DOM 
> objects, then there should be a single transport protocol also.
>
> Vlad
>

- --

---

From: Aki Niemi <[email-masked]>
Date: Tue, 06 Sep 2005 20:20:13 +0300

ext Dave Raggett wrote:
> I think we are in rough agreement, but this needs to be checked, and the 
> charter needs to be elaborated to make explicit the assumptions we are 
> working from. Right now, the draft charter while a good start, it is 
> lacking in details.

I agree, or at least the details need a bit of refinement.

> embedded devices where the resources are tightly constrained, it makes 
> sense to build on top on a protocol that the device already needs for 
> other purposes as it is hard to justify a new protocol stack. This 
> currently makes BEEP less attractive than SIP and HTTP,

Thinking about this a little more, implementing the actual UI remoting 
using SIP events, while possible, might truly be overkill in what I 
think Vlad's main use case at home is all about. For example, SIP 
mandates support for both UDP and TCP. That seems one too many for a 
light-weight Widex implementation.

> Another factor is the prevalance of NAT and firewalls. Consumers find it 
> very difficult to configure their gateways to allow incoming requests. 
> That makes it desirable to use approaches where the initial request is 
> initiated by the client, and once the connection is established, 
> messages can move through the gateway in both directions. SIP provides a 
> good match to these needs

Needless to say, NAT/FW in SIP does have its share of problems, so this 
isn't probably the strongest argument in favor of SIP.

It seems there are three scenarios that fall into the scope of Widex 
that have something to do with NAT traversal:

1) Server is behind the same NAT/FW device as the client, e.g., at home

2) Server has a globally routable, public IP address (and/or FQDN), and 
the client is behind a NAT device

3) Server is behind a NAT device, and the client is accessing from the 
"outside"

Out of these, I think if the charter addressed 1 and 2, but left 3 for 
further study would mean the working group would address the majority of 
use cases for this work plus guarantee that the WG might actually finish 
one day. ;)

> , and that is

Hmm... As the charter says, I think session establishment is not only 
firmly out of scope but also unnecessary, if the remoting protocol is 
sufficiently complete. For example, if the client only needs to know the 
server's address, it could simply connect to that address directly after 
receiving it via some service discovery mechanism.

> for supporting remote user interfaces.

To reiterate, I think the charter should state that the WG works on a 
framework and at least a single remoting protocol that implements the 
framework. There could be others, but LRDP (the BEEP profile based one) 
is the only concrete proposal on the table, and while it probably needs 
some more work, seems like a good starting point.

I think the protocol should be complete in itself so that the only 
"parameter" needed to set up the UI remoting session is the address 
(URI, FQDN, IP address) of the server.

Cheers,
Aki