From widex-bounces@ietf.org Mon May 08 20:17:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdFuX-0002fA-4J; Mon, 08 May 2006 20:17:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdFuW-0002f5-Fk for widex@ietf.org; Mon, 08 May 2006 20:17:08 -0400 Received: from smtp104.sbc.mail.mud.yahoo.com ([68.142.198.203]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FdFuV-0002sx-0l for widex@ietf.org; Mon, 08 May 2006 20:17:08 -0400 Received: (qmail 24157 invoked from network); 8 May 2006 22:50:10 -0000 Received: from unknown (HELO 3150hw) (jinyu1@sbcglobal.net@64.186.173.202 with login) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 8 May 2006 22:50:09 -0000 From: "Jin Yu" To: Date: Mon, 8 May 2006 15:49:14 -0700 Organization: OpenXUP.org Message-ID: <002801c672f1$a20e5190$1e0aa8c0@martsbs.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AcYwIGEcfYMvsJdDRTiXOqfSC0NSshCyWlwA X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [Widex] WiDeX and XUP X-BeenThere: widex@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working list for the WIDEX working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: widex-bounces@ietf.org Hi, I just went through the WiDeX charter and requirements draft. It's very interesting. I find it shares many goals with XUP (Extensible User Interface Protocol), which was published as a W3C Note 4 years ago: . XUP focuses on XML-based user interfaces languages (e.g. XUL, XAML, XHTML) and manipulates DOM instances of those languages. XUP has two main concepts: UI updates and UI events. In XUP, UI updates are just remote DOM manipulations (add, remove, update elements, etc.) of a UI model, which is a DOM instance of an XML UI language. In addition, the UI updates are bi-directional. That is, the user agent sends UI updates to server, containing end user's direct manipulations as well as the UI changes made by client-side scripts; and the server sends UI updates to the user agent, containing server-side application's changes to the UI model. On the other hand, UI events are events generated by the end user operating the user agent; e.g. mouse-click, key-press. XUP allows any UI events to be sent from the user agent to the server. Event details are defined by concrete UI languages such as XUL and XAML. In addition, XUP supports multiple event models. It supports DOM-style capture / bubbling events, as well as Java Swing-style delegation-based events. Currently XUP uses SOAP as the transport protocol. However, the SOAP binding is not critical, and XUP could be used with other transport mechanisms as well. We have built an open source project OpenXUP () on top of XUP. On that web site you can find an implementation prototype as well as some research papers we have published. I hope XUP and OpenXUP will be a useful reference material for this WG. Regards, Jin ________________________________________ Jin Yu OpenXUP.org _______________________________________________ Widex mailing list Widex@ietf.org https://www1.ietf.org/mailman/listinfo/widex From widex-bounces@ietf.org Tue May 09 01:04:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdKNo-0008Al-75; Tue, 09 May 2006 01:03:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdKNn-0008Ab-6B for widex@ietf.org; Tue, 09 May 2006 01:03:39 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdKNi-0000zN-RT for widex@ietf.org; Tue, 09 May 2006 01:03:39 -0400 Received: from [192.168.2.104] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k4954Vpt029000 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 9 May 2006 00:04:33 -0500 In-Reply-To: <002801c672f1$a20e5190$1e0aa8c0@martsbs.local> References: <002801c672f1$a20e5190$1e0aa8c0@martsbs.local> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Widex] WiDeX and XUP Date: Tue, 9 May 2006 00:03:25 -0500 To: Jin Yu X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: widex@ietf.org X-BeenThere: widex@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working list for the WIDEX working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: widex-bounces@ietf.org On May 8, 2006, at 5:49 PM, Jin Yu wrote: > I just went through the WiDeX charter and requirements draft. It's > very > interesting. I find it shares many goals with XUP (Extensible User > Interface > Protocol), which was published as a W3C Note 4 years ago: > . . . . Thanks. This is very interesting. open question: What's the key differentiator between WIDEX and XUP? -- Dean _______________________________________________ Widex mailing list Widex@ietf.org https://www1.ietf.org/mailman/listinfo/widex From widex-bounces@ietf.org Tue May 09 22:35:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdeXA-0005he-9b; Tue, 09 May 2006 22:34:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdeX9-0005hX-DR for widex@ietf.org; Tue, 09 May 2006 22:34:39 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdeX6-0003dj-RF for widex@ietf.org; Tue, 09 May 2006 22:34:39 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4A2YXVQ008725; Wed, 10 May 2006 05:34:33 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 May 2006 05:34:23 +0300 Received: from daebe102.NOE.Nokia.com ([10.241.35.115]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 May 2006 21:34:21 -0500 Received: from [172.19.141.54] ([172.19.141.54]) by daebe102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 May 2006 21:34:20 -0500 Message-ID: <4461505C.2080006@indt.org.br> Date: Tue, 09 May 2006 23:30:52 -0300 From: Rosfran Lins Borges Organization: INdT/Recife User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: widex@ietf.org Subject: [Widex] Working group last call (WGLC) for Requirements: draft-ietf-widex-requirements-01.txt (review) References: <002801c672f1$a20e5190$1e0aa8c0@martsbs.local> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 May 2006 02:34:21.0166 (UTC) FILETIME=[3E48C8E0:01C673DA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: X-BeenThere: widex@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working list for the WIDEX working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: widex-bounces@ietf.org 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 From widex-bounces@ietf.org Wed May 10 20:04:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdyf8-0003JU-Gi; Wed, 10 May 2006 20:04:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdyf6-0003JP-J2 for widex@ietf.org; Wed, 10 May 2006 20:04:12 -0400 Received: from smtp104.sbc.mail.mud.yahoo.com ([68.142.198.203]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fdyf4-0000er-1k for widex@ietf.org; Wed, 10 May 2006 20:04:12 -0400 Received: (qmail 88157 invoked from network); 11 May 2006 00:04:08 -0000 Received: from unknown (HELO 3150hw) (jinyu1@sbcglobal.net@64.186.173.202 with login) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 11 May 2006 00:04:08 -0000 From: "Jin Yu" To: Subject: Re: [Widex] Working group last call (WGLC) for Requirements: draft-ietf-widex-requirements-01.txt Date: Wed, 10 May 2006 17:04:00 -0700 Organization: OpenXUP.org Message-ID: <000301c6748e$68fa25c0$0202fea9@martsbs.local> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AcZ0jmffaPtnBu+qSUW0vT/v89333Q== X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 X-BeenThere: widex@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working list for the WIDEX working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: widex-bounces@ietf.org Hi all, I have a few comments about the requirements draft, mostly based on my experience in working on XUP and X11. * Event Selection In a networked UI environment, efficient event delivery is as important as updating the UI itself. The requirements document already discussed that certain events can be handled locally at the renderer (e.g. a mouse click on a menu bar will display a submenu) and therefore there is no need to send those events to the server. However, in addition to that, it is very important that the renderer only sends events that are *interested* by the application logic on the server side. For example, typing in a text field generates a key press event for each key stroke. But the application may not care about each key stoke; it only wants to receive the entire text when the user clicks on a button labeled "submit". In this case, the application is interested in the mouse click event on the "submit" button, but not interested in the key press events in the text field. So what's needed is an event selection mechanism, and I believe this is needed at the protocol level, not at the XML UI language level. That is, this event selection mechanism should be independent of the actual UI language in use. I think we could define a new type of message - widex event selection object. This is a one directional message that goes from the server to the renderer, allowing the application to instruct the renderer to send only selected events. The widex event selection object would specify the type of event as well as the UI component that fired the event. And the event type would be a namespace-qualified event from any concrete XML UI languages (not limited by DOM events; it could come from XUL, XAML, etc.) Note that the new event selection object would be very different from WO.Event. The event selection object specifies the event delivery criteria; whereas WO.Event specifies the actual event fired, with timestamp, etc. Similar design can be found in XUP, where it has the notion of "event selectors" (). In addition, X11 also allows the selection of events, via the library function XSelectInput(). * UI State Synchronization The diagram at the beginning of section 2 shows the UI update interface as one way messages from the server to the renderer. However, for the UI state to be synchronized, the renderer should also send UI update messages to the server. The server-side UI state is manipulated by application code (e.g. create a new window, change background color of a label, etc.); this results server to renderer UI updates messages. On the other hand, the renderer's UI state is manipulated by the end user. For example, when the user is typing text in a text field, the UI state of that field is getting changed. This change needs to be synchronized to the server. Other examples include resizing a window, checking a check box, etc. Note that the synchronization needs not to be immediate, as the application may just care about the entire text input, not each key stoke. But how and when to synchronize should be left to the application to decide. Again, this could be done by using the widex event selection object proposed above. Regards, Jin ________________________________________ Jin Yu OpenXUP.org _______________________________________________ Widex mailing list Widex@ietf.org https://www1.ietf.org/mailman/listinfo/widex From widex-bounces@ietf.org Fri May 12 09:57:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeY9B-0001tH-7h; Fri, 12 May 2006 09:57:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeY99-0001si-H7 for widex@ietf.org; Fri, 12 May 2006 09:57:35 -0400 Received: from homer.w3.org ([128.30.52.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeY4Y-0005fk-3z for widex@ietf.org; Fri, 12 May 2006 09:52:53 -0400 Received: from localhost (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id A528D4EFCE; Fri, 12 May 2006 09:52:48 -0400 (EDT) Date: Fri, 12 May 2006 14:52:41 +0100 (BST) From: Dave Raggett X-X-Sender: dsr@localhost.localdomain To: Jin Yu Subject: Re: [Widex] Working group last call (WGLC) for Requirements: draft-ietf-widex-requirements-01.txt In-Reply-To: <000301c6748e$68fa25c0$0202fea9@martsbs.local> Message-ID: References: <000301c6748e$68fa25c0$0202fea9@martsbs.local> X-GPG-PUBLIC_KEY: http://www.w3.org/People/Raggett/pubkey-20040130.asc MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: widex@ietf.org X-BeenThere: widex@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working list for the WIDEX working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: widex-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Jin, Some thoughts triggered by your email: Event filtering could be: a) by prior arrangement b) negotiated at the start of the session c) dynamically updated during the session Session initiation is out of scope for REX, but we could support the means to dynamically add or remove event listeners during the session via introducing a pair of new events for that purpose as you suggest. I could draft something on this for the REX mailing list. For Widex, we could explore the idea of negotiating event selection at session initiation. a) a list of explicit event names b) a list of event catgories c) a reference to a list of event names/event categories Event categories are something that was introduced by the W3C Voice Browser working group for VoiceXML and CCXML. They defined event names hierarchically and could name categories of events by reference to this hierarchy, e.g. there are a set of events error.connection.noauthorization error.connection.baddestination error.connection.noroute error.connection.noresource ... you can specify behavior for a specific event, for all error.connection events, or more generally for all error events. Another idea is to be able to indicate which events the server is interested in by reference to a URI for a list of events or event categories. The usual caching rules would apply to such lists. For devices that aren't connected to the Internet, such lists would have to be available on the local network, e.g. on the widex server. An advantage of identifying events by reference is that it can save time if the list is known to be always the same, since then you don't need to download it for each session. One issue is where the event listener is attached to the DOM tree and whether it is invoked in the bubble or capture phase. This only matters when there is another event listener that is invoked prior to the server's event listener, as then there may the possibility of the event being cancelled by the earlier listener. I don't believe it makes sense to allow the server's event listener to be able to cancel events, as this would introduce a significant latency into event handling in the client. For this purpose, the event object, that is passed to the server by the widex implementation, would have the DOM attributes bubbles and cancelable set to false. In principle, we might also need to say something about which events the server can send to the widex renderer. The same negotiation mechanisms could be used as for events the server gets from the client. You also talk about UI initialization. I think this can be handled as part of the UI markup language, and also by additional events sent from the server to the widex renderer. These events are outside the scope of Widex, and would need to have their semantics and XML serialization defined in separate specifications. For REX, it will be easier if we stick to the existing DOM events so that we can limit the scope of what needs to be specified for the processing and serialization of these events. I think we will be able to provide an algorithm for describing the serialization of these events from their IDL definitions. Dave Raggett W3C lead for multimodal interaction http://www.w3.org/People/Raggett +44 1225 866240 (or 867351) On Wed, 10 May 2006, Jin Yu wrote: > Hi all, > > I have a few comments about the requirements draft, mostly based > on my experience in working on XUP and X11. > > * Event Selection > > In a networked UI environment, efficient event delivery is as > important as updating the UI itself. The requirements document > already discussed that certain events can be handled locally at > the renderer (e.g. a mouse click on a menu bar will display a > submenu) and therefore there is no need to send those events to > the server. However, in addition to that, it is very important > that the renderer only sends events that are *interested* by the > application logic on the server side. For example, typing in a > text field generates a key press event for each key stroke. But > the application may not care about each key stoke; it only wants > to receive the entire text when the user clicks on a button > labeled "submit". In this case, the application is interested in > the mouse click event on the "submit" button, but not interested > in the key press events in the text field. > > So what's needed is an event selection mechanism, and I believe > this is needed at the protocol level, not at the XML UI language > level. That is, this event selection mechanism should be > independent of the actual UI language in use. > > I think we could define a new type of message - widex event > selection object. This is a one directional message that goes from > the server to the renderer, allowing the application to instruct > the renderer to send only selected events. The widex event > selection object would specify the type of event as well as the UI > component that fired the event. And the event type would be a > namespace-qualified event from any concrete XML UI languages (not > limited by DOM events; it could come from XUL, XAML, etc.) > > Note that the new event selection object would be very different > from WO.Event. The event selection object specifies the event > delivery criteria; whereas WO.Event specifies the actual event > fired, with timestamp, etc. > > Similar design can be found in XUP, where it has the notion of > "event selectors" > (). > > In addition, X11 also allows the selection of events, via the > library function XSelectInput(). > > * UI State Synchronization > > The diagram at the beginning of section 2 shows the UI update > interface as one way messages from the server to the renderer. > However, for the UI state to be synchronized, the renderer should > also send UI update messages to the server. > > The server-side UI state is manipulated by application code (e.g. > create a new window, change background color of a label, etc.); > this results server to renderer UI updates messages. > > On the other hand, the renderer's UI state is manipulated by the > end user. For example, when the user is typing text in a text > field, the UI state of that field is getting changed. This change > needs to be synchronized to the server. Other examples include > resizing a window, checking a check box, etc. Note that the > synchronization needs not to be immediate, as the application may > just care about the entire text input, not each key stoke. But how > and when to synchronize should be left to the application to > decide. Again, this could be done by using the widex event > selection object proposed above. > > > Regards, > > Jin > ________________________________________ > Jin Yu > OpenXUP.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEZJMvb3AdEmxAsUsRAvHvAKDeStuc9vO3zUK38Dq/DvbO2wGnZQCfYfLe cfOrELwZkXlpNdJV2iY3BNY= =wQS0 -----END PGP SIGNATURE----- _______________________________________________ Widex mailing list Widex@ietf.org https://www1.ietf.org/mailman/listinfo/widex From widex-bounces@ietf.org Fri May 12 14:58:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FecqL-0000te-HG; Fri, 12 May 2006 14:58:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FecqK-0000tZ-Rh for widex@ietf.org; Fri, 12 May 2006 14:58:28 -0400 Received: from smtp103.sbc.mail.mud.yahoo.com ([68.142.198.202]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FecqI-0003yv-Ak for widex@ietf.org; Fri, 12 May 2006 14:58:28 -0400 Received: (qmail 67466 invoked from network); 12 May 2006 18:58:25 -0000 Received: from unknown (HELO 3150hw) (jinyu1@sbcglobal.net@64.186.173.202 with login) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 12 May 2006 18:58:25 -0000 From: "Jin Yu" To: "'Dave Raggett'" Subject: RE: [Widex] Working group last call (WGLC) for Requirements: draft-ietf-widex-requirements-01.txt Date: Fri, 12 May 2006 11:58:21 -0700 Organization: OpenXUP.org Message-ID: <000401c675f6$0ac9a6b0$1e0aa8c0@martsbs.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AcZ1y11BMWxn/D6pT52LKtgiDxIs8gAH/pDg X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: widex@ietf.org X-BeenThere: widex@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working list for the WIDEX working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: widex-bounces@ietf.org > Event filtering could be: > > a) by prior arrangement > b) negotiated at the start of the session > c) dynamically updated during the session Yes, and I think the dynamic part is essential, since most applications will very likely change their event handling behavior at runtime. That is why I see the need of a WO for event selection. > Session initiation is out of scope for REX, but we could support > the means to dynamically add or remove event listeners during > the session via introducing a pair of new events for that purpose > as you suggest. I could draft something on this for the REX mailing > list. > > For Widex, we could explore the idea of negotiating event selection > at session initiation. > > a) a list of explicit event names > b) a list of event catgories > c) a reference to a list of event names/event categories > > Event categories are something that was introduced by the W3C Voice > Browser working group for VoiceXML and CCXML. They defined event > names hierarchically and could name categories of events by > reference to this hierarchy, e.g. there are a set of events > > error.connection.noauthorization > error.connection.baddestination > error.connection.noroute > error.connection.noresource > ... > > you can specify behavior for a specific event, for all > error.connection events, or more generally for all error events. Event categorization is a great concept. But that could be left to the specific UI languages. The protocol should be just concerned with some XML namespace qualified event name; whether that name is a concrete event or an event category could be interpreted by the UI language in use. > One issue is where the event listener is attached to the DOM tree > and whether it is invoked in the bubble or capture phase. This only > matters when there is another event listener that is invoked prior > to the server's event listener, as then there may the possibility of > the event being cancelled by the earlier listener. > > I don't believe it makes sense to allow the server's event listener > to be able to cancel events, as this would introduce a significant > latency into event handling in the client. For this purpose, the > event object, that is passed to the server by the widex > implementation, would have the DOM attributes bubbles and cancelable > set to false. I agree. Actually I believe the DOM event capturing / bubbling model may not fit well with a network UI environment. I think we should not restrict ourselves to DOM style events. What's more appropriate is a *delegation" based event model, which is used by popular desktop GUI toolkits such as .NET WinForms and Java Swing. In this model, one would attach event listeners (or event handlers in .NET WinForms) to a specific UI component for a specific event type. This allows for a loose coupling of UI events and application logic, and it also minimizes event traffic. > You also talk about UI initialization. I think this can be handled > as part of the UI markup language, and also by additional events > sent from the server to the widex renderer. These events are outside > the scope of Widex, and would need to have their semantics and XML > serialization defined in separate specifications. What do you mean by "UI initialization"? I think I was talking about UI state synchronization in my message. Are you referring to something in the XUP spec? > For REX, it will be easier if we stick to the existing DOM events > so that we can limit the scope of what needs to be specified for > the processing and serialization of these events. I think we will > be able to provide an algorithm for describing the serialization > of these events from their IDL definitions. Regards, Jin ________________________________________ Jin Yu OpenXUP.org _______________________________________________ Widex mailing list Widex@ietf.org https://www1.ietf.org/mailman/listinfo/widex From widex-bounces@ietf.org Sun May 14 17:14:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfNuJ-00045n-FE; Sun, 14 May 2006 17:13:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfNuH-0003y6-O6 for widex@ietf.org; Sun, 14 May 2006 17:13:41 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfKuH-0006L2-UA for widex@ietf.org; Sun, 14 May 2006 14:01:29 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FfKf5-0005Jy-Ij for widex@ietf.org; Sun, 14 May 2006 13:45:49 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4EHjiHc008777; Sun, 14 May 2006 20:45:45 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 14 May 2006 20:45:45 +0300 Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 14 May 2006 20:45:45 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Widex] Working group last call (WGLC) for Requirements:draft-ietf-widex-requirements-01.txt Date: Sun, 14 May 2006 20:45:44 +0300 Message-ID: <1C1F3D15859526459B4DD0A7A9B2268B02143E91@trebe101.NOE.Nokia.com> In-Reply-To: <000301c6748e$68fa25c0$0202fea9@martsbs.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Widex] Working group last call (WGLC) for Requirements:draft-ietf-widex-requirements-01.txt Thread-Index: AcZ0jmffaPtnBu+qSUW0vT/v89333QCpATFw From: To: , X-OriginalArrivalTime: 14 May 2006 17:45:45.0048 (UTC) FILETIME=[3A11FD80:01C6777E] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: X-BeenThere: widex@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working list for the WIDEX working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: widex-bounces@ietf.org Hi Jin, We started the requirements draft with the goal of having a minimal set of requirements that a system exporting the UI to another system must fulfill but stop short of going deeper in describing the system. Having these goals in mind we described the high level interactions between the Widex Server and Widex Renderer as having just two basic interfaces:=20 a) update interface, used to send information from the server to the renderer that is basically generated by the application logic; b) event interface, used to send information from the renderer to the server that is basically generated by the user interaction with the rendered UI. It is quite likely that the terms used so far in the requirements draft will not map directly to the specification, as is the case with the proposed Widex framework (http://www.ietf.org/internet-drafts/draft-stirbu-widex-framework-00.txt ) where practically all messages exchanged between the Widex Server and the Widex Renderer are events described using REX. I think that being able to dynamically adjust which events server is interested in is a good feature but that is a design issue and Dave already mentioned several alternatives. We'll have to asses these alternatives and select the optimal one for our environment. As a bottom line, I think that your comments are very useful but I think that they should be considered for the Widex Framework draft rather than for the Requirements. Regards, Vlad _______________________________________________ Widex mailing list Widex@ietf.org https://www1.ietf.org/mailman/listinfo/widex From widex-bounces@ietf.org Mon May 15 19:18:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfmKA-0007aQ-Q4; Mon, 15 May 2006 19:18:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfmK9-0007aL-6S for widex@ietf.org; Mon, 15 May 2006 19:18:01 -0400 Received: from smtp114.sbc.mail.mud.yahoo.com ([68.142.198.213]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FfmK6-0002DM-Nz for widex@ietf.org; Mon, 15 May 2006 19:18:01 -0400 Received: (qmail 14411 invoked from network); 15 May 2006 23:17:58 -0000 Received: from unknown (HELO 3150hw) (jinyu1@sbcglobal.net@64.186.173.202 with login) by smtp114.sbc.mail.mud.yahoo.com with SMTP; 15 May 2006 23:17:57 -0000 From: "Jin Yu" To: , Subject: RE: [Widex] Working group last call (WGLC) for Requirements:draft-ietf-widex-requirements-01.txt Date: Mon, 15 May 2006 16:17:18 -0700 Organization: OpenXUP.org Message-ID: <000101c67875$b65f8d60$0202fea9@martsbs.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <1C1F3D15859526459B4DD0A7A9B2268B02143E91@trebe101.NOE.Nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Thread-Index: AcZ0jmffaPtnBu+qSUW0vT/v89333QCpATFwAFAhbMA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: X-BeenThere: widex@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working list for the WIDEX working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: widex-bounces@ietf.org Hi Vlad, My comments are based on reading both the January framework draft and the April requirement draft. So I agree with you that the comments might be a bit too detailed for the requirements draft, and indeed they may be more appropriate for the framework draft. Regards, Jin ________________________________________ Jin Yu OpenXUP.org > -----Original Message----- > From: Vlad.Stirbu@nokia.com [mailto:Vlad.Stirbu@nokia.com] > Sent: Sunday, May 14, 2006 10:46 AM > To: jyu@openxup.org; widex@ietf.org > Subject: RE: [Widex] Working group last call (WGLC) for > Requirements:draft-ietf-widex-requirements-01.txt > > Hi Jin, > > We started the requirements draft with the goal of having a minimal set > of requirements that a system exporting the UI to another system must > fulfill but stop short of going deeper in describing the system. Having > these goals in mind we described the high level interactions between the > Widex Server and Widex Renderer as having just two basic interfaces: > > a) update interface, used to send information from the server to the > renderer that is basically generated by the application logic; > b) event interface, used to send information from the renderer to the > server that is basically generated by the user interaction with the > rendered UI. > > It is quite likely that the terms used so far in the requirements draft > will not map directly to the specification, as is the case with the > proposed Widex framework > (http://www.ietf.org/internet-drafts/draft-stirbu-widex-framework-00.txt > ) where practically all messages exchanged between the Widex Server and > the Widex Renderer are events described using REX. > > I think that being able to dynamically adjust which events server is > interested in is a good feature but that is a design issue and Dave > already mentioned several alternatives. We'll have to asses these > alternatives and select the optimal one for our environment. > > As a bottom line, I think that your comments are very useful but I think > that they should be considered for the Widex Framework draft rather than > for the Requirements. > > Regards, > Vlad _______________________________________________ Widex mailing list Widex@ietf.org https://www1.ietf.org/mailman/listinfo/widex From widex-bounces@ietf.org Tue May 16 03:24:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FftuO-0001or-Py; Tue, 16 May 2006 03:23:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FftuN-0001fk-98 for widex@ietf.org; Tue, 16 May 2006 03:23:55 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FftuJ-0005U3-4q for widex@ietf.org; Tue, 16 May 2006 03:23:55 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4G7NnC2026149; Tue, 16 May 2006 10:23:50 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 May 2006 10:23:49 +0300 Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 May 2006 10:23:48 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 16 May 2006 10:23:47 +0300 Message-ID: <1C1F3D15859526459B4DD0A7A9B2268B021447B1@trebe101.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated Widex Requirements draft following WGLC comments Thread-Index: AcZ4uaupbax+J97ESraB89bDFLYuWw== From: To: X-OriginalArrivalTime: 16 May 2006 07:23:48.0880 (UTC) FILETIME=[ACBA2100:01C678B9] X-Spam-Score: 0.2 (/) X-Scan-Signature: b6e18fadcfab41fa5e7faede753de4c2 Cc: Subject: [Widex] Updated Widex Requirements draft following WGLC comments X-BeenThere: widex@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working list for the WIDEX working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1133798396==" Errors-To: widex-bounces@ietf.org This is a multi-part message in MIME format. --===============1133798396== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C678B9.ACA2A88D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C678B9.ACA2A88D Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable 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).=20 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:=20 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):=20 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.=20 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".=20 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. ------_=_NextPart_001_01C678B9.ACA2A88D Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable 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-requ= irements-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/msg0= 0093.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/msg0= 0094.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/msg0= 0095.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-f= ramework-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.





------_=_NextPart_001_01C678B9.ACA2A88D-- --===============1133798396== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Widex mailing list Widex@ietf.org https://www1.ietf.org/mailman/listinfo/widex --===============1133798396==-- From widex-bounces@ietf.org Tue May 16 15:50:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg5Yj-000822-6T; Tue, 16 May 2006 15:50:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg5YS-0007pS-GP; Tue, 16 May 2006 15:50:04 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg5YP-0002RI-UY; Tue, 16 May 2006 15:50:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k4GJo11I026551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 May 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fg5YP-0007kf-Jw; Tue, 16 May 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 16 May 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: widex@ietf.org Subject: [Widex] I-D ACTION:draft-ietf-widex-requirements-02.txt X-BeenThere: widex@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working list for the WIDEX working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: widex-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Widget Description Exchange Service Working Group of the IETF. Title : Widget Description Exchange Service (WIDEX) Requirements Author(s) : V. Stirbu, D. Raggett Filename : draft-ietf-widex-requirements-02.txt Pages : 14 Date : 2006-5-16 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-widex-requirements-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-widex-requirements-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-widex-requirements-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-5-16132054.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-widex-requirements-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-widex-requirements-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-16132054.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Widex mailing list Widex@ietf.org https://www1.ietf.org/mailman/listinfo/widex --NextPart-- From widex-bounces@ietf.org Wed May 17 10:20:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgMsc-0006B1-NQ; Wed, 17 May 2006 10:20:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgMsb-0006AE-3t; Wed, 17 May 2006 10:20:01 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgMsZ-00031V-BQ; Wed, 17 May 2006 10:20:01 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4HEJttu005710; Wed, 17 May 2006 17:19:56 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 May 2006 17:19:27 +0300 Received: from daebe102.NOE.Nokia.com ([10.241.35.115]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 May 2006 09:19:26 -0500 Received: from [172.19.141.54] ([172.19.141.54]) by daebe102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 May 2006 09:19:24 -0500 Message-ID: <446B2F91.7050909@indt.org.br> Date: Wed, 17 May 2006 11:13:37 -0300 From: Rosfran Lins Borges Organization: INdT/Recife User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: widex@ietf.org CC: widex-bounces@ietf.org Subject: Re: [Widex] Updated Widex Requirements draft following WGLC comments References: <1C1F3D15859526459B4DD0A7A9B2268B021447B1@trebe101.NOE.Nokia.com> In-Reply-To: <1C1F3D15859526459B4DD0A7A9B2268B021447B1@trebe101.NOE.Nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 May 2006 14:19:24.0697 (UTC) FILETIME=[E60B9890:01C679BC] X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 X-BeenThere: widex@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working list for the WIDEX working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: widex-bounces@ietf.org All comments I sent were properly answered, no questions for now. Regards, Rosfran Borges ext widex-bounces@ietf.org 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 >Widex@ietf.org >https://www1.ietf.org/mailman/listinfo/widex > > _______________________________________________ Widex mailing list Widex@ietf.org https://www1.ietf.org/mailman/listinfo/widex From widex-bounces@ietf.org Wed May 31 07:33:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlOwk-0002YV-2t; Wed, 31 May 2006 07:33:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlOwj-0002YQ-EF for widex@ietf.org; Wed, 31 May 2006 07:33:05 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlOwe-0002OL-V4 for widex@ietf.org; Wed, 31 May 2006 07:33:05 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4VBWvur018485 for ; Wed, 31 May 2006 14:33:00 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 May 2006 14:32:59 +0300 Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 May 2006 14:33:00 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 31 May 2006 14:31:23 +0300 Message-ID: <1C1F3D15859526459B4DD0A7A9B2268B0223D7FB@trebe101.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated Widex framework draft Thread-Index: AcaEpb8YEiThetIGRVumagg6M26dzg== From: To: X-OriginalArrivalTime: 31 May 2006 11:33:00.0222 (UTC) FILETIME=[F89E1DE0:01C684A5] X-Spam-Score: 0.2 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: [Widex] Updated Widex framework draft X-BeenThere: widex@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working list for the WIDEX working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1354435861==" Errors-To: widex-bounces@ietf.org This is a multi-part message in MIME format. --===============1354435861== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C684A5.F837C759" This is a multi-part message in MIME format. ------_=_NextPart_001_01C684A5.F837C759 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi,=20 Updated version of the Widex framework draft available at http://www.kolumbus.fi/vlad.stirbu/draft-stirbu-widex-framework-01.txt. It will be available shortly also in the IETF drafts repository. Vlad ------_=_NextPart_001_01C684A5.F837C759 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Updated Widex framework draft

Hi,
Updated version of = the Widex framework draft available at http://www.kolumbus.fi/vlad.stirbu/draft-stirbu-widex-fr= amework-01.txt. It will be available shortly also in the IETF drafts = repository.

Vlad

------_=_NextPart_001_01C684A5.F837C759-- --===============1354435861== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Widex mailing list Widex@ietf.org https://www1.ietf.org/mailman/listinfo/widex --===============1354435861==--