WIDEX                                                          V. Stirbu
Internet-Draft                                                     Nokia
Expires: July 16, 2006
Intended status: Informational                                D. Raggett
                                                               W3C/Canon
                                                        January 12,
Expires: October 13, 2006                                   W3C/Volantis
                                                          April 11, 2006

        Widget Description Exchange Service (WIDEX) Requirements
                    draft-ietf-widex-requirements-00
                    draft-ietf-widex-requirements-01

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 July 16, October 13, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document defines functional requirements for a framework and a
   protocol used to support XML-based user interfaces, where the user
   interface and application logic may be on different machines, and
   coupled via an exchange of XML DOM events and update/mutation
   operations.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4

   2.  Widex Entities . . . . . . . . . . . . . . . . . . . . . . . .  4

   3.  Widex Terminology  . . . . . . . . . . . . . . . . . . . . . .  4
     3.1.  User Interface . . . . . . . . . . . . . . . . . . . . . .  4
     3.2.  Remote User Interface  . . . . . . . . . . . . . . . . . .  5
     3.3.  Remote User Interface  Widex Objects  . . . . . . . . . . . . . . . . . . . . . .  5
     3.4.  Transport Protocol . . . . . . . . . . . . . . . . . . . .  6
     3.5.  Simple vs. Complex User Interfaces . . . . . . . . . . . .  6
     3.6.  Session  . . . . . . . . . . . . . . . . . . . . . . . . .  6

   4.  Scenarios and Explanatory Discussion . . . . . . . . . . . . .  6
     4.1.  NAT Traversal  . . . . . . . . . . . . . . . . . . . . . .  6
       4.1.1.  Scenario 1: Widex Server and Renderer Located in
               Internet . . . . . . . . . . . . . . . . . . . . . . .  6
       4.1.2.  Scenario 2: Widex Server Located in Internet . . . . .  7
       4.1.3.  Scenario 3: Widex Renderer and Server in the Same
               Network  . . . . . . . . . . . . . . . . . . . . . . .  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.1.  Architecture Requirements  . . . . . . . . . . . . . . . . 10
     5.2.  Discovery and Session Setup Requirements . . . . . . . . . 10
     5.3.  Remote UI  Widex Objects Requirements . . . . . . . . . . . . . . . . 10
     5.4.  Transport Requirements . . . . . . . . . . . . . . . . . . 11

   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11

   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11

   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 12
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 11 12
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 12

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
   Intellectual Property and Copyright Statements . . . . . . . . . . 13 14

1.  Introduction

   With the Internet reaching out to more and more devices, people are
   increasingly expecting to have access to services at anytime, from
   anywhere and using any device.  Such services are being developed
   using Web technologies such as XML and distributed across the network
   rather than resident on any one device.

2.  Widex Entities

   The following picture shows the primary Widex entities in a simple
   and basic architecture.

                    +--------+                  +--------+
                    |        | update interface |        |
                    | Widex  |----------------->| Widex  |
                    | Server |<-----------------|Renderer|
                    |        | event interface  |        |
                    +--------+                  +--------+

                         Figure 1: Widex Entities

   The two primary Entities are described as follows:

   Widex Server (WS):
      The entity that holds the application logic.

   Widex Renderer (WR):
      The entity that renders the user interface.

   There might be several Widex Servers in the same device, one for each
   application that can export the user interface and for each Widex
   server there might be several Widex Renderers which are rendering the
   user interface.

3.  Widex Terminology

   The terminology and definitions detailed below include both terms
   that, besides the Widex entities are used in the requirements section
   of this document.

3.1.  User Interface

   In the context of Widex working group, the user interface is
   understood as XML [XML1.0] data describing the user interface.
   Typically, the XML data is manipulated as levels 2 and 3 in the W3C
   Document Object Model (DOM), see [DOM2.Core], [DOM3.Core], and
   [DOM2.Events] (W3C has yet to complete work on DOM3 events).  Style
   information associated with the user interface can be manipulated via
   the DOM, see [DOM2.Style].

