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]