Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption
On 16.02.2016 20:01, Thijs Alkemade wrote: > >> On 16 feb. 2016, at 17:18, XMPP Extensions Editor wrote: >> >> The XMPP Extensions Editor has received a proposal for a new XEP. >> >> Title: Instant Stream Resumption >> >> Abstract: This specification introduces an mechanism for instant >> stream resumption, based on Stream Management (XEP-0198), allowing >> XMPP entities to instantaneously resume an XMPP stream. >> >> URL: http://xmpp.org/extensions/inbox/isr.html >> >> The XMPP Council will decide in the next two weeks whether to accept this >> proposal as an official XEP. > > > I'll just repeat my point that all quick connection attempts so far seem to > throw out mutual authentication without hesitation. That may be an acceptable > trade-off in certain scenarios, but it should be emphasized that it decreases > security. Thanks for your feedback Thijs. As always, much appreciated. I'd like to say that it's in fact the first time that someone directs me into the mutual authentication problematic. Would adding a 'remotetok' be sufficient. E.g. And then on instant resumption the initiator sends and the remote part responds with Could it really be so easy to add mutual authentication to ISR, or am I missing something? - Florian signature.asc Description: OpenPGP digital signature ___ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption
On 16.02.2016 20:01, Thijs Alkemade wrote: > >> On 16 feb. 2016, at 17:18, XMPP Extensions Editor wrote: >> >> The XMPP Extensions Editor has received a proposal for a new XEP. >> >> Title: Instant Stream Resumption >> >> Abstract: This specification introduces an mechanism for instant >> stream resumption, based on Stream Management (XEP-0198), allowing >> XMPP entities to instantaneously resume an XMPP stream. >> >> URL: http://xmpp.org/extensions/inbox/isr.html >> >> The XMPP Council will decide in the next two weeks whether to accept this >> proposal as an official XEP. > > > I'll just repeat my point that all quick connection attempts so far seem to > throw out mutual authentication without hesitation. That may be an acceptable > trade-off in certain scenarios, but it should be emphasized that it decreases > security. Thanks for your feedback Thijs. As always, much appreciated. I'd like to say that it's in fact the first time that someone directs me into the mutual authentication problematic. Would adding a 'remotetok' be sufficient. E.g. And then on instant resumption the initiator sends and the remote part responds with Could it really be so easy to add mutual authentication to ISR, or am I missing something? - Florian signature.asc Description: OpenPGP digital signature ___ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption
> On 16 feb. 2016, at 17:18, XMPP Extensions Editor wrote: > > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Instant Stream Resumption > > Abstract: This specification introduces an mechanism for instant > stream resumption, based on Stream Management (XEP-0198), allowing > XMPP entities to instantaneously resume an XMPP stream. > > URL: http://xmpp.org/extensions/inbox/isr.html > > The XMPP Council will decide in the next two weeks whether to accept this > proposal as an official XEP. I'll just repeat my point that all quick connection attempts so far seem to throw out mutual authentication without hesitation. That may be an acceptable trade-off in certain scenarios, but it should be emphasized that it decreases security. Thijs signature.asc Description: Message signed with OpenPGP using GPGMail ___ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Token-based reconnection
On 14.02.2016 22:25, Daniel Gultsch wrote: > Hi, > > I said this before but I'll say it again on public record. I like it a > lot. It's very simple, straight forward and thus easy to implement. Both > on the server as well as on the client side. Thanks for the positive feedback. I believe the same to be true and this was a major design principle of ISR. > One comment regarding the isr:location attribute. It's not specified > whether this will be a normal connection or a TLS connection. It *is* specified (at least I tried to express this): """ Note that the hosts announced by the 'location' attribute qualified by the 'urn:xmpp:isr:0' namespace MUST be connected to using Transport Layer Security (TLS, see RFC 5246 [5]) from the beginning, i.e. MUST NOT be used, instead the TLS Handshake is performed right after establishing the connection. """ - Florian signature.asc Description: OpenPGP digital signature ___ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Proposed XMPP Extension: Instant Stream Resumption
The XMPP Extensions Editor has received a proposal for a new XEP. Title: Instant Stream Resumption Abstract: This specification introduces an mechanism for instant stream resumption, based on Stream Management (XEP-0198), allowing XMPP entities to instantaneously resume an XMPP stream. URL: http://xmpp.org/extensions/inbox/isr.html The XMPP Council will decide in the next two weeks whether to accept this proposal as an official XEP. ___ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0357: Push Notifications is missing business rules section
* Daniel Gultsch [2016-02-16 13:32]: > However the XEP is missing some important business rules on *when* to send > push notifications. It only describes the how. I think this should be > clarified for the sake of consistency across multiple clients and multiple > servers. +1 The rules you suggest sound good to me (for IM clients). > for (a) it is no required to keep the session open for much longer than > regular. Except that the server shouldn't simply close the session n minutes after the TCP connection was closed (as it does for "regular" clients), but only if the push client didn't resume the session within n minutes after a notification was sent. That is, if no stanzas are received, the session isn't closed. Holger ___ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XEP-0357: Push Notifications is missing business rules section
Hi, I finally found the time to implement client side support for XEP-0357: Push Notifications (and also wrote my own app server in the process.) For testing purposes it is working quite well with both the ejabberd module and the prosody module (Many thanks to the respective developers for implementing them.) However the XEP is missing some important business rules on *when* to send push notifications. It only describes the how. I think this should be clarified for the sake of consistency across multiple clients and multiple servers. After some consideration and discussions with server developers I came to believe that the following rules are desirable: 1) A server - over time - collects the various delivery targets which are a combination of jid and node attribute + x contained in the enable request. 2) A client resends those on every connect (because it can not know whether the server already knows about this particular delivery target. 3) As a consequence of (2) the server knows the delivery target for a particular session 4) There are three different 'push scenarios' (Situations in which the server should initiate a push) a) In a XEP-0198 stream management session with a closed TCP connection the server should notify the corresponding delivery target on every new stanza that would have been delivery if the TCP stream was alive (meaning all stanzas but honouring CSI if enabled.) b) If a message is being archived into MAM (honouring the MAM archiving rules) *every* delivery targets should be notified unless that delivery target was already notified by rule (a) c) copies rule (b) for offline messages meaning all delivery targets should be notified when a new offline message arrives. (c) and (b) can be combined into one push scenario depending on the server implementation (when MAM and offline are fed by the same data source) for (a) it is no required to keep the session open for much longer than regular. (ejabberd currently does this so i'm saying this here) cheers Daniel ___ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
