Re: [Widex] Updated Widex requirements draft
Rosfran Lins Borges <rosfran.borges@indt.org.br> Wed, 12 April 2006 02:02 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTUgW-0004ao-Aj; Tue, 11 Apr 2006 22:02:20 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTUgU-0004ad-SP for widex@ietf.org; Tue, 11 Apr 2006 22:02:18 -0400
Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTUgS-0007oS-Ce for widex@ietf.org; Tue, 11 Apr 2006 22:02:18 -0400
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k3C216oN013826 for <widex@ietf.org>; Wed, 12 Apr 2006 05:01:07 +0300
Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Apr 2006 05:02:15 +0300
Received: from daebe102.NOE.Nokia.com ([10.241.35.115]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Apr 2006 21:02:12 -0500
Received: from [172.19.141.58] ([172.19.141.58]) by daebe102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Apr 2006 21:02:11 -0500
Message-ID: <443C5E46.2030703@indt.org.br>
Date: Tue, 11 Apr 2006 22:56:22 -0300
From: Rosfran Lins Borges <rosfran.borges@indt.org.br>
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: Re: [Widex] Updated Widex requirements draft
References: <1C1F3D15859526459B4DD0A7A9B2268B01F272CB@trebe101.NOE.Nokia.com>
In-Reply-To: <1C1F3D15859526459B4DD0A7A9B2268B01F272CB@trebe101.NOE.Nokia.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 12 Apr 2006 02:02:12.0122 (UTC) FILETIME=[1CEB07A0:01C65DD5]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d
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
Hi, A minor (maybe) fix: at the following section (3.4), in the Widex requirements draft 01, where there is a reference to "RUIOs", maybe should be "WOs" (Widex Objects). "3.4. Transport Protocol The Transport Protocol is a protocol that just transports the RUIOs as a string of bits, without looking at them." -- Rosfran Borges ext widex-bounces@ietf.org wrote: > Hi, > > Updated version of the Widex requirements draft 01 available at > _http://www.kolumbus.fi/vlad.stirbu/draft-ietf-widex-requirements-01.txt_. > It will be available shortly also in the IETF drafts repository. > > The draft addresses the comments raised during IETF65: > > * Dean: Can we have multiple Widex sessions between client and server? > That would require more than just URI. Dave: Assuming single > > session. Need to document. > - Addressed in section 3.6 > > * Lisa: Strongly suggest making which DOM to modify explicit, not > implicit. > - Addressed in section 5.3 > > * Need to get clarity from REX folks on DOM3 and QNames. We could > work around it by specifying namespaces as a separate attribute or > element. > > - TODO for the framework > > * Need to do addressing (identifying session and DOM tree) in the > protocol. Need to put this into the framework. > - TODO for the framework > > * We cannot have all DOM events get transferred over-the-wire. Need to > figure out how to specify what DOM events at the client get the server > gets notified of. Is it by provisioning (i.e., this application has > these events) or by negotiation? > > - See next bullet. > > * Should UI events that do not update the DOM get propagated via Widex > or the application, such as input focus, text selection, cursor > position? Vlad thinks they should be left out. Dave: Someone needs to > deal with it, but it could be external to Widex. Vlad: Widex needs to > communicate stuff that is relevant to modality. Dave: These are > application events, not strictly UI events. > > - Addressed in section 5.3 > > * Add requirement for not reporting all DOM events from the renderer. > - Addressed in section 3.3 in the WO.Event definition. > > Cheers, > Vlad > >------------------------------------------------------------------------ > >_______________________________________________ >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
- [Widex] Updated Widex requirements draft Vlad.Stirbu
- Re: [Widex] Updated Widex requirements draft Rosfran Lins Borges