Hello Emmanuel Thanks for your mail and all your comments. Sorry for the delay in the response. I've been away of a longer vacation. I'll try to address each one of your concerns one at a time: -----Original Message----- From: Emmanuel Frécon [mailto:emmanuel@sics.se] Sent: den 28 januari 2014 05:16 To: iot(a)xmpp.org Subject: [IOT] Comments on XEP0323 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. Ok. The device can reject a readout request (§3.3) and provide the reason why the readout was rejected. If the device is unable to serve the request it can queue it, reject it or provide a failure, depending on why it was unable to process it. It has been left as implementation specific. * 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. Ok. Updated the id attribute values in all examples, to highlight they are different from the sequence numbers. * 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? In some cases, there's only one field value per timestamp, so this might look strange. But in the general case, there are multiple field values for each timestamp in a meter. Examples: Water meters report (at least) Accumulated Volume & Momentary Flow for each timestamp. Electricity meters report (at least) Accumulated Energy and Power for each timestamp. Heat meters usually report (at least) Accumulated Energy, Accumulated Volume, Momentary Flow, Momentary Power, Supply Temperature, Return Temperature and Temperature Difference, for each timestamp. The main reason is to have a simple way to group together fields belonging together (by time). Otherwise, a long list of values would be provided, and the receiver would need to compare timestamps to know which field values belong together. Compressed, timestamps also require much memory compared to start/end element signals, and by placing the timestamp in a separate element, redundancy is avoided. * 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. Correct. However, most devices I've seen only report seconds, even though fractions of seconds are possible. * 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. Note sure I follow you here. Could you rephrase this? * In the read-out from multiple devices, I would have preferred that the <field>s are placed as sub-element of the <node>. Ok. This would create redundancy in the timestamp part, as explained above. * 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? XEP-0326 contains an alternative way of reporting historical values stored in databases. The values shown here correspond to a momentary readout of a device, where the values have been flagged as historical. The period is described by the timestamp, and here you see the grouping feature of the timestamp element. * 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? The real difference is that peak values are sometimes regulated and have special meaning - in a larger context. Also, a peak value is not necessarily a computed value. It can be a measured value. Note also that peak means an endpoint in a range (both min and max), within some time window. Also, in some cases, peak values can be used in billing, computation of tariffs, etc., and might have a legal/contractual meaning. A computed value on the other hand is not measured, and can be any computed value, a value that is less accurate (but not necessarily so) than say a measured value. It can also include estimates, interpolations, extrapolations, etc. There's a difference in "quality" between the two. And also a conceptual difference between the two, in the following sense: Even though it is possible to request specific field values from a device, there's also a broader more general means of requesting certain conceptual values. You might be interested in only "momentary and peak" values from a device, but ignore status and computed values - regardless of any knowledge what values these might actually contain. The device is not required to respond exactly, but this information can be used as a hint what has to be read and returned. * My first reaction to localizing 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 localizations? Why should this information be carried as part of the protocol? I would say on the contrary. This is precisely the point: The data provided by the device will be able to be processed by both machines and humans, with no need of updating software layers anywhere. If you would have to update each interface in your home every time you buy a new light bulb, you might get tired after a while - especially if our vision is true where each home will contain thousands of devices. Now, localization is optional, but possible. If device manufacturers want to include such localization information in there, it is possible. We recommend it. 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 Thanks a lot for all your input. I hope my responses answers your questions. If you have any further comments on this or the other XEP:s, please feel free to mail them at any time. I've cc:ed the standards mailing list, since I believe discussions about the individual XEP:s better belong there. Best regards, Peter Waher