Hello

Last Friday, IEEE had an introductory WG meeting in their effort to create a standard for IoT based on XMPP. As a member and representative of XSF I participated and expressed my desire to partake in this work. I also expressed the need for IEEE to work with XSF in order to make the IEEE standard an approved XEP. The WG meeting was a presentation made by IEEE with very limited time for discussion/questions. So I wrote them a letter (below) with comments and questions. The material they’ve published are for WG members only, but only included some schematics without technical details. I’ve requested they put more technical details about what has already been developed/standardized – let’s see if we can get access to that.

I see a possible conflict between the interests of IEEE and XSF which needs to be addressed: While XSF is open and community based, XEP’s being available for free, IEEE is closed and standards are not available for free. So, one item to solve, is how to create a XEP (which would include all necessary technical details), without breaking any IEEE rules & regulations. Anybody has any experience working with IEEE & ISO?

Were there any other XSF members at the IEEE meeting?

Any suggestions, comments or disagreements with the below?

I don’t think I can forward the presentations made in the WG to this list. But I believe William Miller is on the IoT mailaing list, and if he sees it fit, might forward them. Or, if not, If anybody wants to get access to the presentations, and were not in the WG meeting, you can try mailing him directly: mact-usa@att.net.

Sincerely,

Peter Waher

From: Peter Waher
Sent: den 11 januari 2013 14:42
To: 'William Miller via IEEESA via IEEE-SA'
Cc: mact-usa@att.net
Subject: RE: [145114public] ISO-IEC-IEEE_M13010101.doc

Dear William Miller.

Thank you for a good presentation, and I applaud your effort.

As a member of the XMPP Standards Foundation (XSF), it is in my interest to address the following topics:

· Sensor networks & IoT over XMPP

· Extending the semantic web over XMPP

· Distributed social networks using XMPP

From the presentations today, I would like to point out the following as important aspects that need to be addressed to have a successful standard for (W)SN over XMPP:

· XMPP is a message transport protocol, and not a request/response protocol, as you pointed out. This implies:

o Request/response mechanisms, important in many metering applications, have to be implemented specifically and security, failability, etc., to be addressed.

o It allows for asynchronous event notification, as you mentioned.

o XMPP also allow for multi-cast messages to receptors that are not registered as friends. In XMPP this is called Multi-user-chat (MUC). This might be a very efficient means of mass-distribution of important information (like setting of sensors clocks), but its use and security issues needs to be regulated.

· Different sensor architectures need to be addressed by the WG:

o Client<->Client (peer-to-peer) is obviously the ultimate goal, i.e. sensors implementing XMPP directly, communicating over IP(6).

o Client<->Gateways<->Client, using proprietary protocols, as you’ve mentioned.

o Client<->Concentrator<->Server, where the server communicates XMPP with concentrators, but concentrators communicate in some (proprietary) fashion with its devices.

o Client->XMPP Server<->Client/Server, Clients (on a limited battery) can publish information (publish/subscribe in XMPP) to XMPP Servers while awake, and peers can read this information even when sensors are asleep. Security considerations and guidelines need to be developed.

· Identity. You’ve mentioned that a sensor needs to be identified using a GUID. XMPP has a method of identifying (uniquely) clients already (called a JID, Jabber ID), similar to mail clients: UserID@Domain/Unit. The operator of the XMPP server defines the domain, and UserIDs are unique in the namespace of the XMPP server. Unit allows different clients (i.e. applications/sensors, etc) behind an address. The Unit is based on the current session. The main obstacle here is to map GUIDs to the JID’s without inserting mapping conflicts. XMPP servers allow for automatic account creation, which would allow sensors to automatically register itself. It could create a JID similar to GUID@domain. However, automatic account creation opens up a series of security issues. Creating accounts manually (or semi-automatically) might be possible, but allows for erroneous maps, and a lot of problems on the distribution side of the (W)SN.

· Since we talk about including WSN with possible little RAM, I would like to note that there’s an effort by IETF and W3C called EXI (Efficient XML Interchange). While compression is not particularly important in PC<->PC communications, for small embedded devices, it might be important.

o W3C WG & recommendation: http://www.w3.org/XML/EXI/

o For a standard aiming at (all) WSN, it would be prudent to include EXI as an option.

o No XMPP Server (that I am aware of, might be wrong) supports EXI today. Support needs to be drawn from developers of XMPP Servers, if this is to be an architectural feature of the new IEEE standard.

