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

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
Widex@ietf.org
https://www1.ietf.org/mailman/listinfo/widex