WIDEX                                                          V. Stirbu
Internet-Draft                                                     Nokia
Intended status: Informational                                D. Raggett
Expires: November 15, 2006 April 1, 2007                                      W3C/Volantis
                                                            May 14,
                                                      September 28, 2006

        Widget Description Exchange Service (WIDEX) Requirements
                    draft-ietf-widex-requirements-02
                    draft-ietf-widex-requirements-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 November 15, 2006. April 1, 2007.

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  3

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

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

   4.  Scenarios and Explanatory Discussion . . . . . . . .  5
     3.7.  Session  . . . . .  6
     4.1.  NAT Traversal . . . . . . . . . . . . . . . . . . . .  5

   4.  Requirements . .  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  . . . . . . .
     4.1.  Architecture Requirements  . . . . . . . . . . . . . . . .  7  6
     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 . . . . . . . . . . . . .  Service Discovery and Session Setup Requirements . . . . .  9
       4.2.3.  IPv4-Only Widex Element communicating with an
               IPv6-Only  6
     4.3.  Widex Element  . . . . . . . Objects Requirements . . . . . . . .  9
       4.2.4.  Application Aspects of IPv6 Transition . . . . . . . . 10

   5.  6
     4.4.  Transport Requirements . . . . . . . . . . . . . . . . . .  6

   5.  IANA Considerations  . . . . . . . 10
     5.1.  Architecture Requirements  . . . . . . . . . . . . . . . . 10
     5.2.  Discovery and Session Setup Requirements .  7

   6.  Security Considerations  . . . . . . . . 10
     5.3.  Widex Objects Requirements . . . . . . . . . . .  7
     6.1.  Privacy Considerations . . . . . 10
     5.4.  Transport Requirements . . . . . . . . . . . . .  7

   7.  Acknowledgements . . . . . 11

   6.  IANA Considerations . . . . . . . . . . . . . . . . . .  8

   8.  References . . . 11

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

   8.  Acknowledgements . . . .  8
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
   9.  8
     8.2.  Informative References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     9.1.  Normative References . . .  9

   Authors' Addresses . . . . . . . . . . . . . . . . 12
     9.2.  Informative References . . . . . . . .  9
   Intellectual Property and Copyright Statements . . . . . . . . . . 12

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

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
   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 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.  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
   Objects (WO), to be used to convey information about interface
   updates and events.  WOs  Widex Objects are used to keep the rendered user
   interface synchronised with the application logic.

   There are two types of WOs: Widex Objects:

   WO Update (WO.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.

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

      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], [W3C.WD-emma-20050916],
      which uses XML for annotated interpretations of user input.

      A secondary use of 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.

3.5.  Transport Protocol

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

3.5.

3.6.  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.  Typically, a simple
      user interface is associated with a single modality, e.g. vision
      modality for graphic user interfaces.

   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] [W3C.WD-sXBL-20050815] for the
      role of shadow DOMs.

3.6.

3.7.  Session

   The Widex Session is initiated between a Widex Server and a Widex
   Renderer for exchanging information about user interface updates
   (e.g.  WO.Update) and events (e.g.  WO.Event) in order to control
   applications remotely.  A Widex Session relate to a single User
   Interface, which can be simple or complex.

4.  Scenarios  Requirements

4.1.  Architecture Requirements

   o  The framework MUST be modular, e.g. multiple service discovery and Explanatory Discussion

   In this section we introduce short scenarios to illustrate how Widex
   services can
      session setup mechanisms may be deployed in some environments.

4.1.  NAT Traversal

   In 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 following sections we will describe some of synchronisation protocol SHOULD be
      stateless.
   o  The framework SHOULD be consistent with the common
   scenarios involving Widex Elements and NAT traversal.

4.1.1.  Scenario 1: Widex Server W3C Multimodal
      Architecture [W3C.WD-mmi-arch-20060414].

4.2.  Service Discovery and Renderer Located in Internet

   In this scenario Session Setup Requirements

   o  The service discovery mechanism MUST be able to discover both the Server
      Widex Renderers and Renderer are located somewhere
   in Widex Servers.
   o  The service discovery mechanism MUST be able to negotiate the Internet and are globally accessible via public IP addresses
   and/or Fully Qualified Domain Name (FQDN).

                               **************
                  +--------+  *  Public      *  +--------+
                  |
      capabilities of both 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

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 Renderers and Widex Servers, e.g.
      supported devices physical characteristics, supported markup
      languages, etc.
   o  The session setup mechanism MUST be able to initiate session
      establishment from both Widex Renderers and Widex Servers, e.g.
      remote user interface pull and push.

