Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

2017-03-20 Thread Peter Saint-Andre
On 3/20/17 4:23 PM, Dave Cridland wrote: > On 20 March 2017 at 22:04, Florian Schmaus wrote: >> On 20.03.2017 22:32, Dave Cridland wrote: >>> Loosely, this is OK, but, in order: >>> >>> 1) Section 6 must go. I don't believe that the XSF has the required >>> expertise to

Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

2017-03-20 Thread Sam Whited
On Mon, Mar 20, 2017 at 12:50 PM, XMPP Extensions Editor wrote: > URL: https://xmpp.org/extensions/inbox/isr-sasl2.html > Example 2. An xmlns:isr='urn:xmpp:isr:0' \ isr:mechanism='X-HT-SHA-256-ENDP'/> I don't think that namespaced attributes are necessary; they add

Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

2017-03-20 Thread Dave Cridland
Ah, but Kev noted to me that this is using namespaced attributes. We have, traditionally, avoided these, on the basis that nobody (well, almost nobody) understands them. I don't think these are actually required here; a child element will work just as well. Can we do that instead? On 20 March

Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

2017-03-20 Thread Dave Cridland
On 20 March 2017 at 22:04, Florian Schmaus wrote: > On 20.03.2017 22:32, Dave Cridland wrote: >> Loosely, this is OK, but, in order: >> >> 1) Section 6 must go. I don't believe that the XSF has the required >> expertise to adequately review a SASL mechanism. I'm saying this >>

Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

2017-03-20 Thread Florian Schmaus
On 20.03.2017 22:32, Dave Cridland wrote: > Loosely, this is OK, but, in order: > > 1) Section 6 must go. I don't believe that the XSF has the required > expertise to adequately review a SASL mechanism. I'm saying this > without commenting on the mechanism described in Section 6. This needs > to

Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

2017-03-20 Thread Peter Saint-Andre
On 3/20/17 3:32 PM, Dave Cridland wrote: > Loosely, this is OK, but, in order: > > 1) Section 6 must go. I don't believe that the XSF has the required > expertise to adequately review a SASL mechanism. I'm saying this > without commenting on the mechanism described in Section 6. This needs > to

Re: [Standards] Proposed XMPP Extension: Instant Stream Resumption

2017-03-20 Thread Florian Schmaus
On 20.03.2017 18:50, XMPP Extensions Editor wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Instant Stream Resumption > > Abstract: This specification introduces a mechanism for instant > stream resumption, based on Stream Management (XEP-0198), allowing >

[Standards] Proposed XMPP Extension: Instant Stream Resumption

2017-03-20 Thread XMPP Extensions Editor
The XMPP Extensions Editor has received a proposal for a new XEP. Title: Instant Stream Resumption Abstract: This specification introduces a mechanism for instant stream resumption, based on Stream Management (XEP-0198), allowing XMPP entities to instantaneously resume an XMPP stream. URL:

Re: [Standards] Soliloquy (self-message) routing rules (RFC6121, XEP-0280)

2017-03-20 Thread Philipp Hörist
Hi, To only generate "sent" carbons when a message is sent to ourself, seems like a easy solution that would make the self messaging use case a bit less complex. I see no downsides to this. To drop that one message that has to be issued according to 6121, seems ok. Philipp

Re: [Standards] Soliloquy (self-message) routing rules (RFC6121, XEP-0280)

2017-03-20 Thread Edwin Mons
On 20/03/2017 16:22, Georg Lukas wrote: > Hi, > > sometimes IM users want to talk to themselves, e.g. to send a URL from > one device to another, or to take notes. In systems like Slack this is > recognized and the self-message area is provided as a draft board. > > In modern XMPP

[Standards] Soliloquy (self-message) routing rules (RFC6121, XEP-0280)

2017-03-20 Thread Georg Lukas
Hi, sometimes IM users want to talk to themselves, e.g. to send a URL from one device to another, or to take notes. In systems like Slack this is recognized and the self-message area is provided as a draft board. In modern XMPP (6121+Carbons/MAM), messages-to-self are always delivered twice(*),

Re: [Standards] Broken XEP PDFs on xmpp.org/extensions (no ToC)

2017-03-20 Thread Sam Whited
On Mon, Mar 20, 2017 at 3:02 AM, Marvin Gülker wrote: > I looked into this problem a little more, and it appears that the > Makefile only runs xelatex once. Sorry about that; this was an oversight on my part. I've fixed it and will merge the changes when CI passes

[Standards] Add a join-and-maybe-create-channel primitive to MIX?

2017-03-20 Thread Florian Schmaus
I found myself a few days ago writing a getOrCreateLeafNode() method for Smack's PubSubManager [1] and noticed that Smack has a similar method for MUC (createOrJoin(), [2]). Both methods are often required, e.g. you need the PubSub one for OMEMO (or everything PEP). But both methods are inherent

Re: [Standards] Broken XEP PDFs on xmpp.org/extensions (no ToC)

2017-03-20 Thread Marvin Gülker
On Sat, Feb 25, 2017 at 09:42:10AM +0100, Marvin Gülker wrote: > However, it appears there's a number of XEPs on xmpp.org/extensions > whose PDF files have no Table of Contents, albeit the HTML versions > have. I looked into this problem a little more, and it appears that the Makefile only runs