3.2.  Remote User Interface

   The Remote User Interface (RUI) is a technique in which a user
   interface is rendered on another device than the one that runs the
   application logic while keeping the user interface synchronised with
   the application logic.

3.3.  Remote User Interface  Widex Objects

   One of the goals of the Widex working group is to define Remote User
   Interface Widex
   Objects (RUIO), (WO), to be used to convey information about interface
   updates and events.  RUIOs  WOs are used to keep the rendered user interface
   synchronised with the application logic.

   There are two types of RUIOs:

   RUIO WOs:

   WO Update (RUI.Update):
      RUI.Update
      WO.Update messages contain description of changes to XML DOM
      trees.  The updates can target individual nodes in order to update
      their properties and attributes, or can target parts of the DOM
      tree in order change its structure, e.g. add/delete/replace nodes
      or branches.

   RUIO

   WO Event (RUI.Event):
      RUI.Event (WO.Event):
      WO.Event messages are primarily used to carry events triggered on
      the Widex Renderer side so that they can be caught by the
      application logic event handlers on the Widex Server side.  Not
      all events need to be forwarded to the application logic, as some
      events are have local scope and may be intended for default event
      handlers or for local scripted event handlers.  The application
      logic in the Widex Server may only be interested in specific
      events.

      RUI.Event

      WO.Event messages may carry data according to the type of the
      event, e.g. application defined events with structured payloads as
      per Extensible Multi-Modal Annotations [EMMA], which uses XML for
      annotated interpretations of user input.

      A secondary use of RUI.Event WO.Event messages is where the application
      logic itself raises events that may be caught by event handlers
      associated with the remote user interface, see for example Web
      Applications 1.0 [WhatWG.WebApps1.0].

3.4.  Transport Protocol

   The Transport Protocol is a protocol that just transports the RUIOs
   as a string of bits, without looking at them.

3.5.  Simple vs. Complex User Interfaces

   Simple User Interface:
      A simple user interface allows the user interface to be
      represented with only one XML DOM object.

   Complex User Interface:
      A complex user interface may include scripted client-side event
      handlers or there can be more than one XML DOM in the user
      interface, e.g. different DOMs for different modalities, but see
      also SVG's XML Binding Language [sXBL] for the role of shadow
      DOMs.

3.6.  Session

   The Widex Session is initiated between a Widex Servers and a Widex
   Renderer for exchanging information about user interface updates and
   events in order to control 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.

                               **************
                              *  Private   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.  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 [I-D.huitema-v6ops-teredo] [RFC4380] MAY be used by the intermediate nodes
   or by the nodes hosting the Widex Elements to tunnel the IPv6 traffic
   over the IPv4-only segment.

4.2.3.  IPv4-Only Widex Element communicating with an IPv6-Only Widex
        Element

    +---------+                                              +---------+
    |  Widex  |                                              |  Widex  |
    | Element |   ***********   +----------+   ***********   | Element |
    +---------+  *           *  | Protocol |  *           *  +---------+
    |IPv4-only|--* IPv4-only *--|Translator|--* IPv6-only *--|IPv6-only|
    +---------+  *           *  |   /ALG   |  *           *  +---------+
                  ***********   +----------+   ***********

         Figure 7: IPv4-Only WE communicating with an IPv6-Only WE

   Protocol translation / Application Level Gateway (ALG) functionality
   is necessary in the network in order to enable the communication
   between an IPv4-only Widex Element with an IPv6-only Widex Element.

   This is not a typical case as the assumption is that IPv6-only nodes
   will not be common in the near future.

4.2.4.  Application Aspects of IPv6 Transition

   Application developers, implementing the Widex framework and
   services, which want to enable IPv6 support in implementations
   running on IPv6 hosts or want to develop IP version-independent
   implementations SHOULD consider recommendations written in RFC 4038
   [RFC4038].

5.  Requirements

