WIDEX V. Stirbu Internet-Draft Nokia
Expires: July 16, 2006Intended status: Informational D. Raggett W3C/Canon January 12,Expires: October 13, 2006 W3C/Volantis April 11, 2006 Widget Description Exchange Service (WIDEX) Requirements draft-ietf-widex-requirements-00draft-ietf-widex-requirements-01 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 16,October 13, 2006. Copyright Notice Copyright (C) The Internet Society (2006). 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 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Widex Entities . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Widex Terminology . . . . . . . . . . . . . . . . . . . . . . 4 3.1. User Interface . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Remote User Interface . . . . . . . . . . . . . . . . . . 5 3.3. Remote User InterfaceWidex Objects . . . . . . . . . . . . . . . . . . . . . . 5 3.4. Transport Protocol . . . . . . . . . . . . . . . . . . . . 6 3.5. Simple vs. Complex User Interfaces . . . . . . . . . . . . 6 3.6. Session . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Scenarios and Explanatory Discussion . . . . . . . . . . . . . 6 4.1. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 6 4.1.1. Scenario 1: Widex Server and Renderer Located in Internet . . . . . . . . . . . . . . . . . . . . . . . 6 4.1.2. Scenario 2: Widex Server Located in Internet . . . . . 7 4.1.3. Scenario 3: Widex Renderer and Server in the Same Network . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. IPv4-IPv6 Interworking . . . . . . . . . . . . . . . . . . 8 4.2.1. Dual-Stack Widex Element Communicating with IPv4-Only Widex Element Using IPv4 . . . . . . . . . . 9 4.2.2. Dual-Stack Widex Elements Communicating over IPv4 Segment using IPv6 . . . . . . . . . . . . . . . . . . 9 4.2.3. IPv4-Only Widex Element communicating with an IPv6-Only Widex Element . . . . . . . . . . . . . . . 9 4.2.4. Application Aspects of IPv6 Transition . . . . . . . . 10 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Architecture Requirements . . . . . . . . . . . . . . . . 10 5.2. Discovery and Session Setup Requirements . . . . . . . . . 10 5.3. Remote UIWidex Objects Requirements . . . . . . . . . . . . . . . . 10 5.4. Transport Requirements . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 1112 9.1. Normative References . . . . . . . . . . . . . . . . . . . 1112 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 1314 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 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 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 InterfaceWidex Objects One of the goals of the Widex working group is to define Remote User InterfaceWidex Objects (RUIO),(WO), to be used to convey information about interface updates and events. RUIOsWOs are used to keep the rendered user interface synchronised with the application logic. There are two types of RUIOs: RUIOWOs: WO Update (RUI.Update): RUI.UpdateWO.Update messages 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. RUIOWO Event (RUI.Event): RUI.Event(WO.Event): WO.Event messages 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 are have local scope and may be intended for default event handlers or for local scripted event handlers. The application logic in the Widex Server may only be interested in specific events. RUI.EventWO.Event messages may carry data according to the type of the event, e.g. application defined events with structured payloads as per Extensible Multi-Modal Annotations [EMMA], which uses XML for annotated interpretations of user input. A secondary use of RUI.EventWO.Event messages 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.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 SVG's XML Binding Language [sXBL] for the role of shadow DOMs. 3.6. Session The Widex Session is initiated between a Widex Servers and a Widex Renderer for exchanging information about user interface updates and events in order to control applications remotely. A Widex Session relate to a single User Interface, which can be simple or complex. 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. NAT Traversal In the following sections we will describe some of the common scenarios involving Widex Elements and NAT traversal. 4.1.1. Scenario 1: Widex Server and Renderer Located in Internet In this scenario both the Server and Renderer are located somewhere in the Internet and are globally accessible via public IP addresses and/or Fully Qualified Domain Name (FQDN). ************** +--------+ * Public * +--------+ | Widex |--* Network *--| Widex | | Server | * * |Renderer| +--------+ ************** +--------+ Figure 2: Widex Server and Renderer Located in Internet 4.1.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. +--------+ ************** | Widex | * Public * | Server |--* Network * +--------+ * * ************** / +--------+ | NAT | +--------+ / ************** * Private * +--------+ * Network *--| Widex | * * |Renderer| ************** +--------+ Figure 3: Widex Server located in Internet 4.1.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. ************** * PrivatePublic * * Network * * * ************** | +--------+ | NAT | +--------+ | ************** +--------+ * Local Area * +--------+ | Widex |---* Network *---| Widex | | Server | * * |Renderer| +--------+ ************** +--------+ Figure 4: Widex Renderer and Server in the same private network The network might be managed in which case a centralised service discovery and session setup mechanism should be used, or unmanaged and a peer-to-peer service discovery and session setup mechanism should be used. 4.2. IPv4-IPv6 Interworking The global deployment of IPv6 is underway, creating an IPv4/IPv6 Internet consisting of IPv4-only and dual-stack IPv4/IPv6 networks and nodes. There may also be IPv6-only nodes. It is highly probable that there will be situations when IPv4-only Widex entities will want to communicate with dual-stack IPv4/IPv6 Widex entities. Also, a valid scenario is where two dual-stack IPv4/IPv6 Widex entities are communicating over a network that includes an IPv4-only segment. In these scenarios, it is expected that at least one Widex Element will be attached to an unmanaged network or to a 3GPP network; IPv6 transition scenarios for unmanaged networks are described in RFC 3750 [RFC3750] and for 3GPP networks are described in RFC 3574 [RFC3574]. A good guideline, when talking about migrating from IPv4 to IPv6, is to select such protocols that do not have big issues with NAT traversal and IPv6 transition mechanisms. In the following sections, we will describe some of the common scenarios involving Widex Elements and IPv4-IPv6 interworking. 4.2.1. Dual-Stack Widex Element Communicating with IPv4-Only Widex Element Using IPv4 +---------+ +---------+ | Widex | | Widex | | Element | *********** | Element | +---------+ * * +---------+ |IPv4/IPv6|--* IPv4/IPv6 *--|IPv4-only| +---------+ * * +---------+ *********** Figure 5: Dual-stack WE communicating with IPv4 only WE using IPv4 4.2.2. Dual-Stack Widex Elements Communicating over IPv4 Segment using IPv6 +---------+ +---------+ | Widex | | Widex | | Server | *********** *********** *********** | Renderer| +---------+ * * * * * * +---------+ |IPv4/IPv6|--* IPv4/IPv6 *--* IPv4-only *--* IPv4/IPv6 *--|IPv4/IPv6| +---------+ * * * * * * +---------+ *********** *********** *********** Figure 6: Dual-stack WE communicating over IPv4 segment using IPv6 When dual-stack Widex Elements communicate using IPv6 over an IPv4- only segment, tunneling mechanisms such as 6to4 [RFC3056], ISATAP [RFC4214] or Teredo [I-D.huitema-v6ops-teredo][RFC4380] MAY be used by the intermediate nodes or by the nodes hosting the Widex Elements to tunnel the IPv6 traffic over the IPv4-only segment. 4.2.3. IPv4-Only Widex Element communicating with an IPv6-Only Widex Element +---------+ +---------+ | Widex | | Widex | | Element | *********** +----------+ *********** | Element | +---------+ * * | Protocol | * * +---------+ |IPv4-only|--* IPv4-only *--|Translator|--* IPv6-only *--|IPv6-only| +---------+ * * | /ALG | * * +---------+ *********** +----------+ *********** Figure 7: IPv4-Only WE communicating with an IPv6-Only WE Protocol translation / Application Level Gateway (ALG) functionality is necessary in the network in order to enable the communication between an IPv4-only Widex Element with an IPv6-only Widex Element. This is not a typical case as the assumption is that IPv6-only nodes will not be common in the near future. 4.2.4. Application Aspects of IPv6 Transition Application developers, implementing the Widex framework and services, which want to enable IPv6 support in implementations running on IPv6 hosts or want to develop IP version-independent implementations SHOULD consider recommendations written in RFC 4038 [RFC4038]. 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. o The framework SHOULD be consistent with the W3C Multimodal Architecture [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 UIWidex Objects Requirements o The RUIOsWOs MUST NOT be aware of the semantics of the markup that is synchronized. o The RUIOsWOs MUST support client initiated updates. o The RUIOsWOs MUST support server initiated updates. o The RUIOsWOs MUST contain only information having remote scope. o The WOs MUST indicate the target XML DOM tree when Complex User Interfaces are involved. o The RUIOsWOs MAY support multiple modes of interaction, and it is the responsibility of the application to synchronise modalities and not that of the Widex protocol. 5.4. Transport Requirements o The Widex protocol MUST deliver RUIOsWOs 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 provide reliable delivery of messages. 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. 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. Requirements defined in this document MUST allow for the implementation according to best common practices. 8. Acknowledgements The authors would like to thank Juha Wiljakka for good input and comments that helped writing this document. 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. [I-D.huitema-v6ops-teredo] Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs", draft-huitema-v6ops-teredo-05 (work in progress), April 2005.[MMI.Arch] Barnett, J., "Multimodal Architecture and Interfaces", W3C Working Draft, April 2005. [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [RFC3574] Soininen, J., "Transition Scenarios for 3GPP Networks", RFC 3574, August 2003. [RFC3750] Huitema, C., Austein, R., Satapati, S., and R. van der Pol, "Unmanaged Networks IPv6 Transition Scenarios", RFC 3750, April 2004. [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, "Application Aspects of IPv6 Transition", RFC 4038, March 2005. [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005. [RFC4214] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 4214, October 2005. [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006. [WhatWG.WebApps1.0] Hickson, I., "Web Applications 1.0", October 2005. [sXBL] Ferraiolo, J., Hickson, I., and D. Hyatt, "SVG's XML Binding Language (sXBL)", W3C Working Draft, August 2005. Authors' Addresses Vlad Stirbu Nokia Visiokatu 3 Tampere 33720 Finland Phone: +358 7180 08000 Email: email@example.com Dave Raggett W3C/CanonW3C/Volantis 35 Frome Road Bradford on Avon, Wiltshire BA15 2EA United Kingdom Phone: +44 1225 866240 Email: firstname.lastname@example.org Full Copyright Statement Copyright (C) The Internet Society (2006). 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 email@example.com. Acknowledgment Funding for the RFC Editor function is currentlyprovided by the Internet Society.IETF Administrative Support Activity (IASA).