On 2014-09-26 15:26, Kevin Smith wrote: > Hi folks, > I promised to see if I could think of something sensible to say > about IOT-Events. > > My core concern here is that this spec > (http://xmpp.org/extensions/inbox/iot-events.html) is designed such > that one entity can publish events, to which assorted other entities > can subscribe, which fundamentally sounds like pubsub, for which we > have some coverage in XEP-0060. IOT-Events comes up with a completely > new syntax for both the subscribing and the publishing from that > described in XEP-0060, and I'd like to see if there is common ground > for sharing syntax (and, ideally, semantics). > > I note at this point that re-use of XEP-0060 syntax would not imply > the use of central pubsub services on components or servers. In > IOT-Events, a Thing is its own (IOT-Events)pubsub service; I'm > interested in seeing if they could be their own (XEP-0060 > subset)pubsub service instead.
I like this general approach! > I suggest we define a standard form that can hold the subscription > options in IOT-Events, so example 1: > > <iq type='get' > from='[email protected]/amr' > to='[email protected]' > id='S0001'> > <subscribe xmlns='urn:xmpp:iot:events' seqnr='1' > momentary='true' maxInterval='PT5M' req='true'/> > </iq> > > would become something a bit like > > <iq type='get' > from='[email protected]/amr' > to='[email protected]' > id='S0001'> > <pubsub xmlns='http://jabber.org/protocol/pubsub'> > > <subscribe > node='somethings' > jid='[email protected]/amr'/> > <options> > <x xmlns='jabber:x:data' type='submit'> > <field var='FORM_TYPE' type='hidden'> > <value>http://jabber.org/protocol/pubsub#subscribe_options</value> > </field> > <field var='iot#seqnr'><value>1</value></field> > <field var='iot#momentary'><value>true</value></field> > <field var='maxInterval'><value>PT5M</value></field> > <field var='pubsub#deliver'><value>1</value></field> > </x> > </options> > </pubsub> > </iq> > > These fields can be standardised in IOT-Events such that discovery is > not necessary, and the number of roundtrips remains the same. A few things here, where I'll refer to XEP-0060 (Publish-Subscribe) version 1.13, as a bunch will move out of XEP-0060 post-split. 1) If I read iot-events correctly, it appears that an entity can have multiple subscriptions to the same 'device'. I see this example uses the node 'somethings'. The combination of these results in the following questions: 1a) How would node identifiers be used in this context? I note that XEP-0323 has the concept of node identifiers. Do these map to general concept of nodes we have in XEP-0060 and also service discovery (XEP-0030)? If so, I note that the attribute used in XEP-0323 (IoT Sensor Data) should really be called 'node' and not 'nodeId' for consistency. If not, it should receive a different name than 'node'. I have more beef with attribute/element naming in XEP-0323 in general, but that's probably out of scope for this exchange. 1b) Can an entity have more than one subscription to the same node/device/entity? 1c) Or, alternatively, will there be a single node identifier (maybe the empty one, also called root node) and will subscriptions be content based rather than topic based? Or a combination of such maybe, where this is like Collections (XEP-0248), but with just a single collection at the root. 2) Is 'seqnr' as currently proposed not exactly like the subscription identifier in Content-based Subscriptions as defined in section 12.19 of XEP-0060 [1]? 3) I want to remark the fields in the example of the form are not named like we want them to look eventually (see XEP-0068). It would be more like: <x xmlns='jabber:x:data' type='submit'> <field var='FORM_TYPE' type='hidden'> <value>http://jabber.org/protocol/pubsub#subscribe_options</value> </field> <field var='{urn:xmpp:iot:sensordata}seqnr'> <value>1</value> </field> <field var='{urn:xmpp:iot:sensordata}momentary'> <value>true</value> </field> <field var='{urn:xmpp:iot:sensordata}maxInterval'> <value>PT5M</value> </field> <field var='pubsub#deliver'><value>1</value></field> </x> [1] http://xmpp.org/extensions/xep-0060.html#impl-content -- ralphm
