XEP-0402: Fix issues found during Stockholm XMPP Sprint #835
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Also all clients will have to agree on one value because otherwise your preconditons will constantly fail when other clients have used a different value before. Which in turn means we really need support for max_items=0 to mean server side max. |
Ppjet6
added
the
Needs Author
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?
TODO: Add the justification for that.
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
There is no rationale for this, and as it overrides the room name “forever” it shouldn’t necessarily be encouraged.
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.
jcbrand
reviewed
Oct 14, 2019
Thanks for the suggestions!
|
I fixed the English issues, thanks for giving me a nice explanation! |
|
@linkmauve LGTM |
Ppjet6
added
Ready To Merge
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR might be more easily read commit per commit.
Rendered version: https://linkmauve.fr/extensions/xep-0402.html
I was extremely surprised at the difference of treatment for notifications between publishing an item (XEP-0060 §7.1.2.1) and purging all items (§8.5.2), both sending a notification if the node is configured for that, and retracting an item (§7.2.2.1) where the publisher additionally has to include a
notify='1'attribute on the<retract/>element.Another issue we’ve identified during the Sprint is password migration, as much as I dislike this feature there are existing MUCs being protected by passwords, and we most likely keep those until we decide on either removing this feature from MUC altogether, or find a more secure way to store passwords on the server.
Otherwise, this specification is pretty nice and should be ready for advancing to draft soon I think.