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 go through the IETF (this document can reference any particular SASL mechanism for MTI it likes, including this one). The right working group is - probably - Kitten, though traditionally XMPP itself works through the ART area, and we might want to give an ART AD or two a heads-up. This issue is a blocker for me.
2) I don't think ยง5.2.3 is right - I don't think ISR should be placing any requirements on the upper layer. You might think - correctly - that a server requiring 2FA on a resume is not behaving very sensibly, but I don't think it's behaving in a way that would cause interoperability problems. 3) My usual distaste for the made-up term "Nonza" remains. Given you clearly understood XEP-0388, which does not use the term, I remain mystified as to its purpose. On 20 March 2017 at 17:50, XMPP Extensions Editor <[email protected]> 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 > XMPP entities to instantaneously resume an XMPP stream. > > URL: https://xmpp.org/extensions/inbox/isr-sasl2.html > > The XMPP Council will decide in the next two weeks whether to accept this > proposal as an official XEP. > > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
