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>
- 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?
