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

[Lisa Dusseault <[e-mail]>]

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

On Jan 15, 2007, at 5:42 AM, Graham Klyne wrote:

> 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?

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.

>
> ...
>
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/widex


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