[Widex] Draft minutes for WIDEX at IETF 66
Dean Willis <dean.willis@softarmor.com> Thu, 27 July 2006 04:13 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5xFY-00006O-HZ; Thu, 27 Jul 2006 00:13:28 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5xFX-00005i-0n for widex@ietf.org; Thu, 27 Jul 2006 00:13:27 -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 1G5xFW-0001BW-Ui for widex@ietf.org; Thu, 27 Jul 2006 00:13:26 -0400
Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G5xDm-0000AS-GA for widex@ietf.org; Thu, 27 Jul 2006 00:11:40 -0400
Received: from [206.176.144.210] (206-176-144-210.waymark.net [206.176.144.210]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k6R4DXpQ011530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <widex@ietf.org>; Wed, 26 Jul 2006 23:13:34 -0500
Message-ID: <44C83CFF.2000204@softarmor.com>
Date: Wed, 26 Jul 2006 23:11:43 -0500
From: Dean Willis <dean.willis@softarmor.com>
User-Agent: Thunderbird 1.5.0.4 (X11/20060516)
MIME-Version: 1.0
To: widex@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: -2.6 (--)
X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34
Subject: [Widex] Draft minutes for WIDEX at IETF 66
X-BeenThere: widex@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Working list for the WIDEX working group at IETF <widex.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/widex>, <mailto:widex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/widex>
List-Post: <mailto:widex@ietf.org>
List-Help: <mailto:widex-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/widex>, <mailto:widex-request@ietf.org?subject=subscribe>
Errors-To: widex-bounces@ietf.org
I've posted the first draft of minutes for WIDEX at IETF 66 at: http://www.softarmor.com/widex/meets/ietf66/notes/minutes-widex-66.html Text follows. Please review for accuracy -- they are a couple of points in there where I think I might have missed something. ------------------ Minutes for WIDEX at IETF 66 The WIDEX working group met on Monday July 10, 66 IETF, Montreal Edited by Dean Willis based on notes by Dave Raggett and Vlad Stirbu Topic: Agenda and Status led by Dean Willis Slides presented. Meeting chair Dean Willis introduces the meeting and starts with the Agenda bash. He reminds people to use the microphone as we may be being streamed to a wider audience. Dave asks if he can talk about HTTP bindings before REX. Dean agrees to this. Vlad launches into the presentation on the Widex Requirements. It has gone through two revisions and has had no objections. The next step is to send it to the IESG for publication, ACTION Dean to forward the Widex Requirements to the IESG Topic: Widex Framework draft. led by Vlad Stirbu Slides presented He summarizes the major updates: * which events have remote scope * clarifications on event listeners * clarifications on networked MVC model - real vs virtual view There are 3 ways to indicate that events have remote scope * prior agreememt * negotiation at session setup, e.g. as a list of event names * Dynamic addition/removal during the session The last led to the addition of a new Widex object called WO.Selector. Some UI markup languages don't include the means to indicate at markup level for event bindings. This is why we defined this new object. A section has been added on processing external resources such as images or sound. It is the responsibility of the Widex Renderer to retrieve these. * references to external resources * synchronization with external resources Next steps: * Add WO.* examples when next draft of REX is available * Add XML Processing parameters to the Service discovery section, e.g. encoding and charset * Are major things missing? Poll: Can we consider adopting the draft framework as a Working Group document? Ted: Can't you reference the public version of REX and update that as we move along? Vlad: the unpublished version addresses the comments we provided on the first public working draft. Dean: when do you think the next draft will be published? Dave: I will talk about this later Vlad: Dave and I have done some implementation work and it seems pretty effective. Dean: there was quite a bit of discussion on the email list and this has died down which is a good sign. Eric: lets come back to the question of whether it is adopted after we have heard about the status of REX. Topic: BEEP bindings for WIDEX led by Vlad Stirbu Slides presented This is aimed at resource constrained devices. There is a one to one relationship between BEEP messages and Widex objects. Dean: is there a potential need to place multiple Widex objects in the same BEEP message for efficiency? Vlad: REX already provides a means to do that Dean: do we really need a new URL scheme? Vlad: BEEP doesn't define its own scheme and leaves that to application specifications. Vlad asks if external resources should be handled in band or separately. Ted: don't put them into the same channel, and in many cases it would be appropriate to use different streams on other protocols. BEEP makes it easy to multiplex channels. Dave Blacker and Andy Newton would be good people to review this as they have done some recent work with BEEP and are familiar with other BEEP applications. Dean talks about two approaches to making documents WG documents. One is to do it early as a sign of concensus and to solicit review, the other is to wait until it is nearly finished. What does the Director recommend? Lisa: it seems that Vlad has a preference for the former Vlad: does it need to wait until there are implementations? No, early review is valuable, even before implementations. We then went into a discussion of pipelining in BEEP. It seems that BEEP supports pipelining naturally, but it is advisable to use multiple channels to avoid a large resource blocking a smaller resource. Using separate channels avoids this. Dean suggests a large SVG document as an example. Vlad: if the UI markup includes a reference to an SVG resource then it is treated as a external resource and should be handled as such via a separate channel. If the resource is included in the UI markup then it can slow down loading. Vlad asks if the document is ready to be adopted as a WG document? Dean asks Eric for his opinion. Response is inconclusive. ACTION: Dean to raise an email poll on adoption of BEEP profile as a Widex WG document Topic: HTTP binding led by Dave Raggett Slides presented Slides incude a good overview of the technique. Discusion followed. Ted Hardie: one REX document from the server but is this true for the renderer also? Dave Raggett: yes a continous POST from the Renderer TH: no need to to the same in both direction. one xml from the server and many small requests from the renderer. Lisa: ADs don't feel that the proposed extensions are in line with the way HTTP was intended to be extended. TH: Suggest we extend HTTP with mime types. We need to spend time to bullet proof this HTTP binding. Solve the issues with HTTP's nature before pushing forward. HTTP might not be the way forward to pass beyond ajax. There migh also be problems with deep inspection proxies that inspect HTTP POST. DW: parallel with SIP on symmetric HTTP TH: HTTP is stateless and you need to layer state over http. REX Status I Petterson: some interoperability problems might appear with event packaging if one widex element makes assumptions about the other end. Topic: Situation on W3C REX and influence on us led by Dave raggett Slides presented The primary issue is that W3C work on REX appears to be stalled, following an IPR delcaration by Rance Telecom. Action: Ted has filed a 3rd party IPR declaration to IETF. Action: WG to review the IPR disclosures from FT and think about how they affect us. Chair to raise discussion on-list. Topic: SIP Binding led by Dean Willis no slides presented There appears to be a consensus not to pursue a SIP binding at this time, although the working group may revisit this at a future date. Meeting closed with 15 minutes remaining. _______________________________________________ Widex mailing list Widex@ietf.org https://www1.ietf.org/mailman/listinfo/widex
- [Widex] Draft minutes for WIDEX at IETF 66 Dean Willis