Re: [Widex] Updated Widex Requirements draft following WGLC comments

[Rosfran Lins Borges <[e-mail]>]

       All comments I sent were properly answered, no questions for now.


Regards,
Rosfran Borges

ext [e-mail] wrote:

> 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.
>
>
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Widex mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/widex
>  
>


_______________________________________________
Widex mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/widex