WIDEX V. Stirbu Internet-Draft Nokia Intended status: Informational D. Raggett Expires: July 12, 2007 W3C/Volantis January 8, 2007 Widget Description Exchange Service (WIDEX) Requirements draft-ietf-widex-requirements-04 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 July 12, 2007. Copyright Notice Copyright (C) The Internet Society (2007). 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. Stirbu & Raggett Expires July 12, 2007 [Page 1] Internet-Draft WIDEX Requirements January 2007 Requirements Language 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. Multimodal Interaction . . . . . . . . . . . . . . . . . . 4 3.4. Widex Objects . . . . . . . . . . . . . . . . . . . . . . 4 3.5. Transport Protocol . . . . . . . . . . . . . . . . . . . . 5 3.6. Simple vs. Complex User Interfaces . . . . . . . . . . . . 5 3.7. Session . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.8. State . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Architecture Requirements . . . . . . . . . . . . . . . . 6 4.2. Service Discovery and Session Setup Requirements . . . . . 6 4.3. Widex Objects Requirements . . . . . . . . . . . . . . . . 6 4.4. Transport Requirements . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6.1. Privacy Considerations . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 11 Stirbu & Raggett Expires July 12, 2007 [Page 2] Internet-Draft WIDEX Requirements January 2007 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 | | +--------+ +--------+ Figure 1: Widex Entities 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 this context, 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), Stirbu & Raggett Expires July 12, 2007 [Page 3] Internet-Draft WIDEX Requirements January 2007 see [DOM2.Core], [DOM3.Core], and [DOM2.Events] (W3C has yet to complete work on DOM3 events). Style 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. Multimodal Interaction Multimodal interaction provides the user with multiple modes of interfacing with a system beyond the traditional keyboard and mouse input/output. The most common such interface combines a visual modality (e.g. a display, keyboard, and mouse) with a voice modality (speech recognition for input, speech synthesis and recorded audio for output). However other modalities, such as pen-based input or haptic input/output, may be used. For example, W3C has developed a Multimodal Interaction Framework [W3C.NOTE-mmi-framework-20030506] that is intended as a basis for developing multimodal applications in terms of markup, scripting, styling and other resources. 3.4. Widex Objects One of the goals is to define Widex Objects (WO) that are used to convey information about interface updates and events. Widex Objects are used to keep the rendered user interface synchronised with the application logic. There are two types of Widex Objects: WO Update (WO.Update): WO.Update object contain description of changes to XML DOM trees. The updates can target individual nodes in order to update their properties and attributes, or can target parts of the DOM tree in order change its structure, e.g. add/delete/replace nodes or branches. WO Event (WO.Event): WO.Event objects are primarily used to carry events triggered on the Widex Renderer side so that they can be caught by the application logic event handlers on the Widex Server side. Not all events need to be forwarded to the application logic, as some events have local scope and may be intended for default event Stirbu & Raggett Expires July 12, 2007 [Page 4] Internet-Draft WIDEX Requirements January 2007 handlers or for local scripted event handlers. The application logic in the Widex Server may only be interested in specific events. WO.Event object may carry data according to the type of the event, e.g. application defined events with structured payloads as per Extensible Multi-Modal Annotations [W3C.WD-emma-20050916], which uses XML for annotated interpretations of user input. A secondary use of WO.Event objects is where the application logic itself raises events that may be caught by event handlers associated with the remote user interface, see for example Web Applications 1.0 [WhatWG.WebApps1.0]. 3.5. Transport Protocol The Transport Protocol is a protocol that just transports the Widex Objects as a string of bits, without looking at them. 3.6. 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. Typically, a simple user interface is associated with a single modality, e.g. vision modality for graphic user interfaces. 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 SVG's XML Binding Language [W3C.WD-sXBL-20050815] for the role of shadow DOMs. 3.7. Session The Widex Session is initiated between a Widex Server and a Widex Renderer for exchanging information about user interface updates (e.g. WO.Update) and events (e.g. WO.Event) in order to control applications remotely. A Widex Session relate to a single User 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. Stirbu & Raggett Expires July 12, 2007 [Page 5] Internet-Draft WIDEX Requirements January 2007 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.1. Architecture Requirements o The service discovery and session setup component MUST be replaceable. o The transport component MUST be replaceable. o Keeping the user interface and the application logic synchronised MUST occur at a fairly loose level that allows for a simple approach to propagating changes. o The framework SHOULD be stateless. o The framework SHOULD be consistent with the W3C Multimodal Architecture [W3C.WD-mmi-arch-20060414]. 4.2. Service 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 UI markup languages, etc. o The session setup mechanism MUST be able to initiate session establishment from both Widex Renderers and Widex Servers, e.g. remote user interface pull and push. 4.3. Widex Objects Requirements o The Widex Objects MUST NOT be aware of the semantics of the UI markup language. o The Widex Objects MUST support client initiated events. o The Widex Objects MUST support server initiated updates. o The Widex Objects MUST contain only information meaningful in the context of the Widex Session. o The Widex Objects MUST indicate the target XML DOM tree when Complex User Interfaces are involved. o The Widex Objects MAY support multimodal interaction, and it is the responsibility of the application to synchronise modalities and not that of the Widex protocol. Stirbu & Raggett Expires July 12, 2007 [Page 6] Internet-Draft WIDEX Requirements January 2007 4.4. Transport Requirements o The Widex protocol MUST deliver Widex Objects in the order determined by the originator regardless of the underlying network topology. The order is relevant within a single Widex Session. The co-ordination between several Widex Sessions in a Widex Server is outside the scope of this document. o The Widex protocol MUST handle each modality within the context of a single Widex Session. o The Widex protocol MUST provide reliable delivery of Widex Objects. If this proves to be impractical in a given situation, the protocol MUST provide the means for application to detect such failures. o The Widex protocol MUST tolerate limitations in available bandwidth. o The Widex protocol MUST tolerate delays caused by network induced latency. Latency and time-outs may need to be handled at the application level. o The Widex protocol MUST have support for authentication and secure sessions, e.g. data privacy and integrity. 5. IANA Considerations This document makes no request of IANA. 6. 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. 6.1. Privacy Considerations Exposing the capabilities of Widex Servers and Widex Renderers using the appropriate service discovery and session setup mechanism has privacy implications as malicious users may harvest information about physical characteristics and applications hosted by Widex Entities. Implementors should carefully balance which characteristics of the Widex Entities are exposed over the network in accordance with the expected behaviour in their deployment environments as strong privacy measures may lead to degraded usability. For example, a TV set or a smart screen playing the role of the Widex Stirbu & Raggett Expires July 12, 2007 [Page 7] Internet-Draft WIDEX Requirements January 2007 Renderer can be very well used as a secondary display. In such a case, the Widex Renderer must be discoverable and its should expose its capabilities so that a Widex Server will be able to provide the user interface that best matches those capabilities instead of falling back to the default user interface, which generally leads to a degraded user experience. In another example, a Widex Server hosting sensitive applications that are only visible by selected set of users must protect the privacy of the applications during discovery phase so that unauthorised users are not even able to discover the existence of the application before being prevented to initiate Widex sessions. Privacy enforcement MUST allow implementation according to best common practices of the selected service discovery and session setup mechanism. 7. Acknowledgements The authors would like to thank Lisa Dusseault and David Black for their comments that made this document more readable. 8. References 8.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. Stirbu & Raggett Expires July 12, 2007 [Page 8] Internet-Draft WIDEX Requirements January 2007 [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. 8.2. Informative References [W3C.NOTE-mmi-framework-20030506] Raman, T., Larson, J., and D. Raggett, "W3C Multimodal Interaction Framework", World Wide Web Consortium NOTE NOTE-mmi-framework-20030506, May 2003, . [W3C.WD-emma-20050916] Johnston, M., Chou, W., McCobb, G., Raggett, D., and D. Dahl, "EMMA: Extensible MultiModal Annotation markup language", World Wide Web Consortium LastCall WD-emma- 20050916, September 2005, . [W3C.WD-mmi-arch-20060414] Bodell, M., Wahbe, A., Raggett, D., and J. Barnett, "Multimodal Architecture and Interfaces", World Wide Web Consortium WD WD-mmi-arch-20060414, April 2006, . [W3C.WD-sXBL-20050815] Ferraiolo, J., Hickson, I., and D. Hyatt, "SVG's XML Binding Language (sXBL)", World Wide Web Consortium WD WD- sXBL-20050815, August 2005, . [WhatWG.WebApps1.0] Hickson, I., "Web Applications 1.0", October 2005. Stirbu & Raggett Expires July 12, 2007 [Page 9] Internet-Draft WIDEX Requirements January 2007 Authors' Addresses Vlad Stirbu Nokia Visiokatu 3 Tampere 33720 Finland Phone: +358 7180 08000 Email: vlad.stirbu@nokia.com Dave Raggett W3C/Volantis 35 Frome Road Bradford on Avon, Wiltshire BA15 2EA United Kingdom Phone: +44 1225 866240 Email: dsr@w3.org Stirbu & Raggett Expires July 12, 2007 [Page 10] Internet-Draft WIDEX Requirements January 2007 Full Copyright Statement Copyright (C) The Internet Society (2007). 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. 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Stirbu & Raggett Expires July 12, 2007 [Page 11]