[Standards] NEW: XEP-0470 (Pubsub Attachments)
Version 0.1.0 of XEP-0470 (Pubsub Attachments) has been released. Abstract: This specification provides a way to attach elements to a pubsub item. Changelog: Accepted by vote of Council on 2022-07-27. (XEP Editor (jsc)) URL: https://xmpp.org/extensions/xep-0470.html Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] NEW: XEP-0469 (Bookmark Pinning)
Version 0.1.0 of XEP-0469 (Bookmark Pinning) has been released. Abstract: This document defines an XMPP protocol extension to allow users to pin PEP Native Bookmarks. Changelog: Accepted by vote of Council on 2022-07-27. (XEP Editor (jsc)) URL: https://xmpp.org/extensions/xep-0469.html Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] STABLE: XEP-0215 (External Service Discovery)
Version 1.0.0 of XEP-0215 (External Service Discovery) has been released. Abstract: This document specifies an XMPP protocol extension for discovering services external to the XMPP network. Changelog: Accept as Stable as per Council Vote from 2022-08-03. (XEP Editor (jsc)) URL: https://xmpp.org/extensions/xep-0215.html Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] UPDATED: XEP-0447 (Stateless file sharing)
Version 0.2.0 of XEP-0447 (Stateless file sharing) has been released. Abstract: This specification describes a protocol for stateless asynchronous file sharing with integrity and transport flexibility. It allows clients to provide a good interoperable user experience in combination with Carbons and MAM. Changelog: Add disposition attribute to signal when inlining is desired. (lmw) URL: https://xmpp.org/extensions/xep-0447.html Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] NEW: XEP-0397 (Instant Stream Resumption)
On 22/08/2022 16.07, Daniel Gultsch wrote> I have some new found interest in Instant Stream Resumption and after reading the XEP again I find myself agreeing with a lot of what Dave said 4.5 years ago especially with regard to decoupling the HT-* family of authentication from ISR itself. One might argue that more XEPs means more complexity but to the contrary I think it would actually reduce complexity because one could - theoretically - implement ISR with PLAIN and then not having to worry about HT-* and channel binding. (Don’t get me wrong I like channel binding and I like HT-* but if one is in the market for some quick and easy stream resumption being able to do it with PLAIN would help a lot.) The XEP is written with that in mind (as far as I remember). It has a strong bias towards SASL HT-* as this mechanisms protects the token, whereas using PLAIN does not. Furthermore, it is not immediately clear what Instant Stream Resumption (ISR) and SASL PLAIN exactly is, as there are (at least) two approaches imaginable (that also do not rule each other out): First, perform ISR + SASL PLAIN with the users password. Which would be a big step backwards in terms of security. Second, perform ISR + SASL PLAIN with the token obtained by ISR. Obviously better than the first variant, while not as secure as HT-*. I think all variants, including the HT-* one have different advantages and disadvantages, and we ultimately need more implementation experience. So, by all means, please go ahead. What Dave outlined in his comment to §4 seems sensible enough to me?! I am not sure what the advantage of obtaining the ISR token simultaneously with the SASL authentication. You need to do the request/response pair to enable Stream Management anyway afterwards (unless you would use bind2, I assume, in which case it wouldn't matter what the parent of the the XML element is). What am I missing? Minor stuff: I’m also agreeing with the feedback on location and compression. However the above (allowing multiple SASL mechanisms) is the urgent one for me right now. I can't find anything regarding 'compression' in Dave's Mail from 2018-01-22. Furthermore, I am not sure how the 'location' attribute from Stream Management can be re-used or how that would improve things. Again, being slightly jet lagged, I am maybe missing something. Examples would probably help. In summary, please go ahead and implement ISR in any way you feel sensible and report back your findings. :) - Flow OpenPGP_signature Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
