Comments about TSC

[Daniel Berenguer <dberenguer@xxxxxxxxxxxx>]

Following Kevin's call-up request, I've revisited the TSC (v.42)
specification draft and have found some points that I would like to
discuss here:

1. TSC.query vs TSC.request
The document mixes both classes so I understand that it's an error.
Which is the correct class?

2. TSC for numeric values - BSC for states
I understand that BSC can still be used for many applications but I
believe that TSC should be able to manage binary states too.
Otherwise, we'll be force to do dual-implementations almost in any
device. BSC's main strengths are interoperability and the fact that
it's a common schema for all. I agree that TSC is a more complete
schema that could replace BSC for most applications but having to
manage TSC for numeric and BSC for binary is a nonsense in my opinion.
Why not using value=on/off in TSC too? From my point of view, we need
simple mechanisms capable to do complex things. One schema for all is
perfect for gateways and embedded controllers. Otherwise, we'll have
to manage with queries/commands from different schemas, send
duplicated events/infos, ... I also agree that we'll have to keep BSC
for backward compatibility in current designs but once TSC will be
widely adopted, TSC is a perfect candidate for becoming the main xAP
interoperable schema for control and telemetry applications.

3. Response to TSC.cmd resets
The specification states that the response to a TSC.cmd (counter)
reset has to be a TSC.info after having reseted the counter. This
breaks BSC's command/event query/info mechanisms and, will force us to
manage a exception when receiving RESET commands. Why not sending a
TSC.event after reseting the counter? Reseting a counter means that
the endpoint will change its value (if not 0 before that).

There are a lot of common points between BSC and TSC and I appreciate
this as it will simplify the adoption of the later schema. On the
other hand, all my suggestions are targeted to simplify the
implementation (lines of code and processing speed) and give more
power to TSC. Instead of creating a new schema, I'd have preferred to
enrich BSC with new fields but the creation of TSC is something good
because we have now the opportunity to customize this schema for M2M
apps. On the other hand, implementing new protocosl or schemas is
something time-costly so we'll have to be very precise and effective
in our work.

I vote for one schema for all in the M2M area. TSC for M2M and BSC for
basic home automation stuff. Isn't it too late for coming here with
such arguments?

Thanks for your time,

--
Daniel Berenguer
http://www.usapiens.com
http://www.opnode.org


------------------------------------