From widex-bounces@ietf.org Tue Jan 09 18:50:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Qjk-0007YT-J4; Tue, 09 Jan 2007 18:50:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4Qjg-0007TS-WE; Tue, 09 Jan 2007 18:50:33 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H4Qjg-0003lm-M7; Tue, 09 Jan 2007 18:50:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 84D2F2AD37; Tue, 9 Jan 2007 23:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H4QjC-00045m-A4; Tue, 09 Jan 2007 18:50:02 -0500 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, 09 Jan 2007 18:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: widex@ietf.org Subject: [Widex] I-D ACTION:draft-ietf-widex-requirements-04.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-04.txt Pages : 11 Date : 2007-1-9 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-04.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-04.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-04.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: <2007-1-9153504.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-widex-requirements-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-widex-requirements-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-9153504.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 Tue Jan 16 14:42:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6uC1-00005W-Oh; Tue, 16 Jan 2007 14:42:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6TCz-0002ev-DB for widex@ietf.org; Mon, 15 Jan 2007 09:53:13 -0500 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6TCv-0000Mn-7a for widex@ietf.org; Mon, 15 Jan 2007 09:53:13 -0500 Received: from [127.0.0.1] (mail.songbird.com [208.184.79.10]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l0FEqxX5011283 for ; Mon, 15 Jan 2007 06:53:00 -0800 Message-ID: <45AB84D7.6090604@ninebynine.org> Date: Mon, 15 Jan 2007 13:42:47 +0000 From: Graham Klyne User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: widex@ietf.org X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: gk@ninebynine.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 X-Mailman-Approved-At: Tue, 16 Jan 2007 14:41:54 -0500 Subject: [Widex] Comments on http://www.ietf.org/internet-drafts/draft-ietf-widex-requirements-04.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 Hi, I just read through: http://www.ietf.org/internet-drafts/draft-ietf-widex-requirements-04.txt and I think there are a couple of areas where the requirements as stated aren't entirely clear: - Section 4.1, 4th bullet (The framework SHOULD be stateless): I *think* I know what this is intended to mean, but in light of the preceding section 3.8 there seems some scope for confusion. Also, section 4.3 bullet 4 seems to imply that the WO must contain some (session-related) state. What is unclear is the scope of the "framework" that should be stateless. - Section 4.4: I guess the "Widex protocol" is just the same as the "transport protocol" mentioned in section 3.5? Or is there more? ... I'm interested in this work, in part, as I'm working on systems using web protocols and systems for real-time monitoring and control purposes, some of which overlap applications hinted at in your draft. I'm concerned that the requirement for reliable and in-order delivery (section 4.4) of events may be rather hard to implement on some of our devices (currently based on PIC microchips), and unnecessary, in an environment where we are using UDP packets to deliver events. (I recognize the need for in-order delivery of updates.) Such events might be coupled to, say, physical switches that are used to generate on/off type signals. You mention, as an example, the role of a TV set as a secondary display. Would it also not be desirable for the TV set's IR remote to serve as a secondary input? But for IR signals, there is no reliable-delivery protocol. What this leads to is wanting to better understand the intended scope of the WIDEX framework, and how it might interact with other interfaces "at the edge". ... Another application I foresee for this work, from work supporting life science research activities, is the kind of experience currently provided imperfectly by web portals -- allowing users to interact with multiple resources, and have those interactions maintained in some kind of synchrony. That seems quite well covered by your requirements. #g -- Graham Klyne For email: http://www.ninebynine.org/#Contact _______________________________________________ Widex mailing list Widex@ietf.org https://www1.ietf.org/mailman/listinfo/widex From widex-bounces@ietf.org Thu Jan 18 14:43:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7dAB-0005o6-Gx; Thu, 18 Jan 2007 14:43:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7dAA-0005lx-Dd for widex@ietf.org; Thu, 18 Jan 2007 14:43:06 -0500 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7dA7-0001VZ-TV for widex@ietf.org; Thu, 18 Jan 2007 14:43:06 -0500 Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 3A0AA14226C; Thu, 18 Jan 2007 11:42:57 -0800 (PST) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23999-04; Thu, 18 Jan 2007 11:42:54 -0800 (PST) Received: from [192.168.1.101] (c-69-181-78-47.hsd1.ca.comcast.net [69.181.78.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id A4D1814225E; Thu, 18 Jan 2007 11:42:54 -0800 (PST) In-Reply-To: <45AB84D7.6090604@ninebynine.org> References: <45AB84D7.6090604@ninebynine.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <47D8E7F4-F5D2-4A96-A98B-F38D68B82B4F@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [Widex] Comments on http://www.ietf.org/internet-drafts/draft-ietf-widex-requirements-04.txt Date: Thu, 18 Jan 2007 11:42:52 -0800 To: Graham Klyne X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e 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 Hi Graham, These comments came in after the close of IETF Last Call (well after). Are these issues specific to the changes that were made in draft -04, the one that was published after IETF Last Call? Or are any of these issue very important given that we're publishing this as a record of work done and not proceeding with Standards Track WIDEX protocol documents at this time? BTW, thanks regardless for the review... it doesn't hurt to get this on the record anyway. And I tried to answer one of your questions below, inline. Vlad, are there any comments here you believe need to be addressed in a new draft or answers for Graham's questions? Lisa On Jan 15, 2007, at 5:42 AM, Graham Klyne wrote: > Hi, > > I just read through: > > http://www.ietf.org/internet-drafts/draft-ietf-widex- > requirements-04.txt > > and I think there are a couple of areas where the requirements as > stated aren't > entirely clear: > > - Section 4.1, 4th bullet (The framework SHOULD be stateless): I > *think* I know > what this is intended to mean, but in light of the preceding > section 3.8 there > seems some scope for confusion. Also, section 4.3 bullet 4 seems > to imply that > the WO must contain some (session-related) state. What is unclear > is the scope > of the "framework" that should be stateless. > > - Section 4.4: I guess the "Widex protocol" is just the same as > the "transport > protocol" mentioned in section 3.5? Or is there more? The WG has previously considered binding the WIDEX messages either to BEEP or to some other transport (possibly one more likely to traverse NATs; XMPP and HTTP-based stuff have been at least mentioned). I understand this section to be requirements on the choice of an appropriate layer to use below the WIDEX messages. > > ... > > I'm interested in this work, in part, as I'm working on systems > using web > protocols and systems for real-time monitoring and control > purposes, some of > which overlap applications hinted at in your draft. > > I'm concerned that the requirement for reliable and in-order > delivery (section > 4.4) of events may be rather hard to implement on some of our > devices (currently > based on PIC microchips), and unnecessary, in an environment where > we are using > UDP packets to deliver events. (I recognize the need for in-order > delivery of > updates.) Such events might be coupled to, say, physical switches > that are used > to generate on/off type signals. > > You mention, as an example, the role of a TV set as a secondary > display. Would > it also not be desirable for the TV set's IR remote to serve as a > secondary > input? But for IR signals, there is no reliable-delivery > protocol. What this > leads to is wanting to better understand the intended scope of the > WIDEX > framework, and how it might interact with other interfaces "at the > edge". > > ... > > Another application I foresee for this work, from work supporting > life science > research activities, is the kind of experience currently provided > imperfectly by > web portals -- allowing users to interact with multiple resources, > and have > those interactions maintained in some kind of synchrony. That > seems quite well > covered by your requirements. > > #g > > -- > Graham Klyne > For email: > http://www.ninebynine.org/#Contact > > > > > _______________________________________________ > 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