[Standards] Proposed XMPP Extension: Message Replies
The XMPP Extensions Editor has received a proposal for a new XEP. Title: Message Replies Abstract: This document defines a way to indicate that a message is a reply to a previous message. URL: https://xmpp.org/extensions/inbox/replies.html The 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: standards-unsubscr...@xmpp.org ___
[Standards] Proposed XMPP Extension: Call Invites
The XMPP Extensions Editor has received a proposal for a new XEP. Title: Call Invites Abstract: This document defines how to invite someone to a call and how to respond to the invite. URL: https://xmpp.org/extensions/inbox/call-invites.html The 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: standards-unsubscr...@xmpp.org ___
[Standards] Proposed XMPP Extension: PubSub Namespaces
The XMPP Extensions Editor has received a proposal for a new XEP. Title: PubSub Namespaces Abstract: This extension defines a new PubSub node attribute to specify the type of payload. URL: https://xmpp.org/extensions/inbox/pubsub-ns.html The 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: standards-unsubscr...@xmpp.org ___
[Standards] Proposed XMPP Extension: Compatibility Fallbacks
The XMPP Extensions Editor has received a proposal for a new XEP. Title: Compatibility Fallbacks Abstract: This document defines a way to indicate that a specific part of the body only serves as fallback and which specification the fallback is for. URL: https://xmpp.org/extensions/inbox/compatibility-fallback.html The 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: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0425 (Message Moderation)
> 1. Is this specification needed to fill gaps in the XMPP protocol > stack or to clarify an existing protocol? Yes, this is a needed use case. > 2. Does the specification solve the problem stated in the introduction > and requirements? No. This has been pointed out by Marvin very well, so not going to repeat. I'm actually torn between the IQ semantics of the XEP and the message-based semantics of 0308 and 0424. IQ ensures the authorization of the moderator, but has a rather cumbersome flow requiring significant differences from 0308 and 0424, and different payload types. I'd prefer a message-based retraction/moderation, but then everybody could add a "moderate" element to a MUC message and all recipients would have to reconstruct the room membership at the time of that message. What if we would implement a mixed approach, where any moderator can send an LMC / retraction / flagging message to the room, and the room service would verify the moderator's permissions and re-send the respective message from the bare JID of the room (indicating that it is legitimate) with an additional by=moderator element/attribute stuffed somewhere, e.g. Perpetrator sends: DM me for free magic potions! Moderator sends: This message contains inappropriate content for this forum And the room intercepts that, tombstones the original message and sends an annotated retract from the room JID: This message contains inappropriate content for this forum This could also work with whatever syntax we figure out for 0424, and it could work with 0308 with another element indicating who moderated the message. A MUC that supports the protocol would reject moderation from non-moderators, and a legacy MUC would just reflect the moderation attempts wth @from set to the full JID of the non-moderator. A receiving client then only needs to ensure that the moderation comes from the original sender or the bare room JID, which is not too hard to accomplish. > 3. Do you plan to implement this specification in your code? If not, > why not? Yes, eventually. > 4. Do you have any security concerns related to this specification? No. > 5. Is the specification accurate and clearly written? See above & remarks from Marvin. Georg P.S: I accidentally signed my last message to the list <20220104170640.vo2lhw3iit7uy...@boerde.de> with the wrong key. I hereby assure that I was the sender indeed. signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0424 (Message Retraction)
* Sam Whited [2021-12-07 19:38]: > I would like to point out that this specification relies on XEP-0359, > XEP-0422, and XEP-0428 all of which are deferred. While 0359 is widely > implemented and probably fine to rely on, I don't believe 0422 is as > widely used and we should probably let a solution for referencing other > messages shake out before advancing something that relies on one that > may not be the final solution. I fully agree with that. (Personally, I'd just love to see origin-id disappear and have modern clients use @id consistenly everywhere to reduce the amount of ambiguity. However, I'm not going to veto just because of this) > I also just think that fastening is unnecessary in this context; > retract can just include the stanza ID directly, no need for all the > extra protocol. I understand that some server developers have a creative use case for fastening as a generic mechanism to make logical connections between different messages, but I think that each of the different logical connections requires its own business rules that can not be generalized into something that's less frightening than XSLT. Until we have sorted that out, I'm not sure if fastening fastening to our protocols is a good idea. I also very much like the simple syntax of XEP-0308 and I think it would be fully adequate for the use case of message retraction. I'd even go as far as suggesting an LMC payload as part of the fallback for 0424 to accomodiate clients that do 0308 but don't do 0424 ;) Georg smime.p7s Description: S/MIME cryptographic signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XMPP Council Agenda 2022-01-05
Hi, the next XMPP Council meeting will take place on January 5th 2022 at 16:00Z in xmpp:coun...@muc.xmpp.org?join The agenda is as follows: 1) Roll call 2) Agenda bashing 3) Editors update - None. 4) Items for voting * LAST CALL: XEP-0424 (Message Retraction) * LAST CALL: XEP-0425 (Message Moderation) 5) Pending votes Everyone but Jonas pending on XEP-0060: Release version 1.23.0 (https://github.com/xsf/xeps/pull/1126) See the all new Spreadsheet of Doom: https://docs.google.com/spreadsheets/d/1aA6tQJ8XJ_UjCKrcJ6CyG-l3L5xETSlBrPRR-37Z_1E/edit?usp=sharing 6) Date of Next 7) AOB 8) Close ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
