draft-ietf-widex-requirements-02.txt   draft-ietf-widex-requirements-03.txt 
WIDEX V. Stirbu WIDEX V. Stirbu
Internet-Draft Nokia Internet-Draft Nokia
Intended status: Informational D. Raggett Intended status: Informational D. Raggett
Expires: November 15, 2006 W3C/Volantis Expires: April 1, 2007 W3C/Volantis
May 14, 2006 September 28, 2006
Widget Description Exchange Service (WIDEX) Requirements Widget Description Exchange Service (WIDEX) Requirements
draft-ietf-widex-requirements-02 draft-ietf-widex-requirements-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 15, 2006. This Internet-Draft will expire on April 1, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document defines functional requirements for a framework and a This document defines functional requirements for a framework and a
protocol used to support XML-based user interfaces, where the user protocol used to support XML-based user interfaces, where the user
interface and application logic may be on different machines, and interface and application logic may be on different machines, and
skipping to change at page 2, line 13 skipping to change at page 2, line 13
operations. operations.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Widex Entities . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Widex Entities . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Widex Terminology . . . . . . . . . . . . . . . . . . . . . . 4 3. Widex Terminology . . . . . . . . . . . . . . . . . . . . . . 3
3.1. User Interface . . . . . . . . . . . . . . . . . . . . . . 4 3.1. User Interface . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Remote User Interface . . . . . . . . . . . . . . . . . . 5 3.2. Remote User Interface . . . . . . . . . . . . . . . . . . 4
3.3. Widex Objects . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Multimodal Interaction . . . . . . . . . . . . . . . . . . 4
3.4. Transport Protocol . . . . . . . . . . . . . . . . . . . . 6 3.4. Widex Objects . . . . . . . . . . . . . . . . . . . . . . 4
3.5. Simple vs. Complex User Interfaces . . . . . . . . . . . . 6 3.5. Transport Protocol . . . . . . . . . . . . . . . . . . . . 5
3.6. Session . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.6. Simple vs. Complex User Interfaces . . . . . . . . . . . . 5
3.7. Session . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Scenarios and Explanatory Discussion . . . . . . . . . . . . . 6 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Architecture Requirements . . . . . . . . . . . . . . . . 6
4.1.1. Scenario 1: Widex Server and Renderer Located in 4.2. Service Discovery and Session Setup Requirements . . . . . 6
Internet . . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Widex Objects Requirements . . . . . . . . . . . . . . . . 6
4.1.2. Scenario 2: Widex Server Located in Internet . . . . . 7 4.4. Transport Requirements . . . . . . . . . . . . . . . . . . 6
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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5.1. Architecture Requirements . . . . . . . . . . . . . . . . 10
5.2. Discovery and Session Setup Requirements . . . . . . . . . 10
5.3. Widex Objects Requirements . . . . . . . . . . . . . . . . 10
5.4. Transport Requirements . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6.1. Privacy Considerations . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 11
1. Introduction 1. Introduction
With the Internet reaching out to more and more devices, people are With the Internet reaching out to more and more devices, people are
increasingly expecting to have access to services at anytime, from increasingly expecting to have access to services at anytime, from
anywhere and using any device. Such services are being developed anywhere and using any device. Such services are being developed
using Web technologies such as XML and distributed across the network using Web technologies such as XML and distributed across the network
rather than resident on any one device. rather than resident on any one device.
2. Widex Entities 2. Widex Entities
skipping to change at page 4, line 37 skipping to change at page 3, line 37
The two primary Entities are described as follows: The two primary Entities are described as follows:
Widex Server (WS): Widex Server (WS):
The entity that holds the application logic. The entity that holds the application logic.
Widex Renderer (WR): Widex Renderer (WR):
The entity that renders the user interface. The entity that renders the user interface.
There might be several Widex Servers in the same device, one for each There might be several Widex Servers in the same device, one for each
application that can export the user interface and for each Widex application that can export the user interface and for each Widex
server there might be several Widex Renderers which are rendering the Server there might be several Widex Renderers which are rendering the
user interface. user interface.
3. Widex Terminology 3. Widex Terminology
The terminology and definitions detailed below include both terms The terminology and definitions detailed below include both terms
that, besides the Widex entities are used in the requirements section that, besides the Widex Entities are used in the requirements section
of this document. of this document.
3.1. User Interface 3.1. User Interface
In the context of Widex working group, the user interface is In the context of Widex working group, the user interface is
understood as XML [XML1.0] data describing the user interface. understood as XML [XML1.0] data describing the user interface.
Typically, the XML data is manipulated as levels 2 and 3 in the W3C Typically, the XML data is manipulated as levels 2 and 3 in the W3C
Document Object Model (DOM), see [DOM2.Core], [DOM3.Core], and Document Object Model (DOM), see [DOM2.Core], [DOM3.Core], and
[DOM2.Events] (W3C has yet to complete work on DOM3 events). Style [DOM2.Events] (W3C has yet to complete work on DOM3 events). Style
information associated with the user interface can be manipulated via information associated with the user interface can be manipulated via
the DOM, see [DOM2.Style]. the DOM, see [DOM2.Style].
3.2. Remote User Interface 3.2. Remote User Interface
The Remote User Interface (RUI) is a technique in which a user The Remote User Interface (RUI) is a technique in which a user
interface is rendered on another device than the one that runs the interface is rendered on another device than the one that runs the
application logic while keeping the user interface synchronised with application logic while keeping the user interface synchronised with
the application logic. the application logic.
3.3. Widex Objects 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 One of the goals of the Widex working group is to define Widex
Objects (WO), to be used to convey information about interface Objects (WO), to be used to convey information about interface
updates and events. WOs are used to keep the rendered user interface updates and events. Widex Objects are used to keep the rendered user
synchronised with the application logic. interface synchronised with the application logic.
There are two types of WOs: There are two types of Widex Objects:
WO Update (WO.Update): WO Update (WO.Update):
WO.Update messages contain description of changes to XML DOM WO.Update messages contain description of changes to XML DOM
trees. The updates can target individual nodes in order to update trees. The updates can target individual nodes in order to update
their properties and attributes, or can target parts of the DOM their properties and attributes, or can target parts of the DOM
tree in order change its structure, e.g. add/delete/replace nodes tree in order change its structure, e.g. add/delete/replace nodes
or branches. or branches.
WO Event (WO.Event): WO Event (WO.Event):
WO.Event messages are primarily used to carry events triggered on WO.Event messages are primarily used to carry events triggered on
the Widex Renderer side so that they can be caught by the the Widex Renderer side so that they can be caught by the
application logic event handlers on the Widex Server side. Not application logic event handlers on the Widex Server side. Not
all events need to be forwarded to the application logic, as some all events need to be forwarded to the application logic, as some
events are have local scope and may be intended for default event events have local scope and may be intended for default event
handlers or for local scripted event handlers. The application handlers or for local scripted event handlers. The application
logic in the Widex Server may only be interested in specific logic in the Widex Server may only be interested in specific
events. events.
WO.Event messages may carry data according to the type of the WO.Event messages may carry data according to the type of the
event, e.g. application defined events with structured payloads as event, e.g. application defined events with structured payloads as
per Extensible Multi-Modal Annotations [EMMA], which uses XML for per Extensible Multi-Modal Annotations [W3C.WD-emma-20050916],
annotated interpretations of user input. which uses XML for annotated interpretations of user input.
A secondary use of WO.Event messages is where the application A secondary use of WO.Event messages is where the application
logic itself raises events that may be caught by event handlers logic itself raises events that may be caught by event handlers
associated with the remote user interface, see for example Web associated with the remote user interface, see for example Web
Applications 1.0 [WhatWG.WebApps1.0]. Applications 1.0 [WhatWG.WebApps1.0].
3.4. Transport Protocol 3.5. Transport Protocol
The Transport Protocol is a protocol that just transports the WOs as The Transport Protocol is a protocol that just transports the Widex
a string of bits, without looking at them. Objects as a string of bits, without looking at them.
3.5. Simple vs. Complex User Interfaces 3.6. Simple vs. Complex User Interfaces
Simple User Interface: Simple User Interface:
A simple user interface allows the user interface to be A simple user interface allows the user interface to be
represented with only one XML DOM object. 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: Complex User Interface:
A complex user interface may include scripted client-side event A complex user interface may include scripted client-side event
handlers or there can be more than one XML DOM in the user handlers or there can be more than one XML DOM in the user
interface, e.g. different DOMs for different modalities, but see interface, e.g. different DOMs for different modalities, but see
also SVG's XML Binding Language [sXBL] for the role of shadow also SVG's XML Binding Language [W3C.WD-sXBL-20050815] for the
DOMs. role of shadow DOMs.
3.6. Session 3.7. Session
The Widex Session is initiated between a Widex Server and a Widex The Widex Session is initiated between a Widex Server and a Widex
Renderer for exchanging information about user interface updates and Renderer for exchanging information about user interface updates
events in order to control applications remotely. A Widex Session (e.g. WO.Update) and events (e.g. WO.Event) in order to control
relate to a single User Interface, which can be simple or complex. 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.
**************
* 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 4. Requirements
5.1. Architecture Requirements 4.1. Architecture Requirements
o The framework MUST be modular, e.g. multiple session setup o The framework MUST be modular, e.g. multiple service discovery and
mechanisms may be used. session setup mechanisms may be used.
o The synchronisation MUST occur at a fairly loose level that allows o The synchronisation MUST occur at a fairly loose level that allows
for a simple approach to propagating changes. for a simple approach to propagating changes.
o The framework and the synchronisation protocol SHOULD be o The framework and the synchronisation protocol SHOULD be
stateless. stateless.
o The framework SHOULD be consistent with the W3C Multimodal o The framework SHOULD be consistent with the W3C Multimodal
Architecture [MMI.Arch]. Architecture [W3C.WD-mmi-arch-20060414].
5.2. Discovery and Session Setup Requirements 4.2. Service Discovery and Session Setup Requirements
o The service discovery mechanism MUST be able to discover both o The service discovery mechanism MUST be able to discover both
Widex Renderers and Widex Servers. Widex Renderers and Widex Servers.
o The service discovery mechanism MUST be able to negotiate the o The service discovery mechanism MUST be able to negotiate the
capabilities of both Widex Renderers and Widex Servers, e.g. capabilities of both Widex Renderers and Widex Servers, e.g.
supported devices physical characteristics, supported markup supported devices physical characteristics, supported markup
languages, etc. languages, etc.
o The session setup mechanism MUST be able to initiate session o The session setup mechanism MUST be able to initiate session
establishment from both Widex Renderers and Widex Servers, e.g. establishment from both Widex Renderers and Widex Servers, e.g.
remote user interface pull and push. remote user interface pull and push.
5.3. Widex Objects Requirements 4.3. Widex Objects Requirements
o The WOs MUST NOT be aware of the semantics of the UI markup o The Widex Objects MUST NOT be aware of the semantics of the UI
language that is synchronized. markup language that is synchronized.
o The WOs MUST support client initiated updates. o The Widex Objects MUST support client initiated updates.
o The WOs MUST support server initiated updates. o The Widex Objects MUST support server initiated updates.
o The WOs MUST contain only information having remote scope. o The Widex Objects MUST contain only information meaningful in the
o The WOs MUST indicate the target XML DOM tree when Complex User context of the Widex Session.
Interfaces are involved. o The Widex Objects MUST indicate the target XML DOM tree when
Complex User Interfaces are involved.
o The Widex Objects MAY support multimodal interaction, and it is
the responsibility of the application to synchronise modalities
and not that of the Widex protocol.
o The WOs MAY support multiple modes of interaction, and it is the 4.4. Transport Requirements
responsibility of the application to synchronise modalities and
not that of the Widex protocol.
5.4. Transport Requirements o The Widex protocol MUST deliver Widex 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-ordination between several Widex Sessions in a Widex Server
is outside the scope of this document.
o The Widex protocol MUST deliver WOs in the order determined by the o The Widex protocol MUST handle each modality within the context of
originator regardless of the underlying network topology. The a single Widex Session.
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 o The Widex protocol MUST provide reliable delivery of messages. If
this proves to be impractical in a given situation, the protocol this proves to be impractical in a given situation, the protocol
MUST provide the means for application to detect such failures. MUST provide the means for application to detect such failures.
o The Widex protocol MUST tolerate limitations in available o The Widex protocol MUST tolerate limitations in available
bandwidth. bandwidth.
o The Widex protocol MUST tolerate delays caused by network induced o The Widex protocol MUST tolerate delays caused by network induced
latency. Latency and time-outs may need to be handled at the latency. Latency and time-outs may need to be handled at the
application level. application level.
o The Widex protocol MUST have support for authentication and secure o The Widex protocol MUST have support for authentication and secure
sessions, e.g. data privacy and integrity. sessions, e.g. data privacy and integrity.
6. IANA Considerations 5. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
7. Security Considerations 6. Security Considerations
As a means to support remote user interfaces, a number of security As a means to support remote user interfaces, a number of security
considerations need to be addressed, including the potential for considerations need to be addressed, including the potential for
unauthorized access to application services, monitoring of unauthorized access to application services, monitoring of
interactions by unauthorized third parties, spoofing of application interactions by unauthorized third parties, spoofing of application
services as a means to support phishing attacks, and denial of services as a means to support phishing attacks, and denial of
service attacks. Requirements defined in this document MUST allow service attacks. Requirements defined in this document MUST allow
for the implementation according to best common practices. for the implementation according to best common practices.
8. Acknowledgements 6.1. Privacy Considerations
The authors would like to thank Juha Wiljakka for good input and Exposing the capabilities of Widex Servers and Widex Renderers using
comments that helped writing this document. 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.
9. References 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 Widex Renderer must be discoverable and its should expose
its capabilities so that a Widex Server will be able to provide the
user interface that best matches those capabilities instead of
falling back to the default user interface, which generally leads to
a degraded user experience.
9.1. Normative References In another example, a Widex Server hosting sensitive applications
that are only visible by selected set users must protect the privacy
of the applications during discovery phase so that unauthorised users
are not even able to discover the existence of the application before
being prevented to initiate Widex sessions.
Privacy enforcement MUST allow implementation according to best
common practices of the selected service discovery and session setup
mechanism.
7. Acknowledgements
The authors would like to thank Lisa Dusseault for her comments that
made this document more readable.
8. References
8.1. Normative References
[DOM2.Core] [DOM2.Core]
Le Hors, A., Le Hegaret, P., Wood, L., Nicol, G., Robie, Le Hors, A., Le Hegaret, P., Wood, L., Nicol, G., Robie,
J., Champion, M., and S. Byrne, "Document Object Model J., Champion, M., and S. Byrne, "Document Object Model
(DOM) Level 2 Core Specification", W3C Recommendation, (DOM) Level 2 Core Specification", W3C Recommendation,
November 2000. November 2000.
[DOM2.Events] [DOM2.Events]
Pixley, T., "Document Object Model (DOM) Level 2 Events Pixley, T., "Document Object Model (DOM) Level 2 Events
Specification", W3C Recommendation, November 2000. Specification", W3C Recommendation, November 2000.
skipping to change at page 12, line 34 skipping to change at page 9, line 5
J., and S. Byrne, "Document Object Model (DOM) Level 3 J., and S. Byrne, "Document Object Model (DOM) Level 3
Core Specification", W3C Recommendation, April 2004. Core Specification", W3C Recommendation, April 2004.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[XML1.0] Yergeau, F., Bray, T., Paoli, J., Sperberg-McQueen, C., [XML1.0] Yergeau, F., Bray, T., Paoli, J., Sperberg-McQueen, C.,
and E. Maler, "Extensible Markup Language (XML) 1.0 (Third and E. Maler, "Extensible Markup Language (XML) 1.0 (Third
Edition)", W3C Recommendation, February 2004. Edition)", W3C Recommendation, February 2004.
9.2. Informative References 8.2. Informative References
[EMMA] Johnston, M., Chou, W., Dahl, D., McCobb, G., and D.
Raggett, "Extensible Multi-Modal Annotations (EMMA)",
W3C Last Call Working Draft, September 2005.
[MMI.Arch]
Barnett, J., "Multimodal Architecture and Interfaces",
W3C Working Draft, April 2005.
[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. [W3C.NOTE-mmi-framework-20030506]
Castro, "Application Aspects of IPv6 Transition", Raman, T., Larson, J., and D. Raggett, "W3C Multimodal
RFC 4038, March 2005. Interaction Framework", World Wide Web Consortium
NOTE NOTE-mmi-framework-20030506, May 2003,
<http://www.w3.org/TR/2003/NOTE-mmi-framework-20030506>.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms [W3C.WD-emma-20050916]
for IPv6 Hosts and Routers", RFC 4213, October 2005. Dahl, D., Chou, W., Johnston, M., Raggett, D., and G.
McCobb, "EMMA: Extensible MultiModal Annotation markup
language", World Wide Web Consortium LastCall WD-emma-
20050916, September 2005,
<http://www.w3.org/TR/2005/WD-emma-20050916>.
[RFC4214] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, [W3C.WD-mmi-arch-20060414]
"Intra-Site Automatic Tunnel Addressing Protocol Bodell, M., Wahbe, A., Raggett, D., and J. Barnett,
(ISATAP)", RFC 4214, October 2005. "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>.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through [W3C.WD-sXBL-20050815]
Network Address Translations (NATs)", RFC 4380, Ferraiolo, J., Hickson, I., and D. Hyatt, "SVG's XML
February 2006. Binding Language (sXBL)", World Wide Web Consortium WD WD-
sXBL-20050815, August 2005,
<http://www.w3.org/TR/2005/WD-sXBL-20050815>.
[WhatWG.WebApps1.0] [WhatWG.WebApps1.0]
Hickson, I., "Web Applications 1.0", October 2005. 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 Authors' Addresses
Vlad Stirbu Vlad Stirbu
Nokia Nokia
Visiokatu 3 Visiokatu 3
Tampere 33720 Tampere 33720
Finland Finland
Phone: +358 7180 08000 Phone: +358 7180 08000
Email: vlad.stibu@nokia.com Email: vlad.stibu@nokia.com
 End of changes. 49 change blocks. 
284 lines changed or deleted 151 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/