From widex-bounces@ietf.org Mon Apr 03 14:06:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQTRj-0000Lm-SQ; Mon, 03 Apr 2006 14:06:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQTRi-0000Lh-42 for widex@ietf.org; Mon, 03 Apr 2006 14:06:34 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQTRh-0005cb-Iu for widex@ietf.org; Mon, 03 Apr 2006 14:06:34 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k33I5uPJ007484; Mon, 3 Apr 2006 21:05:56 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Apr 2006 21:06:33 +0300 Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Apr 2006 21:06:31 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Widex] suggestions re timestamps Date: Mon, 3 Apr 2006 21:06:30 +0300 Message-ID: <1C1F3D15859526459B4DD0A7A9B2268B01E89946@trebe101.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Widex] suggestions re timestamps Thread-Index: AcZPZobOdQO0gkCRSQm2N4yfP7TesQH3zx/w From: To: , X-OriginalArrivalTime: 03 Apr 2006 18:06:31.0991 (UTC) FILETIME=[565EA470:01C65749] X-Spam-Score: 0.2 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: 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 Dave, I agree with your proposal to define the timestamp as "non-negative integer denoting the number of milliseconds from the current reference point". This can be considered as good baseline for processing time stamps which probably suits most environments. Looking at how REX is defining the meaning of the timestamp (e.g. "an integer in milliseconds relative to the epoch") I noticed that the format is the same (e.g. an integer) and only the processing model is different. The difference between the Widex proposal and the REX model is that Widex has relative reference point while REX has absolute reference point (e.g. 00:00:00 UTC 1st January 1970). There are good reasons for using relative and absolute reference points depending on the deploying environment. In order to better accommodate these environments, the Widex framework can make use of the Service Discovey component to enable the Widex Renderer and the Widex Server to negociate and agree on a common processing model for the timestamp. Thus, we can consider that the relative reference point is the default processing model for timestamps but more demanding environments (e.g. MORE - where streaming is involved) can use the absolute reference point as defined by REX. In addition, by negociating the processing model for the timestamp during service discovery step, we allow particular environments to deploy their own processing models, which could be undefined at this time, without affecting the core Widex framework. Vlad >-----Original Message----- >From: ext Dave Raggett [mailto:dsr@w3.org]=20 >Sent: 24 March, 2006 19:15 >To: widex@ietf.org >Subject: [Widex] suggestions re timestamps > >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >In the face to face meeting on Thursday, we discussed the=20 >potential problems with how REX specifies timestamps for=20 >updates that are intended to be applied at a future time. > >REX currently specifies these in terms of the renderer's clock=20 >as milliseconds since the start of 1970 GMT. The problem is=20 >the likelihood of a significant clock skew between the=20 >renderer and the server, and the latency incurred by the=20 >protocol. This makes it difficult to the server to set the=20 >appropriate timestamps when the update is to be applied in a=20 >relatively short time interval into the future. > >In principle, the server may be able to estimate the clock=20 >skew and the network latency from a sequence of interactions=20 >with the renderer, but this is tricky and subject to uncertainties. > >W3C's SMIL language deals with this by allowing you to specify=20 >event timestamps in terms off timed offsets from other events=20 >(the beginning or end of a give presentation). SMIL isn't=20 >itself a solution to Widex as it doesn't deal with the means=20 >to transport DOM events and updates. > >Widex/REX could use the SMIL event-value syntax, which=20 >includes a reference to a named event and a signed time=20 >offset. This would be very general, but comes with an=20 >implementation overhead that may not be acceptable in all=20 >environments. A simpler approach would be use non-negative=20 >timed offsets from an implicit reference event. You would be=20 >able to designate that a given event is the new reference=20 >point, replacing the previous reference point. The initial=20 >reference point is the start of the session. > >This technique avoids the need to record the times of events=20 >as they are applied. You only need to record the time of the=20 >current reference point. The syntax for identifying an event=20 >as a reference point would involve a new attribute. The=20 >existing timestamp would be refined as a non-negative integer=20 >denoting the number of milliseconds from the current reference point. > >For multimedia presentations, the audio track is often used as=20 >the reference timebase since human perception finds disruption=20 >to the audio more disturbing than to the visual presentation. >A question for the W3C REX task force is whether they are=20 >interested in synchronizing SVG updates to streaming audio,=20 >and if so whether the presentation can be paused/resumed. If=20 >yes, then this should be taken into account in the semantics=20 >for timestamps, e.g. the clock should be paused along with the=20 >presentation. > >Comments? > > > Dave Raggett W3C lead for multimodal interaction > http://www.w3.org/People/Raggett +44 1225 866240 (or 867351) > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.1 (GNU/Linux) > >iD8DBQFEJCkFb3AdEmxAsUsRAmG1AKCiQWEkIYxLYmAOhQIYlxmhnByyEgCgn3bl >+M+Bs9+lJX/0L5mtiu2xYvM=3D >=3DUZF3 >-----END PGP SIGNATURE----- > >_______________________________________________ >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 From widex-bounces@ietf.org Tue Apr 11 11:54:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTLCJ-0006Zd-KS; Tue, 11 Apr 2006 11:54:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTLCI-0006ZF-OG for widex@ietf.org; Tue, 11 Apr 2006 11:54:30 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTLCG-0007EU-6V for widex@ietf.org; Tue, 11 Apr 2006 11:54:30 -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 k3BFrKVl011445; Tue, 11 Apr 2006 18:53:21 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Apr 2006 18:54:09 +0300 Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Apr 2006 18:54:09 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 11 Apr 2006 18:54:08 +0300 Message-ID: <1C1F3D15859526459B4DD0A7A9B2268B01F272CB@trebe101.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated Widex requirements draft Thread-Index: AcZdgCq+1oUZHXQKTEC+zBzTnXIOuA== From: To: X-OriginalArrivalTime: 11 Apr 2006 15:54:09.0624 (UTC) FILETIME=[2BA79D80:01C65D80] X-Spam-Score: 0.3 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: Subject: [Widex] Updated Widex requirements draft 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: , Content-Type: multipart/mixed; boundary="===============1745180728==" Errors-To: widex-bounces@ietf.org This is a multi-part message in MIME format. --===============1745180728== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C65D80.2B065BCE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C65D80.2B065BCE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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=20 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 ------_=_NextPart_001_01C65D80.2B065BCE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Updated Widex requirements draft

