On 20 March 2017 at 22:04, Florian Schmaus <f...@geekplace.eu> 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 >> 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. > > Section 6. was written in mind being probably factored out. So I'm happy > to bring this to the IETF. Anyone who wants to shepherd me? >
I'm confident we can find a shepherd, but I can do that if we need one. (Assuming you actually do mean a Document Shepherd). Incidentally, I think a token-based SASL mechanism might be generally useful; Surevine could use one if it existed, certainly. It's useful to have a device-specific token which can then be managed and/or revoked, independent of ISR - this implies a multiple-use token rather than a single-use one, however. I have a vague feeling that something based around a fusion of HOTP and YAP might yield something that satisfies this. If you're open to the idea, I'll outline a quick design. > What is MTI? > "Mandatory To Implement". (But not to deploy). >> 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. > > I'm sorry, but I'm confused (maybe it is already to late for me :)). You > mean ISR should not allow 2FA on resume? Why not? Care to elaborate what > you mean with "placing any requirements on the upper layer"? If ISR is > based on SASL2, why shouldn't it also support <continue/> XEP-0388 § 2.6.3? > No, I mean the reverse. §5.2.3 says: Performing instant stream resumption using multiple SASL mechanisms MUST only be done if the 'without-isr-token' attribute is set to 'true'. I took that to mean, "Servers MUST NOT use <continue/> if the without-isr-token attribute is set to true". >> 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. > > I tired to motivate a clear definition for Nonzas in XEP-0360 § 1. and > like to point out that I receive many positive feedback for doing so. I > also note that I asked for suggestions for the exact term back then. I don't think it needs (and has ever needed) a single word term. Most of the time, "element" suffices. > Anyway, I assume that 3) is no blocker for you? Neither (3) nor (2) are blockers - that is I won't use my veto, though I'll continue to argue against both. Dave. _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
