[Standards] Council Minutes 2020-04-29
https://logs.xmpp.org/council/2020-04-29?p=h#2020-04-29-165cf7eb87180b83 1) Roll Call Present: Georg, Daniel, Zash, Jonas Apologies: Dave 2) Agenda Bashing Jonas apologises for the delayed agenda, and hopes nothing was missed - nobody says otherwise. 3) Editor's Update * Expired calls: None * Calls in progress: None * Some backlog on processing votes. 4) Items for a Vote Nothing new. 5) Outstanding Votes Jonas is interpreting Dave's on-list vote for Room Activity Indicators (RAI) as an implicit +1 conditioned on the Editor issuing a namespace upon acceptance. Daniel has yet to read RAI, but intends to read and respond after the meeting - Jonas notes that would technically be too late (it expires today) - Daniel quickly throws in a ±0. Jonas adds his own +1 (can iron out the edges in Experimental, or learn it should be discarded.) Jonas still needs to request feedback on-list for PR #924. The remaining pending votes are Dave's [now completed [1]]. 6) Date of Next 2020-05-06 1500 UTC 7) AOB Sam, as author, requests a Last Call for XEP-0393 (Message Styling) since it has been stable for a while and feedback would be useful - Jonas notes that it's currently in the queue and will be issued once the current LCs have cleared (to avoid having too many going on at the same time.) Zash would still like to see "XHTML-IM 2" - as would Jonas, and Link, and Pep. Now all that's required is for Someone™ to write it. 8) Close Thanks everyone. [1] https://mail.jabber.org/pipermail/standards/2020-April/037322.html ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XEP-0424: Service discovery on the server side
Hi, I am a developer of MongooseIM (https://github.com/esl/MongooseIM) and currently I am adding the support for message retraction (XEP-0424). There is a growing need for a standard way to support message deletion/retraction, so I like the fact that there is a new specification for it. According to the XEP: "If a client or service implements message retraction, it MUST specify the 'urn:xmpp:message-retract:0' feature in its service discovery information features". When should the server include this feature in its discovery information? If a client sends a discovery request to the address of the main XMPP service, should the server response contain this feature if the server archives retraction messages in MAM (XEP-0313)? This should be enough to satisfy the only mandatory server-side requirement of the XEP. Another option would be to advertise this feature only if messages are really removed or replaced with tombstones whenever a retract message is received. However, support for actual removal of messages is not mandatory in the XEP. MongooseIM would replace the messages with tombstones if such a feature is enabled by the user. I think that whatever rule is chosen, the same should apply for a MUC service if message archive/retraction is enabled for it. -- Regards, Paweł Chrząszcz ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XEP-0289 FMUC: Do joined nodes know what mode is configured?
Hello all, A XEP-0289 FMUC question, related to section 5.2 ( https://xmpp.org/extensions/xep-0289.html#messages ). The example describes how a joining FMUC node (elsinore) sends a message to the joined FMUC node (rabbithole). Federation is configured to use the master-slave mode (where rabbithole is the master). This sentence makes me wonder if I misunderstand a key part of the XEP: This example is for master-master mode, so rabbithole does not echo the > message back to elsinore and elsinore does not need to wait for receipt of > this stanza from rabbithole (...) As I understand the XEP, the federation is initiated by elisnore. This is where the configuration lives. No negotiation of the configuration (specifically, the type of mode that's used) seems to take place. This is also referenced to in section 5.1: Note that this configuration only needs to be one way (that is: there is no > protocol reason why rabbithole needs to know that elsinor will be > federating with it in advance) How does rabbithole determine that it needs not echo the message back to elsinore? Regards, Guus ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
