[Standards] XEP0384 OMEMO pubsub#publish-options clarification

Ruslan N. Marchenko me at ruff.mobi
Sat Aug 29 06:14:24 UTC 2020


Am Samstag, den 08.08.2020, 09:22 +0200 schrieb Philipp Hörist:
> Hi,
> 
> Note that major server implementation don’t support checking all
> fields they support with publish-options
> 
> Means only because a server supports max_items, it does not mean it
> can check the value via publish-options.
> 
Ok, thanks for the hint, although I've implemented all preconditions
checks, will see how far it goes.

But I still have a question regarding OMEMO and publish-options,
In XEP-0384 7.1 it mentions:
 * The pubsub service MUST persist node items.
 * The pubsub service MUST support publishing options as defined
in XEP-0060 §7.1.5.
 * The pubsub service MUST support 'max' as a value for the
'pubsub#persist_items' node configuration.
 * The pubsub service MUST support the 'open' access model for node
configuration and 'pubsub#access_model' as a publish option.
The way I read it initially was "pubsub service MUST support persitent
items" but it seems it really mandates pubsub default config rather
than feature support?
Then "'max' as value to persisy_items" I persume is a typo and should
read as 'max' value to 'max_items' when used together with
'persist_items'?

After I implemented publish-options, configure-node, persist-items,
multi-items, delete-items (and retract-item which seem to be redundant)
I still see the omemo merely sets access-model to open (as in XEP's
example) but not others.
And since my default pep node config is no persist, max 1, pam=presence
it only flips pam to open and the rest remains as is (no persistence,
max=1). 
Is it just conversations specific or the XEP really mandates defaults
on the PEP node? It should be fairly easy to set the rest of the
required options in publish options instead of mandating the defaults.

--rr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200829/c4575c89/attachment.html>


More information about the Standards mailing list