Minutes, WIDEX meeting at IETF 64

Edited by Dean WIllis from notes by Jerry Shih

Meeting held Tuesday, November 8, 0900-1130.

Meeting called to order by chair Dean Willis.

IETF IPR policy noted.

Jerry Shih agreed to act as secretary.

Robert Sparks agreed to act as Jabber scribe.

Noted that Dave Raggett would be listening to the session's MP3 stream and sending commentary via Jabber.

Agenda agreed as proposed:

but noted that Vlad Stribu will lead the discussion of W3C work on behalf of Dave using slides submitted by Dave.

Topic: Charter

Discussion led by chair Dean Willis

Slides presented (and included in proceedings).

Charter and milestones reviewed with little discussion or commentary.

Noted that working group mailing list would be moved from remoteui@ietf.org to widex@ietf.org

TODO: Chairs to make sure the charter web page is updated to show the new working group mailing list.

Topic: WIDEX Requirements

Discussion led by Vlad Stirbu

Slides presented (and included in proceedings).

Supporting document: draft-stirbu-widex-requirements-00.txt

Presentation reported that the user interface is assumed to be modeled  in XML DOM and may vary in complexity across a wide range.  It also established a a requirement for dealing with three classes of alterations to that DOM: updates, mutations, and events.

TODO:  Author to add scenario on IPV4-IPV6 interworking.

TODO:  Author to clarify security requirements to indicate needs for protection of both data privacy and integrity.

Noted that the XML-patchBOF is looking at a similar thing (synchronizing XML) and that this raises a question as to whether we should be considering a general solution.  Discussion of the charter indicates that neotehr requires nor forbids addressing the problem in this working group, so the question is deferred,

It was suggested by Eric that we avoid targeting a specific application that might undermine the powerful capability of the IETF to define general-purpose transport protocols. 

Noted that there is some relationship between this work and OMA's SyncML, but that SyncML is intended for static documents and does not deal with events.

Proposed that the existing document draft-stirbu-widex-requirements-00.txt be adopted as baseline text for the working group's requirements deliverable. This proposal was accepted by unamimous consent.

TODO:  Editor to revise draft-stirbu-widex-requirements-00.txt and resubmit as draft-ietf-widex-requirements-00

Topic: W3C work on MultiModal MMS Architecture

Discussion led by Vlad Stirbu using slides by Dave Raggett

Slides presented.

Discussion followed:

Question: Does the existing requirements address Messaging order and reliability?

TODO: Editor to add these requirements to requirements draft

Noted on Binding messages: W3C comments indicate we may need to indicate which DOM tree or XML document is the target of each WIDEX event. Do we need to put this into each event, or do we have a binding between a WIDEX session and a single document such that the session context conveys this information?

TODO: Editor to clarify whether we have a requirement to relate a WIDEX  session to a single document, or should defer this discussion for implementation phases.

Noted that each application appears to be responsible for actual synchronization. 

Questions: Do we have a requirement to provide even ordering? If so, does this requirement extend beyond single WIDEX session or document? How does this apply to multiple renderers? 

TODO: Editor to address in requirements document.

Question: Do we need temporal coordination for multimodal interactions? Is time-based coordination adequate for the multi-renderer scenarios, given that it implies synchronized clocks?

TODO:  Editor to address in requirements document.

Topic: Working Group Open Discussion

The chair polled the room to see who would be interested in  more active roles such as authorship, review and comments. No volunteers were noted for document authoring or editing, but several people indicated a willingness to review documents.

Noted that we may need to think about network latency, which could provide a problem in sync.

Noted that Not all the events need to be sent to server; some could be handled locally.

Meeting adjourned by chair at 11:10