Re: [Standards] IOT-Events
[Sending a few mails to try to rekindle this discussion] My summary of where the thread is at the moment is that there’s some support for doing things in a xep60ish way, and no technical objections to doing so but that we need to ensure that what we produce is feasible to implement on the necessary device types (not having unnecessary flexibility beyond that required by the current iot-events proposal). Does that sound fair? /K
Re: [Standards] IOT-Events
[Sending a few mails to try to rekindle this discussion] On Thu, Oct 9, 2014 at 10:53 AM, Joachim Lindborg wrote: > I agree in the need for multiple subscriptions. I have that in several > usecases. OK, thanks. > I would also adress the "keep it simple need" the xep 323 is very easy to > use and the need for events for small sensors are essential to prevent > extensive polling. > Demanding pubsub and forms notation to the devices adds a lot of complexity > to the implementor of the sensor implementor. > > I could almost argue that the stanza should be added to the > xep 323 for simplicity but a see the need for a separate namespace and > perhaps other usecases It's not clear to me exactly how big an issue this is. I stress that I am not suggesting that IoT devices should need to have a full xep60 implementation (if such a thing exists), but rather just that the syntax (and where possible semantics) can be sensibly reused. I'm not suggesting, for example, that there needs to be a full xep4 implementation in the clients allowing them to deal with arbitrary fields (if this is not necessary), just a different representation of the semantics presented by the iot-events proposal so as to have more consistency between IoT XMPP and non-IoT XMPP. I think we should avoid having two ecosystems of IoT and non-IoT XMPP, and just have "XMPP". /K
Re: [Standards] IOT-Events
[Sending a few mails to try to rekindle this discussion] On Tue, Sep 30, 2014 at 5:20 PM, Hund, Johannes wrote: > My $0.02: > >> > >> 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 fully agree that the best way IMHO is generalizing XEP-0060 and keeping as > close as possible to the regular semantics Great. >> 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. > > Maybe I am misundertanding it, but I think single-subscriptions would > restrict some use cases. Could well be, yes. 60 will support either model, though, I think (at least - I don't think it misses anything), we would just need to decide which to go with (assuming we want to tightly define the xep60 subset in use for IoT, so as to minimise complexity for small devices).. > An example use case is if you have different subscriptions with different > timely resolutions, maximum ages etc. > This can happen when you have an entity that has several applications running > which do require different event notifications. > > I would not restrict it to single-subscription given it does not cause an > unreasonable overhead. Sounds reasonable, thanks. /K
[Standards] IOT-Events
I agree in the need for multiple subscriptions. I have that in several usecases. I would also adress the "keep it simple need" the xep 323 is very easy to use and the need for events for small sensors are essential to prevent extensive polling. Demanding pubsub and forms notation to the devices adds a lot of complexity to the implementor of the sensor implementor. I could almost argue that the stanza should be added to the xep 323 for simplicity but a see the need for a separate namespace and perhaps other usecases *Regards* Joachim Lindborg CTO, systems architect Sustainable Innovation SUST.se Barnhusgatan 3 111 23 Stockholm Email: joachim.lindb...@sust.se linkedin: http://www.linkedin.com/in/joachimlindborg Tel +46 706-442270 2014-09-30 18:20 GMT+02:00 Hund, Johannes >: > My $0.02: > > > > >> 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 fully agree that the best way IMHO is generalizing XEP-0060 and keeping > as close as possible to the regular semantics > > > 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. > > Maybe I am misundertanding it, but I think single-subscriptions would > restrict some use cases. > > An example use case is if you have different subscriptions with different > timely resolutions, maximum ages etc. > This can happen when you have an entity that has several applications > running which do require different event notifications. > > I would not restrict it to single-subscription given it does not cause an > unreasonable overhead. > -- *Regards* Joachim Lindborg CTO, systems architect Sustainable Innovation SUST.se Barnhusgatan 3 111 23 Stockholm Email: joachim.lindb...@sust.se linkedin: http://www.linkedin.com/in/joachimlindborg Tel +46 706-442270
Re: [Standards] IOT-Events
My $0.02: > > >> 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 fully agree that the best way IMHO is generalizing XEP-0060 and keeping as close as possible to the regular semantics > 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. Maybe I am misundertanding it, but I think single-subscriptions would restrict some use cases. An example use case is if you have different subscriptions with different timely resolutions, maximum ages etc. This can happen when you have an entity that has several applications running which do require different event notifications. I would not restrict it to single-subscription given it does not cause an unreasonable overhead.
Re: [Standards] IOT-Events
Thanks Ralph. On Fri, Sep 26, 2014 at 3:36 PM, Ralph Meijer 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: >> >> >from='cli...@clayster.com/amr' >>to='dev...@clayster.com' >>id='S0001'> >> > momentary='true' maxInterval='PT5M' req='true'/> >> >> >> would become something a bit like >> >> >from='cli...@clayster.com/amr' >>to='dev...@clayster.com' >>id='S0001'> >> >> >> > node='somethings' >> jid='cli...@clayster.com/amr'/> >> >> >> >> http://jabber.org/protocol/pubsub#subscribe_options >> >> 1 >> true >> PT5M >> 1 >> >> >> >> >> >> 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: > > > > http://jabber.org/protocol/pubsub#subscribe_options > > > 1 > > > true > > > PT5M > > 1 > 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
Re: [Standards] IOT-Events
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: > > from='cli...@clayster.com/amr' >to='dev...@clayster.com' >id='S0001'> >momentary='true' maxInterval='PT5M' req='true'/> > > > would become something a bit like > > from='cli...@clayster.com/amr' >to='dev...@clayster.com' >id='S0001'> > > > node='somethings' > jid='cli...@clayster.com/amr'/> > > > > http://jabber.org/protocol/pubsub#subscribe_options > > 1 > true > PT5M > 1 > > > > > > 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: http://jabber.org/protocol/pubsub#subscribe_options 1 true PT5M 1 [1] http://xmpp.org/extensions/xep-0060.html#impl-content -- ralphm
[Standards] IOT-Events
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 suggest we define a standard form that can hold the subscription options in IOT-Events, so example 1: would become something a bit like http://jabber.org/protocol/pubsub#subscribe_options 1 true PT5M 1 These fields can be standardised in IOT-Events such that discovery is not necessary, and the number of roundtrips remains the same. What do folks think of this as a starting point? (There are further questions that need answering about this approach later...) /K
