- Do not return error IQ result if the string to validate is not a
valid JID. It is indistinguishable if the error is caused by the
string to check, or if some other involved JID, like the one in the
'to' attribute, is malformed.
- Return the normalized JID in its parts, to make it clear which parts
constitute the JID</li>
- Do not use text as child of an IQ child element. Using text makes it
impossible to inject further child elements as XMPP disallows mixed
content.
- Add support for base64 encoding.
After getting a green light from Lance on collaborating with me on
this, this commit also adds me to the author list.
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
Rationale is inline. Summary: those errors indicate unreachability
of the server and most certainly not (with confidence) that the
client has been removed from the room.
* Add rfc8264 to xeps.ent (requested here: https://github.com/xsf/xeps/pull/825)
* Sort entries
* Remove duplicate rfc3261 entry
* Update URL for rfc7301 to be same as others
