Re: [IOT] Comments on XEP0323

Hello Emmanuel Thanks for all your input. I'll respond in full when I'm back from my vacation in a couple of weeks. Best regards, Peter Emmanuel Frécon &lt;emmanuel(a)sics.se&gt; escribió: 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 _______________________________________________ IOT mailing list IOT(a)xmpp.org http://mail.jabber.org/mailman/listinfo/iot