XSF Discussion - 2020-01-04

Does jingle content-accept also assume transport-accept? For example I send content-add and shortly transport-replace for this content. Can the remote side reply with just content-accept to accept both?

rion, juding from xep166 § 7.2.1 "The content-accept action is used to accept a content-add action received from another party." i'd say 'no'

flow: so I guess if the remote sends content-accept first and we still need to wait for transport-accept before starting doing anything in this case

jingle allows too much freedom in interpreting things :(

https://twitter.com/AlecMuffett/status/1213356702399115267

No, content-accept can't imply transport-accept. The XEP mandates a transport-accept or reject response. But more importantly, it is valid to transport-replace with the same kind of transport in order to change the initial parameters. In which case, you wouldn't have a way to know if the content-accept was made against the original offer's parameters, or the replacement's parameters.

I have a strong feeling that we need to fix once for all this max_items thing in Pubsub/PEP

this value is defined differently by default in each XMPP server implementations, changes between versions, cannot be easily discovered client side, can be overset client side and override by another client

and on top of that, is basically a destructive configuration (I got several time people that asked why their microblog content was destroyed because another client basically set back max_items to 1)

on a more general point of view, I don't see the point of having this configuration field mandatory or set at all by default

we don't have such thing for mam

so I'd maybe propose to disable the limit by default and let the admin and/or client to set it by himself