Thanks Ralph. On Fri, Sep 26, 2014 at 3:36 PM, Ralph Meijer <[email protected]> wrote: > 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!
Excellent. >> 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. The way I read IOT-Events, it was a single subscription, but I'm hoping Peter or other IOT folks can weight in here much more usefully than I can. Fortunately we have the mechanisms in xep60 to cope with either. > 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]? Good catch. > 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> Yep - my strings were meant to be placeholders rather than real suggestions (but you're right that I should have just written them in a sensible format to start with). /K
