The LC never ended and it was agreed by council and the author to put it
back.
> [T]here's only the last call vote for XEP-0335, which got passed. We did
> a Last Call, but I don't see any subsequent vote on advancing it to
> Draft - equally, I do see feedback and no new version, so...
> After a quick chat with Matt, I'll leave '335 for now.
https://logs.xmpp.org/council/2019-05-21?p=h#2019-05-21-49640fd1dbb137b1
Signed-off-by: Maxime “pep” Buquet <pep@bouah.net>
Make it a SHOULD that it joins MUCs on retrieval of autojoin='1'
bookmarks, leaves them on autojoin='0' or no autojoin, and does the same
when it’s the one modifying the bookmarks.
PubSub §7.2.2.1 says “If no error occurs and the <retract/> element
included a 'notify' attribute with a value of "true" or "1", then the
service MUST delete the item and MUST notify all subscribers as shown
below.”
This means the publishing entity, not the server or the subscription
state, is responsible for properly enabling notifications to other
resources, which makes no sense.
See https://xmpp.org/extensions/xep-0060.xml#publisher-delete-success-notify
In order not to replace old bookmarks when pushing a new one, we need to
request a good max_items value. This one has been picked as some random
large enough number, bikeshed welcome!
TODO: add support for unlimited values?
* Send an IQ to a groupchat service to moderate a message
* Allow for a reason to be specified
* The groupchat service is responsible for sending out a moderation message
* Use XEP-0422 for the moderated message sent out by the service
* The MUC moderation use-case will be split out into a different XEP
* Update this XEP to handle the case where a user retracts their own message
* Use XEP-0422 for the retraction message
* Mention in security considerations that the XEP-0421 occupant id must be checked
