Re: [Standards] XEP Dependencies

> The others are Deferred, which means they've Expired - we do not, typically, > clean-up Deferred XEPs. Understandable, though I had assumed that Deferred meant "not recently maintained" rather than expiration - which suggests 'do not implement.' So then there is a question of whether there

[Standards] DEFERRED: XEP-0386 (Bind 2.0)

XEP-0386 (Bind 2.0) has been Deferred because of inactivity. Abstract: This specification provides a single-request replacement for several activities an XMPP client needs to do at startup. URL: https://xmpp.org/extensions/xep-0386.html If and when a new revision of this XEP is published, its

[Standards] UPDATED: XEP-0060 (Publish-Subscribe)

Version 1.15.1 of XEP-0060 (Publish-Subscribe) has been released. Abstract: This specification defines an XMPP protocol extension for generic publish-subscribe functionality. The protocol enables XMPP entities to create nodes (topics) at a pubsub service and publish information at those nodes; an

[Standards] UPDATED: XEP-0174 (Serverless Messaging)

Version 2.0.1 of XEP-0174 (Serverless Messaging) has been released. Abstract: This specification defines how to communicate over local or wide-area networks using the principles of zero-configuration networking for endpoint discovery and the syntax of XML streams and XMPP messaging for real-time

[Standards] DEFERRED: XEP-0383 (Burner JIDs)

XEP-0383 (Burner JIDs) has been Deferred because of inactivity. Abstract: A mechanism by which users may request anonymous, ephemeral "burner" JIDs. URL: https://xmpp.org/extensions/xep-0383.html If and when a new revision of this XEP is published, its status will be changed back to

[Standards] LAST CALL: XEP-0280 (Message Carbons)

This message constitutes notice of a Last Call for comments on XEP-0280. Title: Message Carbons Abstract: In order to keep all IM clients for a user engaged in a conversation, outbound messages are carbon-copied to all interested resources. URL: https://xmpp.org/extensions/xep-0280.html This

Re: [Standards] XEP Dependencies

According to both https://github.com/xsf/xeps and https://xmpp.org/extensions : * XEP-0105 (Tree Transfer Stream Initiation Profile) [Deferred] * XEP-0135 (File Sharing) [Deferred] * XEP-0137 (Publishing Stream Initi-ation Requests) [Draft] * XEP-0159 (Spim-Blocking Control) [Deferred] * XEP-0241

Re: [Standards] Adding logo to MUC and PubSub node

Quoting Jonas Wielicki : On Donnerstag, 8. Februar 2018 14:34:12 CET W. Martin Borgert wrote: I had another idea before coming up with the configuration variable, but I find it very ugly, but maybe others might find some beauty (or pragmatism) in it: A PubSub node could

Re: [Standards] XEP Dependencies

On 8 February 2018 at 15:35, Sam Whited wrote: > On Thu, Feb 8, 2018, at 09:23, Tedd Sterr wrote: >> After noticing that XEP-0137 depends on "Stream Initiation" which is now >> deprecated, I checked through all XEPs for their dependencies and found >> the following: > >

Re: [Standards] XEP Dependencies

On Thu, Feb 8, 2018, at 09:23, Tedd Sterr wrote: > After noticing that XEP-0137 depends on "Stream Initiation" which is now > deprecated, I checked through all XEPs for their dependencies and found > the following: Thanks, this is a great help! We should probably be doing this periodically. >

[Standards] XEP Dependencies

After noticing that XEP-0137 depends on "Stream Initiation" which is now deprecated, I checked through all XEPs for their dependencies and found the following: == Strong Dependencies (the XEP is pointless without them) == * XEP-0105 (Tree Transfer Stream Initiation Profile) depends on:

Re: [Standards] Adding logo to MUC and PubSub node

On Donnerstag, 8. Februar 2018 14:34:12 CET W. Martin Borgert wrote: > Quoting Daniel Gultsch : > > polling is a terrible idea traffic wise and very nontransparent for the > > user. > > > > I don't have an opinion on pubsub. > > I had another idea before coming up with the