5.3.

4.3.  Widex Objects Requirements

   o  The WOs Widex Objects MUST NOT be aware of the semantics of the UI
      markup language that is synchronized.
   o  The WOs Widex Objects MUST support client initiated updates.
   o  The WOs Widex Objects MUST support server initiated updates.
   o  The WOs Widex Objects MUST contain only information having remote scope. meaningful in the
      context of the Widex Session.
   o  The WOs Widex Objects MUST indicate the target XML DOM tree when
      Complex User Interfaces are involved.
   o  The WOs Widex Objects MAY support multiple modes of multimodal interaction, and it is
      the responsibility of the application to synchronise modalities
      and not that of the Widex protocol.

5.4.

4.4.  Transport Requirements

   o  The Widex protocol MUST deliver WOs 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 co-ordination between several Widex Sessions in a Widex Server
      is outside the scope of this document.

   o  The Widex protocol MUST handle each modality within the context of
      a single Widex Session.
   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 handled at the
      application level.
   o  The Widex protocol MUST have support for authentication and secure
      sessions, e.g. data privacy and integrity.

5.  IANA Considerations

   This document makes no request of IANA.

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

6.1.  Privacy Considerations

   Exposing the capabilities of Widex Servers and Widex Renderers using
   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.

   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
      application level.
   o  The Widex protocol MUST have support for authentication and secure
      sessions, e.g. data privacy Renderer must be discoverable and integrity.

6.  IANA Considerations

   This document makes no request of IANA.

7.  Security Considerations

   As its should expose
   its capabilities so that a means Widex Server will be able to support remote provide the
   user interfaces, a number interface that best matches those capabilities instead of security
   considerations need
   falling back to be addressed, including the potential for
   unauthorized access default user interface, which generally leads to application services, monitoring of
   interactions
   a degraded user experience.

   In another example, a Widex Server hosting sensitive applications
   that are only visible by unauthorized third parties, spoofing selected set users must protect the privacy
   of application
   services as a means the applications during discovery phase so that unauthorised users
   are not even able to support phishing attacks, and denial discover the existence of
   service attacks.  Requirements defined in this document the application before
   being prevented to initiate Widex sessions.

   Privacy enforcement MUST allow
   for the implementation according to best
   common practices.

8. practices of the selected service discovery and session setup
   mechanism.

7.  Acknowledgements

   The authors would like to thank Juha Wiljakka Lisa Dusseault for good input and her comments that helped writing
   made this document.

9. document more readable.

8.  References

9.1.

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

8.2.  Informative References

   [EMMA]     Johnston, M.,

   [W3C.NOTE-mmi-framework-20030506]
              Raman, T., Larson, J., and D. Raggett, "W3C Multimodal
              Interaction Framework", World Wide Web Consortium
              NOTE NOTE-mmi-framework-20030506, May 2003,
              <http://www.w3.org/TR/2003/NOTE-mmi-framework-20030506>.

   [W3C.WD-emma-20050916]
              Dahl, D., Chou, W., Dahl, Johnston, M., Raggett, D., McCobb, G., and D.
              Raggett, "Extensible Multi-Modal Annotations (EMMA)",
              W3C Last Call Working Draft, G.
              McCobb, "EMMA: Extensible MultiModal Annotation markup
              language", World Wide Web Consortium LastCall WD-emma-
              20050916, September 2005.

   [MMI.Arch] 2005,
              <http://www.w3.org/TR/2005/WD-emma-20050916>.

   [W3C.WD-mmi-arch-20060414]
              Bodell, M., Wahbe, A., Raggett, D., and J. 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, World Wide Web
              Consortium WD WD-mmi-arch-20060414, 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] 2006,
              <http://www.w3.org/TR/2006/WD-mmi-arch-20060414>.

   [W3C.WD-sXBL-20050815]
              Ferraiolo, J., Hickson, I., and D. Hyatt, "SVG's XML
              Binding Language (sXBL)", W3C Working Draft, World Wide Web Consortium WD WD-
              sXBL-20050815, August 2005,
              <http://www.w3.org/TR/2005/WD-sXBL-20050815>.

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

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

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