2.1.8 Remote UI (rui)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.

Last Modified: 2005-07-02

Chair(s):

Vlad Stirbu <vlad.stibu@nokia.com>

Applications Area Director(s):

Ted Hardie <hardie@qualcomm.com>
Scott Hollenbeck <sah@428cobrajet.net>

Applications Area Advisor:

Ted Hardie <hardie@qualcomm.com>

Mailing Lists:

General Discussion:
To Subscribe:
Archive:

Description of Working Group:

No description available

Goals and Milestones:

No Current Internet-Drafts

No Request For Comments

Current Meeting Report

Remote UI BoF Minutes

Reported by Dean Willis and Vlad Stirbu from notes by Randall Gellens

Introduction and Status Update

The Remote UI BoF met Tuesday August 2nd at the 63rd IETF meeting in Paris (July 31 - August 5, 2005) and was chaired by Vlad Stirbu and Dean Willis. Agenda bashing was followed by a short introduction from the chairs. Dean Willis explained that the deliverable slide doesn't suggest that we already decided what to do but what we might do if we decide to do something. Vlad Stirbu explained that a lot of confusion was created around the topic by the Remote UI name and that the scope is much narrow and a new name like Widget Description Exchange Service (widex) is more appropriate. Discussion proceded with an overview of the W3C Multi-Modal Interaction work, followed by discussion about WiDeX problem statement, possible solutions, and deliverables.

W3C Work Relevant to Remote User Interfaces

Dave Raggett summarized that W3C should do markup languages and DOM work while IETF should do the remoting protocol.

Problem Statement

Pete Resnick raised the question what does "discovery and session setup indepenedent" mean? Vlad Stirbu mentioned that the remoting protocol should be able to use together with multiple mechanisms, e.g. SIP/SDP or zero-conf. Dean Willis gave the example of KPML, which is using SIP session setup for discovery that you need KPML, then SIP to transport digits back to the application, but it might be reasonable to use the SIP session setup mechanism and to use other protocols to convey the user interface state changes back to the application, so the mechanisms by which the application discovers might be fundamanetaly different from the mechanism through which the application is synchronised.

Possible Solutions

draft-stirbu-lrdp-00.txt

James van Loo raised the issue that the proposed architecture is specifying UI behaviour, not over-the-wire protocol. Vlad Stirbu and Dean Willis commented that the focus of the work is on the remoting protocol (e.g. UI updates and UI events messages) while the exact UI element description and its behaviour are out-of-scope. There are some assumptions about the applications that are using this model: UI can be described semantically, application can be split into MVC model, and user is being able to interact with the UI which sends back events to the application.

Eric Burger mentioned that the terms "client" and "server" are confusing, do not look like x-windows terms. Vlad Stirbu and Dean Willis commented that the terms are consistent with the web terminology where the application is the web server and the browser is the client.

Aki Niemi raised the issue of session setup as out-of-scope; at least you need to negotiate the widgets. Vlad commented that session-setup is a precondition and we need to mention what needs to be negotiated, so that session setup mechanisms could incorporate that information. Aki said that there are many UI languages and you need a common one that is understood. Dave Raggett commented that W3C is developing a framework that enables negotiations of UI languages/properties to take place. Markus Isomaki commented that negotiation-then-transport is like RTP, which is independent of the session negotiation and is independent on the payload that is carring and the important point is that they must be defined somewhere, e.g. SDP; as a design principle it is ok to have one protocol that is doing the transport. Eric Burger wanted to see the group explaining how the protocol works, e.g. how to use this with mobile phones with SIP.

Eric Burger pointed out that this work looks more like keeping DOM in sync and proposed that the focus of the group should change to keeping generic DOMs in sync. Harald Alvestrand commented that a protocol needs to be good for at least one specific thing before being general purpose; otherwise it is likely good for nothing; wg should have specific goal to make DOM object synchronization work. Pete Resnick commented that the core of scope is clear now and we need to keep the focus otherwise scope gets out of hand. Dave Crocker recommends on not doing a general solution that has one specific applicability, instead do specific solution that can be used for other things.

Chris Newman commented that using XML and needing multiple channels, BEEP usage sounds like a slam-dunk. Pete Resnick mentioned that XMPP might be usefull although it doesn't have the advantages of BEEP, like multiple channels. Aki Niemi said that it could be implemented on top of SIP events. James van Loo mentioned that this could be done in a private protocol fashion on a case-by-case basis depending on the application. Dean Willis commented that the assumption is that the client is independent of the application so that you can render the UI of any application that is compatible with that client. No need to download any software that is specific to that particular application like with Jini where you have a full Java program, much worse security implications, larger size and needs a full JVM. What we need is semantic model, no arbitrary execution of code, no JVM, etc. Eric Burger mentioned that it would be helpful to have requirements from W3C; there are a lot of really cool and nifty things we could do that no one would care about.

Dean Willis asked the audience about the interest in this work: is there work here for IETF (a large number do) or is it out-of-scope for IETF (a few hands go up). Scott Hollenbeck mentioned that he is optimistic and there is a clear positive momentum behind this BoF; the group should work on the mailinglist (remoteui@ietf.org) to refine the scope and the boundaries and to put together a charter and define goals. Dean Willis concluded that the work should continue on the mailinglist on defining the charter and goals.

Slides

Remote User Interface Organizational BoF
W3C work relevant to remote user interfaces
WiDeX Problem Statement
LRDP: The Lightweight Remote Display Protocol