WIDEX V. Stirbu Internet-Draft Nokia Intended status: Informational D. Raggett Expires:
November 15, 2006April 1, 2007 W3C/Volantis May 14,September 28, 2006 Widget Description Exchange Service (WIDEX) Requirements draft-ietf-widex-requirements-02draft-ietf-widex-requirements-03 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 November 15, 2006.April 1, 2007. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 43 2. Widex Entities . . . . . . . . . . . . . . . . . . . . . . . . 43 3. Widex Terminology . . . . . . . . . . . . . . . . . . . . . . 43 3.1. User Interface . . . . . . . . . . . . . . . . . . . . . . 43 3.2. Remote User Interface . . . . . . . . . . . . . . . . . . 54 3.3. Widex Objects . . . .Multimodal Interaction . . . . . . . . . . . . . . . . . . 54 3.4. Transport Protocol . . . . . . . . . . .Widex Objects . . . . . . . . . 6 3.5. Simple vs. Complex User Interfaces. . . . . . . . . . . . 6 3.6. Session. 4 3.5. Transport Protocol . . . . . . . . . . . . . . . . . . . . 5 3.6. Simple vs. Complex User Interfaces . . . . 6 4. Scenarios and Explanatory Discussion. . . . . . . . 5 3.7. Session . . . . . 6 4.1. NAT Traversal. . . . . . . . . . . . . . . . . . . . 5 4. Requirements . . 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 . . . . . . .4.1. Architecture Requirements . . . . . . . . . . . . . . . . 76 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 . . . . . . . . . . . . .Service Discovery and Session Setup Requirements . . . . . 9 4.2.3. IPv4-Only Widex Element communicating with an IPv6-Only6 4.3. Widex Element . . . . . . .Objects Requirements . . . . . . . . 9 4.2.4. Application Aspects of IPv6 Transition. . . . . . . . 10 5.6 4.4. Transport Requirements . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . 10 5.1. Architecture Requirements . . .. . . . . . . . . . . . . 10 5.2. Discovery and Session Setup Requirements. 7 6. Security Considerations . . . . . . . . 10 5.3. Widex Objects Requirements. . . . . . . . . . . 7 6.1. Privacy Considerations . . . . . 10 5.4. Transport Requirements. . . . . . . . . . . . . 7 7. Acknowledgements . . . . . 11 6. IANA Considerations. . . . . . . . . . . . . . . . . . 8 8. References . . . 11 7. Security Considerations. . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements. . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9.8 8.2. Informative References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . .9 Authors' Addresses . . . . . . . . . . . . . . . . 12 9.2. Informative References. . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 1411 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 serverServer 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 entitiesEntities 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. 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 of the Widex working group is to define Widex Objects (WO), to be used to convey information about interface updates and events. WOsWidex Objects are used to keep the rendered user interface synchronised with the application logic. There are two types of WOs:Widex Objects: WO Update (WO.Update): WO.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. WO 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 arehave 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. WO.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],[W3C.WD-emma-20050916], which uses XML for annotated interpretations of user input. A secondary use of WO.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]. 22.214.171.124. Transport Protocol The Transport Protocol is a protocol that just transports the WOsWidex Objects as a string of bits, without looking at them. 126.96.36.199. 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 [sXBL][W3C.WD-sXBL-20050815] for the role of shadow DOMs. 188.8.131.52. 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. 4. ScenariosRequirements 4.1. Architecture Requirements o The framework MUST be modular, e.g. multiple service discovery and Explanatory Discussion In this section we introduce short scenarios to illustrate how Widex services cansession setup mechanisms may be deployed in some environments. 4.1. NAT Traversal Inused. o The synchronisation MUST occur at a fairly loose level that allows for a simple approach to propagating changes. o The framework and the following sections we will describe some ofsynchronisation protocol SHOULD be stateless. o The framework SHOULD be consistent with the common scenarios involving Widex Elements and NAT traversal. 4.1.1. Scenario 1: Widex ServerW3C Multimodal Architecture [W3C.WD-mmi-arch-20060414]. 4.2. Service Discovery and Renderer Located in Internet In this scenarioSession Setup Requirements o The service discovery mechanism MUST be able to discover both the ServerWidex Renderers and Renderer are located somewhere inWidex Servers. o The service discovery mechanism MUST be able to negotiate the Internet and are globally accessible via public IP addresses and/or Fully Qualified Domain Name (FQDN). ************** +--------+ * Public * +--------+ |capabilities of both 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. ************** * Public * * 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 RFC 4213 [RFC4213]. 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 [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 andRenderers and Widex Servers, e.g. supported devices physical characteristics, supported 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. 184.108.40.206. Widex Objects Requirements o The WOsWidex Objects MUST NOT be aware of the semantics of the UI markup language that is synchronized. o The WOsWidex Objects MUST support client initiated updates. o The WOsWidex Objects MUST support server initiated updates. o The WOsWidex Objects MUST contain only information having remote scope.meaningful in the context of the Widex Session. o The WOsWidex Objects MUST indicate the target XML DOM tree when Complex User Interfaces are involved. o The WOsWidex Objects MAY support multiple modes ofmultimodal interaction, and it is the responsibility of the application to synchronise modalities and not that of the Widex protocol. 220.127.116.11. Transport Requirements o The Widex protocol MUST deliver WOsWidex 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- ordinationco-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 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 athandled 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. Requirements defined in this document MUST allow for the implementation according to best common practices. 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 Renderer can be very well used as a secondary display. In such a case, the application level. o TheWidex protocol MUST have support for authentication and secure sessions, e.g. data privacyRenderer must be discoverable and integrity. 6. IANA Considerations This document makes no request of IANA. 7. Security Considerations Asits should expose its capabilities so that a meansWidex Server will be able to support remoteprovide the user interfaces, a numberinterface that best matches those capabilities instead of security considerations needfalling back to be addressed, includingthe potential for unauthorized accessdefault user interface, which generally leads to application services, monitoring of interactionsa degraded user experience. In another example, a Widex Server hosting sensitive applications that are only visible by unauthorized third parties, spoofingselected set users must protect the privacy of application services as a meansthe applications during discovery phase so that unauthorised users are not even able to support phishing attacks, and denialdiscover the existence of service attacks. Requirements defined in this documentthe application before being prevented to initiate Widex sessions. Privacy enforcement MUST allow for theimplementation according to best common practices. 8.practices of the selected service discovery and session setup mechanism. 7. Acknowledgements The authors would like to thank Juha WiljakkaLisa Dusseault for good input andher comments that helped writingmade this document. 9.document more readable. 8. References 18.104.22.168. 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. 22.214.171.124. Informative References [EMMA] Johnston, M.,[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, <http://www.w3.org/TR/2003/NOTE-mmi-framework-20030506>. [W3C.WD-emma-20050916] Dahl, D., Chou, W., Dahl,Johnston, M., Raggett, D., McCobb, G.,and D. Raggett, "Extensible Multi-Modal Annotations (EMMA)", W3C Last Call Working Draft,G. McCobb, "EMMA: Extensible MultiModal Annotation markup language", World Wide Web Consortium LastCall WD-emma- 20050916, September 2005. [MMI.Arch]2005, <http://www.w3.org/TR/2005/WD-emma-20050916>. [W3C.WD-mmi-arch-20060414] Bodell, M., Wahbe, A., Raggett, D., and J. 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,World Wide Web Consortium WD WD-mmi-arch-20060414, 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]2006, <http://www.w3.org/TR/2006/WD-mmi-arch-20060414>. [W3C.WD-sXBL-20050815] Ferraiolo, J., Hickson, I., and D. Hyatt, "SVG's XML Binding Language (sXBL)", W3C Working Draft,World Wide Web Consortium WD WD- sXBL-20050815, August 2005, <http://www.w3.org/TR/2005/WD-sXBL-20050815>. [WhatWG.WebApps1.0] Hickson, I., "Web Applications 1.0", October 2005. Authors' Addresses Vlad Stirbu Nokia Visiokatu 3 Tampere 33720 Finland Phone: +358 7180 08000 Email: email@example.com Dave Raggett W3C/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 provided by the IETF Administrative Support Activity (IASA).