Subject: Remote UI BoF at IETF63

From: [email-masked]
Date: Thu, 30 Jun 2005 13:02:52 +0300

Hi,

The attached is the description and agenda of Remote UI BOF (rui) for IETF63. Those interested are encouraged to attend. Thanks!

Regards,
Vlad

Remote UI BoF (rui)
-------------------

CHAIRS

Vlad Stirbu <[email-masked]>
TBA

DESCRIPTION:

The Remote UI is a mechanism that enables user interfaces to be rendered on
other devices than those that run the application logic.

Manufacturers are creating devices that are highly optimised for certain 
environments. Because the devices are intended for a diverse range of purposes, 
their UI capabilities can vary considerably; screen size and ratio, color depth, 
windowing system with various widget sets, input methods are making the 
environment highly heterogeneous. At the same time, application developers and UI 
designers are trying to create user interfaces that are high optimised for the 
rendering platform, so that the user experience is improved by having the 
respective application easy to learn and use.

A user interface may be composed of several widgets, wherein a widget is 
understood as an element of a user interface that displays information or 
provides a specific way for a user to interact with an application. Widgets may 
for instance comprise icons, pull-down menus, buttons, selection buttons, 
progress indicators, on-off checkmarks, scrollbars, windows, window edges, toggle 
buttons, forms and any other elements for displaying information, inviting, 
accepting, and responding to user actions.

Therefore, when an UI is rendered on another device than the one that is running
the application logic, provisions need to be made, so that the user can perceive
the UI as a local application making it intuitively usable.

A widget-level Remote UI protocol provides the mechanism which enable a client 
device to generate a UI, received from a server device, using the client device's 
native UI capabilities, and keeping the UI synchronised with the application 
logic. Typically, a widget-level Remote UI mechanism has usually three components:

- UI description language: contains the descriptions of the widgets, their 
properties and relationships between the widgets. Typically the widget-level 
UI descriptions are augmented with stylesheets containing hints such as preferred 
colours to use, which layout to use, which background picture, etc.

- The UI remoting protocol: is the transport protocol that is responsible with 
communicating (partial) UI updates from the server to the client and UI events 
triggered through changes in widget states made by the user from the client to 
the server.

- Session setup: is responsible with identifying compatible servers and clients 
and initiating the UI remoting session between them. A client is compatible with 
a server when they support the same UI remoting protocol and the same UI 
description language.

GOALS:

The goal of the WG is to create a UI remoting protocol for applications that are 
using UI Description Languages.

AGENDA:

- Agenda Bashing (5 min)
- Introduction & Background information (10 min)
- Problem Statement (60 min)
- Possible Solutions (20 min)
- Next Steps/WG Charter (10 min)

LOGISTICS:

Mailing list: [email-masked]

Subscriptions: https://www1.ietf.org/mailman/listinfo/remoteui

Internet-Drafts:

http://www.ietf.org/internet-drafts/draft-stirbu-lrdp-00.txt

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

---

From: Dave Crocker <[email-masked]>
Date: Thu, 30 Jun 2005 09:41:21 -0700

Vlad,

Howdy.

[email-masked] wrote:
  > The attached is the description and agenda of Remote UI BOF (rui) for 
IETF63. Those interested are encouraged to attend. Thanks!

I would like to help with your effort.  My original professional focus was on 
human factors and cognitive psychology.  For that matter, the first protocol 
work I did was a telnet option to improve remote terminal interactions over 
poor links.  So the goal of your effort is rather exciting to me.

The charter you circulated describes some usage cases, but does not specify 
the exact scope of the work, nor does it provide any input materials.  The 
world of usability and human factors design is broad, and efforts to produce 
network-based standards are sufficiently thin. Success will require a 
"multi-cultural" collaboration between protocol designers and UI engineers.

This presents significant challenges, with the risk of a BOF -- and, by the 
way, working group -- experience that is unfocused and unproductive, with a 
tendency to discuss concepts rather than design a concrete protocol.

I'd like to attempt a revision to the charter that restricts scope and 
specifies the output more precisely.

Can you characterize the solution space in a more constrained fashion?  What 
types of interactions and what types of devices are within scope?  What is out 
of scope?

Are there any materials to use as input, either as exemplars or possibly even 
as a beginning specification?  This latter would be particularly helpful for 
the success of the effort?

d/

---

From: Pekka Savola <[email-masked]>
Date: Thu, 30 Jun 2005 20:42:22 +0300 (EEST)

On Thu, 30 Jun 2005, Dave Crocker wrote:
[...]
> the success of the effort?

FWIW, when I read the BoF description, I started wondering about the 
same things.  Specifically I started thinking about the half a dozen 
protocols that already exist in this space (vnc, rdp, ...).  It'd be 
very good to understand the scope of the work, and how the existing 
protocols fit (or don't fit) the bill.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings