Hi, I find the whole passage „Discovering Capabilities“ of Serverless Messaging [1] a bit confusing.
1. Why can’t the receiving entity include its Entity Caps as stream feature as described in [2]. 2. I can see the slight optimization of including disco#info data as stream feature (similar as with including Entity Caps), but the reasoning here is far-fetched: "full stream negotiation already can require a large number of packets“. (a) Stream negotiation should already be less expensive than in a real client-to-server session and (b) I can’t imagine that a single additional IQ-get request for disco#info would have a performance impact in a serverless messaging environment or would justify the additional implementation complexity: 3. disco#info as stream feature adds unnecessary burden to developers, which must now: - Deal with Entity Caps in TXT records (publish and read Entity Caps to/from another source) - Check stream features not only for Entity Caps, but also for disco#info. (otherwise we could simply reuse existing logic from [2]) Am I missing something here? What are your thoughts about it? Can the section be updated although the specification is final? — Christian [1]: https://xmpp.org/extensions/xep-0174.html#caps [2]: https://xmpp.org/extensions/xep-0115.html#stream _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
