Subject: [Widex] Comments on http://www.ietf.org/internet-drafts/draft-ietf-widex-requirements-04.txt

From: Graham Klyne <[email-masked]>
Date: Mon, 15 Jan 2007 13:42:47 +0000

Hi,

I just read through:

  http://www.ietf.org/internet-drafts/draft-ietf-widex-requirements-04.txt

and I think there are a couple of areas where the requirements as stated aren't
entirely clear:

- Section 4.1, 4th bullet (The framework SHOULD be stateless):  I *think* I know
what this is intended to mean, but in light of the preceding section 3.8 there
seems some scope for confusion.  Also, section 4.3 bullet 4 seems to imply that
the WO must contain some (session-related) state.  What is unclear is the scope
of the "framework" that should be stateless.

- Section 4.4:  I guess the "Widex protocol" is just the same as the "transport
protocol" mentioned in section 3.5?  Or is there more?

...

I'm interested in this work, in part, as I'm working on systems using web
protocols and systems for real-time monitoring and control purposes, some of
which overlap applications hinted at in your draft.

I'm concerned that the requirement for reliable and in-order delivery (section
4.4) of events may be rather hard to implement on some of our devices (currently
based on PIC microchips), and unnecessary, in an environment where we are using
UDP packets to deliver events.  (I recognize the need for in-order delivery of
updates.)  Such events might be coupled to, say, physical switches that are used
to generate on/off type signals.

You mention, as an example, the role of a TV set as a secondary display.  Would
it also not be desirable for the TV set's IR remote to serve as a secondary
input?  But for IR signals, there is no reliable-delivery protocol.  What this
leads to is wanting to better understand the intended scope of the WIDEX
framework, and how it might interact with other interfaces "at the edge".

...

Another application I foresee for this work, from work supporting life science
research activities, is the kind of experience currently provided imperfectly by
web portals -- allowing users to interact with multiple resources, and have
those interactions maintained in some kind of synchrony.  That seems quite well
covered by your requirements.

#g

-- 
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

_______________________________________________
Widex mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/widex

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 18 Jan 2007 11:42:52 -0800

Hi Graham,

These comments came in after the close of IETF Last Call (well  
after).  Are these issues specific to the changes that were made in  
draft -04, the one that was published after IETF Last Call?  Or are  
any of these issue very important given that we're publishing this as  
a record of work done and not proceeding with Standards Track WIDEX  
protocol documents at this time?

BTW, thanks regardless for the review... it doesn't hurt to get this  
on the record anyway.  And I tried to answer one of your questions  
below, inline.

Vlad, are there any comments here you believe need to be addressed in  
a new draft or answers for Graham's questions?

Lisa

> protocol" mentioned in section 3.5?  Or is there more?

The WG has previously considered binding the WIDEX messages either to  
BEEP or to some other transport (possibly one more likely to traverse  
NATs; XMPP and HTTP-based stuff have been at least mentioned).   I  
understand this section to be requirements on the choice of an  
appropriate layer to use below the WIDEX messages.