Hi, my original question quickly drifted away to a discussion about the use case of serverless messaging.
But I feel my concern was not addressed: 1. Why can’t the receiving entity include its Entity Caps as stream feature as described in XEP-0115? 2. Why should we instead use disco#info? I don't consider disco#info in stream features an optimization which justifies the additional implementation overhead: - Deal with Entity Caps in TXT records. It's only to potentially know an entity's capabilities before having initiated a stream with it, right? Sounds ok then, but unreliable. - Deal with yet another stream feature which covers an existing use case: to know an entity's capabilities (Entity Caps, Caps 2.0, disco#info) - Nowhere else is disco#info mentioned to be included in stream features Thoughts? I'd prefer the following: The receiving entity includes Entity Caps in it's stream features. If not known by the initiating entity, it may request disco#info and proceed normally (verify and cache the result). Most, or even all of an existing Entity Caps implementation could be reused then. 3. Can the section be updated although the specification is final? -- Christian _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
