From remoteui-bounces@lists.ietf.org Fri Jul 01 05:41:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoI1U-0003VU-Dz; Fri, 01 Jul 2005 05:41:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoHlM-0003KJ-8b; Fri, 01 Jul 2005 05:24:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11825; Fri, 1 Jul 2005 05:24:41 -0400 (EDT) From: Vlad.Stirbu@nokia.com Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoIBI-0007Aq-6Y; Fri, 01 Jul 2005 05:51:32 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j619LfCL019879; Fri, 1 Jul 2005 12:21:42 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jul 2005 12:24:37 +0300 Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jul 2005 12:24:36 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Jul 2005 12:24:35 +0300 Message-ID: <1C1F3D15859526459B4DD0A7A9B2268BA0E6D7@trebe101.NOE.Nokia.com> Thread-Topic: Remote UI BoF at IETF63 Thread-Index: AcV9myWeEE0GVNFBSiyvJSVU0VnWqwAgDsFA To: , X-OriginalArrivalTime: 01 Jul 2005 09:24:36.0935 (UTC) FILETIME=[B3214D70:01C57E1E] X-Spam-Score: 0.3 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Content-Transfer-Encoding: quoted-printable Cc: ietf@ietf.org, remoteui@ietf.org Subject: [REMOTEUI] RE: Remote UI BoF at IETF63 X-BeenThere: remoteui@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Remote UI BoF and future WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: remoteui-bounces@lists.ietf.org Errors-To: remoteui-bounces@lists.ietf.org Hi, Please find attached a Remote UI BoF FAQ which explains some of the = problems with existing protocols and clarifies the scope of proposed = work. To discuss this in more detail, a mailing list is available at = remoteui@ietf.org and you can subscribe here = https://www1.ietf.org/mailman/listinfo/remoteui. Also, a starting point for this work can be found here=20 http://www.ietf.org/internet-drafts/draft-stirbu-lrdp-00.txt. Regards, Vlad Frequently Asked Questions - Remote UI BoF ------------------------------------------ 1. What problem is the Remote UI protocol trying to solve? The Remote UI is a mechanism that enables user interfaces to be rendered = on other devices than those that have the application logic. The Remote = UI protocol provides the mechanism which enable a client device the = generate a UI, received from a server device, using the client device's = native UI capabilities, and keeping the UI synchronised with the = application logic. 2. Who needs this solution? Device manufacturers invest a lot of energy in trying to optimise their = devices for certain environments. Because the devices are intended for a = diverse range of purposes, their UI capabilities can vary considerably; = screen size and ratio, color depth, windowing system with various widget = sets, input methods are making the environment highly heterogeneous. At = the same time, application developers and UI designers are trying to = create user interfaces that are high optimised for the rendering = platform, so that the user experience is improved by having the = respective application easy to learn and use. Therefore, when an UI is rendered on another device than the one that is = running the application logic provisions need to be made, so that the = user can perceive the UI as a local application making it intuitively = usable. For=20 example an application UI may appear differently when remoted on an = Windows XP desktop vs. a mobile phone. 3. Why this cannot be done with existing protocol? Existing protocols can be split in two categories: framebuffer-level and = graphics-level protocols. In the framebuffer-level protocol, the contents of the framebuffer (i.e. = the individual pixels) are copied across the network to a framebuffer on = the client. In order to avoid sending the full screen every time = something changed on the screen, these protocols typically send only the = pixels that are changed inside the clipping regions to the client. = Examples of such protocols are VNC and protocols based on T.120, like = Microsoft's RDP. In the graphics-level protocol, the drawing request to the graphical = device interface (GDI), such as DrawLine(), DrawString(), etc. are = copied across the network. The client is responsible for interpreting = these commands and rendering the lines, rectangles, strings, etc. in its = framebuffer. Example of such protocol is X Windows. The problem with these approaches is that, in order to render the UI, = the clients are following blindly the instructions received from the = server; they don't have means to influence the appearance of the UI, = they just render the UI using the graphical elements/instructions that = are provided by the server and are specific to the server platform. 4. What are the pieces, building blocks that are needed to build this = solution? In order to correct the problems pointed out with the existing = protocols, a mechanism is needed so that information about the widgets = or widget trees is sent to the client, so that it can generate the UI = using native client's widgets. This mechanism has usually three = components: UI description language, UI remoting protocol and session = setup. UI description language contains the descriptions of the widgets, their = properties and relationships between the widgets. Typically the = widget-level UI descriptions are augmented with stylesheets containing = hints such as preferred colours to use, which layout to use, which = background picture, etc. Examples of such UI=20 descriptions languages are Mozillla's XUL and OASIS' UIML. The UI remoting protocol is the transport protocol that is responsible = with communicating (partial) UI updates from the server to the client = and UI events triggered through changes in widget states made by the = user from the client to the server. Usually an UI update can have three = meanings: =09 * UI Initialisation - an application can send the full description of = the UI at session setup. =09 * UI Fragment - an application is sending partial descriptions of the = UI when the application is becoming aware of which parts of the UI will = be used depending on the runtime status. =09 * UI Update - an application is sending notifications when widget = properties are changing due to changes in application state. The actual structures that are exchanged with UI updates and UI events = are described using the UI description language. Session setup is responsible with identifying compatible servers and = clients and initiating the UI remoting session between them. A client is = compatible with a server when they support the same UI remoting protocol = and the same UI description language. Examples of session setup = protocols are SIP/SDP and UPnP Remote UI. 5. What is the goal of the Remote UI effort in IETF? Create a UI remoting protocol for applications that are using UI = Description Languages. > -----Original Message----- > From: ext Pekka Savola [mailto:pekkas@netcore.fi] > Sent: 30 June, 2005 20:42 > To: Dave Crocker > Cc: Stirbu Vlad (Nokia-TP-MSW/Tampere); ietf@ietf.org > Subject: Re: Remote UI BoF at IETF63 >=20 >=20 > On Thu, 30 Jun 2005, Dave Crocker wrote: > [...] > > Are there any materials to use as input, either as=20 > exemplars or possibly even=20 > > as a beginning specification? This latter would be=20 > particularly helpful for=20 > > the success of the effort? >=20 > FWIW, when I read the BoF description, I started wondering about the=20 > same things. Specifically I started thinking about the half a dozen=20 > protocols that already exist in this space (vnc, rdp, ...). It'd be=20 > very good to understand the scope of the work, and how the existing=20 > protocols fit (or don't fit) the bill. >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 _______________________________________________ REMOTEUI mailing list REMOTEUI@lists.ietf.org https://www1.ietf.org/mailman/listinfo/remoteui From remoteui-bounces@lists.ietf.org Fri Jul 01 06:55:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoJB3-0008VI-3w; Fri, 01 Jul 2005 06:55:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoIjh-0006Qk-0w; Fri, 01 Jul 2005 06:27:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28241; Fri, 1 Jul 2005 06:27:02 -0400 (EDT) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoJ9d-0005tj-IK; Fri, 01 Jul 2005 06:53:54 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4499361AFD; Fri, 1 Jul 2005 12:27:03 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20027-03; Fri, 1 Jul 2005 12:26:59 +0200 (CEST) Received: from halvestr-w2k02.emea.cisco.com (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 160C761B03; Fri, 1 Jul 2005 12:26:59 +0200 (CEST) Date: Fri, 01 Jul 2005 12:25:27 +0200 From: Harald Tveit Alvestrand To: Vlad.Stirbu@nokia.com, ietf@ietf.org Message-ID: In-Reply-To: <1C1F3D15859526459B4DD0A7A9B2268BA0E6C9@trebe101.NOE.Nokia.com> References: <1C1F3D15859526459B4DD0A7A9B2268BA0E6C9@trebe101.NOE.Nokia.com> X-Mailer: Mulberry/4.0.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 01 Jul 2005 06:55:19 -0400 Cc: remoteui@ietf.org Subject: [REMOTEUI] Re: Remote UI BoF at IETF63 X-BeenThere: remoteui@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Remote UI BoF and future WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: remoteui-bounces@lists.ietf.org Errors-To: remoteui-bounces@lists.ietf.org Vlad, while I think this is a very interesting area for research and perhaps development, I've got to ask the questions that Dave Crocker always pulls up as standard questions for new work in the IETF..... - What expertise do you see that the IETF has (and other groups do not have) that makes it the right body to work on this set of issues? - What importance to the Internet does this work have that makes it a correct use of IETF resources? In the terms of the IETF mission statement, RFC 3935: The goal of the IETF is to make the Internet work better. The mission of the IETF is to produce high quality, relevant technical and engineering documents that influence the way people design, use, and manage the Internet in such a way as to make the Internet work better. These documents include protocol standards, best current practices, and informational documents of various kinds. this would definitely fall into the "use" category. But RFC 3935 also says: In attempting to resolve the question of the IETF's scope, perhaps the fairest balance is struck by this formulation: "protocols and practices for which secure and scalable implementations are expected to have wide deployment and interoperation on the Internet, or to form part of the infrastructure of the Internet." In addition to this constraint, we are also constrained by the principle of competence: Where we do not have, and cannot gather, the competence needed to make technically sound standards, we should not attempt to take the leadership. I must admit that I, like Dave, find the concept fascinating, and that existing protocols like the X Windows protocol may not be the right fit for your requirements, but the IETF is an organization that has traditionally run very far and fast away from any mention of the words "user interface", so it seems like a bit of a strange fit.... More background, please! Harald _______________________________________________ REMOTEUI mailing list REMOTEUI@lists.ietf.org https://www1.ietf.org/mailman/listinfo/remoteui From remoteui-bounces@lists.ietf.org Fri Jul 01 07:39:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoJru-00065G-1P; Fri, 01 Jul 2005 07:39:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoJnJ-0004LC-Ab; Fri, 01 Jul 2005 07:34:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09669; Fri, 1 Jul 2005 07:34:50 -0400 (EDT) Received: from smtp-out4.blueyonder.co.uk ([195.188.213.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoKDF-0004ns-My; Fri, 01 Jul 2005 08:01:43 -0400 Received: from [127.0.0.1] ([82.42.16.20]) by smtp-out4.blueyonder.co.uk with Microsoft SMTPSVC(5.0.2195.6713); Fri, 1 Jul 2005 12:35:32 +0100 Message-ID: <42C52A59.9080702@blueyonder.co.uk> Date: Fri, 01 Jul 2005 12:34:49 +0100 From: David Hopwood User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf@ietf.org, remoteui@ietf.org References: <1C1F3D15859526459B4DD0A7A9B2268BA0E6D7@trebe101.NOE.Nokia.com> In-Reply-To: <1C1F3D15859526459B4DD0A7A9B2268BA0E6D7@trebe101.NOE.Nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Jul 2005 11:35:32.0740 (UTC) FILETIME=[FD8E0440:01C57E30] X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 01 Jul 2005 07:39:37 -0400 Cc: Subject: [REMOTEUI] Re: Remote UI BoF at IETF63 X-BeenThere: remoteui@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: david.nospam.hopwood@blueyonder.co.uk List-Id: Remote UI BoF and future WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: remoteui-bounces@lists.ietf.org Errors-To: remoteui-bounces@lists.ietf.org Vlad.Stirbu@nokia.com wrote: > 3. Why this cannot be done with existing protocol? > > Existing protocols can be split in two categories: framebuffer-level and > graphics-level protocols. > > In the framebuffer-level protocol, the contents of the framebuffer (i.e. the > individual pixels) are copied across the network to a framebuffer on the client. > In order to avoid sending the full screen every time something changed on the > screen, these protocols typically send only the pixels that are changed inside > the clipping regions to the client. Examples of such protocols are VNC and > protocols based on T.120, like Microsoft's RDP. > > In the graphics-level protocol, the drawing request to the graphical device > interface (GDI), such as DrawLine(), DrawString(), etc. are copied across the > network. The client is responsible for interpreting these commands and > rendering the lines, rectangles, strings, etc. in its framebuffer. Example of > such protocol is X Windows. Framebuffer-level protocols can be viewed as a special case of graphics-level protocols where the drawing commands are restricted to bitblt-like commands. > The problem with these approaches is that, in order to render the UI, the > clients are following blindly the instructions received from the server; > they don't have means to influence the appearance of the UI, they just > render the UI using the graphical elements/instructions that are provided > by the server and are specific to the server platform. Having the UI adapt to a look-and-feel appropriate to the client device (and user's preferences) doesn't automatically imply that it has to be the client that does this adaptation. The client could send the server a description of the preferred L&F. The advantage of this is that it allows clients to be much simpler, putting the complexity on the server which is likely to have more memory, processing power, etc. -- David Hopwood _______________________________________________ REMOTEUI mailing list REMOTEUI@lists.ietf.org https://www1.ietf.org/mailman/listinfo/remoteui From remoteui-bounces@lists.ietf.org Sun Jul 03 15:40:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpAKU-0001UU-Mn; Sun, 03 Jul 2005 15:40:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dp9nk-0001FX-93; Sun, 03 Jul 2005 15:06:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29026; Sun, 3 Jul 2005 15:06:46 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpAE6-0006wz-Ed; Sun, 03 Jul 2005 15:34:06 -0400 Received: from [192.168.0.251] (adsl-67-112-201-9.dsl.sntc01.pacbell.net [67.112.201.9]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j63J73lC030385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Jul 2005 12:07:04 -0700 Message-ID: <42C83726.70907@dcrocker.net> Date: Sun, 03 Jul 2005 12:06:14 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Harald Tveit Alvestrand References: <1C1F3D15859526459B4DD0A7A9B2268BA0E6C9@trebe101.NOE.Nokia.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: dhc2@dcrocker.net X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 03 Jul 2005 15:40:37 -0400 Cc: Vlad.Stirbu@nokia.com, ietf@ietf.org, remoteui@ietf.org Subject: [REMOTEUI] Re: Remote UI BoF at IETF63 X-BeenThere: remoteui@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Remote UI BoF and future WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: remoteui-bounces@lists.ietf.org Errors-To: remoteui-bounces@lists.ietf.org Folks, Since his name was taken in vain (vein?), Dave will proffer his own answer's to Harald's questions. (OK, I'll admit it. I'd be offering this response even if Harald hadn't referenced me.) > - What expertise do you see that the IETF has (and other groups do not > have) that makes it the right body to work on this set of issues? This is an effort to specify an open, platform-independent method of maintaining remote display objects, called widgets. The application-level object-maintenance protocol that is described in is very nicely simple. This means that the real work of pursuing such a service covers the network-based mechanics of connectivity, reliability, security, and so on. That's a set of activities about which the IETF has better experience than anywhere else. > - What importance to the Internet does this work have that makes it a > correct use of IETF resources? (I'm still working on my understanding of where this work fits, among a range of higher- and lower-level work, as well as work that might be called "competing" work. Therefore my response here is quite tentative.) Existing open and deployed work has a focus either on the micro-behaviors of drawing graphics, or the macro-behavior of pure presentation. The current work navigates space in between these two, creating and maintaining remote, user-visible "objects". Hence it combines lessons learned from html, xml and object-oriented programming, into a specification of an object-oriented display and input environment, with presentation controlled by style templates. Other comparable work is proprietary. > I must admit that I, like Dave, find the concept fascinating, and that > existing protocols like the X Windows protocol may not be the right fit > for your requirements, but the IETF is an organization that has > traditionally run very far and fast away from any mention of the words > "user interface", so it seems like a bit of a strange fit.... Although formally valid, use of the term "user interface" for this work is entirely unnecessary. At the least it is too broad. In fact it has pretty much nothing to do with human factors, cognitive science, or usability. On looking at the proffered draft document, calling the proposal something mundane like "remote widget exchange service" would be more precise and, I suspect, far more helpful. -- d/ Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net _______________________________________________ REMOTEUI mailing list REMOTEUI@lists.ietf.org https://www1.ietf.org/mailman/listinfo/remoteui From remoteui-bounces@lists.ietf.org Mon Jul 04 09:05:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpQdR-0001hr-Ii; Mon, 04 Jul 2005 09:05:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpQdP-0001gu-MP; Mon, 04 Jul 2005 09:05:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10710; Mon, 4 Jul 2005 09:05:14 -0400 (EDT) From: Vlad.Stirbu@nokia.com Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpR3y-0000FD-7H; Mon, 04 Jul 2005 09:32:44 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j64D270p006581; Mon, 4 Jul 2005 16:02:09 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Jul 2005 16:05:06 +0300 Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Jul 2005 16:05:06 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 4 Jul 2005 16:05:06 +0300 Message-ID: <1C1F3D15859526459B4DD0A7A9B2268BA0E6E3@trebe101.NOE.Nokia.com> Thread-Topic: Remote UI BoF at IETF63 Thread-Index: AcV+MXwRZWfGTPyVQFqdEcnmEwAB5ACY4mjQ To: , , X-OriginalArrivalTime: 04 Jul 2005 13:05:06.0274 (UTC) FILETIME=[FFAB7C20:01C58098] X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Cc: Subject: [REMOTEUI] RE: Remote UI BoF at IETF63 X-BeenThere: remoteui@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Remote UI BoF and future WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: remoteui-bounces@lists.ietf.org Errors-To: remoteui-bounces@lists.ietf.org Hi David, >=20 > Framebuffer-level protocols can be viewed as a special case=20 > of graphics-level > protocols where the drawing commands are restricted to=20 > bitblt-like commands. >=20 Yes, it is possible to have a graphics-level protocol with a restricted = functionality that is matching that of framebuffer-level protocol but = the overhead and the software and hardware complexity required are to = high. >=20 > Having the UI adapt to a look-and-feel appropriate to the=20 > client device > (and user's preferences) doesn't automatically imply that it has to be > the client that does this adaptation. The client could send=20 > the server a > description of the preferred L&F. The advantage of this is=20 > that it allows > clients to be much simpler, putting the complexity on the=20 > server which is > likely to have more memory, processing power, etc. >=20 Yes, you are right. For some simple devices you can do the customisation = on the server side in order to reduce the complexity, but in that case = it is probably best to use a framebuffer-level protocol rather than a = widget-level one; these simple clients typically don't have a windowing = system/widget set anyway.=20 The work proposed here is for advanced client devices that have their = own windowing system and their own widget sets, i.e. desktop, laptop or = tablet computers, PDAs or mobile phones. These devices have enough = resources and the means to do the scaling and adaptation by themselves. Vlad _______________________________________________ REMOTEUI mailing list REMOTEUI@lists.ietf.org https://www1.ietf.org/mailman/listinfo/remoteui From remoteui-bounces@lists.ietf.org Mon Jul 04 11:13:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpSd8-0005XK-E6; Mon, 04 Jul 2005 11:13:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpSVc-0003T9-VV; Mon, 04 Jul 2005 11:05:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27869; Mon, 4 Jul 2005 11:05:19 -0400 (EDT) Received: from v-mail.vsnl.com ([203.200.237.34] helo=vmail.vsnl.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpSwD-0001pw-Pq; Mon, 04 Jul 2005 11:32:50 -0400 Received: from MONICAFAMILY ([172.16.29.33]) by vmail.vsnl.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with SMTP id <0IJ300678Z8ALQ@vmail.vsnl.com>; Mon, 04 Jul 2005 20:34:59 +0530 (IST) Date: Mon, 04 Jul 2005 20:35:58 +0530 From: saravanan t s In-reply-to: <42C52A59.9080702@blueyonder.co.uk> To: ietf@ietf.org, remoteui@ietf.org Message-id: <003f01c580a9$e2e14690$e319320a@telxsi.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7BIT X-Mailman-Approved-At: Mon, 04 Jul 2005 11:13:06 -0400 Cc: Subject: [REMOTEUI] RE: Remote UI BoF at IETF63 X-BeenThere: remoteui@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: saravanants@tataelxsi.co.in List-Id: Remote UI BoF and future WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: remoteui-bounces@lists.ietf.org Errors-To: remoteui-bounces@lists.ietf.org Hi Vlad & others Just adding some opinions on this from my side, since I found this idea interesting: 1. Even though today's clients are powerful enough to handle the widgets and adaptation, maybe on the server side, certain computations and algos could be clubbed to reduce the load on the pda's and other devices. The extra resources (maybe read "power") on the pda's and other devices could be used for adding additional features (or maybe extending battery life?) 2. How many look and feel "standards" or maybe "UI Languages" the server can support? Does this imply that there will be only a limited set of L&F that can be supported by the server and rendered on the client? Will this be a limitation for different devices (talking of embedded) having different levels of needs on widgets (qualitatively: very simple to quite complex)? 3. On the other hand, there may be one more advantage to have clients send the description of the L&F sent to the server & server managing the client based on its description - is it possible that the bandwidth will be used more efficiently than the existing protocols that seem to achieve similar purposes for the end user? Regards, Saravanan T S >-----Original Message----- >From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org]On Behalf Of >David Hopwood >Sent: Friday, July 01, 2005 5:05 PM >To: ietf@ietf.org; remoteui@ietf.org >Subject: Re: Remote UI BoF at IETF63 > > >Vlad.Stirbu@nokia.com wrote: >> 3. Why this cannot be done with existing protocol? >> >> Existing protocols can be split in two categories: >framebuffer-level and >> graphics-level protocols. >> >> In the framebuffer-level protocol, the contents of the >framebuffer (i.e. the >> individual pixels) are copied across the network to a >framebuffer on the client. >> In order to avoid sending the full screen every time >something changed on the >> screen, these protocols typically send only the pixels that >are changed inside >> the clipping regions to the client. Examples of such >protocols are VNC and >> protocols based on T.120, like Microsoft's RDP. >> >> In the graphics-level protocol, the drawing request to the >graphical device >> interface (GDI), such as DrawLine(), DrawString(), etc. are >copied across the >> network. The client is responsible for interpreting these >commands and >> rendering the lines, rectangles, strings, etc. in its >framebuffer. Example of >> such protocol is X Windows. > >Framebuffer-level protocols can be viewed as a special case of >graphics-level >protocols where the drawing commands are restricted to >bitblt-like commands. > >> The problem with these approaches is that, in order to >render the UI, the >> clients are following blindly the instructions received from >the server; >> they don't have means to influence the appearance of the UI, >they just >> render the UI using the graphical elements/instructions that >are provided >> by the server and are specific to the server platform. > >Having the UI adapt to a look-and-feel appropriate to the client device >(and user's preferences) doesn't automatically imply that it has to be >the client that does this adaptation. The client could send >the server a >description of the preferred L&F. The advantage of this is >that it allows >clients to be much simpler, putting the complexity on the >server which is >likely to have more memory, processing power, etc. > >-- >David Hopwood > > >_______________________________________________ >Ietf mailing list >Ietf@ietf.org >https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ REMOTEUI mailing list REMOTEUI@lists.ietf.org https://www1.ietf.org/mailman/listinfo/remoteui From remoteui-bounces@lists.ietf.org Mon Jul 04 11:21:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpSku-0007F4-KV; Mon, 04 Jul 2005 11:21:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpSkt-0007Eu-CS; Mon, 04 Jul 2005 11:21:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00809; Mon, 4 Jul 2005 11:21:05 -0400 (EDT) From: Vlad.Stirbu@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpTBU-0003OB-Dj; Mon, 04 Jul 2005 11:48:36 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j64FGH0x014055; Mon, 4 Jul 2005 18:16:18 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Jul 2005 18:21:03 +0300 Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Jul 2005 18:21:02 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 4 Jul 2005 18:21:02 +0300 Message-ID: <1C1F3D15859526459B4DD0A7A9B2268BA0E6E4@trebe101.NOE.Nokia.com> Thread-Topic: Remote UI BoF at IETF63 Thread-Index: AcV+J5Ie3XXCBOGLQM6sdWBCIRB3PACcmheg To: , X-OriginalArrivalTime: 04 Jul 2005 15:21:02.0927 (UTC) FILETIME=[FD69F5F0:01C580AB] X-Spam-Score: 0.3 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Cc: remoteui@ietf.org Subject: [REMOTEUI] RE: Remote UI BoF at IETF63 X-BeenThere: remoteui@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Remote UI BoF and future WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: remoteui-bounces@lists.ietf.org Errors-To: remoteui-bounces@lists.ietf.org Hi Harald, I have to recognise that the name choice for this effort was not = entirely appropriate as it drags the spotlight on the "user interface" = while leaving the "remoting" unfairly in the shadows. > - What expertise do you see that the IETF has (and other=20 > groups do not=20 > have) that makes it the right body to work on this set of issues? With the risk of repeating what Dave already mentioned, I have to point = out that in the process of remoting a ui two entities (i.e. the server = and the client) are exchanging information about display objects (i.e. = widgets) over *the network*. As there are other bodies that have the experience on defining what = display objects are needed and what is their behaviour, the aim of this = effort is to develop an open, platform-independent mechanism of creating = and maintaining remote display objects and the focus should be on the = network-based mechanisms covering the connectivity, reliability, = security, etc., on which the IETF has the best experience around. > - What importance to the Internet does this work have that makes it a=20 > correct use of IETF resources? Broadband and wireless technology will enable more and more "smart" = devices (i.e. Internet tablets, PDAs, mobile phones, PCs, etc.) to be = connected to the Internet. Soon the proliferation of these devices will = make them the most numerous device "category" on the Internet and their = users will want to interact remotely, for various reasons, with = applications that are not hosted on the devices; thus, making this = effort fit within IETF's scope "protocols and practices for which secure = and scalable implementations are expected to have wide deployment and = interoperation on the Internet, or to form part of the infrastructure of = the Internet."=20 Vlad _______________________________________________ REMOTEUI mailing list REMOTEUI@lists.ietf.org https://www1.ietf.org/mailman/listinfo/remoteui From remoteui-bounces@lists.ietf.org Tue Jul 05 04:01:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpiMq-0006cY-O4; Tue, 05 Jul 2005 04:01:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpiMo-0006Zw-93; Tue, 05 Jul 2005 04:01:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16104; Tue, 5 Jul 2005 04:01:16 -0400 (EDT) From: Vlad.Stirbu@nokia.com Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpinX-00054j-3x; Tue, 05 Jul 2005 04:28:56 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j658133k002987; Tue, 5 Jul 2005 11:01:08 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jul 2005 11:01:08 +0300 Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jul 2005 11:01:07 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Jul 2005 11:01:07 +0300 Message-ID: <1C1F3D15859526459B4DD0A7A9B2268BA0E6E7@trebe101.NOE.Nokia.com> Thread-Topic: Remote UI BoF at IETF63 Thread-Index: AcWAqpK52BNmrEMmRk2OFDfA5bYIRwAiBqHA To: , , X-OriginalArrivalTime: 05 Jul 2005 08:01:07.0883 (UTC) FILETIME=[B3279FB0:01C58137] X-Spam-Score: 0.3 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable Cc: Subject: [REMOTEUI] RE: Remote UI BoF at IETF63 X-BeenThere: remoteui@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Remote UI BoF and future WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: remoteui-bounces@lists.ietf.org Errors-To: remoteui-bounces@lists.ietf.org Hi, > -----Original Message----- > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org]On Behalf Of > ext saravanan t s > Sent: 04 July, 2005 18:06 > To: ietf@ietf.org; remoteui@ietf.org > Subject: RE: Remote UI BoF at IETF63 >=20 >=20 > Hi Vlad & others >=20 > Just adding some opinions on this from my side, since I found=20 > this idea > interesting: >=20 > 1. Even though today's clients are powerful enough to handle=20 > the widgets and > adaptation, maybe on the server side, certain computations=20 > and algos could > be clubbed to reduce the load on the pda's and other devices.=20 > The extra > resources (maybe read "power") on the pda's and other devices=20 > could be used > for adding additional features (or maybe extending battery life?) >=20 Talking about power saving, I think that the most important feature that = we have here is that the application logic is run entirely in the server = side. This thing will definitely save power and also will reduce the = software complexity of the client. If the client supports widgets = natively it will use them anyway to render the UI regardless the = adaptation is done on the server side or not. Lets not forget that the servers also are not having unlimited resources = and it would be nice to use the resources where they are available (i.e. = clients with native widgets). > 2. How many look and feel "standards" or maybe "UI Languages"=20 > the server can > support? Does this imply that there will be only a limited=20 > set of L&F that > can be supported by the server and rendered on the client?=20 > Will this be a > limitation for different devices (talking of embedded) having=20 > different > levels of needs on widgets (qualitatively: very simple to=20 > quite complex)? >=20 The protocol should be UI language independent and I believe that it = will not add "technical" constraints on the server side, those will be = rather of "business" nature. >From the protocol point of view the UI is just a collection of widgets. = Now it is up to the widgets to be very simple or complex. > 3. On the other hand, there may be one more advantage to have=20 > clients send > the description of the L&F sent to the server & server=20 > managing the client > based on its description - is it possible that the bandwidth=20 > will be used > more efficiently than the existing protocols that seem to=20 > achieve similar > purposes for the end user? >=20 I think that by sending widget description over the wire you already use = the bandwidth more efficiently than existing protocols (i.e. = framebuffer-level or graphics-level) which tend to send more "screen = captures" that in the end eats more bandwidth. Even so, in the case of widget-level protocol, the client and server = exchange information about look and feel during the "session setup" = step. Please have a look at the proposed protocol draft here = http://www.ietf.org/internet-drafts/draft-stirbu-lrdp-00.txt. Vlad =20 _______________________________________________ REMOTEUI mailing list REMOTEUI@lists.ietf.org https://www1.ietf.org/mailman/listinfo/remoteui From remoteui-bounces@lists.ietf.org Tue Jul 05 10:18:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpoFP-0000rv-PW; Tue, 05 Jul 2005 10:18:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpoFJ-0000oj-7P; Tue, 05 Jul 2005 10:17:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27889; Tue, 5 Jul 2005 10:17:52 -0400 (EDT) Received: from v-mail.vsnl.com ([203.200.237.34] helo=vmail.vsnl.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dpod9-0003Ih-2W; Tue, 05 Jul 2005 10:42:35 -0400 Received: from MONICAFAMILY ([172.16.29.33]) by vmail.vsnl.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with SMTP id <0IJ500721RKIH7@vmail.vsnl.com>; Tue, 05 Jul 2005 19:44:43 +0530 (IST) Date: Tue, 05 Jul 2005 19:45:42 +0530 From: saravanan t s In-reply-to: <1C1F3D15859526459B4DD0A7A9B2268BA0E6E7@trebe101.NOE.Nokia.com> To: Vlad.Stirbu@nokia.com, ietf@ietf.org, remoteui@ietf.org Message-id: <005901c5816c$07ae9460$e319320a@telxsi.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: 7BIT Cc: Subject: [REMOTEUI] RE: Remote UI BoF at IETF63 X-BeenThere: remoteui@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: saravanants@tataelxsi.co.in List-Id: Remote UI BoF and future WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: remoteui-bounces@lists.ietf.org Errors-To: remoteui-bounces@lists.ietf.org Hi Vlad, Thanks for the reply. I will now go through the draft for a better understanding. Regards, Saravanan T S >-----Original Message----- >From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org]On Behalf Of >Vlad.Stirbu@nokia.com >Sent: Tuesday, July 05, 2005 1:31 PM >To: saravanants@tataelxsi.co.in; ietf@ietf.org; remoteui@ietf.org >Subject: RE: Remote UI BoF at IETF63 > > >Hi, > >> -----Original Message----- >> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org]On >Behalf Of >> ext saravanan t s >> Sent: 04 July, 2005 18:06 >> To: ietf@ietf.org; remoteui@ietf.org >> Subject: RE: Remote UI BoF at IETF63 >> >> >> Hi Vlad & others >> >> Just adding some opinions on this from my side, since I found >> this idea >> interesting: >> >> 1. Even though today's clients are powerful enough to handle >> the widgets and >> adaptation, maybe on the server side, certain computations >> and algos could >> be clubbed to reduce the load on the pda's and other devices. >> The extra >> resources (maybe read "power") on the pda's and other devices >> could be used >> for adding additional features (or maybe extending battery life?) >> > >Talking about power saving, I think that the most important >feature that we have here is that the application logic is run >entirely in the server side. This thing will definitely save >power and also will reduce the software complexity of the >client. If the client supports widgets natively it will use >them anyway to render the UI regardless the adaptation is done >on the server side or not. > >Lets not forget that the servers also are not having unlimited >resources and it would be nice to use the resources where they >are available (i.e. clients with native widgets). > >> 2. How many look and feel "standards" or maybe "UI Languages" >> the server can >> support? Does this imply that there will be only a limited >> set of L&F that >> can be supported by the server and rendered on the client? >> Will this be a >> limitation for different devices (talking of embedded) having >> different >> levels of needs on widgets (qualitatively: very simple to >> quite complex)? >> > >The protocol should be UI language independent and I believe >that it will not add "technical" constraints on the server >side, those will be rather of "business" nature. > >>From the protocol point of view the UI is just a collection >of widgets. Now it is up to the widgets to be very simple or complex. > >> 3. On the other hand, there may be one more advantage to have >> clients send >> the description of the L&F sent to the server & server >> managing the client >> based on its description - is it possible that the bandwidth >> will be used >> more efficiently than the existing protocols that seem to >> achieve similar >> purposes for the end user? >> > >I think that by sending widget description over the wire you >already use the bandwidth more efficiently than existing >protocols (i.e. framebuffer-level or graphics-level) which >tend to send more "screen captures" that in the end eats more >bandwidth. > >Even so, in the case of widget-level protocol, the client and >server exchange information about look and feel during the >"session setup" step. Please have a look at the proposed >protocol draft here >http://www.ietf.org/internet-drafts/draft->stirbu-lrdp-00.txt. > >Vlad > > >_______________________________________________ >Ietf mailing list >Ietf@ietf.org >https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ REMOTEUI mailing list REMOTEUI@lists.ietf.org https://www1.ietf.org/mailman/listinfo/remoteui From remoteui-bounces@lists.ietf.org Tue Jul 05 11:40:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DppXY-0000j0-IG; Tue, 05 Jul 2005 11:40:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DppXW-0000g1-K6; Tue, 05 Jul 2005 11:40:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11443; Tue, 5 Jul 2005 11:40:46 -0400 (EDT) Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DppqQ-0001Rz-Vj; Tue, 05 Jul 2005 12:00:24 -0400 Received: from [192.168.0.251] (adsl-67-112-201-9.dsl.sntc01.pacbell.net [67.112.201.9]) (authenticated bits=0) by sb7.songbird.com (8.12.11/8.12.11) with ESMTP id j65FWve7000743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Jul 2005 08:32:58 -0700 Message-ID: <42CAA7F9.7000407@dcrocker.net> Date: Tue, 05 Jul 2005 08:32:09 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vlad.Stirbu@nokia.com References: <1C1F3D15859526459B4DD0A7A9B2268BA0E6E7@trebe101.NOE.Nokia.com> In-Reply-To: <1C1F3D15859526459B4DD0A7A9B2268BA0E6E7@trebe101.NOE.Nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Found to be clean X-Songbird-From: dhc2@dcrocker.net X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: ietf@ietf.org, remoteui@ietf.org Subject: [REMOTEUI] Re: Remote UI BoF at IETF63 X-BeenThere: remoteui@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Remote UI BoF and future WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: remoteui-bounces@lists.ietf.org Errors-To: remoteui-bounces@lists.ietf.org > Talking about power saving, I think that the most important feature that we > have here is that the application logic is run entirely in the server side. > This thing will definitely save power and also will reduce the software > complexity of the client. on the other hand, having all the semantics on the server means that there will be a higher interaction rate with the server. More network traffic and therefore the client will be doing more network i/o. that takes power. > I think that by sending widget description over the wire you already use > the bandwidth more efficiently than existing protocols (i.e. > ramebuffer-level or graphics-level) which tend to send more > "screen captures" that in the end eats more bandwidth. right. -- d/ Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net _______________________________________________ REMOTEUI mailing list REMOTEUI@lists.ietf.org https://www1.ietf.org/mailman/listinfo/remoteui From remoteui-bounces@lists.ietf.org Fri Jul 22 02:47:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvrJJ-0008GI-94; Fri, 22 Jul 2005 02:47:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvllm-0000rv-Ng for remoteui@megatron.ietf.org; Thu, 21 Jul 2005 20:52:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07014 for ; Thu, 21 Jul 2005 20:52:05 -0400 (EDT) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvmFu-0006Xx-F6 for remoteui@ietf.org; Thu, 21 Jul 2005 21:23:15 -0400 Received: from [64.101.149.168] ([64.101.149.168]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id j6M0ttEx014894 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Thu, 21 Jul 2005 19:55:56 -0500 Mime-Version: 1.0 (Apple Message framework v622) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: remoteui@ietf.org From: Dean Willis Date: Thu, 21 Jul 2005 19:52:08 -0500 X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 22 Jul 2005 02:47:04 -0400 Cc: Subject: [REMOTEUI] Proposed Agenda for BoF at IETF 63 X-BeenThere: remoteui@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Remote UI BoF and future WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: remoteui-bounces@lists.ietf.org Errors-To: remoteui-bounces@lists.ietf.org I've posted (and will update as appropriate) a draft agenda for the Remote UI BOF at: http://www.softarmor.com/rui/meets/ietf63/agenda.html Note that the RUI supplementary web page at http://www.softarmor.com/rui/ currently has related information. Please provide feedback about the agenda ASAP. The draft agenda follows: Agenda Bashing, 5 min Introduction & Background information, 10 min W3C Multimodal Interaction Work, Dave Raggett, 10 min Discussion: Problem Statement, 20 min Discussion: Possible Solutions, 15 min Discussion: Deliverables, 20 min Requirements Doc Framework Doc Protocol Doc(s) Next Steps/WG Charter (10 min) -- Dean Willis BOF cochair _______________________________________________ REMOTEUI mailing list REMOTEUI@lists.ietf.org https://www1.ietf.org/mailman/listinfo/remoteui From remoteui-bounces@lists.ietf.org Fri Jul 22 10:08:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvyCB-0001AK-6o; Fri, 22 Jul 2005 10:08:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvyC9-00018D-Mh for remoteui@megatron.ietf.org; Fri, 22 Jul 2005 10:08:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17423 for ; Fri, 22 Jul 2005 10:08:06 -0400 (EDT) Received: from hagen.doit.wisc.edu ([144.92.197.163] helo=smtp7.wiscmail.wisc.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvygM-00070X-5P for remoteui@ietf.org; Fri, 22 Jul 2005 10:39:25 -0400 Received: from avs-daemon.smtp7.wiscmail.wisc.edu by smtp7.wiscmail.wisc.edu (iPlanet Messaging Server 5.2 HotFix 2.04 (built Feb 8 2005)) id <0IK10033M8L58S@smtp7.wiscmail.wisc.edu> for remoteui@ietf.org; Fri, 22 Jul 2005 09:07:53 -0500 (CDT) Received: from ThinkPadR40 (p549D1FE7.dip0.t-ipconnect.de [84.157.31.231]) by smtp7.wiscmail.wisc.edu (iPlanet Messaging Server 5.2 HotFix 2.04 (built Feb 8 2005)) with ESMTPSA id <0IK1009QP8L2L1@smtp7.wiscmail.wisc.edu>; Fri, 22 Jul 2005 09:07:52 -0500 (CDT) Date: Fri, 22 Jul 2005 16:07:48 +0200 From: Gottfried Zimmermann In-reply-to: To: remoteui@ietf.org Message-id: <006b01c58ec6$bee42a20$7001a8c0@ThinkPadR40> Organization: Trace Center MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.4510 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Report: AuthenticatedSender=yes, SenderIP=84.157.31.231 X-Spam-PmxInfo: Server=avs-5, Version=4.7.1.128075, Antispam-Engine: 2.0.3.1, Antispam-Data: 2005.7.22.11, SenderIP=84.157.31.231 Keywords: Trace X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7BIT Cc: Subject: [REMOTEUI] Input for BoF session X-BeenThere: remoteui@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: zimmer@trace.wisc.edu List-Id: Remote UI BoF and future WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: remoteui-bounces@lists.ietf.org Errors-To: remoteui-bounces@lists.ietf.org Hi, since i will not be able to participate at the BoF in Paris the week after next week, here some input for the session: (1) I welcome the effort on developing a ui exchange protocol for facilitation of remote uis across platforms. (2) The protocol should also work across multiple modalities of user interfaces and their input and output components, e.g. graphical, auditory, or tactile output or any combination of these. Therefore the protocol should talk about "ui components" rather than "widgets". UI components (or interactors) are modality-independent, but are of course rendered in a specific way on a specific system. (3) Example use case: A user starts an interaction with a ticket sales service from their mobile phone by using the graphical user interface of the service. Then the user enters a car and drives away, continuing the interaction by using voice only. (4) A couple of references may be useful for this development effort: * The upcoming V2-URC (Universal Remote Console) standard which defines a set of modality-neutral interactors (defined in a "Presentation Template"). www.myurc.com. * The XForms 1.0 form controls, http://www.w3.org/TR/2003/REC-xforms-20031014/slice8.html. Have a good session in Paris, Gottfried ___________________________________________________ Gottfried Zimmermann, Ph.D. Phone +49 7121 790806 ICT Systems Architect under contract for: Trace R&D Center, University of Wisconsin-Madison ___________________________________________________ _______________________________________________ REMOTEUI mailing list REMOTEUI@lists.ietf.org https://www1.ietf.org/mailman/listinfo/remoteui