o There are tools that automatically create efficient C/C++ code for compression/decompression of XML based on valid & known XML Schemas.

· To be able to create an approved XEP (XMPP Extension), the XSF needs to be involved. This means (in short words):

o The XEP needs to be documented and mailed (in a specific format) to the XSF for voting.

o Any objections needs to be worked on, or responded to.

o When approved, it will become experimental.

o After sufficient implementation experience exists, it may become rejected or approved.

o The current working group needs to understand, that it cannot simply post a proposal, and being IEEE it will automatically be accepted. It has to be subject to vote and possibly change, as it might not be optimal or sufficient for XMPP. (Not being optimal or sufficient opens up for new XEPs to be created, which should be avoided If possible.)

o More information: http://xmpp.org/extensions/xep-0001.html

I’m interested to participate in work relating to XSF and XEP, according to the descriptions in the above item. I’m also interested to participate in all proposed groups SG1, SG2 & SG3,to make sure they take into account above items.

Any contact details can be found below

Sincerely,

Peter Waher

Peter Waher, Gerente General

Clayster Chile Ltda

Calle Blanco 1623, oficina 1402

Valparaíso, Chile

Teléfono: +56-32-2122533, +56-9-71993640

Skype: peter.waher

Correo electrónico: peter.waher@clayster.com

Twitter: https://twitter.com/ClaysterLabs, https://twitter.com/PeterWaher

LinkedIn: http://se.linkedin.com/pub/peter-waher/1a/71b/a29

La información contenida en esta transmisión es confidencial y propietaria y no puede ser utilizada por personas distintas a su(s) destinatario(s). La utilización no autorizada de la información contenida en este correo por cualquier forma puede ser sancionada criminalmente de conformidad con la Ley Chilena e infringir normas sobre propiedad intelectual, propiedad industrial o secretos comerciales. Si ha recibido esta transmisión por error, por favor destrúyala y notifique al remitente telefónicamente, con cobro revertido o vía e-mail. Atendido que no existe certidumbre que el presente mensaje no será modificado como resultado de su transmisión por correo electrónico CLAYSTER Laboratorios Chile Limitada, no será responsable si el contenido del mismo ha sido modificado. Visite nuestra página WEB www.clayster.com.

The information contained in this transmission is confidential and proprietary and it cannot be used by any person other than its addressee(s). Unauthorized use of the information contained in this transmission in any form may be punished under Chilean Law and be considered a copyright, industrial property or trade secrets infringement. If received in error, please destroy it and notify the sender by calling collect or e-mail. As there can be no certainty that this message will not be modified as a result of its transmission via e-mail, CLAYSTER Laboratorios Chile Limitada shall not be responsible if the content of the same has been modified. Visit www.clayster.com.

From: Peter Waher
Sent: den 2 januari 2013 22:17
To: 'William Miller via IEEESA via IEEE-SA'
Cc: mact-usa@att.net
Subject: RE: [145114public] ISO-IEC-IEEE_M13010101.doc

Dear William Miller.

Find my responses to your questions in the attached document.

Sincerely,

Peter Waher

From: William Miller via IEEESA via IEEE-SA [mailto:reply.21707498.305616.35809258626BD0CE3E8DCF4408D92EF3C97104646@in.centraldesktop.com]
Sent: den 1 januari 2013 22:55
To: Peter Waher
Subject: [145114public] ISO-IEC-IEEE_M13010101.doc

~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=

New File Added: ISO-IEC-IEEE_M13010101.doc (142 KB) Download File

Uploaded By: William Miller

Comment:

To All Members,

Please review the attached file and return your response prior to January 11, 2013.

Thanks for your participation.

All the best for the New Year 2013!

Description: Member Questionnaire..

Reply to this email to respond to all participants in this thread. Your response will be logged in Central Desktop.

Participants:

Abhinna Biswal, akh@et.aau.dk, Ana Stachowiak, Anthony SUNG, António Espírito Santo, Arumugam Manoharan, Asghar Mesbah-Nejad, Benny Shaya, Bhupender Bodh, bob.wynnyk@vishaypg.com, and 85 others

Workspace: 21451-1-4 Working Group Public » Items not in Folders

To view the details of this item visit:
http://ieee-sa.centraldesktop.com/p/aQAAAAABSzrq

Click Here to Unsubscribe from this File.