On 3/12/18 9:17 AM, Christian Schudt wrote:
> 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?

That would be consistent with

> 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 can't recall why we defined this disco#info thing but in hindsight I
agree that it's ugly.

> 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?

I would not object.


Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org

Reply via email to