draft-ietf-widex-requirements-00.txt   draft-ietf-widex-requirements-01.txt 
WIDEX V. Stirbu WIDEX V. Stirbu
Internet-Draft Nokia Internet-Draft Nokia
Expires: July 16, 2006 D. Raggett Intended status: Informational D. Raggett
W3C/Canon Expires: October 13, 2006 W3C/Volantis
January 12, 2006 April 11, 2006
Widget Description Exchange Service (WIDEX) Requirements Widget Description Exchange Service (WIDEX) Requirements
draft-ietf-widex-requirements-00 draft-ietf-widex-requirements-01
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 July 16, 2006. This Internet-Draft will expire on October 13, 2006.
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 17 skipping to change at page 2, line 20
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Widex Entities . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Widex Entities . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Widex Terminology . . . . . . . . . . . . . . . . . . . . . . 4 3. Widex Terminology . . . . . . . . . . . . . . . . . . . . . . 4
3.1. User Interface . . . . . . . . . . . . . . . . . . . . . . 4 3.1. User Interface . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Remote User Interface . . . . . . . . . . . . . . . . . . 5 3.2. Remote User Interface . . . . . . . . . . . . . . . . . . 5
3.3. Remote User Interface Objects . . . . . . . . . . . . . . 5 3.3. Widex Objects . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Transport Protocol . . . . . . . . . . . . . . . . . . . . 6 3.4. Transport Protocol . . . . . . . . . . . . . . . . . . . . 6
3.5. Simple vs. Complex User Interfaces . . . . . . . . . . . . 6 3.5. Simple vs. Complex User Interfaces . . . . . . . . . . . . 6
3.6. Session . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.6. Session . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Scenarios and Explanatory Discussion . . . . . . . . . . . . . 6 4. Scenarios and Explanatory Discussion . . . . . . . . . . . . . 6
4.1. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 6 4.1. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 6
4.1.1. Scenario 1: Widex Server and Renderer Located in 4.1.1. Scenario 1: Widex Server and Renderer Located in
Internet . . . . . . . . . . . . . . . . . . . . . . . 6 Internet . . . . . . . . . . . . . . . . . . . . . . . 6
4.1.2. Scenario 2: Widex Server Located in Internet . . . . . 7 4.1.2. Scenario 2: Widex Server Located in Internet . . . . . 7
4.1.3. Scenario 3: Widex Renderer and Server in the Same 4.1.3. Scenario 3: Widex Renderer and Server in the Same
skipping to change at page 2, line 41 skipping to change at page 2, line 44
IPv4-Only Widex Element Using IPv4 . . . . . . . . . . 9 IPv4-Only Widex Element Using IPv4 . . . . . . . . . . 9
4.2.2. Dual-Stack Widex Elements Communicating over IPv4 4.2.2. Dual-Stack Widex Elements Communicating over IPv4
Segment using IPv6 . . . . . . . . . . . . . . . . . . 9 Segment using IPv6 . . . . . . . . . . . . . . . . . . 9
4.2.3. IPv4-Only Widex Element communicating with an 4.2.3. IPv4-Only Widex Element communicating with an
IPv6-Only Widex Element . . . . . . . . . . . . . . . 9 IPv6-Only Widex Element . . . . . . . . . . . . . . . 9
4.2.4. Application Aspects of IPv6 Transition . . . . . . . . 10 4.2.4. Application Aspects of IPv6 Transition . . . . . . . . 10
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Architecture Requirements . . . . . . . . . . . . . . . . 10 5.1. Architecture Requirements . . . . . . . . . . . . . . . . 10
5.2. Discovery and Session Setup Requirements . . . . . . . . . 10 5.2. Discovery and Session Setup Requirements . . . . . . . . . 10
5.3. Remote UI Objects Requirements . . . . . . . . . . . . . . 10 5.3. Widex Objects Requirements . . . . . . . . . . . . . . . . 10
5.4. Transport Requirements . . . . . . . . . . . . . . . . . . 11 5.4. Transport Requirements . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14
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 5, line 16 skipping to change at page 5, line 16
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. Remote User Interface Objects 3.3. Widex Objects
One of the goals of the Widex working group is to define Remote User One of the goals of the Widex working group is to define Widex
Interface Objects (RUIO), to be used to convey information about Objects (WO), to be used to convey information about interface
interface updates and events. RUIOs are used to keep the rendered updates and events. WOs are used to keep the rendered user interface
user interface synchronised with the application logic. synchronised with the application logic.
There are two types of RUIOs: There are two types of WOs:
RUIO Update (RUI.Update): WO Update (RUI.Update):
RUI.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.
RUIO Event (RUI.Event): WO Event (WO.Event):
RUI.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 may be intended for default event handlers or for local events are have local scope and may be intended for default event
scripted event handlers. The application logic in the Widex handlers or for local scripted event handlers. The application
Server may only be interested in specific events. logic in the Widex Server may only be interested in specific
events.
RUI.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 [EMMA], which uses XML for
annotated interpretations of user input. annotated interpretations of user input.
A secondary use of RUI.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.4. Transport Protocol
The Transport Protocol is a protocol that just transports the RUIOs The Transport Protocol is a protocol that just transports the RUIOs
as a string of bits, without looking at them. as a string of bits, without looking at them.
3.5. Simple vs. Complex User Interfaces 3.5. Simple vs. Complex User Interfaces
skipping to change at page 8, line 6 skipping to change at page 8, line 6
************** +--------+ ************** +--------+
Figure 3: Widex Server located in Internet Figure 3: Widex Server located in Internet
4.1.3. Scenario 3: Widex Renderer and Server in the Same Network 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 In this scenario the Server is located behind the same NAT device as
the Renderer. the Renderer.
************** **************
* Private * * Public *
* Network * * Network *
* * * *
************** **************
| |
+--------+ +--------+
| NAT | | NAT |
+--------+ +--------+
| |
************** **************
+--------+ * Local Area * +--------+ +--------+ * Local Area * +--------+
skipping to change at page 9, line 33 skipping to change at page 9, line 33
| Server | *********** *********** *********** | Renderer| | Server | *********** *********** *********** | Renderer|
+---------+ * * * * * * +---------+ +---------+ * * * * * * +---------+
|IPv4/IPv6|--* IPv4/IPv6 *--* IPv4-only *--* IPv4/IPv6 *--|IPv4/IPv6| |IPv4/IPv6|--* IPv4/IPv6 *--* IPv4-only *--* IPv4/IPv6 *--|IPv4/IPv6|
+---------+ * * * * * * +---------+ +---------+ * * * * * * +---------+
*********** *********** *********** *********** *********** ***********
Figure 6: Dual-stack WE communicating over IPv4 segment using IPv6 Figure 6: Dual-stack WE communicating over IPv4 segment using IPv6
When dual-stack Widex Elements communicate using IPv6 over an IPv4- When dual-stack Widex Elements communicate using IPv6 over an IPv4-
only segment, tunneling mechanisms such as 6to4 [RFC3056], ISATAP only segment, tunneling mechanisms such as 6to4 [RFC3056], ISATAP
[RFC4214] or Teredo [I-D.huitema-v6ops-teredo] MAY be used by the [RFC4214] or Teredo [RFC4380] MAY be used by the intermediate nodes
intermediate nodes or by the nodes hosting the Widex Elements to or by the nodes hosting the Widex Elements to tunnel the IPv6 traffic
tunnel the IPv6 traffic over the IPv4-only segment. over the IPv4-only segment.
4.2.3. IPv4-Only Widex Element communicating with an IPv6-Only Widex 4.2.3. IPv4-Only Widex Element communicating with an IPv6-Only Widex
Element Element
+---------+ +---------+ +---------+ +---------+
| Widex | | Widex | | Widex | | Widex |
| Element | *********** +----------+ *********** | Element | | Element | *********** +----------+ *********** | Element |
+---------+ * * | Protocol | * * +---------+ +---------+ * * | Protocol | * * +---------+
|IPv4-only|--* IPv4-only *--|Translator|--* IPv6-only *--|IPv6-only| |IPv4-only|--* IPv4-only *--|Translator|--* IPv6-only *--|IPv6-only|
+---------+ * * | /ALG | * * +---------+ +---------+ * * | /ALG | * * +---------+
skipping to change at page 10, line 41 skipping to change at page 10, line 41
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 establish sessions o The session setup mechanism MUST be able to establish sessions
from both Widex Renderers and Widex Servers, e.g. remote user from both Widex Renderers and Widex Servers, e.g. remote user
interface pull and push. interface pull and push.
5.3. Remote UI Objects Requirements 5.3. Widex Objects Requirements
o The RUIOs MUST NOT be aware of the semantics of the markup that is o The WOs MUST NOT be aware of the semantics of the markup that is
synchronized. synchronized.
o The RUIOs MUST support client initiated updates. o The WOs MUST support client initiated updates.
o The RUIOs MUST support server initiated updates. o The WOs MUST support server initiated updates.
o The RUIOs MUST indicate the target XML DOM tree when Complex User o The WOs MUST contain only information having remote scope.
o The WOs MUST indicate the target XML DOM tree when Complex User
Interfaces are involved. Interfaces are involved.
o The RUIOs MAY support multiple modes of interaction, and it is the
o The WOs MAY support multiple modes of interaction, and it is the
responsibility of the application to synchronise modalities and responsibility of the application to synchronise modalities and
not that of the Widex protocol. not that of the Widex protocol.
5.4. Transport Requirements 5.4. Transport Requirements
o The Widex protocol MUST deliver RUIOs in the order determined by o The Widex protocol MUST deliver WOs in the order determined by the
the originator regardless of the underlying network topology. The originator regardless of the underlying network topology. The
order is relevant within a single Widex Session. The co- order is relevant within a single Widex Session. The co-
ordination between several Widex Sessions in a Widex Server is ordination between several Widex Sessions in a Widex Server is
outside the scope of this document. 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
skipping to change at page 12, line 34 skipping to change at page 12, line 40
[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 9.2. Informative References
[EMMA] Johnston, M., Chou, W., Dahl, D., McCobb, G., and D. [EMMA] Johnston, M., Chou, W., Dahl, D., McCobb, G., and D.
Raggett, "Extensible Multi-Modal Annotations (EMMA)", Raggett, "Extensible Multi-Modal Annotations (EMMA)",
W3C Last Call Working Draft, September 2005. W3C Last Call Working Draft, September 2005.
[I-D.huitema-v6ops-teredo]
Huitema, C., "Teredo: Tunneling IPv6 over UDP through
NATs", draft-huitema-v6ops-teredo-05 (work in progress),
April 2005.
[MMI.Arch] [MMI.Arch]
Barnett, J., "Multimodal Architecture and Interfaces", Barnett, J., "Multimodal Architecture and Interfaces",
W3C Working Draft, April 2005. W3C Working Draft, April 2005.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001. via IPv4 Clouds", RFC 3056, February 2001.
[RFC3574] Soininen, J., "Transition Scenarios for 3GPP Networks", [RFC3574] Soininen, J., "Transition Scenarios for 3GPP Networks",
RFC 3574, August 2003. RFC 3574, August 2003.
skipping to change at page 13, line 16 skipping to change at page 13, line 16
Castro, "Application Aspects of IPv6 Transition", Castro, "Application Aspects of IPv6 Transition",
RFC 4038, March 2005. RFC 4038, March 2005.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005. for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4214] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, [RFC4214] Templin, F., Gleeson, T., Talwar, M., and D. Thaler,
"Intra-Site Automatic Tunnel Addressing Protocol "Intra-Site Automatic Tunnel Addressing Protocol
(ISATAP)", RFC 4214, October 2005. (ISATAP)", RFC 4214, October 2005.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380,
February 2006.
[WhatWG.WebApps1.0] [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 [sXBL] Ferraiolo, J., Hickson, I., and D. Hyatt, "SVG's XML
Binding Language (sXBL)", W3C Working Draft, August 2005. 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
Dave Raggett Dave Raggett
W3C/Canon W3C/Volantis
35 Frome Road 35 Frome Road
Bradford on Avon, Wiltshire BA15 2EA Bradford on Avon, Wiltshire BA15 2EA
United Kingdom United Kingdom
Phone: +44 1225 866240 Phone: +44 1225 866240
Email: dsr@w3.org Email: dsr@w3.org
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
skipping to change at page 14, line 39 skipping to change at page 14, line 47
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 26 change blocks. 
44 lines changed or deleted 45 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/