[Standards] XMPP team activity

Peter Saint-Andre - &yet peter at andyet.net
Tue Sep 29 16:59:28 UTC 2015

On 9/28/15 4:00 PM, Evgeny Khramtsov wrote:
> Mon, 28 Sep 2015 15:16:47 -0600
> Peter Saint-Andre - &yet <peter at andyet.net> wrote:
>> You noted several failings in XMPP. There are XEPs out there for
>> those features: push, file transfer, message archiving, avatars, etc.
>> Part of the problem we have is that sometimes we have two different
>> approaches to the same problem, developed at different times. We need
>> to be more decisive about moving from old to new. That means we need
>> more code for the new solutions.
>> Sometimes we're developing solutions to newer problems. Here again
>> code helps. Constructive comments on the new solutions is also good.
> OK, let's be more specific.
> 1) Push. There is a problem with IQ responses in a "pushed" session.
> Obviously, in such state a client is unable to respond for incoming IQs
> and as a consequence some clients like Gajim are indefinitely rendering
> progress bar in the user's vcard interface because they are unable to
> obtain time and version IQs.
> 2) File transfer. Those jingle specs don't resolve all the problems I
> mentioned in
> http://mail.jabber.org/pipermail/standards/2015-August/030214.html
> HTTP Upload is good, but you still need to transfer an URL somehow to
> the recipient and there are no normative rules for that. We can
> obviously use jabber:x:oob message btw.
> 3) MAM. Message deletion is still lacking. Note that the deletion
> should be also performed via complex requests, like "delete everything
> from previous month".
> 4) Avatars. Gajim is able to render avatars in conferences and
> Conversations is not. Kaiwa is fetching avatars via Gravatar. And those
> are clients in active development. How is that even possible that we got
> avatars broken by 2015? I didn't even delve into the problem, I guess
> there is vcard-based avatars vs pubsub avatars problem. How is it
> supposed to make a transition from the old spec to the newer one?
> Should every new client implement both specs? Isn't it too complex?

Thanks for the constructive feedback. :-)

>> Although I prefer early implementations of extensions that people are
>> trying to standardize, sometimes proprietary extensions are helpful
>> too in order to gain experience with different ways to solve a
>> problem.
> As an example: so I did an extension for ejabberd for image thumbnails,
> came here and asked the HTTP Upload author to improve the spec. And got
> a response like: "we don't need that":
> http://mail.jabber.org/pipermail/standards/2015-September/030314.html
> That is very motivating. So for me implementation before
> standardization looks like waste of a time and resources, because you
> can always get responses like those.
>> I don't mind complaining. I do mind complaining without doing. In
>> general you are doing, but in this thread you're just complaining and
>> that's not especially constructive. Better to channel your annoyance
>> into feedback on, and implementation of, XEP-0357, XEP-0234, XEP-0313
>> and XEP-0280, etc. Let's get those finished and implemented and
>> deployed so that we solve these important problems!
> First of all, all mentioned XEPs are implemented in ejabberd, except
> jingle file transfer, obviously. That's not even a problem implementing
> something for me, the problems are in clients: there are no clients
> present at the moment having all those specs implemented.

This is sadly true.


More information about the Standards mailing list