Hi folks,
Pubsub's <publish-options/> is an important part of the protocol, e.g.
to ensure that private data stays private and isn't accidentally
published to a misconfigured node:
https://xmpp.org/extensions/xep-0060.html#publisher-publish-options
When the configuration provided by the client in publish-options does
not match the node, XEP-0060 requires the service to reject the
publish with a 'precondition-not-met' error. This lets the client
decide how to proceed.
My understanding is that most clients today will simply respond to
such an error with a configuration request, to set the node
configuration to what they expect.
This has a few problems. It's possible that clients might fight over
configuration values (most likely to happen on non-essential options
such as max_items, where maybe one client sets it to 999999 and
another sets it to 'max'). It's also inefficient, especially in the
case where publishes are frequent and two clients disagree over the
correct configuration of the node.
I'd like to find a way to eliminate the round-trip introduced by the
precondition-not-met error, and allow clients to request that the
server simply overwrites the current configuration options with the
provided values in the case of a mismatch.
This is theoretically easy to do, because if the server doesn't
support this it will simply return precondition-not-met and the client
can fall back to the traditional behaviour. My question therefore is
more about how we would want the syntax of this change to look.
For example, we could introduce a new attribute on publish-options, e.g.:
<publish-options onconflict="overwrite">
<x xmlns="jabber:x:data">[form here]</x>
</publish-options>
I suspect some may object to this without a namespace bump (which I'm
sure we all agree is out of the question).
Or, we can add a new element:
<publish-options>
<conflict-resolution xmlns="urn:xmpp:pubsub:conflict:0"
behaviour="overwrite" />
<x xmlns="jabber:x:data">[form here]</x>
</publish-options>
Or, we could add this as a form field in some way. That could be as a
special-case field, or as an actual node configuration option (which
implies that we could set the default conflict behaviour on a per-node
basis). Note that the latter removes some control from the publishing
client, and potentially changes behaviour for existing clients that
didn't opt in to the new behaviour.
Before I proceed, does anyone have any strong feelings about any of
this, or shall I close my eyes, pick one at random and PR? :)
Regards,
Matthew
_______________________________________________
Standards mailing list -- standards@xmpp.org
Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s
_______________________________________________
