Jump to: navigation, search


Internet of Things Special Interest Group (IoT SIG)

Welcome to the Wiki page of the XSF IoT SIG (XEP-0381)

We use Jitsi Meet for the meeting (please turn of video to reduce the bandwith consumption). Please use jitsi to join

Next Meeting

The next meeting of the SIG is at: TBA (some time after the XSF Summit)

Past Meeting Protocols


Current Action Items

Definition of Friendship

The term Friendship is nowhere formally specified as XMPP protocol primitives in the XEPs, yet it is a fundamental building block of the IoT XEPs. I'd like to change the XEPs so that they define Friendship as "E is a friend of T, iff E is subscribed to T's presence" (where E is an entity, and T is a thing).

Notification mechanism of owner decision

A common scenario which caused us a lot of effort to addresses when integrating Smack's client code with Claysters provisioning server. Consider an XMPP entity R trying to befriend a thing T. R sends a presence subscription request to T to do so. T forwards that request in form of a isFriend request to its provisioning server (PS). The PS now exposes the pending friendship request of R in its web interface while at the same time sends a "R is not a friend of T" response to T. Upon receiving that response T will reject R's presence subscription request. R now just got its friendship request rejected without knowing the reason. Was it denied by the owner?

  R    presence subscribe request -->   T
                                        T "isFriend R?" --> PS
                                                            publish on web
                                        T <-- isNotFriend   PS
  R <-- presence unsubscribed           T

Now, at some later point in time, the Owner (O) uses the PS's web interface to accept the friendship request. The current IoT XEPs miss a mechanism to deliver that decision to R.