From: http://www.ietf.org/internet-drafts/draft-stirbu-widex-framework-03.txt Title: Widget Description Exchange Service (WIDEX) Framework Date: October 24, 2006 I-D Tracker: http://ietfreport.isoc.org/idref/draft-stirbu-widex-framework/ See also: Widget Description Exchange Service (WIDEX) Requirements http://xml.coverpages.org/draft-ietf-widex-requirements-04.txt Widget Description Exchange Service (WIDEX) Working Group http://www.ietf.org/html.charters/widex-charter.html Alternate WIDEX Wg resources http://www.softarmor.com/widex/ ========================================================================== WIDEX V. Stirbu Internet-Draft Nokia Intended status: Standards Track D. Raggett Expires: April 27, 2007 W3C/Volantis October 24, 2006 Widget Description Exchange Service (WIDEX) Framework draft-stirbu-widex-framework-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 April 27, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document defines a framework 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 operations. Stirbu & Raggett Expires April 27, 2007 [Page 1] Internet-Draft The WIDEX Framework October 2006 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. Architecture Paradigm . . . . . . . . . . . . . . . . . . . . 4 3. The Widex Framework Definition . . . . . . . . . . . . . . . . 5 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Components . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.1. Service Discovery and Session Setup . . . . . . . . . 8 3.2.2. Widex Synchronisation . . . . . . . . . . . . . . . . 9 3.2.3. Transport . . . . . . . . . . . . . . . . . . . . . . 9 4. Widex Synchronisation Messages . . . . . . . . . . . . . . . . 9 4.1. WO.Update Message . . . . . . . . . . . . . . . . . . . . 9 4.2. WO.Event Message . . . . . . . . . . . . . . . . . . . . . 9 4.3. WO.Selector Message . . . . . . . . . . . . . . . . . . . 10 5. Processing External Resources . . . . . . . . . . . . . . . . 10 5.1. References to External Resources . . . . . . . . . . . . . 10 5.2. Synchronising with External Resources . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 Appendix A. Topology Considerations . . . . . . . . . . . . . . . 13 A.1. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 13 A.1.1. Scenario 1: Widex Server and Renderer Located in Internet . . . . . . . . . . . . . . . . . . . . . . . 14 A.1.2. Scenario 2: Widex Server Located in Internet . . . . . 14 A.1.3. Scenario 3: Widex Renderer and Server in the Same Network . . . . . . . . . . . . . . . . . . . . . . . 14 A.2. IPv4-IPv6 Interworking Considerations . . . . . . . . . . 15 A.2.1. Dual-Stack Widex Element Communicating with Stirbu & Raggett Expires April 27, 2007 [Page 2] Internet-Draft The WIDEX Framework October 2006 IPv4-Only Widex Element Using IPv4 . . . . . . . . . . 16 A.2.2. Dual-Stack Widex Elements Communicating over IPv4 Segment using IPv6 . . . . . . . . . . . . . . . . . . 16 A.2.3. IPv4-Only Widex Element communicating with an IPv6-Only Widex Element . . . . . . . . . . . . . . . 16 A.2.4. Application Aspects of IPv6 Transition . . . . . . . . 17 Appendix B. Widex Framework Deployment Considerations . . . . . . 17 B.1. Simple Widex Elements . . . . . . . . . . . . . . . . . . 17 B.2. Multimodal Widex Server . . . . . . . . . . . . . . . . . 17 B.3. Multiple Rendering Engines Widex Renderer . . . . . . . . 17 B.4. Hybrid . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 19 Stirbu & Raggett Expires April 27, 2007 [Page 3] Internet-Draft The WIDEX Framework October 2006 1. Introduction This document describes the components and interactions between them of the Widex framework 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 operations. The framework described in this document is intended to fulfil the requirements described in Internet-Draft Widex Requirements [I-D.ietf-widex-requirements]. 2. Architecture Paradigm The Model-View-Controller architectural pattern (MVC) [MVC] divides an interactive application into three components. The model contains the core functionality and data. Views display information to the user. Controllers handle user input. Views and controllers together comprise the user interface. A change-propagation mechanism ensures consistency between the user interface and the model. Figure 1 describes an extension to the MVC architecture which enables the situations where the user interface and the model may be on different machines. +-----------------------------+ +---------------+ | Widex Server | | Widex Renderer| | +-------+ .............. | | +-----------+ | | | | . .--------------->| | | | | | . View . | Updates | | | | | | | . (Virtual) .<---------------| | | | | | .............. | | | | | | | Model | | | | View | | | | | +------------+ | | | | | | | | | |<---------------| | | | | | | Controller | | Events | | | | | | | | |--------------->| | | | +-------+ +------------+ | | +-----------+ | +-----------------------------+ +---------------+ Figure 1: Architecture paradigm - A networked MVC architecture In the networked MVC architecture, the View is exported on the remote device while a Virtual View is maintained on the server. The change- propagation mechanism that ensures consistency between the user interface and the model is augmented with methods which keep the View synchronised with the Virtual View, synchronisation being done via updates. Additionally, user interactions or gestures are captured by the View copy and passed to the Controller as events. Stirbu & Raggett Expires April 27, 2007 [Page 4] Internet-Draft The WIDEX Framework October 2006 It is quite common that the View is not needed in the Widex Server, but there are situations (e.g. desktop applications) in which the Widex Server has to maintain a real copy of the View. Therefore, we call the View in the Widex Server to be Virtual. 3. The Widex Framework Definition 3.1. Overview 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]. The Widex Framework, described in Figure 2, is based on the networked MVC paradigm described in Section 2. The Widex framework is handling all network related issues involved in the networked MVC architecture, e.g. discovery and matching of Widex Elements, setting up sessions between Widex Elements, marshaling XML DOM updates or events and exchanging them over the wire. There are many events emitted on the Widex Renderer side that have no meaning for the application running in the Widex Server and in order to minimise the network traffic the Widex Framework MUST deliver only the information having remote scope. Stirbu & Raggett Expires April 27, 2007 [Page 5] Internet-Draft The WIDEX Framework October 2006 +-------------------------------+ +--------------------------+ | Widex Server | | Widex Renderer | | | | | |+--------------------+ | | +---------------+| || Application | | | | Rendering || || | | | | Engine || ||+---++------------+ | +-----+ | | +-----+ | +------------+|| ||| ||+..........+| | | | |Selector| | | | |+..........+||| ||| ||. Event .|-->| |----------->| |-->|. Event .||| ||| ||. Handler .| | | F | | | | F | | |. Listener .||| ||| M ||+..........+| | | r | | | | r | | |+..........+||| ||| o || |<--| W a |<-----------| W a |<--| XML DOM ||| ||| d || Controller | | | i m | | Events | | i m | | | ||| ||| e || |-->| d e |----------->| d e |-->| Engine ||| ||| l |+------------+ | | e w | | | | e w | | +------------+|| ||| |.............. | | x o | | | | x o | | +------------+|| ||| |. View .-->| r |----------->| r |-->| View ||| ||| |. (Virtual) . | | k | |Updates | | k | | | ||| ||| |. XML DOM .<--| |<-----------| |<--| XML DOM ||| ||+---+.............. | | | | | | | | +------------+|| |+--------------------+ +-----+ | | +-----+ +---------------+| +-------------------------------+ +--------------------------+ Figure 2: Widex Framework Overview The Widex Framework needs a mechanism by which the Widex Renderer determines which events have a remote scope and therefore need to be serialized and forwarded to the Widex Server. The determination of which events have a remote scope could be achieved in one of three ways: o prior agreement between the Widex Renderer and Widex Server o a list of event names passed during session establishment o the Widex Server could direct the Widex Renderer to add and remove event listeners during the session The Widex Framework enables remote event listeners to be dynamically attached to DOM nodes during the session using WO.Selector messages as described in Section 4.3. Local event listeners that are not forwarded to the Widex Server may be dynamically attached through WO.Update messages as described in Section 4.1, and which update the DOM tree that is interpreted by the Widex Renderer. With the Model-View-Controller design pattern, updates to the (virtual) DOM tree held by the Widex Server are reflected as WO.Update messages that in turn result in the Widex Renderer updating its copy of the DOM tree to match the changes made by the Widex Server. A similar process occurs when the Widex Server adds or Stirbu & Raggett Expires April 27, 2007 [Page 6] Internet-Draft The WIDEX Framework October 2006 removes event listeners, where these changes are mediated by WO.Selector messages. With the DOM Event model it is possible to attach multiple event listeners for the same event. The DOM event model defines an ordering in which the listeners are invoked, and provides a means to stop further propagation of the event, and to prevent the default event handler from being invoked. In the case of a mix of local and remote event listeners, depending on where they are attached, a local event listener could stop further propagation and thereby prevent the remote event listener from being invoked. The other way around is more complicated. The stub used by the Widex Renderer for remote event listeners could itself stop further propagation, but there would be undue latency incurred if this was to be done by the corresponding event handler in the Widex Server. In an implementation where the Widex Server maintains an explicit XML DOM for the View, changes made by the Widex Server to this View result in DOM events, e.g. DOM Mutation events. The Widex Framework in the server (as shown in Figure 1) can listen for these events to generate the corresponding Widex messages. The Widex Framework in the Renderer interprets these messages to reflect the changes to its copy of the XML DOM for the View. Note that the Widex messages are independent of whether the Widex Server maintains an explicit DOM for the View, that is, an in-memory XML DOM tree, as this is an implementation dependent design choice. 3.2. Components The Widex Framework has three components: o Service Discovery and Session Setup o Widex Sync o Transport Stirbu & Raggett Expires April 27, 2007 [Page 7] Internet-Draft The WIDEX Framework October 2006 +-----------+ +--------------------------+ | | | | | Service | | Widex Sync | | Discovery | | | | and | +--------------------------+ | Session | | Setup | +--------------------------+ | | | Transport | +-----------+ +--------------------------+ Figure 3: Widex Framework Components 3.2.1. Service Discovery and Session Setup The Service Discovery and Session Setup component is treated by the Widex Framework as a black box; any service discovery mechanism being able to find matches between a Widex Server and a Widex Renderer and any session setup mechanism able to establish a session between a matching Widex Server and Widex Renderer can be used as part of the framework. We define a match or compatibility between a Widex Server and Widex Renderer when the Widex Renderer can display the user interface exported by the Widex Server. Typically this means that both devices support the same XML DOM and XML DOM Events specifications and the Widex Renderer has rendering capabilities for the XML user interface language exported by the server. Quite often, the Widex Server can make better decisions on what user interface to export to a particular Widex Renderer if it has additional information about its hardware capabilities, e.g. screen size, color depth, input methods. Therefore, the Service Discovery mechanism MUST negotiate the following capabilities: o supported XML DOM level, o supported XML DOM Events level, o supported XML user interface description language, o supported transport mechanism. The Service Discovery mechanism SHOULD negotiate the following capabilities for the Widex Renderer: o event listeners o device configuration where examples of the device configuration includes the display Stirbu & Raggett Expires April 27, 2007 [Page 8] Internet-Draft The WIDEX Framework October 2006 resolution, the color depth, and input methods. The Session Setup mechanism MUST be able to initiate the Widex Session between the Widex Server and the Widex Renderer using the selected transport mechanism. 3.2.2. Widex Synchronisation The Widex Sync component provides the functionality that enables the marshaling of XML DOM updates and events. Additionally, the Widex Sync component provides the control messages that determine which events have remote scope. 3.2.3. Transport The Transport component is treated by the Widex Framework as a black box; any transport mechanism being able to facilitate the exchange of Widex Sync messages between a Widex Server and a Widex Renderer can be used as part of the framework. The Transport mechanisms MUST deliver the Widex Sync messages as string of bits between the Widex Server and the Widex Renderer in a timely, reliable and in sequence manner. 4. Widex Synchronisation Messages 4.1. WO.Update Message The 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 to change its structure, e.g. add/delete/replace nodes or branches. Typically, a Widex Servers can trigger WO.Update messages that produce the full range of mutations while Widex Renderers trigger WO.Update messages that target individual nodes to update their properties and attributes. WO.Update messages MUST be encoded using formats defined by REX [W3C.WD-rex-20060202]. 4.2. WO.Event Message The 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. A secondary use of Stirbu & Raggett Expires April 27, 2007 [Page 9] Internet-Draft The WIDEX Framework October 2006 WO.Event messages is where the application logic itself raises events that may be caught by event handlers associated with the remote user interface. Note: Some UI markup languages, e.g. Glade [1], do not have events defined at document level and therefore WO.Event messages MUST be able to serialize the events emitted by the associated libraries, e.g. GTK+ [2]. 4.3. WO.Selector Message The WO.Selector message MUST contain sufficient information to enable the Widex Renderer to add or remove remote event listeners associated with particular nodes in the XML DOM. 5. Processing External Resources 5.1. References to External Resources User interface markup languages may contain references to external resources such as images and streaming audio/visual media. The means by which the Widex Renderer accesses these resources is out of scope for the Widex Framework. 5.2. Synchronising with External Resources WO.Update messages may including timing information for when they should be applied. In some cases, this will involve synchronising to streaming media, for instance, when WO.Update is used to update a user interface described in SVG, where the updates need to be synchronized with an associated audio stream. 6. IANA Considerations This document makes no request to IANA. 7. Security Considerations The Widex Framework provides no security facilities (e.g. authentication or privacy ) of its own. It relies on the framework components for all of these abilities. Stirbu & Raggett Expires April 27, 2007 [Page 10] Internet-Draft The WIDEX Framework October 2006 8. Acknowledgements The authors would like to thank Jin Yu for his contribution in developing this document. 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. [I-D.ietf-widex-requirements] Stirbu, V. and D. Raggett, "Widget Description Exchange Service (WIDEX) Requirements", draft-ietf-widex-requirements-03 (work in progress), September 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [W3C.WD-DOM-Level-3-Events-20060413] Pixley, T., Hegaret, P., and B. Hoehrmann, "Document Object Model (DOM) Level 3 Events Specification", World Wide Web Consortium WD WD-DOM-Level-3-Events-20060413, April 2006, . [W3C.WD-rex-20060202] Berjon, R., "Remote Events for XML (REX) 1.0", World Wide Web Consortium WD WD-rex-20060202, February 2006, . [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 [MVC] Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., and M. Stal, "Pattern-Oriented Software Architecture, Volume 1: A System of Patterns", John Wiley & Sons , August 1996. [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. [W3C.NOTE-xup-20020528] Yu, J., "XUP - Extensible User Interface Protocol", W3C NOTE NOTE-xup-20020528, May 2002. [W3C.REC-SVG11-20030114] Stirbu & Raggett Expires April 27, 2007 [Page 12] Internet-Draft The WIDEX Framework October 2006 淳, e., Jackson, D., and J. Ferraiolo, "Scalable Vector Graphics (SVG) 1.1 Specification", World Wide Web Consortium Recommendation REC-SVG11-20030114, January 2003, . [W3C.REC-xhtml1-20020801] Pemberton, S., "XHTML[TM] 1.0 The Extensible HyperText Markup Language (Second Edition)", World Wide Web Consortium Recommendation REC-xhtml1-20020801, August 2002, . [W3C.REC-xml-events-20031014] McCarron, S., Raman, T., and S. Pemberton, "XML Events", World Wide Web Consortium Recommendation REC-xml-events- 20031014, October 2003, . [W3C.WD-mmi-arch-20060414] Barnett, J., Bodell, M., Raggett, D., and A. Wahbe, "Multimodal Architecture and Interfaces", World Wide Web Consortium WD WD-mmi-arch-20060414, April 2006, . URIs [1] [2] Appendix A. Topology Considerations In this section we introduce short scenarios to illustrate how Widex services can be deployed in some environments. Each of the enviroments are posing particular challenges and implementers should choose the appropriate mechanism to overcome those, as components of the Widex Framework. The section should provide an introduction to implementers on the kind of problems that are induced by the network topology. A.1. NAT Traversal In the following sections we will describe some of the common scenarios involving Widex Elements and NAT traversal. Stirbu & Raggett Expires April 27, 2007 [Page 13] Internet-Draft The WIDEX Framework October 2006 A.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 4: Widex Server and Renderer Located in Internet A.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 5: Widex Server located in Internet A.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. Stirbu & Raggett Expires April 27, 2007 [Page 14] Internet-Draft The WIDEX Framework October 2006 ************** * Public * * Network * * * ************** | +--------+ | NAT | +--------+ | ************** +--------+ * Local Area * +--------+ | Widex |---* Network *---| Widex | | Server | * * |Renderer| +--------+ ************** +--------+ Figure 6: 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. A.2. IPv4-IPv6 Interworking Considerations 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. Stirbu & Raggett Expires April 27, 2007 [Page 15] Internet-Draft The WIDEX Framework October 2006 A.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 7: Dual-stack WE communicating with IPv4 only WE using IPv4 A.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 8: 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. A.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 9: 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. Stirbu & Raggett Expires April 27, 2007 [Page 16] Internet-Draft The WIDEX Framework October 2006 This is not a typical case as the assumption is that IPv6-only nodes will not be common in the near future. A.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]. Appendix B. Widex Framework Deployment Considerations This section describes the possible scenarios for deploying the Widex Framework. B.1. Simple Widex Elements In this scenario both devices running the Widex Server and the Widex Renderer are using the same platform. B.2. Multimodal Widex Server In this scenario the application running in the Widex Server is a multi-modal application compliant with W3C's Multimodal Architecture and Interfaces [W3C.WD-mmi-arch-20060414], enabling him to interact with several Widex Renderers. B.3. Multiple Rendering Engines Widex Renderer In this scenario the Widex Renderer has support for multiple rendering engines, enabling it to interact with several types of Widex Servers. B.4. Hybrid In this scenario the application running in the Widex Server is a multi-modal application and at the same time the Widex Renderer has multiple rendering capabilities. It is the job of the Service Discovery and Session Setup component to determine which is the most appropriate modality of interaction. Stirbu & Raggett Expires April 27, 2007 [Page 17] Internet-Draft The WIDEX Framework October 2006 Authors' Addresses Vlad Stirbu Nokia Visiokatu 3 Tampere 33720 Finland Phone: +358 7180 08000 Email: vlad.stibu@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 April 27, 2007 [Page 18] Internet-Draft The WIDEX Framework October 2006 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 ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Stirbu & Raggett Expires April 27, 2007 [Page 19]