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

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

On 29 September 2015 at 08:12, Christian Schudt <christian.schudt at gmx.de>

> Am 29.09.2015 um 02:02 schrieb Evgeny Khramtsov <xramtsov at gmail.com>:
> > 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:
> > 1) Avatars: XEP-0084 vs XEP-0153
> > 2) Time: XEP-0090 vs XEP-0202. Yes, there are still abandoned quite
> > popular clients with no support of XEP-0202.
> > 3) Filetransfer. Tons of specs. The transition might be HTTP
> > Upload + jabber:x:oob, until Jingle specs are finalized.
> > 4) MUC. Inventing MUC2 will result in the similar problems. The
> > transition will be painful due to MUC complexity.
> I agree, too. The list can go on:
> XEP-0054 vs. XEP-0292 (VCard)

There's also XEP-0154, which is deferred but not deprecated. One
server-side vCard implementation I wrote got amazingly complex trying to
design for this... My understanding is that's been fixed now.

But XEP-0292 does not offer any compatibility path back to XEP-0054 either;
we really need to fix this.

> XEP-0256 vs. XEP-0319 (Idle/Last active time, clients now need to append
> both extensions)

Can we do server translation of this? At least for the Idle case?

> XEP-0136 vs. XEP-0313 (Archive)

XEP-0136 is pretty much dead, I think, and XEP-0313 can be built
server-side on top of XEP-0136 stores with some effort.

> XEP-0049 vs. XEP-0223 (Private storage, e.g. how do clients know where
> XEP-0048 bookmarks are really stored?)

Private storage in these cases should be mapped to the right PEP node
transparently, so clients don't have to guess.

> XEP-0079 vs. XEP-0334 (Message Processing, I believe 100% of 0334 can be
> covered with 0079, so why a new XEP?)

We should definitely move XEP-0079 to deprecated. It's horribly complex,
and nobody implemented it that I can recall anyway.

> XEP-0191 vs. XEP-0016 (Blocking Users)

XEP-0016 covers three cases, in fact:
 - the blocking of users which is covered by XEP-0191.
 - invisibility, covered by XEP-0186.
 - weird stuff nobody used.

We should deprecate it.

XEP-0085 vs. XEP-0022 (Ok, to be fair, this transition was successful I
> guess)

Yes, definitely done; though we should consider revisiting XEP-0085 in MUC

> XEP-0249 vs. XEP-0045 (2 kinds of MUC invitations)


We want to send a message direct from one user to another - the XEP-0249
case - but we also often need the MUC to know a user is to be invited - the
XEP-0045 case.

> XEP-0186 vs. XEP-0126 (How to deal with invisibility?)
As above; I have no idea why a client developer would prefer to use
XEP-0016 manipulation for invisibility.

> On top of that, different ways of storage or transports (e.g. as in
> XEP-0152) makes implementation not easier, especially for client developers.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20150929/6fec6a43/attachment-0001.html>

More information about the Standards mailing list