Hello
Sorry for the late reply. I'll take the time to answer some of the concerns and
thoughts that arose during the meeting:
Regarding sensor-data:
> The iqs are bare JID instead of full JID.
Yes. Many sensor configurations may be done in a production environment, where
runtime resource/session information is not available. This simplifies things.
It's not a limitation though.
> Why not use type='error' for error stanzas?
Because an "error" on the sensor level is not necessarily an error at the
transport level. A sensor reporting an error, might be an OK response/message.
To be able to answer more precisely, could you provide an example, or link to
an example in the document which you think should be done in another way?
> Why not send iq responses after processing, instead of before?
I'm not sure I follow you. Could you provide more info on what is the concern,
or point to an example which illustrates the concern?
> Should times use 82?
???
> I'm not entirely sure that I understand the translation stuff. Isn't this
> equivalent to using strings in e.g. English, and then having a translation
> map?
That would be a subset of what the translation model can do, as a basic case:
Mapping string IDs to translated strings. This model also allows for modules,
sensors or devices to aggregate information to the field name, still making it
possible to make the end result localizable. Note that devices in the sensor
network will not be able to perform the localization themselves, so the
information has to be delivered to a system that can do it.
A simple example:
Say a Sensor reports a "Temperature". This string could be given an ID and a
given Language Module.
Another device in the network (or perhaps the same device), could take all
temperatures and make calculations on these: Peak values (Min & Max), Average,
Mean, StdDev, etc. (just to name a few). Now, this device could do this for any
type of momentary value (Temperatures, power, flow, etc.). So, it would be
impossible to create a simple translation map for these type of strings
("Temperature, Min", "Power, Average", etc.) since the device creating the
value is not responsible for the localization of the base, and simply does not
know at design time of all possibilities. Also, maintaining such a large string
table would be very inefficient. So, instead, the device could have localized
strings "%0%, Min", "%0%, Max", etc. in its own language module which makes the
translation of the part it knows. Translating the full field name then becomes
a two-step process, first translating the base, and then aggregating a
translation of the second part, etc.
> I think multicast is probably misleading here as what it's likely to be doing
> is really a multi-singlcast type of thing.
It will use MUC as a base for multi-casting messages.
Regarding EXI:
> I'm going to not object at the moment to it going to Experimental, although I
> do still have reservations about it.
Ok, which ones?
> I'd quite like to know how EXI in this case compares to zlib (It looks rather
> like zlib should cope pretty well with these data).
EXI can compress XML several multiples better than zip, in the general case. It
is also very efficient execution wise. It of course all depends on type of XML
and availability of schemas. I'm sure numbers will be available later in the
process for explicit cases.
Sincerely,
Peter Waher
-----Original Message-----
From: Kevin Smith [mailto:[email protected]]
Sent: den 27 mars 2013 08:19
To: XMPP Standards
Subject: [Standards] Fwd: Minutes 2013-03-20
FYI
---------- Forwarded message ----------
From: Kevin Smith
Date: Wed, Mar 27, 2013 at 11:18 AM
Subject: Re: Minutes 2013-03-20
To: XMPP Council
On Thu, Mar 21, 2013 at 10:24 AM, Kevin Smith wrote:
> 6) http://xmpp.org/extensions/inbox/sensor-data.html
> Accept as Experimental?
>
> No objections from Matt, Matt, Ralph. Kev and Tobias have a fortnight to
> object.
The iqs are bare JID instead of full JID.
Why not use type='error' for error stanzas?
Why not send iq responses after processing, instead of before?
Should times use 82?
I'm not entirely sure that I understand the translation stuff. Isn't this
equivalent to using strings in e.g. English, and then having a translation map?
I think multicast is probably misleading here as what it's likely to be doing
is really a multi-singlcast type of thing.
No objections to it going to Experimental, in any case.
>
> 7) http://xmpp.org/extensions/inbox/exi.html
> Accept as experimental
>
> Much discussion during the meeting - see the room logs.
>
> Main points of contention were whether attacks were possible by doing
> schema exchange pre-auth and whether it fits the 138 model or should
> be a new transport binding.
>
> Matt Wild didn't object, others have a fortnight to object.
I'm going to not object at the moment to it going to Experimental, although I
do still have reservations about it.
I'd quite like to know how EXI in this case compares to zlib (It looks rather
like zlib should cope pretty well with these data).
/K
