OpenADR comment period
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear IOTers, It has come to my attention that the OpenADR Alliance, which produces technical guidelines for demand-response systems, has released a draft version of their 2.0 specification for public comments. You can find the spec here: http://www.openadr.org/specification The primary text of interest is Section 9.3, which defines their use of XMPP. Comments can be sent to mailto:comments@openadr.org (as I understand it, preferably by the end of next week). I'll be sending my feedback before then, and encourage other folks here to do the same. Thanks! Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRwl4zAAoJEOoGpJErxa2pFjkP/j+J0mAWMqaUaVM0tYw4VRf9 BA0wql2d67tRAd/JB2LmZiW0eKfkHBNXtVhrPvXi4eCqPh7Vcr/2FENt28Rc1AWR rR0PO4I/1etLE5HCbYJSWaWQA9WREAGlPSr12hcXRs82CJdwajWUnQMuUJbx7S4t Yxe+6QVdsmqQBQBv3L0ZFiA0B+iLpqr1BW0RVqLBeaYXSynQ2GiBfsuEWZy7jXIH f3eAfB9qUz1B03BVVwLFUlazGKFkQE1KOFKxsDi9uEymvMHDpXZQSSpHYV35F9GJ 72vzSmmtJ4Gp2wZpg9eaZcrJHjoiBu7i8vnqMK9/9A7U1k58EU7DZjc5wj9pStlV taF9WLYfFcEIY7YjNwozH5yLKySCX/erKyq4CbWUyVXOt/P5XARnye4PXvyzAwQH eUhAzSYFU4Dp/9V8rqVRixP0JdVIPf6FW2ajlKjNasj31EQLyksvsPZgu4r5xsp4 MnqQ3PpAtG+JiB2pI1vN2mMPtCL9DkvACFmlxgJeJ/EU9yxkBmXGIR9aXrnLpD36 cwDK0MYvEUk0gREyA9BaOCKH6CViPgrI+XWy8CSytGi3SB475RkfNApM6YCEKuTR blcRHI4P9Dy4Q3zGcQ5FWXQwdYXmog6+KU0gI97ywox0Wap/wMjszGgWdfjaktJh U9xHZHU5UGVmrgmwIwUO =8WEq -----END PGP SIGNATURE-----
Peter - thanks for sharing this! For background, EnerNOC has used XMPP internally for our enterprise-to-device communications for years now, and we've been driving XMPP specification for OpenADR. To give some context, OpenADR is a complex multi-protocol (HTTP and XMPP) specification and we've purposely limited some of the XMPP features that we use, to maintain a certain level of parity between XMPP and HTTP. Many of the OpenADR alliance members have never used XMPP and we tried to keep things simple to make adoption easier, while still giving some of the immediate benefits over HTTP. Our hope is that we can optimize and take advantage of more XMPP features in future versions of the OpenADR spec as we gain experience. To answer some possible FAQs: - Why not use messages? All OpenADR service operations currently expect a response, and the response contains relevant info. In the future, some operations could possibly be optimized to assume message delivery and a "OK" response by default. - Why not use pub-sub? While some event dispatches could be multicast to many clients (VENs) the spec assumes the event payload can contain unique info per client. So a separate payload must be created for each client. But another possible opportunity for optimization nonetheless. Also, we've purposely limited (but not eliminated) the use of presence for two reasons: - Consumer end nodes (VENs) should not be aware of other VENs, only the VTN (the coordinator/ virtual top node) - a top node with thousands or millions of VENs subscribed to its presence presents a performance issue. Some more context: OpenADR is a "high level" energy communication schema that attempts to avoid "direct load control" e.g. Directly interacting with actuators. OpenADR communicates event information and assumes the VEN (client end point) will decide on discrete actions to perform. Similarly, OpenADR supplies "reports" but no direct sensor access. In this way, I think OpenADR is very complementary to the other XMPP IoT efforts going on right now. Open to any comments and feedback from XMPP experts! Thanks! -Thom Thom Nichols Principal Engineer, Advanced Technology Twitter: @thom_nic | Skype: thom.nichols o: 617.532.8154 | m: 401.323.1813 http://open.enernoc.com EnerNOC - get more from energy On 6/20/13 10:43 AM, "Peter Saint-Andre" <stpeter@stpeter.im> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dear IOTers,
It has come to my attention that the OpenADR Alliance, which produces technical guidelines for demand-response systems, has released a draft version of their 2.0 specification for public comments. You can find the spec here:
http://www.openadr.org/specification
The primary text of interest is Section 9.3, which defines their use of XMPP.
Comments can be sent to mailto:comments@openadr.org (as I understand it, preferably by the end of next week). I'll be sending my feedback before then, and encourage other folks here to do the same.
Thanks!
Peter
- -- Peter Saint-Andre https://stpeter.im/
-----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRwl4zAAoJEOoGpJErxa2pFjkP/j+J0mAWMqaUaVM0tYw4VRf9 BA0wql2d67tRAd/JB2LmZiW0eKfkHBNXtVhrPvXi4eCqPh7Vcr/2FENt28Rc1AWR rR0PO4I/1etLE5HCbYJSWaWQA9WREAGlPSr12hcXRs82CJdwajWUnQMuUJbx7S4t Yxe+6QVdsmqQBQBv3L0ZFiA0B+iLpqr1BW0RVqLBeaYXSynQ2GiBfsuEWZy7jXIH f3eAfB9qUz1B03BVVwLFUlazGKFkQE1KOFKxsDi9uEymvMHDpXZQSSpHYV35F9GJ 72vzSmmtJ4Gp2wZpg9eaZcrJHjoiBu7i8vnqMK9/9A7U1k58EU7DZjc5wj9pStlV taF9WLYfFcEIY7YjNwozH5yLKySCX/erKyq4CbWUyVXOt/P5XARnye4PXvyzAwQH eUhAzSYFU4Dp/9V8rqVRixP0JdVIPf6FW2ajlKjNasj31EQLyksvsPZgu4r5xsp4 MnqQ3PpAtG+JiB2pI1vN2mMPtCL9DkvACFmlxgJeJ/EU9yxkBmXGIR9aXrnLpD36 cwDK0MYvEUk0gREyA9BaOCKH6CViPgrI+XWy8CSytGi3SB475RkfNApM6YCEKuTR blcRHI4P9Dy4Q3zGcQ5FWXQwdYXmog6+KU0gI97ywox0Wap/wMjszGgWdfjaktJh U9xHZHU5UGVmrgmwIwUO =8WEq -----END PGP SIGNATURE----- _______________________________________________ IOT mailing list IOT@xmpp.org http://mail.jabber.org/mailman/listinfo/iot
This email and any information disclosed in connection herewith, whether written or oral, is the property of EnerNOC, Inc. and is intended only for the person or entity to which it is addressed. This email may contain information that is privileged, confidential or otherwise protected from disclosure. Distributing or copying any information contained in this email to anyone other than the intended recipient is strictly prohibited.
One question, which is more of an implementation detail but we would like some input, is how to prevent communication between end node clients. I think during registration, VENs would have to be added to an ACL or group, and then a filter would be used at the XMPP server to block packets whose "to" and "from" belong to that group. Any general guidelines or best practices for securing a public XMPP server with possibly untrusted clients would be welcome. Thanks again! -Thom On 6/20/13 10:43 AM, "Peter Saint-Andre" <stpeter@stpeter.im> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dear IOTers,
It has come to my attention that the OpenADR Alliance, which produces technical guidelines for demand-response systems, has released a draft version of their 2.0 specification for public comments. You can find the spec here:
http://www.openadr.org/specification
The primary text of interest is Section 9.3, which defines their use of XMPP.
Comments can be sent to mailto:comments@openadr.org (as I understand it, preferably by the end of next week). I'll be sending my feedback before then, and encourage other folks here to do the same.
Thanks!
Peter
- -- Peter Saint-Andre https://stpeter.im/
-----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRwl4zAAoJEOoGpJErxa2pFjkP/j+J0mAWMqaUaVM0tYw4VRf9 BA0wql2d67tRAd/JB2LmZiW0eKfkHBNXtVhrPvXi4eCqPh7Vcr/2FENt28Rc1AWR rR0PO4I/1etLE5HCbYJSWaWQA9WREAGlPSr12hcXRs82CJdwajWUnQMuUJbx7S4t Yxe+6QVdsmqQBQBv3L0ZFiA0B+iLpqr1BW0RVqLBeaYXSynQ2GiBfsuEWZy7jXIH f3eAfB9qUz1B03BVVwLFUlazGKFkQE1KOFKxsDi9uEymvMHDpXZQSSpHYV35F9GJ 72vzSmmtJ4Gp2wZpg9eaZcrJHjoiBu7i8vnqMK9/9A7U1k58EU7DZjc5wj9pStlV taF9WLYfFcEIY7YjNwozH5yLKySCX/erKyq4CbWUyVXOt/P5XARnye4PXvyzAwQH eUhAzSYFU4Dp/9V8rqVRixP0JdVIPf6FW2ajlKjNasj31EQLyksvsPZgu4r5xsp4 MnqQ3PpAtG+JiB2pI1vN2mMPtCL9DkvACFmlxgJeJ/EU9yxkBmXGIR9aXrnLpD36 cwDK0MYvEUk0gREyA9BaOCKH6CViPgrI+XWy8CSytGi3SB475RkfNApM6YCEKuTR blcRHI4P9Dy4Q3zGcQ5FWXQwdYXmog6+KU0gI97ywox0Wap/wMjszGgWdfjaktJh U9xHZHU5UGVmrgmwIwUO =8WEq -----END PGP SIGNATURE----- _______________________________________________ IOT mailing list IOT@xmpp.org http://mail.jabber.org/mailman/listinfo/iot
This email and any information disclosed in connection herewith, whether written or oral, is the property of EnerNOC, Inc. and is intended only for the person or entity to which it is addressed. This email may contain information that is privileged, confidential or otherwise protected from disclosure. Distributing or copying any information contained in this email to anyone other than the intended recipient is strictly prohibited.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Thom, thanks for your other post. On 6/19/13 8:52 PM, Thomas Nichols wrote:
One question, which is more of an implementation detail but we would like some input, is how to prevent communication between end node clients. I think during registration, VENs would have to be added to an ACL or group, and then a filter would be used at the XMPP server to block packets whose "to" and "from" belong to that group.
Would service providers want to forbid all communication among clients, or limit it to communication among particular "groups", as you say? That kind of thing usually is implementation-specific, but if you let us know what you're trying to achieve perhaps we can provide some pointers. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRwm/kAAoJEOoGpJErxa2pytcP/RK6BNMmBsW9Eiej2T16jhEP y52kiJNMpXA57fNknPqiKCXduoIqk+MvcExV08z8+N4tx8+DfyU9jqJjS+gGFGgb fEw/w0FBFgbdgpb5QYf02TKhEnyl4sGBIeDf13rHRxNVV7dXqH+S5LNybrnG+kqt V9U7VcoCrgobCaGiNAlZ/H2YPiItNk+zZ2y2Oi1AkNJzqrVUQHSuzuHM8zu83NwK nneN7NUo03fy9xvgYxbmUTy2gjetEH1GX8I61MTa+JM6eHxm/cpTkaErFTIEWvli xcNUL6aAvPqaLXfQ612UhZG187Pnk35xiROyNvgKjjfV5CKSnuJdejEiARjUrD9X bnyZzZrIFZ417Gr3ElwH4Xw58Iu2eBqBOCknmGGgyi/Fw8txeVPkB6DnCa2e4tN8 TWo1KCKxVVm4KhkVSQ/nDq1zXTdK0CMo8RXLARGXql3o7eWMzTOVzwOsnM1um8O1 74W1z7r/kHH+wcE3HUXbPLC3vpe5SIBSTtNoZweYnx3aZ5PXJ8txiSO6tfr4K9ox ahevU7MGRqXje+ARrrUFutszQyvNTBmDjU9hQqP35yBfVfxx9RV7JZU8I03c7keG aPpd+9FjfnCxyRql825Ykw/KoXZaben2C6dOC8vRxgRQQFGX+jQKCLVWwI5srLpG T4yKMuk5SdwJFAu+kplN =NCvu -----END PGP SIGNATURE-----
An OpenADR network conceptually looks like a star network, with a single VTN (virtual top node/ coordinator) and many VENS (virtual end nodes.) The VEN needs to trust commands from a top node, and VENs can't communicate -- ever -- with other VENs as far as OpenADR is concerned. Agreed it's largely an implementation concern which is why it's not laid out in the spec, more of a guidance. We consider in most cases, the VTN and XMPP server will be controlled by the same entity. The VTN could be connected as an XMPP client (or multiple clients) or VTN endpoints could be exposed as service JIDs. I think we have two choices. (1) Tell VTN implementers/ deployments that they need to secure the XMPP server to prevent VEN to VEN communication. Or (2) we require VENs to maintain a whitelist of VTN JIDs, and drop or reject packets that are not from an approved JID. Or maybe both. Thanks! -Thom On 6/20/13 11:58 AM, "Peter Saint-Andre" <stpeter@stpeter.im> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Thom, thanks for your other post.
On 6/19/13 8:52 PM, Thomas Nichols wrote:
One question, which is more of an implementation detail but we would like some input, is how to prevent communication between end node clients. I think during registration, VENs would have to be added to an ACL or group, and then a filter would be used at the XMPP server to block packets whose "to" and "from" belong to that group.
Would service providers want to forbid all communication among clients, or limit it to communication among particular "groups", as you say?
That kind of thing usually is implementation-specific, but if you let us know what you're trying to achieve perhaps we can provide some pointers.
Peter
- -- Peter Saint-Andre https://stpeter.im/
-----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRwm/kAAoJEOoGpJErxa2pytcP/RK6BNMmBsW9Eiej2T16jhEP y52kiJNMpXA57fNknPqiKCXduoIqk+MvcExV08z8+N4tx8+DfyU9jqJjS+gGFGgb fEw/w0FBFgbdgpb5QYf02TKhEnyl4sGBIeDf13rHRxNVV7dXqH+S5LNybrnG+kqt V9U7VcoCrgobCaGiNAlZ/H2YPiItNk+zZ2y2Oi1AkNJzqrVUQHSuzuHM8zu83NwK nneN7NUo03fy9xvgYxbmUTy2gjetEH1GX8I61MTa+JM6eHxm/cpTkaErFTIEWvli xcNUL6aAvPqaLXfQ612UhZG187Pnk35xiROyNvgKjjfV5CKSnuJdejEiARjUrD9X bnyZzZrIFZ417Gr3ElwH4Xw58Iu2eBqBOCknmGGgyi/Fw8txeVPkB6DnCa2e4tN8 TWo1KCKxVVm4KhkVSQ/nDq1zXTdK0CMo8RXLARGXql3o7eWMzTOVzwOsnM1um8O1 74W1z7r/kHH+wcE3HUXbPLC3vpe5SIBSTtNoZweYnx3aZ5PXJ8txiSO6tfr4K9ox ahevU7MGRqXje+ARrrUFutszQyvNTBmDjU9hQqP35yBfVfxx9RV7JZU8I03c7keG aPpd+9FjfnCxyRql825Ykw/KoXZaben2C6dOC8vRxgRQQFGX+jQKCLVWwI5srLpG T4yKMuk5SdwJFAu+kplN =NCvu -----END PGP SIGNATURE-----
This email and any information disclosed in connection herewith, whether written or oral, is the property of EnerNOC, Inc. and is intended only for the person or entity to which it is addressed. This email may contain information that is privileged, confidential or otherwise protected from disclosure. Distributing or copying any information contained in this email to anyone other than the intended recipient is strictly prohibited.
Hi Thomas, On 20.06.2013 05:41, Thomas Nichols wrote:
I think we have two choices. (1) Tell VTN implementers/ deployments that they need to secure the XMPP server to prevent VEN to VEN communication. Or (2) we require VENs to maintain a whitelist of VTN JIDs, and drop or reject packets that are not from an approved JID. Or maybe both.
In my humble opinion, (2) is the safest, because it does not rely on a third party (the server) to protect the first party (the VEN). However, blocking the traffic at the server (as in (1)) has benefits for the end user, as it is thus impossible to run a denial-of-service attack on another end user with in-band messages, which is probably desired. I'm not sure whether there exist solutions for (1) in form of XEP or code though. regards, Jonas
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6/20/13 8:00 AM, Jonas Wielicki wrote:
Hi Thomas,
On 20.06.2013 05:41, Thomas Nichols wrote:
I think we have two choices. (1) Tell VTN implementers/ deployments that they need to secure the XMPP server to prevent VEN to VEN communication. Or (2) we require VENs to maintain a whitelist of VTN JIDs, and drop or reject packets that are not from an approved JID. Or maybe both.
In my humble opinion, (2) is the safest, because it does not rely on a third party (the server) to protect the first party (the VEN).
However, blocking the traffic at the server (as in (1)) has benefits for the end user, as it is thus impossible to run a denial-of-service attack on another end user with in-band messages, which is probably desired.
I'm not sure whether there exist solutions for (1) in form of XEP or code though.
Basically you'd want to use a highly modular codebase that includes a module for the ability to send messages. Then just disable that module. (However, I assume that you'd want the VENs to be able to send messages to the VTN.) Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRw3ULAAoJEOoGpJErxa2p4TIP/3FbuiDvwGJPDviYaeKOX/Wp rr+OTDI6M5bKutTFGoltbbU/qghFViW4gkqt0r6be+/PEOUsBsCxNej0CxPGviNB FM2FueByqG9m5I40Qp5sS1SBBLHXhhaHBGk4jZJ3OZul7eHhOKZ2SvepWpoleB0N UNdzbIBJmowhDlKQfbSIA7vK3ln/hyZsWgq0RzJG7cyA/1wX0TPrpdp9k1dC5fJY ODBmgYZTKtuwSRzEiqm45pZawcLM2oQB6kBoajzDheaQb5FPb+q0yAIcX6scCzEj rhDiiOL9l5fQ3shxCoIkVPSNL0DL+W9mBBdB0RftzH1c2d8JTyYE92obKUamt2TO 3drxByeDVlv/BXcPAvtsKTt78nmlnBmFHt1HK2Voe/6LSYhaZkPUvKoIfHKCUEXg 4vE4UnCo9N6aK2oYlMGHx+vr941qzBw0f9z0t6dsidxauMKpUnE8FVcLOvvOEDXt O+dg7Nltd34WCKVb+GnJhsxfZBTi+tJK/Vl4gpMg4sdpiUVwbHS9coQSolleW38V IG64eVjBm3i0bJlushcCjts6npw2R4yot4Q4872ZCyigdn/uxvyIyfD3kacXoJa2 8uUqvk+w6jCCQj0j3vNFBQFG0txqn5NHMstPyXxLWAB99d+ArhLnq0vSIrLrbJco IPzO1Ulvff/UF1agXvt5 =rCNd -----END PGP SIGNATURE-----
Hello Thom Have you had any chance to look at XEP-0324: Provisioning? It provides a mechanism to control who/what talks to who/what, what users have what access rights to what services, etc. Sincerely, Peter Waher -----Original Message----- From: Thomas Nichols [mailto:tnichols@enernoc.com] Sent: den 19 juni 2013 22:52 To: XMPP in the Internet of Things Subject: Re: [IOT] OpenADR comment period One question, which is more of an implementation detail but we would like some input, is how to prevent communication between end node clients. I think during registration, VENs would have to be added to an ACL or group, and then a filter would be used at the XMPP server to block packets whose "to" and "from" belong to that group. Any general guidelines or best practices for securing a public XMPP server with possibly untrusted clients would be welcome. Thanks again! -Thom On 6/20/13 10:43 AM, "Peter Saint-Andre" <stpeter@stpeter.im> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dear IOTers,
It has come to my attention that the OpenADR Alliance, which produces technical guidelines for demand-response systems, has released a draft version of their 2.0 specification for public comments. You can find the spec here:
http://www.openadr.org/specification
The primary text of interest is Section 9.3, which defines their use of XMPP.
Comments can be sent to mailto:comments@openadr.org (as I understand it, preferably by the end of next week). I'll be sending my feedback before then, and encourage other folks here to do the same.
Thanks!
Peter
- -- Peter Saint-Andre https://stpeter.im/
-----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJRwl4zAAoJEOoGpJErxa2pFjkP/j+J0mAWMqaUaVM0tYw4VRf9 BA0wql2d67tRAd/JB2LmZiW0eKfkHBNXtVhrPvXi4eCqPh7Vcr/2FENt28Rc1AWR rR0PO4I/1etLE5HCbYJSWaWQA9WREAGlPSr12hcXRs82CJdwajWUnQMuUJbx7S4t Yxe+6QVdsmqQBQBv3L0ZFiA0B+iLpqr1BW0RVqLBeaYXSynQ2GiBfsuEWZy7jXIH f3eAfB9qUz1B03BVVwLFUlazGKFkQE1KOFKxsDi9uEymvMHDpXZQSSpHYV35F9GJ 72vzSmmtJ4Gp2wZpg9eaZcrJHjoiBu7i8vnqMK9/9A7U1k58EU7DZjc5wj9pStlV taF9WLYfFcEIY7YjNwozH5yLKySCX/erKyq4CbWUyVXOt/P5XARnye4PXvyzAwQH eUhAzSYFU4Dp/9V8rqVRixP0JdVIPf6FW2ajlKjNasj31EQLyksvsPZgu4r5xsp4 MnqQ3PpAtG+JiB2pI1vN2mMPtCL9DkvACFmlxgJeJ/EU9yxkBmXGIR9aXrnLpD36 cwDK0MYvEUk0gREyA9BaOCKH6CViPgrI+XWy8CSytGi3SB475RkfNApM6YCEKuTR blcRHI4P9Dy4Q3zGcQ5FWXQwdYXmog6+KU0gI97ywox0Wap/wMjszGgWdfjaktJh U9xHZHU5UGVmrgmwIwUO =8WEq -----END PGP SIGNATURE----- _______________________________________________ IOT mailing list IOT@xmpp.org http://mail.jabber.org/mailman/listinfo/iot
This email and any information disclosed in connection herewith, whether written or oral, is the property of EnerNOC, Inc. and is intended only for the person or entity to which it is addressed. This email may contain information that is privileged, confidential or otherwise protected from disclosure. Distributing or copying any information contained in this email to anyone other than the intended recipient is strictly prohibited. _______________________________________________ IOT mailing list IOT@xmpp.org http://mail.jabber.org/mailman/listinfo/iot ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3345 / Virus Database: 3199/6420 - Release Date: 06/18/13
participants (4)
-
Jonas Wielicki -
Peter Saint-Andre -
Peter Waher -
Thomas Nichols