Hello
We're planning to start writing a new XEP proposal for IoT device discovery. I've received interest from a couple of people who wants to work on this. If anybody is interested in participating in this work, please let me know.
The first proposal for the proto-XEP will be published in normal order on the standards list for anybody to comment on.
Best regards,
Peter Waher
Dear Folks!
I have just gone through a thorough reading of XEP-0323 with the view of
understanding its details before an implementation. I have a number of
comments and suggestions, but also questions that I would like to share
and raise. Note that I haven't spent so much time on "cross-XEP" reading.
But first of all, I would like to congratulate Peter on putting together
a strong (set of) XEP(s) that aim at solving some of the issues faced by
IoT applications! Well done.
And now... comes the list in no particular order, you will notice that
there is a mix of tiny problems and sometimes larger questions.
* I have a general question about security and request/responses. I
don't see any protection against too many requests sent within a too
short time frame. This could harm the receivers since we are usually
talking about tiny devices with few resources. The proposal mentions
that these requests might not be served, but having to process too many
of them, even if taking the decision of not serving them might put a
small sensor to its knees. I understand that requesting and requested
must be friends, but such an issue might occur because of bad coding or
corner cases being reached. I have no real solution, but I thought that
I would mention it.
* Every example in the text uses a sequence number that matches the "id"
field of the <iq>. A non-initiated might be misled that they should be
the same.
* I am bit puzzled by having values listed as a sub-element of a
<timestamp>. This is especially true since, for example, errors place
the timestamp as an attribute of the <error> tag. What are the design
decisions that led to this ordering?
* As a side-note, I think that some of the example should highlight the
fact that the dateTime type can also specify fractions of seconds, these
might be important for some applications.
* Since units are only under recommendation (and I think that this is
very wise), we might consider having not having them as a "required"
attribute for numerical values at all. Obviously, this is not very
interoperable but it is as good as introducing unknown units that are
only recognised within the namespace of an application.
* In the read-out from multiple devices, I would have preferred that the
<field>s are placed as sub-element of the <node>.
* Wouldn't it be more future-proof to have <historical*> field types
represented by a field called <historical> with an attribute describing
the period of the history?
* I wonder what the real difference is between "peak" and "computed" in
the field types. The problem that I have with peak is that it shuts off
other mathematical constructs such as mean, median, average, etc. Maybe
is "peak" misleading just by its name, or maybe is it too specific and
we could allow for a "comment" (or "method") attribute for the
"computed" field type?
* My first reaction to localising strings was that it brings unnecessary
complexity to the XEP. The name of the fields, as transported over the
wire/air, will seldom be shown to the user without passing through a
software layer that would be able to perform the necessary
localisations? Why should this information be carried as part of the
protocol?
Please bear with me if you already have discussed some of these issues
in the past. I hope that this input will help improving the content of
the XEP.
/Emmanuel
