WIDEX V. Stirbu
Internet-Draft Nokia
Expires: April 20, 2006 D. Raggett
W3C/Canon
October 17, 2005
Widget Description Exchange Service (WIDEX) Requirements
draft-stirbu-widex-requirements-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 20, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document defines functional requirements for a framework and a
protocol used to support XML-based user interfaces, where the user
interface and application logic may be on different machines, and
coupled via an exchange of XML DOM events and update/mutation
operations.
Requirements Language
Stirbu & Raggett Expires April 20, 2006 [Page 1]
Internet-Draft WIDEX Requirements October 2005
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Widex Entities . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Widex Terminology . . . . . . . . . . . . . . . . . . . . . . 3
3.1. User Interface . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Remote User Interface . . . . . . . . . . . . . . . . . . 4
3.3. Remote User Interface Objects . . . . . . . . . . . . . . 4
3.4. Transport Protocol . . . . . . . . . . . . . . . . . . . . 5
3.5. Simple vs. Complex User Interfaces . . . . . . . . . . . . 5
4. Scenarios and Explanatory Discussion . . . . . . . . . . . . . 5
4.1. Scenario 1: Widex Server and Renderer Located in
Internet . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Scenario 2: Widex Server Located in Internet . . . . . . . 5
4.3. Scenario 3: Widex Renderer and Server in the Same
Network . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Architecture Requirements . . . . . . . . . . . . . . . . 6
5.2. Discovery and Session Setup Requirements . . . . . . . . . 7
5.3. Remote UI Objects Requirements . . . . . . . . . . . . . . 7
5.4. Transport Requirements . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11
Stirbu & Raggett Expires April 20, 2006 [Page 2]
Internet-Draft WIDEX Requirements October 2005
1. Introduction
With the Internet reaching out to more and more devices, people are
increasingly expecting to have access to services at anytime, from
anywhere and using any device. Such services are being developed
using Web technologies such as XML and distributed across the network
rather than resident on any one device.
2. Widex Entities
The following picture shows the primary Widex entities in a simple
and basic architecture.
+--------+ +--------+
| | update interface | |
| Widex |----------------->| Widex |
| Server |<-----------------|Renderer|
| | event interface | |
+--------+ +--------+
The two primary Entities are described as follows:
Widex Server (WS):
The entity that holds the application logic.
Widex Renderer (WR):
The entity that renders the user interface.
There might be several Widex Servers in the same device, one for each
application that can export the user interface and for each Widex
server there might be several Widex Renderers which are rendering the
user interface.
3. Widex Terminology
The terminology and definitions detailed below include both terms
that, besides the Widex entities are used in the requirements section
of this document.
3.1. User Interface
In the context of Widex working group, the user interface is
understood as XML [XML1.0] data describing the user interface.
Typically, the XML data is manipulated as levels 2 and 3 in the W3C
Document Object Model (DOM), see [DOM2.Core], [DOM3.Core], and
[DOM2.Events] (W3C has yet to complete work on DOM3 events). Style
Stirbu & Raggett Expires April 20, 2006 [Page 3]
Internet-Draft WIDEX Requirements October 2005
information associated with the user interface can be manipulated via
the DOM, see [DOM2.Style].
3.2. Remote User Interface
The Remote User Interface (RUI) is a technique in which a user
interface is rendered on another device than the one that runs the
application logic while keeping the user interface synchronised with
the application logic.
3.3. Remote User Interface Objects
One of the goals of the Widex working group is to define Remote User
Interface Objects (RUIO), to be used to convey information about
interface updates and events. RUIOs are used to keep the rendered
user inteface synchronised with the application logic.
There are three types of RUIOs:
RUIO Update (RUI.Update):
RUI.Update messages are sent by the Widex Server in order to
update XML DOM nodes and associated style properties.
RUIO Mutation (RUI.Mutation):
RUI.Mutation messages are sent by the Widex Server in order to
modify the structure of the XML DOM on the Widex Renderer side,
e.g. add/remove XML DOM nodes.
RUIO Event (RUI.Event):
RUI.Event messages are used to carry events triggered on the Widex
Renderer side so that they can be caught by the application logic
event handles on the Widex Server side. Not all events needs to
be forwarded to the application logic. Some events may be
intended for default event handlers or for local scripted event
handlers. The application logic in the RUI server may only be
interested in specific events.
RUI.Event messages may carry data according to the type of the
event, e.g. application defined events with structured payloads as
per [EMMA], which uses XML for annotated interpretations of user
input.
It might be possible for the application logic to raise events
itself which can then be caught by event handlers associated with
the remote user interface (RUI), see e.g. [WhatWG.WebApps1.0].
Stirbu & Raggett Expires April 20, 2006 [Page 4]
Internet-Draft WIDEX Requirements October 2005
3.4. Transport Protocol
The Transport Protocol is a protocol that just transports the RUIOs
as a string of bits, without looking at them.
3.5. Simple vs. Complex User Interfaces
Simple User Interface:
A simple user interface allows the user interface to be
represented with only one XML DOM object.
Complex User Interface:
A complex user interface may include scripted client-side event
handlers or there can be more than one XML DOM in the user
interface, e.g. different DOMs for different modalities, but see
also [sXBL] for the role of shadow DOMs.
4. Scenarios and Explanatory Discussion
In this section we introduce short scenarios to illustrate how Widex
services can be deployed in some environments.
4.1. Scenario 1: Widex Server and Renderer Located in Internet
In this scenario both the Server and Rendere are located somewhere in
the Internet and are globally accessible via public IP addresses
(and/or FQDN).
+--------+ _____
| Widex | _,-'' `--. +--------+
| Server |---/ ` | Widex |
+--------+ \ Internet ,'---|Renderer|
`._ _,' +--------+
``-----'
4.2. Scenario 2: Widex Server Located in Internet
In this scenario the Server is located somewhere in the Internet, has
a globally routable, public IP address (and/or FQDN), and the client
is behind a NAT device. The access network is a network where
private IP addresses are used and NAT is required in order to access
the public network, e.g. a home network, a hotspot.
Stirbu & Raggett Expires April 20, 2006 [Page 5]
Internet-Draft WIDEX Requirements October 2005
+--------+ _____
| Widex | _,-'' `--.
| Server |---/ `
+--------+ \ Internet ,'
`._ _,'
``-----'
/
+--------+
| NAT |
+--------+
____/
_,-'' `--.
/ Access ` +--------+
\ Network ,'--| Widex |
`._ _,' |Renderer|
``-----' +--------+
4.3. Scenario 3: Widex Renderer and Server in the Same Network
In this scenario the Server is located behind the same NAT device as
the Renderer.
+--------+
| NAT |
+--------+
____/
_,-'' `--.
+--------+ / Home ` +--------+
| Widex |----\ Network ,'--| Widex |
| Server | `._ _,' |Renderer|
+--------+ ``-----' +--------+
The network might be managed in which case a centralised service
discovery and session setup mechanism should be used, or unmanged and
a peer-to-peer service discovery and session setup mechanism should
be used.
5. Requirements
5.1. Architecture Requirements
o The framework MUST be modular, e.g. multiple session setup
mechanisms may be used.
o The synchronisation MUST occur at a fairly loose level that allows
for a simple approach to propagating changes.
o The framework and the synchronisation protocol SHOULD be
stateless.
Stirbu & Raggett Expires April 20, 2006 [Page 6]
Internet-Draft WIDEX Requirements October 2005
o The framework SHOULD be consistent with the W3C Multimodal
Architecture, see [MMI.Arch].
5.2. Discovery and Session Setup Requirements
o The service discovery mechanism MUST be able to discover both
Widex Renderers and Widex Servers.
o The service discovery mechanism MUST be able to negotiate the
capabilities of both Widex Renderers and Widex Servers, e.g.
supported devices physical characteristics, supported markup
languages, etc.
o The session setup mechanism MUST be able to establish sessions
from both Widex Renderers and Widex Servers, e.g. remote user
interface pull and push.
5.3. Remote UI Objects Requirements
o The RUIOs MUST NOT be aware of the semantics of the markup that is
synchronized.
o The RUIOs MUST support client initiated updates.
o The RUIOs MUST support server initiated updates.
5.4. Transport Requirements
o The protocol MUST deliver RUIOs regardless of the undelying
network topology.
o The protocol MUST be reliable.
o The protocol MUST tolerate limitations in available bandwidth.
o The protocol MUST tolerate delays caused by network induced
latency.
o The protocol MUST have support for authentication and secure
sessions.
6. IANA Considerations
This document makes no request of IANA.
7. Security Considerations
As a means to support remote user interfaces, a number of security
considerations need to be addressed, including the potential for
unauthorized access to application services, monitoring of
interactions by unauthorized third parties, spoofing of application
services as a means to support phishing attacks, and denial of
service attacks.
Stirbu & Raggett Expires April 20, 2006 [Page 7]
Internet-Draft WIDEX Requirements October 2005
8. Acknowledgements
T.B.D.
9. References
9.1. Normative References
[DOM2.Core]
Le Hors, A., Le Hegaret, P., Wood, L., Nicol, G., Robie,
J., Champion, M., and S. Byrne, "Document Object Model
(DOM) Level 2 Core Specification", W3C Recommendation,
November 2000.
[DOM2.Events]
Pixley, T., "Document Object Model (DOM) Level 2 Events
Specification", W3C Recommendation, November 2000.
[DOM2.Style]
Wilson, C., Le Hegaret, P., and V. Apparao, "Document
Object Model (DOM) Level 2 Style Specification",
W3C Recommendation, November 2000.
[DOM3.Core]
Le Hors, A., Le Hegaret, P., Wood, L., Nicol, G., Robie,
J., and S. Byrne, "Document Object Model (DOM) Level 3
Core Specification", W3C Recommendation, April 2004.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[XML1.0] Yergeau, F., Bray, T., Paoli, J., Sperberg-McQueen, C.,
and E. Maler, "Extensible Markup Language (XML) 1.0 (Third
Edition)", W3C Recommendation, February 2004.
9.2. Informative References
[EMMA] Johnston, M., Chou, W., Dahl, D., McCobb, G., and D.
Raggett, "Extensible Multi-Modal Annotations (EMMA)",
W3C Last Call Working Draft, September 2005.
[MMI.Arch]
Barnett, J., "Multimodal Architecture and Interfaces",
W3C Working Draft, April 2005.
[WhatWG.WebApps1.0]
Hickson, I., "Web Applications 1.0", October 2005.
Stirbu & Raggett Expires April 20, 2006 [Page 8]
Internet-Draft WIDEX Requirements October 2005
[sXBL] Ferraiolo, J., Hickson, I., and D. Hyatt, "SVG's XML
Binding Language (sXBL)", W3C Working Draft, August 2005.
Stirbu & Raggett Expires April 20, 2006 [Page 9]
Internet-Draft WIDEX Requirements October 2005
Authors' Addresses
Vlad Stirbu
Nokia
Visiokatu 3
Tampere 33720
Finland
Phone: +358 7180 60572
Email: vlad.stibu@nokia.com
Dave Raggett
W3C/Canon
35 Frome Road
Bradford on Avon, Wiltshire BA15 2EA
United Kingdom
Phone: +44 1225 866240
Email: dsr@w3.org
Stirbu & Raggett Expires April 20, 2006 [Page 10]
Internet-Draft WIDEX Requirements October 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Stirbu & Raggett Expires April 20, 2006 [Page 11]