Re: [Standards] Adding logo to MUC and PubSub node

Quoting Daniel Gultsch : polling is a terrible idea traffic wise and very nontransparent for the user. I don't have an opinion on pubsub. I had another idea before coming up with the configuration variable, but I find it very ugly, but maybe others might find some beauty

Re: [Standards] Adding logo to MUC and PubSub node

Thu, 8 Feb 2018 14:21:49 +0100 Daniel Gultsch wrote: > 2018-02-08 13:43 GMT+01:00 Evgeny Khramtsov : > > Thu, 8 Feb 2018 13:17:14 +0100 > > Daniel Gultsch wrote: > > > >> at least for MUC I would prefer vCard + hash in presence from

Re: [Standards] Adding logo to MUC and PubSub node

2018-02-08 13:43 GMT+01:00 Evgeny Khramtsov : > Thu, 8 Feb 2018 13:17:14 +0100 > Daniel Gultsch wrote: > >> at least for MUC I would prefer vCard + hash in presence from the bare >> muc jid. (as discussed in our 34C3 meeting and/or various discussions >> we

Re: [Standards] Adding logo to MUC and PubSub node

Thu, 8 Feb 2018 13:17:14 +0100 Daniel Gultsch wrote: > I don't have an opinion on pubsub. I guess that's not a problem for PubSub service to send notifications? :) A dedicated and well-known node should be enough for this. ___

Re: [Standards] Adding logo to MUC and PubSub node

Thu, 8 Feb 2018 13:17:14 +0100 Daniel Gultsch wrote: > at least for MUC I would prefer vCard + hash in presence from the bare > muc jid. (as discussed in our 34C3 meeting and/or various discussions > we had prior to this) What was the conclusion? (If any)

Re: [Standards] Adding logo to MUC and PubSub node

at least for MUC I would prefer vCard + hash in presence from the bare muc jid. (as discussed in our 34C3 meeting and/or various discussions we had prior to this) polling is a terrible idea traffic wise and very nontransparent for the user. I don't have an opinion on pubsub. 2018-02-07 22:16

Re: [Standards] Adding logo to MUC and PubSub node

On Donnerstag, 8. Februar 2018 13:01:17 CET W. Martin Borgert wrote: > Quoting Timothée Jaussoin : > > In the end I don't think that it's a big issue to have those info > > requested manually, having a cache of a few hours on the clients is > > an OK solution for me at the

Re: [Standards] Adding logo to MUC and PubSub node

Quoting Timothée Jaussoin : In the end I don't think that it's a big issue to have those info requested manually, having a cache of a few hours on the clients is an OK solution for me at the moment. Maybe a refresh or poll rate of e.g. 12..24 hours can "officially" be

Re: [Standards] XEP-0198: Stream should be closed when 'h' value is to high

On 08.02.2018 11:39, Guus der Kinderen wrote: > Thank you for all feedback. > > The general consensus appears to be in favor of this change, but that a > stream error definition should be added. > > None of the other RFC-6120-defined conditions appear to be fitting here, > so I suggest that

Re: [Standards] XEP-0198: Stream should be closed when 'h' value is to high

Thank you for all feedback. The general consensus appears to be in favor of this change, but that a stream error definition should be added. None of the other RFC-6120-defined conditions appear to be fitting here, so I suggest that `undefined-condition` is used. Additionally, we should add an

Re: [Standards] XEP-0060: max-nodes-exceeded error is not described.

Hi,   Openfire does implement it.   -- Christian   Gesendet: Donnerstag, 08. Februar 2018 um 03:26 Uhr Von: "Peter Saint-Andre" An: standards@xmpp.org Betreff: Re: [Standards] XEP-0060: max-nodes-exceeded error is not described. On 2/7/18 2:04 AM, Christian Schudt