draft-ietf-widex-requirements-03.txt   draft-ietf-widex-requirements-04.txt 
WIDEX V. Stirbu WIDEX V. Stirbu
Internet-Draft Nokia Internet-Draft Nokia
Intended status: Informational D. Raggett Intended status: Informational D. Raggett
Expires: April 1, 2007 W3C/Volantis Expires: July 12, 2007 W3C/Volantis
September 28, 2006 January 8, 2007
Widget Description Exchange Service (WIDEX) Requirements Widget Description Exchange Service (WIDEX) Requirements
draft-ietf-widex-requirements-03 draft-ietf-widex-requirements-04
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 1, 2007. This Internet-Draft will expire on July 12, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2007).
Abstract Abstract
This document defines functional requirements for a framework and a This document defines functional requirements for a framework and a
protocol used to support XML-based user interfaces, where the user protocol used to support XML-based user interfaces, where the user
interface and application logic may be on different machines, and interface and application logic may be on different machines, and
coupled via an exchange of XML DOM events and update/mutation coupled via an exchange of XML DOM events and update/mutation
operations. operations.
Requirements Language Requirements Language
skipping to change at page 2, line 25 skipping to change at page 2, line 25
2. Widex Entities . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Widex Entities . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Widex Terminology . . . . . . . . . . . . . . . . . . . . . . 3 3. Widex Terminology . . . . . . . . . . . . . . . . . . . . . . 3
3.1. User Interface . . . . . . . . . . . . . . . . . . . . . . 3 3.1. User Interface . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Remote User Interface . . . . . . . . . . . . . . . . . . 4 3.2. Remote User Interface . . . . . . . . . . . . . . . . . . 4
3.3. Multimodal Interaction . . . . . . . . . . . . . . . . . . 4 3.3. Multimodal Interaction . . . . . . . . . . . . . . . . . . 4
3.4. Widex Objects . . . . . . . . . . . . . . . . . . . . . . 4 3.4. Widex Objects . . . . . . . . . . . . . . . . . . . . . . 4
3.5. Transport Protocol . . . . . . . . . . . . . . . . . . . . 5 3.5. Transport Protocol . . . . . . . . . . . . . . . . . . . . 5
3.6. Simple vs. Complex User Interfaces . . . . . . . . . . . . 5 3.6. Simple vs. Complex User Interfaces . . . . . . . . . . . . 5
3.7. Session . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.7. Session . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.8. State . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Architecture Requirements . . . . . . . . . . . . . . . . 6 4.1. Architecture Requirements . . . . . . . . . . . . . . . . 6
4.2. Service Discovery and Session Setup Requirements . . . . . 6 4.2. Service Discovery and Session Setup Requirements . . . . . 6
4.3. Widex Objects Requirements . . . . . . . . . . . . . . . . 6 4.3. Widex Objects Requirements . . . . . . . . . . . . . . . . 6
4.4. Transport Requirements . . . . . . . . . . . . . . . . . . 6 4.4. Transport Requirements . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6.1. Privacy Considerations . . . . . . . . . . . . . . . . . . 7 6.1. Privacy Considerations . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
skipping to change at page 3, line 48 skipping to change at page 3, line 48
user interface. user interface.
3. Widex Terminology 3. Widex Terminology
The terminology and definitions detailed below include both terms The terminology and definitions detailed below include both terms
that, besides the Widex Entities are used in the requirements section that, besides the Widex Entities are used in the requirements section
of this document. of this document.
3.1. User Interface 3.1. User Interface
In the context of Widex working group, the user interface is In this context, the user interface is understood as XML [XML1.0]
understood as XML [XML1.0] data describing the user interface. data describing the user interface. Typically, the XML data is
Typically, the XML data is manipulated as levels 2 and 3 in the W3C manipulated as levels 2 and 3 in the W3C Document Object Model (DOM),
Document Object Model (DOM), see [DOM2.Core], [DOM3.Core], and see [DOM2.Core], [DOM3.Core], and [DOM2.Events] (W3C has yet to
[DOM2.Events] (W3C has yet to complete work on DOM3 events). Style complete work on DOM3 events). Style information associated with the
information associated with the user interface can be manipulated via user interface can be manipulated via the DOM, see [DOM2.Style].
the DOM, see [DOM2.Style].
3.2. Remote User Interface 3.2. Remote User Interface
The Remote User Interface (RUI) is a technique in which a user The Remote User Interface (RUI) is a technique in which a user
interface is rendered on another device than the one that runs the interface is rendered on another device than the one that runs the
application logic while keeping the user interface synchronised with application logic while keeping the user interface synchronised with
the application logic. the application logic.
3.3. Multimodal Interaction 3.3. Multimodal Interaction
skipping to change at page 4, line 33 skipping to change at page 4, line 32
for output). However other modalities, such as pen-based input or for output). However other modalities, such as pen-based input or
haptic input/output, may be used. haptic input/output, may be used.
For example, W3C has developed a Multimodal Interaction Framework For example, W3C has developed a Multimodal Interaction Framework
[W3C.NOTE-mmi-framework-20030506] that is intended as a basis for [W3C.NOTE-mmi-framework-20030506] that is intended as a basis for
developing multimodal applications in terms of markup, scripting, developing multimodal applications in terms of markup, scripting,
styling and other resources. styling and other resources.
3.4. Widex Objects 3.4. Widex Objects
One of the goals of the Widex working group is to define Widex One of the goals is to define Widex Objects (WO) that are used to
Objects (WO), to be used to convey information about interface convey information about interface updates and events. Widex Objects
updates and events. Widex Objects are used to keep the rendered user are used to keep the rendered user interface synchronised with the
interface synchronised with the application logic. application logic.
There are two types of Widex Objects: There are two types of Widex Objects:
WO Update (WO.Update): WO Update (WO.Update):
WO.Update messages contain description of changes to XML DOM WO.Update object contain description of changes to XML DOM trees.
trees. The updates can target individual nodes in order to update The updates can target individual nodes in order to update their
their properties and attributes, or can target parts of the DOM properties and attributes, or can target parts of the DOM tree in
tree in order change its structure, e.g. add/delete/replace nodes order change its structure, e.g. add/delete/replace nodes or
or branches. branches.
WO Event (WO.Event): WO Event (WO.Event):
WO.Event objects are primarily used to carry events triggered on
WO.Event messages are primarily used to carry events triggered on
the Widex Renderer side so that they can be caught by the the Widex Renderer side so that they can be caught by the
application logic event handlers on the Widex Server side. Not application logic event handlers on the Widex Server side. Not
all events need to be forwarded to the application logic, as some all events need to be forwarded to the application logic, as some
events have local scope and may be intended for default event events have local scope and may be intended for default event
handlers or for local scripted event handlers. The application handlers or for local scripted event handlers. The application
logic in the Widex Server may only be interested in specific logic in the Widex Server may only be interested in specific
events. events.
WO.Event messages may carry data according to the type of the WO.Event object may carry data according to the type of the event,
event, e.g. application defined events with structured payloads as e.g. application defined events with structured payloads as per
per Extensible Multi-Modal Annotations [W3C.WD-emma-20050916], Extensible Multi-Modal Annotations [W3C.WD-emma-20050916], which
which uses XML for annotated interpretations of user input. uses XML for annotated interpretations of user input.
A secondary use of WO.Event messages is where the application A secondary use of WO.Event objects is where the application logic
logic itself raises events that may be caught by event handlers itself raises events that may be caught by event handlers
associated with the remote user interface, see for example Web associated with the remote user interface, see for example Web
Applications 1.0 [WhatWG.WebApps1.0]. Applications 1.0 [WhatWG.WebApps1.0].
3.5. Transport Protocol 3.5. Transport Protocol
The Transport Protocol is a protocol that just transports the Widex The Transport Protocol is a protocol that just transports the Widex
Objects as a string of bits, without looking at them. Objects as a string of bits, without looking at them.
3.6. Simple vs. Complex User Interfaces 3.6. Simple vs. Complex User Interfaces
skipping to change at page 6, line 5 skipping to change at page 5, line 46
role of shadow DOMs. role of shadow DOMs.
3.7. Session 3.7. Session
The Widex Session is initiated between a Widex Server and a Widex The Widex Session is initiated between a Widex Server and a Widex
Renderer for exchanging information about user interface updates Renderer for exchanging information about user interface updates
(e.g. WO.Update) and events (e.g. WO.Event) in order to control (e.g. WO.Update) and events (e.g. WO.Event) in order to control
applications remotely. A Widex Session relate to a single User applications remotely. A Widex Session relate to a single User
Interface, which can be simple or complex. Interface, which can be simple or complex.
3.8. State
The Widex Server is maintaining the state of the user interface.
Upon ungraceful session break, the Widex Renderer retrieves the
current user interface state from the Widex Server when the session
is re-established.
Certain UI markup languages allow the remote renderers to operate in
disconnected mode. In such cases, the application is responsible for
keeping the state on the Widex Server consistent with the changes
occured in the Widex Renderer when it operated in disconnected mode.
4. Requirements 4. Requirements
4.1. Architecture Requirements 4.1. Architecture Requirements
o The framework MUST be modular, e.g. multiple service discovery and o The service discovery and session setup component MUST be
session setup mechanisms may be used. replaceable.
o The synchronisation MUST occur at a fairly loose level that allows o The transport component MUST be replaceable.
for a simple approach to propagating changes. o Keeping the user interface and the application logic synchronised
o The framework and the synchronisation protocol SHOULD be MUST occur at a fairly loose level that allows for a simple
stateless. approach to propagating changes.
o The framework SHOULD be stateless.
o The framework SHOULD be consistent with the W3C Multimodal o The framework SHOULD be consistent with the W3C Multimodal
Architecture [W3C.WD-mmi-arch-20060414]. Architecture [W3C.WD-mmi-arch-20060414].
4.2. Service Discovery and Session Setup Requirements 4.2. Service Discovery and Session Setup Requirements
o The service discovery mechanism MUST be able to discover both o The service discovery mechanism MUST be able to discover both
Widex Renderers and Widex Servers. Widex Renderers and Widex Servers.
o The service discovery mechanism MUST be able to negotiate the o The service discovery mechanism MUST be able to negotiate the
capabilities of both Widex Renderers and Widex Servers, e.g. capabilities of both Widex Renderers and Widex Servers, e.g.
supported devices physical characteristics, supported markup supported devices physical characteristics, supported UI markup
languages, etc. languages, etc.
o The session setup mechanism MUST be able to initiate session o The session setup mechanism MUST be able to initiate session
establishment from both Widex Renderers and Widex Servers, e.g. establishment from both Widex Renderers and Widex Servers, e.g.
remote user interface pull and push. remote user interface pull and push.
4.3. Widex Objects Requirements 4.3. Widex Objects Requirements
o The Widex Objects MUST NOT be aware of the semantics of the UI o The Widex Objects MUST NOT be aware of the semantics of the UI
markup language that is synchronized. markup language.
o The Widex Objects MUST support client initiated updates. o The Widex Objects MUST support client initiated events.
o The Widex Objects MUST support server initiated updates. o The Widex Objects MUST support server initiated updates.
o The Widex Objects MUST contain only information meaningful in the o The Widex Objects MUST contain only information meaningful in the
context of the Widex Session. context of the Widex Session.
o The Widex Objects MUST indicate the target XML DOM tree when o The Widex Objects MUST indicate the target XML DOM tree when
Complex User Interfaces are involved. Complex User Interfaces are involved.
o The Widex Objects MAY support multimodal interaction, and it is o The Widex Objects MAY support multimodal interaction, and it is
the responsibility of the application to synchronise modalities the responsibility of the application to synchronise modalities
and not that of the Widex protocol. and not that of the Widex protocol.
4.4. Transport Requirements 4.4. Transport Requirements
skipping to change at page 7, line 4 skipping to change at page 7, line 12
the responsibility of the application to synchronise modalities the responsibility of the application to synchronise modalities
and not that of the Widex protocol. and not that of the Widex protocol.
4.4. Transport Requirements 4.4. Transport Requirements
o The Widex protocol MUST deliver Widex Objects in the order o The Widex protocol MUST deliver Widex Objects in the order
determined by the originator regardless of the underlying network determined by the originator regardless of the underlying network
topology. The order is relevant within a single Widex Session. topology. The order is relevant within a single Widex Session.
The co-ordination between several Widex Sessions in a Widex Server The co-ordination between several Widex Sessions in a Widex Server
is outside the scope of this document. is outside the scope of this document.
o The Widex protocol MUST handle each modality within the context of o The Widex protocol MUST handle each modality within the context of
a single Widex Session. a single Widex Session.
o The Widex protocol MUST provide reliable delivery of messages. If o The Widex protocol MUST provide reliable delivery of Widex
this proves to be impractical in a given situation, the protocol Objects. If this proves to be impractical in a given situation,
MUST provide the means for application to detect such failures. the protocol MUST provide the means for application to detect such
failures.
o The Widex protocol MUST tolerate limitations in available o The Widex protocol MUST tolerate limitations in available
bandwidth. bandwidth.
o The Widex protocol MUST tolerate delays caused by network induced o The Widex protocol MUST tolerate delays caused by network induced
latency. Latency and time-outs may need to be handled at the latency. Latency and time-outs may need to be handled at the
application level. application level.
o The Widex protocol MUST have support for authentication and secure o The Widex protocol MUST have support for authentication and secure
sessions, e.g. data privacy and integrity. sessions, e.g. data privacy and integrity.
5. IANA Considerations 5. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
6. Security Considerations 6. Security Considerations
As a means to support remote user interfaces, a number of security As a means to support remote user interfaces, a number of security
considerations need to be addressed, including the potential for considerations need to be addressed, including the potential for
unauthorized access to application services, monitoring of unauthorized access to application services, monitoring of
interactions by unauthorized third parties, spoofing of application interactions by unauthorized third parties, spoofing of application
services as a means to support phishing attacks, and denial of services as a means to support phishing attacks, and denial of
service attacks. Requirements defined in this document MUST allow service attacks.
for the implementation according to best common practices.
6.1. Privacy Considerations 6.1. Privacy Considerations
Exposing the capabilities of Widex Servers and Widex Renderers using Exposing the capabilities of Widex Servers and Widex Renderers using
the appropriate service discovery and session setup mechanism has the appropriate service discovery and session setup mechanism has
privacy implications as malicious users may harvest information about privacy implications as malicious users may harvest information about
physical characteristics and applications hosted by Widex Entities. physical characteristics and applications hosted by Widex Entities.
Implementors should carefully balance which characteristics of the Implementors should carefully balance which characteristics of the
Widex Entities are exposed over the network in accordance with the Widex Entities are exposed over the network in accordance with the
expected behaviour in their deployment environments as strong privacy expected behaviour in their deployment environments as strong privacy
skipping to change at page 8, line 6 skipping to change at page 8, line 12
For example, a TV set or a smart screen playing the role of the Widex For example, a TV set or a smart screen playing the role of the Widex
Renderer can be very well used as a secondary display. In such a Renderer can be very well used as a secondary display. In such a
case, the Widex Renderer must be discoverable and its should expose case, the Widex Renderer must be discoverable and its should expose
its capabilities so that a Widex Server will be able to provide the its capabilities so that a Widex Server will be able to provide the
user interface that best matches those capabilities instead of user interface that best matches those capabilities instead of
falling back to the default user interface, which generally leads to falling back to the default user interface, which generally leads to
a degraded user experience. a degraded user experience.
In another example, a Widex Server hosting sensitive applications In another example, a Widex Server hosting sensitive applications
that are only visible by selected set users must protect the privacy that are only visible by selected set of users must protect the
of the applications during discovery phase so that unauthorised users privacy of the applications during discovery phase so that
are not even able to discover the existence of the application before unauthorised users are not even able to discover the existence of the
being prevented to initiate Widex sessions. application before being prevented to initiate Widex sessions.
Privacy enforcement MUST allow implementation according to best Privacy enforcement MUST allow implementation according to best
common practices of the selected service discovery and session setup common practices of the selected service discovery and session setup
mechanism. mechanism.
7. Acknowledgements 7. Acknowledgements
The authors would like to thank Lisa Dusseault for her comments that The authors would like to thank Lisa Dusseault and David Black for
made this document more readable. their comments that made this document more readable.
8. References 8. References
8.1. Normative References 8.1. Normative References
[DOM2.Core] [DOM2.Core]
Le Hors, A., Le Hegaret, P., Wood, L., Nicol, G., Robie, Le Hors, A., Le Hegaret, P., Wood, L., Nicol, G., Robie,
J., Champion, M., and S. Byrne, "Document Object Model J., Champion, M., and S. Byrne, "Document Object Model
(DOM) Level 2 Core Specification", W3C Recommendation, (DOM) Level 2 Core Specification", W3C Recommendation,
November 2000. November 2000.
skipping to change at page 9, line 14 skipping to change at page 9, line 21
8.2. Informative References 8.2. Informative References
[W3C.NOTE-mmi-framework-20030506] [W3C.NOTE-mmi-framework-20030506]
Raman, T., Larson, J., and D. Raggett, "W3C Multimodal Raman, T., Larson, J., and D. Raggett, "W3C Multimodal
Interaction Framework", World Wide Web Consortium Interaction Framework", World Wide Web Consortium
NOTE NOTE-mmi-framework-20030506, May 2003, NOTE NOTE-mmi-framework-20030506, May 2003,
<http://www.w3.org/TR/2003/NOTE-mmi-framework-20030506>. <http://www.w3.org/TR/2003/NOTE-mmi-framework-20030506>.
[W3C.WD-emma-20050916] [W3C.WD-emma-20050916]
Dahl, D., Chou, W., Johnston, M., Raggett, D., and G. Johnston, M., Chou, W., McCobb, G., Raggett, D., and D.
McCobb, "EMMA: Extensible MultiModal Annotation markup Dahl, "EMMA: Extensible MultiModal Annotation markup
language", World Wide Web Consortium LastCall WD-emma- language", World Wide Web Consortium LastCall WD-emma-
20050916, September 2005, 20050916, September 2005,
<http://www.w3.org/TR/2005/WD-emma-20050916>. <http://www.w3.org/TR/2005/WD-emma-20050916>.
[W3C.WD-mmi-arch-20060414] [W3C.WD-mmi-arch-20060414]
Bodell, M., Wahbe, A., Raggett, D., and J. Barnett, Bodell, M., Wahbe, A., Raggett, D., and J. Barnett,
"Multimodal Architecture and Interfaces", World Wide Web "Multimodal Architecture and Interfaces", World Wide Web
Consortium WD WD-mmi-arch-20060414, April 2006, Consortium WD WD-mmi-arch-20060414, April 2006,
<http://www.w3.org/TR/2006/WD-mmi-arch-20060414>. <http://www.w3.org/TR/2006/WD-mmi-arch-20060414>.
skipping to change at page 9, line 44 skipping to change at page 10, line 14
Authors' Addresses Authors' Addresses
Vlad Stirbu Vlad Stirbu
Nokia Nokia
Visiokatu 3 Visiokatu 3
Tampere 33720 Tampere 33720
Finland Finland
Phone: +358 7180 08000 Phone: +358 7180 08000
Email: vlad.stibu@nokia.com Email: vlad.stirbu@nokia.com
Dave Raggett Dave Raggett
W3C/Volantis W3C/Volantis
35 Frome Road 35 Frome Road
Bradford on Avon, Wiltshire BA15 2EA Bradford on Avon, Wiltshire BA15 2EA
United Kingdom United Kingdom
Phone: +44 1225 866240 Phone: +44 1225 866240
Email: dsr@w3.org Email: dsr@w3.org
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 End of changes. 24 change blocks. 
55 lines changed or deleted 67 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/