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,
<http://www.w3.org/TR/2006/
Stirbu & Raggett Expires April 27, 2007 [Page 11]
Internet-Draft The WIDEX Framework October 2006
WD-DOM-Level-3-Events-20060413>.
[W3C.WD-rex-20060202]
Berjon, R., "Remote Events for XML (REX) 1.0", World Wide
Web Consortium WD WD-rex-20060202, February 2006,
<http://www.w3.org/TR/2006/WD-rex-20060202>.
[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,
<http://www.w3.org/TR/2003/REC-SVG11-20030114>.
[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,
<http://www.w3.org/TR/2002/REC-xhtml1-20020801>.
[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,
<http://www.w3.org/TR/2003/REC-xml-events-20031014>.
[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,
<http://www.w3.org/TR/2006/WD-mmi-arch-20060414>.
URIs
[1] <http://glade.gnome.org/index.html>
[2] <http://www.gtk.org/>
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]