ack-ing (was Re: Feedback from UHKA 2003)

[Patrick Lidstone]

> I had wondered about the possibility of including a 'ACK=Yes'
type
> parameter in targeted messages to effectively confirm delivery of a
packet -
> although this is a sender to receiver mechanism only (it wouldn't
handle the
> receiver knowing it had missed something). Using this for example a
security
> sensor could broadcast its status generally (broadcast) and
additionally
> target a critical receiver with an ACK=Yes mechanism. Towards the
end of our
> discussion David seemed happy that if we could include this sort of
> mechanism - plus the standard (universal) parameters for ON/OFF and
level -
> along with additionally a defined and standard way of polling the
status of
> a device then he would be very happy with xAP - he loves the higher
level
> stuff (text display - DB lookup etc). I think this last bit of
defining a
> status.request along with a status.report type schema that includes
the
> ON/OFF and Level would help everyone here. Maybe there's more than
level but
> I think most HA applications (and devices) only support this need.
>
> Obviously we need to address configuration and discovery as
well
> (untargeted message with Ack=Yes).
>

Ack=yes is certainly a simple solution. Even better might be ack=nnn
where nnn is a sequence number/key. Then you know which message is
being acked.

My only reservation about an ack=yes scenario is that we are again
raising the bar on the minimum level of functionality required in a
device. Perhaps ack-supporting devices should include an
"ack-able"
indication in their heartbeat? That way a sender could discover if a
device supports acking, leaving devices with the option of not
supporting it & we would retain backwards compatibility.

Patrick