IoT SIG

From XMPP WIKI
Jump to: navigation, search

Contents

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

https://meet.jit.si/XsfIotSig

Next Meeting

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

Past Meeting Protocols

IoT_SIG/2016-12-22

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.