[Standards] NEW: XEP-0363 (HTTP File Upload)

Dave Cridland dave at cridland.net
Tue Sep 29 07:28:45 UTC 2015

On 29 September 2015 at 01:02, Evgeny Khramtsov <xramtsov at gmail.com> wrote:

> Thu, 24 Sep 2015 13:10:44 +0300
> PG Stath <pgstath at gmail.com> wrote:
> > In general I think that XMPP might be missing developers not because
> > features are missing but because of non compatible extensions lists
> > and extension implementations among different libraries, servers and
> > applications.
> Totally agreed. As a note, I think the list of deprecated XEPs should be
> revised and a transition mechanism should be developed. The specs are:

Thanks for this list.

Quick thoughts applying to all of these: a lot of these cases (some here,
some in Christian's list) are where PEP services on supposedly modern
servers have been treated as a second-class citizen - not being persistent,
lacking all but the barest minimum of XEP-0060 features, not adhering to
the spec. I'm not sure any of the mainstream server developers can take any
kind of moral high-ground and blame the client developers for lagging
behind given this.

This single thing has held back real-world deployment of about half our
modern specifications; many of which make unwarranted assumptions that the
server developers will implement the specs.

> 1) Avatars: XEP-0084 vs XEP-0153

In principle, setting (via whichever flavour of vCard applies) an avatar
should update it everywhere.

> 2) Time: XEP-0090 vs XEP-0202. Yes, there are still abandoned quite
> popular clients with no support of XEP-0202.

Supporting genuinely ancient clients is a general problem; I think we can
address this by IQ protocol translation, but I imagine I'll get push-back
from server developers there.

> 3) Filetransfer. Tons of specs. The transition might be HTTP
> Upload + jabber:x:oob, until Jingle specs are finalized.

File transfer, on the other hand, could very usefully be done via protocol
translation. Converting SI to Jingle and back again - or even terminating
Jingle in the server and translating to HTTP - really feels like it should
be practical.

> 4) MUC. Inventing MUC2 will result in the similar problems. The
> transition will be painful due to MUC complexity.

That's true. I think it's unavoidable, but I think we should ensure we're
able to offer '45 interfaces to MUC2 chatrooms.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150929/87f3c8ce/attachment.html>

More information about the Standards mailing list