Hi,

Updated version of = the Widex requirements draft 01 available at http://www.kolumbus.fi/vlad.stirbu/draft-ietf-widex-requ= irements-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

------_=_NextPart_001_01C65D80.2B065BCE-- --===============1745180728== 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 --===============1745180728==-- From widex-bounces@ietf.org Tue Apr 11 22:02:21 2006 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 ; 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From widex-bounces@ietf.org Wed Apr 12 15:50:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTlLn-0005Zb-D5; Wed, 12 Apr 2006 15:50:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTlLm-0005YT-7g; Wed, 12 Apr 2006 15:50:02 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTlLm-0002Ce-07; Wed, 12 Apr 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k3CJo1BX029528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Apr 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FTlLl-0002et-Oc; Wed, 12 Apr 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 12 Apr 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: widex@ietf.org Subject: [Widex] I-D ACTION:draft-ietf-widex-requirements-01.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-01.txt Pages : 14 Date : 2006-4-12 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-01.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-01.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-01.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: <2006-4-12104014.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-widex-requirements-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-widex-requirements-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-12104014.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 Thu Apr 13 16:43:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU8fG-0002Cd-Kb; Thu, 13 Apr 2006 16:43:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU8fF-0002CY-N6 for widex@ietf.org; Thu, 13 Apr 2006 16:43:41 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU8fE-0003Ag-Cu for widex@ietf.org; Thu, 13 Apr 2006 16:43:41 -0400 Received: from [64.101.149.214] (deanwillis-ib.cisco.com [64.101.149.214]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k3DKiOHq026775 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Thu, 13 Apr 2006 15:44:25 -0500 Mime-Version: 1.0 (Apple Message framework v749.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: widex@ietf.org From: Dean Willis Date: Thu, 13 Apr 2006 15:43:36 -0500 X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Widex] Draft Minutes for WIDEX at IETF 65 Posted 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 Draft minutes for WIDEX at IETF 65 have been posted at: http://www3.ietf.org/proceedings/06mar/minutes/widex.txt Please review and report any issues to me. Thanks, -- Dean Willis You Humble Footstool, as I Haven't Back Enough To Be A Chair _______________________________________________ Widex mailing list Widex@ietf.org https://www1.ietf.org/mailman/listinfo/widex From widex-bounces@ietf.org Tue Apr 25 15:58:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYTfp-0003fo-MA; Tue, 25 Apr 2006 15:58:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYTfo-0003fZ-Ex for widex@ietf.org; Tue, 25 Apr 2006 15:58:12 -0400 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYTfo-0003sA-2r for widex@ietf.org; Tue, 25 Apr 2006 15:58:12 -0400 Received: from [192.168.2.103] (c-24-1-184-104.hsd1.tx.comcast.net [24.1.184.104]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.13.1) with ESMTP id k3PJx4G7021231 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 25 Apr 2006 14:59:05 -0500 Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <720C0F5E-1E21-4BB6-B59A-2BC98311340E@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Date: Tue, 25 Apr 2006 14:58:25 -0500 To: widex@ietf.org X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Vlad.Stirbu@nokia.com Subject: [Widex] Working group last call (WGLC) for Requirements: draft-ietf-widex-requirements-01.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 I'd like to request that the WIDEX working group commence last call on our requirements draft: http://www.ietf.org/internet-drafts/draft-ietf-widex-requirements-01.txt Please copy all comments to the list and to the authors directly. I'd like to conclude WGLC by May 15, 2006. So what does this mean? Since it's our first WGLC, let's talk about it: First, everybody participating in the working group needs to read the draft carefully, even if they don't care much about the topic. Do we agree with the requirements listed? Are there any requirements that we know of that aren't listed? Is the text clear, concise, and well-worded? Is everything spelled right? Are the right documents referenced? Are all the referenced documents needed? Note: IDNITS says: - Unused Reference: [RFC4213] is defined on line 511, but not referenced ' [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms' so it's possible that not all the referenced documents are needed, or vice-versa. One of the tricky parts with lightly-attended working groups is making sure that review has been sufficient. Would anyone (who is not an author of this draft) be willing to write up a review of the draft? Please volunteer . . . It would be even better to have two designated reviewers. Thanks, -- Dean Willis chair, WIDEX _______________________________________________ Widex mailing list Widex@ietf.org https://www1.ietf.org/mailman/listinfo/widex From widex-bounces@ietf.org Sat Apr 29 23:26:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fa2ZU-0005iy-KP; Sat, 29 Apr 2006 23:26:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fa2ZT-0005it-Oy for widex@ietf.org; Sat, 29 Apr 2006 23:26:07 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fa2ZQ-0000bM-10 for widex@ietf.org; Sat, 29 Apr 2006 23:26:07 -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 k3U3Q2gi028630 for ; Sun, 30 Apr 2006 06:26:02 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 30 Apr 2006 06:25:49 +0300 Received: from daebe102.NOE.Nokia.com ([10.241.35.115]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 29 Apr 2006 22:25:48 -0500 Received: from [172.19.141.58] ([172.19.141.58]) by daebe102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 29 Apr 2006 22:25:47 -0500 Message-ID: <44542C47.2010906@indt.org.br> Date: Sun, 30 Apr 2006 00:17:27 -0300 From: Rosfran Lins Borges 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] Working group last call (WGLC) for Requirements: draft-ietf-widex-requirements-01.txt References: <720C0F5E-1E21-4BB6-B59A-2BC98311340E@softarmor.com> In-Reply-To: <720C0F5E-1E21-4BB6-B59A-2BC98311340E@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Apr 2006 03:25:47.0317 (UTC) FILETIME=[C5A48E50:01C66C05] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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 want to be a volunteer on writing this review to the IETF Widex draft. I have been following all the Widex document releases, since the time it had been started (I had studied the later LRDP draft too, another standard released by Vlad Stirbu last year on IETF), and did read some another RUI architectures. So, it will be a pleasure to contribute to this standard! Thanks, Rosfran Borges ext Dean Willis wrote: > I'd like to request that the WIDEX working group commence last call > on our requirements draft: > > http://www.ietf.org/internet-drafts/draft-ietf-widex-requirements-01.txt > > Please copy all comments to the list and to the authors directly. > > I'd like to conclude WGLC by May 15, 2006. > > So what does this mean? Since it's our first WGLC, let's talk about it: > > First, everybody participating in the working group needs to read the > draft carefully, even if they don't care much about the topic. > > Do we agree with the requirements listed? Are there any requirements > that we know of that aren't listed? Is the text clear, concise, and > well-worded? Is everything spelled right? Are the right documents > referenced? Are all the referenced documents needed? > > Note: IDNITS says: > > - Unused Reference: [RFC4213] is defined on line 511, but not > referenced > ' [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition > Mechanisms' > > so it's possible that not all the referenced documents are needed, or > vice-versa. > > > One of the tricky parts with lightly-attended working groups is > making sure that review has been sufficient. Would anyone (who is not > an author of this draft) be willing to write up a review of the > draft? Please volunteer . . . It would be even better to have two > designated reviewers. > > Thanks, > > -- > Dean Willis > chair, WIDEX > > > _______________________________________________ > Widex mailing list > Widex@ietf.org > https://www1.ietf.org/mailman/listinfo/widex -- Rosfran Lins Borges Engenheiro de Software Instituto Nokia de Tecnologia - INdT/Recife _______________________________________________ Widex mailing list Widex@ietf.org https://www1.ietf.org/mailman/listinfo/widex