[Widex] Updated Widex Requirements draft following WGLC comments

Hi,

We have updated the Widex requirements draft taking into account the
comments received so far on the mailing list. The draft will be
available shortly in the IETF draft repository but until then you can
find it here:
http://www.kolumbus.fi/vlad.stirbu/draft-ietf-widex-requirements-02.txt.

The authors would like to ask the working group if we appropriately
answered to comments so that we can finalize the WGLC and move to the
next step?

Regards,
Vlad

------------------------------------------------------------------------
-

Comments from Rosfran Borges
http://www1.ietf.org/mail-archive/web/widex/current/msg00093.html:

Rosfran:

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

Vlad:

I think that the relationship between the Widex Renderer and the User
Interface is clarified by the definition of the Widex Session (section
3.6).

Rosfran:

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: 

Vlad:

The term "device" refers to a physical device attached to the internet,
so having at least one network interface. In the context of this draft
the term device with this meaning is used first in the Introduction
(section 1)

Rosfran:

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

Vlad:

WOs already contain serialized data and the transport protocol must
carry these object without having to understand their meaning.

Rosfran:

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. 

Vlad:

There are two aspects in this comment: the first one related to session
establishment and the second related to NAT traversal.

Firstly, the meaning of this requirement is that the Session Setup
component can initiate the session from both Widex Server and Widex
renderer, it doesn't necessarily mean that the actual session should be
established from the Server to the Renderer. I have reworded the
requirement to include the above mentioned clarification.

Secondly, Widex Servers located in private networks are not directly
reachable from the internet without some special procedures being
performed by the network administrator (e.g. creating some port mappings
in the NAT/gateway device). These procedures are generic and they should
be performed also for non-Widex specific servers and in the end the
server is reachable via the public IP address of the NAT/gateway device
making this scenario equivalent with Scenario 1 (section 4.1.1) or
Scenario 2 (section 4.1.2).

Rosfran:

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

Vlad:

Well, the meaning here is that events and updates are just the means to
perform the synchronization but in order to do the sync you don't have
to understand what you are synchronizing as long as the UI markup
language is manipulated as XML DOM.

Comments from Jin Yu
http://www1.ietf.org/mail-archive/web/widex/current/msg00094.html:

Jin's comment on Event selection and efficient event delivery

Vlad:

We consider that this is an implementation option and we don't need to
have a special requirement for this further than the one already listed
in the draft (section 5.3): "The WOs MUST contain only information
having remote scope.". Dave mentioned several implementation options in
his reply
http://www1.ietf.org/mail-archive/web/widex/current/msg00095.html, and
we need to consider which is the most appropriate one in the Widex
Framework draft
(http://www.ietf.org/internet-drafts/draft-stirbu-widex-framework-00.txt
), for example.

Jin's comment on "UI State Synchronization"

Vlad:

We consider that the figure in section 2 describes the minimal set of
interactions performed in order to export the UI from the Widex Server
to the Widex Renderer. At this point we are not making any assumptions
on the nature of the messages exchanged over these interfaces. A more
elaborate diagram showing the messages exchanged between the WS and WR
is described in the Widex Framework draft, but there we are discussing
an implementation option.