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

Christian Schudt christian.schudt at gmx.de
Tue Sep 29 07:12:08 UTC 2015

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)
XEP-0256 vs. XEP-0319 (Idle/Last active time, clients now need to append both extensions)
XEP-0136 vs. XEP-0313 (Archive)
XEP-0049 vs. XEP-0223 (Private storage, e.g. how do clients know where XEP-0048 bookmarks are really stored?)
XEP-0079 vs. XEP-0334 (Message Processing, I believe 100% of 0334 can be covered with 0079, so why a new XEP?)
XEP-0191 vs. XEP-0016 (Blocking Users)
XEP-0085 vs. XEP-0022 (Ok, to be fair, this transition was successful I guess)
XEP-0249 vs. XEP-0045 (2 kinds of MUC invitations)
XEP-0186 vs. XEP-0126 (How to deal with 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.

- Christian

More information about the Standards mailing list