Notes -- RemoteUI BoF at IETF 63
Reported by Randall Gellens
Dean: use ID-nits for nits
Agenda Bashing
proposed deliverables slide
q: does deliverable slide suggest we've already decided what to do?
Dean: no, it suggests what we might do if we decide to do something
Vlad: "remote user interface" may no longer we appropriate name; we
have narrowed our scope
Dave (W3C) presentation
- web limitations (visual, mouse, limited devices, etc.)
- overview of web (resources, languages/formats, protocols, etc.)
- separation of presentation from views, data model from ???, etc.
- the DOM: platform and language neutral APIs for manipulating XML
documents with a rich model of events
- DOM enhancements (user prefs, device capabilities, configuration,
environmental conditions, access to remote services)
- layering APIs on protocols (DOM property w/ GET/SET methods)
- propagation of local events (e.g., device out of paper)
- speech, keypad, or pen for user input (cars)
- variety of output options
- dialog between user and application (expressed via markup,
client/server scripts)
- who is in control (user, wizards)
- xml data exchange between input processors and interaction mgmt systems
- processors annotate application specific data with confidence
scores, timestamps, input/output modes, partial results, etc.
- no standards-based solutions yet; contributions on SALT and X+V
- W3C MMI WG developing architecture
- other protocols possible
- modality components communicate via asynch msgs (DOM may hide protocol)
- distributed DOM events (events signaling changes to user prefs,
device config/capabilities, environmental conditions, shared data
model)
- propagate changes to shared data model
- synchronize local copies of remote properties (ink levels in
network printer, geo loc of device)
- W3C should do markup, DOM, IETF do remote protocol
Vlad presentation
- what is Remote UI (mechanism to allow user interface to be rendered
on separate device from application logic)
- compare to alternatives (framebuffer [VNC, RDP, Hot Desk],
graphics-level [x-windows])
- problem with these: UI is slave to logic; can't adapt to device or
user or environment
- widely diverse device characteristics
UI descriptions (W3C markup languages; discovery session setup [mmusic])
- WiDeX Goal & Scope (specify an open platform-independent method for
use in an IP network for user-visible objects)
- WiDeX requirements and assumptions
q: what does "discovery and session setup independent" mean?
Vlad: need to be able to use multiple mechanisms, e.g., SDP, zero-conf
Dean: KPML uses SIP-session setup for discovery, then SIp to carry
events, but may want to use other protocols; see draft-stirbu-ordp-00
- MVC* Architecture overview
- MVC elements (model, view, controller)
- Remoting UI Concept
- MVC Architecture Over the Network
- WiDeX Framework Overview
q: this looks like specifying ui behavior, not over-the-wire protocol
Vlad: no, scope is limited to protocol; UI elements and behavior out of scope
c: this gives context to protocol since IETF normally doesn't do UI
Dean: need UI that can be described semantically; need to be able to
split into model/view/controller; need to be able to synchronize
events
c: document looks like it focuses on UI; should rename document "how
to keep DOMs synchronized"
c: use of "client" and "server" is confusing, doesn't look like x-windows terms
Dean: no, this is web-server terms
c: saying session setup is out of scope is not right
Vlad: maybe so
c: scope is keeping state synchronized, after session has been setup
Vlad: you are doing synchronization, but you don't care how UI is represented
q: "keeping ui in sync" keeps being said; better to focus on keeping
DOM in sync
Dean: proposal to focus on keeping DOMs in sync
c: session setup happens before synchronization, may need protocol;
my web page says 'here is URL for my pvi; you can click but you don't
know what widgets will be sent
Dean: protocol may not care what widgets
c: W3C will provide framework for [missed]
c: Vlad was talking about need for protocol that can be used for
several things; W3C folks want to aim for DOM; to do something
general purpose you need at least one specific thing it is good for,
otherwise it is likely good for nothing; WG should have specific goal
to make DOM object synchronization work, but it should not make a
protocol that is limited to this
c: negotiation-then-transport is like RTP (SDP then payload formats);
important that this be specified someplace
c: session startup discussion is confusing; best guess is that
session initiation is a sequence that eventually sends payload; URI
reference is a way to start; at some point thing doing exchange and
update has to start by negotiating; that phase has to take place as
part of this protocol
c: device characteristics versus large database are PFM as far as
this group is concerned; can think of at least 5 mechanisms (SDP,
RTSP, etc.); we don't need yet another one
Dean: how does synchronizing two XML document differ from sipping or
presence distribution
q: unclear on intent
Vlad: you are synchronizing two DOM objects; don't need to have
stateful devices or applications; only application logic is
maintaining state of system; everything is related to application
logic; UI is representation of that
c: I'm jet lagged; please raise hand if you believe you understand
scope of work (a number of people raised hands)
c: I'm finishing my PhD in pretty much this, so yes; I'd suggest that
a document that described how to use this with mobile phones with SIP
would be needed; this does need to be used for something; this group
needs to explain how it works
Vlad: SIP in Minneapolis concluded that SIP/SDP needs protocol to
show what needs to be synchronized
c: I think I understand chewy center of scope; unclear where hard
candy boundary is (limits of scope, only core of scope is clear);
which parts of service discovery get included; what are other ends of
protocols; the more general this gets the harder it is to understand;
pick something specific (e.g., XML documents) and keep that in focus;
otherwise scope gets out of hand
c: client need not be stateful -- if true, example is video; don't
need to sync back to server that you rec'd video; may have to sync
when formats change so client and server are on same page; so client
needs to be stateful
Dean: video with streams is an important issue; because we are using
UI descriptions [missed]; could use embedded widgets to play video;
send events when video is completed
c: you just described a state machine
Dean: clients may have state
c: recommend not doing general solution that has one specific
solution; instead do specific solution that can be used for other
things
(back to slides)
- LRDP Protocol Components
- Conclusions
- Questions (MVC right for WiDeX? more fine-grained UI exhange msgs?
Beep right protocol?)
Dean: this is so lightweight there's not really any protocol there
CHris: like SASL
Dean: yes
c: synchronizing client state with server has been done before; IMAP
is one; ACAP is another that had a much simpler data model than XML;
caution since we've failed before. BEEP sounds like slam dunk since
you're using XML and need multiple channels
c: XMPP may be right; doesn't have multiple channels of BEEP
c: could use on top of SIP events
c: what is interoperation point? If it is network for lots of
configuration points, there are lots of network elements that talk to
each other; that's not what we're doing here; classic way to do this
is write application, split into two pieces (client and server); use
private protocol between them; why do you need to expose nature of
content?
Vlad: you don't expose nature of content
c: this problem is in application domain; don't need a network protocol
Dean: assumption that client is independent of application; protocol
definition between two elements to enable application without having
to download software to understand UI elements
Dean asks how many optimists in room? If there work here for IETF,
please raise hand (a large number do)
Dean asks to raise hand if you think this is out of scope of IETF (a
few hands go up)
Dean asks what we can do to better understand problem so all hands on
are same side; need architecture model and maybe requirements document
c: my hand was half-up; it isn't clear that we have bounds; we need
to charter-bash and see if we can get reasonable bounds
Scott: mailing list (remoteui@ietf.org) is available; we need to
refine scope and work on boundaries; we need to do this on the
mailing list; next step is to put together charter to define goals
Dean: we'll continue with charter discussion on mailing list
c: why would I use this instead of, e.g., Sun's GENIE?
Dean: I had same question; objection description in GENIE is a Java
program; much worse security implications, larger size, need full
JVM, etc. We need a semantic model, no arbitrary execution of code,
limited execution, no JVM, etc.
c: 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; a goals document would help