5.1.  Architecture Requirements

   o  The framework MUST be modular, e.g. multiple session setup
      mechanisms may be used.
   o  The synchronisation MUST occur at a fairly loose level that allows
      for a simple approach to propagating changes.
   o  The framework and the synchronisation protocol SHOULD be
      stateless.
   o  The framework SHOULD be consistent with the W3C Multimodal
      Architecture [MMI.Arch].

5.2.  Discovery and Session Setup Requirements

   o  The service discovery mechanism MUST be able to discover both
      Widex Renderers and Widex Servers.
   o  The service discovery mechanism MUST be able to negotiate the
      capabilities of both Widex Renderers and Widex Servers, e.g.
      supported devices physical characteristics, supported markup
      languages, etc.
   o  The session setup mechanism MUST be able to establish sessions
      from both Widex Renderers and Widex Servers, e.g. remote user
      interface pull and push.

5.3.  Remote UI  Widex Objects Requirements

   o  The RUIOs WOs MUST NOT be aware of the semantics of the markup that is
      synchronized.
   o  The RUIOs WOs MUST support client initiated updates.
   o  The RUIOs WOs MUST support server initiated updates.
   o  The RUIOs WOs MUST contain only information having remote scope.
   o  The WOs MUST indicate the target XML DOM tree when Complex User
      Interfaces are involved.

   o  The RUIOs WOs MAY support multiple modes of interaction, and it is the
      responsibility of the application to synchronise modalities and
      not that of the Widex protocol.

5.4.  Transport Requirements

   o  The Widex protocol MUST deliver RUIOs WOs 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 provide reliable delivery of messages.  If
      this proves to be impractical in a given situation, the protocol
      MUST provide the means for application to detect such failures.
   o  The Widex protocol MUST tolerate limitations in available
      bandwidth.
   o  The Widex protocol MUST tolerate delays caused by network induced
      latency.  Latency and time-outs may need to be handled at the
      application level.
   o  The Widex protocol MUST have support for authentication and secure
      sessions, e.g. data privacy and integrity.

6.  IANA Considerations

   This document makes no request of IANA.

7.  Security Considerations

   As a means to support remote user interfaces, a number of security
   considerations need to be addressed, including the potential for
   unauthorized access to application services, monitoring of
   interactions by unauthorized third parties, spoofing of application
   services as a means to support phishing attacks, and denial of
   service attacks.  Requirements defined in this document MUST allow
   for the implementation according to best common practices.

8.  Acknowledgements

   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.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [XML1.0]   Yergeau, F., Bray, T., Paoli, J., Sperberg-McQueen, C.,
              and E. Maler, "Extensible Markup Language (XML) 1.0 (Third
              Edition)", W3C Recommendation, February 2004.

9.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.

   [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]
              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.
              Castro, "Application Aspects of IPv6 Transition",
              RFC 4038, March 2005.

   [RFC4213]  Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
              for IPv6 Hosts and Routers", RFC 4213, October 2005.

   [RFC4214]  Templin, F., Gleeson, T., Talwar, M., and D. Thaler,
              "Intra-Site Automatic Tunnel Addressing Protocol
              (ISATAP)", RFC 4214, October 2005.

   [RFC4380]  Huitema, C., "Teredo: Tunneling IPv6 over UDP through
              Network Address Translations (NATs)", RFC 4380,
              February 2006.

   [WhatWG.WebApps1.0]
              Hickson, I., "Web Applications 1.0", October 2005.

   [sXBL]     Ferraiolo, J., Hickson, I., and D. Hyatt, "SVG's XML
              Binding Language (sXBL)", W3C Working Draft, August 2005.

Authors' Addresses

   Vlad Stirbu
   Nokia
   Visiokatu 3
   Tampere  33720
   Finland

   Phone: +358 7180 08000
   Email: vlad.stibu@nokia.com

   Dave Raggett
   W3C/Canon
   W3C/Volantis
   35 Frome Road
   Bradford on Avon, Wiltshire  BA15 2EA
   United Kingdom

   Phone: +44 1225 866240
   Email: dsr@w3.org

Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society. IETF
   Administrative Support Activity (IASA).