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