[Widex] Working group last call (WGLC) for Requirements: draft-ietf-widex-requirements-01.txt (review)

        Hi,
        As a reader of this list, and an enthusiast of everything 
related with technology and its applications (such as the evolving 
Remote UI), I've been looking at the Widex evolution since the initial 
draft, and I compiled a small list of comments concerning this newly 
released Widex Requirements document. I hope my comments may be useful 
to everybody interested. Next, there are some points I felt that may 
potentially be misunderstood:
        At the second section (section 2, "Widex Entities"), there is a 
description about a lot of complex interactions among Widex Server 
instances and Widex Renderers. We can correctly understand that there is 
a component relationship [1:1] between the Widex Server and the User 
Interface (that, by its way, relates with the application logic), and a 
relation [1:m] (1 to many), where for each Widex Server instance, there 
are some Widex Renderer related instances. By reading this paragraph, 
one can see that may be missing a little something about Widex Renderers 
and User Interfaces, and it would be: 1) something really missing, and 
maybe the Widex requirements now hasn't been worrying so much about it, 
and this will be pretty specified in the framework. or 2) it is a open 
question, it will be put in the hands of implementors. But, this is a 
very important concern, because there are a lot of UI mappings (such as 
session IDs, timestamps for UI events, UI component/widgets IDs, etc.), 
which should be considered on remote UI framework models (e.g., 
synchronizing the UI Model state between the UI application and Widex 
Renderer). Below, the part of the draft I got this:

/--- ( Widex Requirements snippet start) ---
//
2.  Widex Entities
(...)
   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.
--- ( Widex Requirements snippet finish) ---/

    I observed yet that there are explanations using the term "device", 
which couldn't be interpreted as a "distributed/networked device", as it 
really is meaning:

/--- ( Widex Requirements snippet start) ---
//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.

--- ( Widex Requirements snippet finish) ---/

    The next thing I had noted was in the section 3.3, "Widex Objects": 
RUI (Remote UI Objects) are not defined anymore in this draft, it was 
changed to Widex Objects (WO). You can see this typo below:

/--- ( Widex Requirements snippet start) ---

//3.3.  Widex Objects

 (...)

   There are two types of WOs:

   WO Update (*RUI*.Update):
      *WO*.Update messages contain description of changes to XML DOM
      trees.  The updates can target individual nodes in order to update

--- ( Widex Requirements snippet finish) ---/

    The next section, 3.4, has two concerns: the first one is the typo 
that refers to a "RUIO" (Remote UI Object), when it should be "WO" 
(Widex Object); second aspect in this paragraph is the description of 
the transport protocol as a component that transports WOs as a "string 
of bits, without looking at them": this would mean that the protocol 
must to send the WOs through the network transport layer using some kind 
of data serialization, which will get the original XML-based data for 
all the UI events and updates, and create a binary representation of 
them before sending/receiving. But I am just guessing. And I hadn't 
understood the requisite that says that WO data must to be transported 
using this protocol, and it cannot "look at them" ("them" referring to 
the WO data):

/--- ( Widex Requirements snippet start) ---/
/3.4.  Transport Protocol

   The Transport Protocol is a protocol that just transports the *RUI*Os
   as a string of bits, without looking at them.
//--- ( Widex Requirements snippet //finish //) ---/

       There are 3 NAT traversal scenarios described in the draft, but 
since there is a item at section 5.3 ("The WOs MUST support server 
initiated updates"), this creates a new need, since we complain with the 
rule that says: "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" (section 5.2, "Session Setup"). Since Widex 
Session Setup can establish a session from both Renderers and Servers, I 
can see a scenario where a Widex Server must to establish a session, and 
send some kind of UI model (WO update) to the Renderer located in a 
public network, them it should guess about some kind of NAT traversal to 
allow a proper interaction between Renderer and Server. For example, a 
remote user interface push to the Renderer in a public network, and a 
Server that works in a private network enviroment, like a house; the 
Server providing instantaneous security images from user's home, let's 
suppose. So, I guess is missing the case when the Widex Server is 
located inside a private network.

/--- ( Widex Requirements snippet //start // ) ---/
/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/
/--- ( Widex Requirements snippet //finish // ) ---/

    At a first sight, the first item of the section 5.3 is not clear 
enough: we can think in the "semantics" term, the "markup" concept is 
very clear too, but I couldn't relate these 2 words with the last word 
of this item, "synchronized": one cannot make assumptions with 
"semantincs synchronized", nor "markup synchronized", but maybe this 
ought to really means that "the WOs MUST NOT be aware of the semantics 
of the markup language that describes its event and update messages, 
which is one of the attributes negotiated at the Widex Session 
instantiation". I could see this only after some readings in the draft:

/--- ( Widex Requirements snippet start) ---/
/5.3.  Widex Objects Requirements

   o  The WOs MUST NOT be aware of the *semantics of the markup that is
      synchronized.*
/
/--- ( Widex Requirements snippet finish) ---/

    I hope that it had been well explained (I tried!). Let me see if you 
found something useful in my explanation...

Regards,
Rosfran Borges

_______________________________________________
Widex mailing list
Widex@ietf.org
https://www1.ietf.org/mailman/listinfo/widex