[Standards] Releases

Jonas Wielicki jonas at wielicki.name
Sun Mar 4 17:51:44 UTC 2018


On Sonntag, 4. März 2018 10:29:02 CET Gerion Entrup wrote:
> Hi,
> 
> I'm a user of XMPP and have very mixed experiences with different clients.
> 
> There are clients that do very well and implement a lot of availabe XEPs,
> but other clients only implement a fraction of available XEPs. The XEPs are
> optional, if I get it right, but the user experience varies a lot with
> dfferent set of XEPs.
> 
> I found it difficult to get a list of supported XEPs by client and it is
> time consuming to understand what XEPs are for what feature. So a propasal
> I have is to do releases (of the standard).
> 
> A release contains a set of new (final) XEPs and a list of obsolete XEPs and
> all clients and servers that support XMPP version X have to implement this
> XEPs.

I tend to like this idea, as already mentioned in a past post in another 
thread:

https://mail.jabber.org/pipermail/standards/2018-February/034314.html
plus the context in
https://mail.jabber.org/pipermail/standards/2018-January/034181.html

I would extend it beyond Final (at least Draft) though :-).

> That would allow users to see, what a client is capable of. That would also
> allow client to show a message to there users about the client on the other
> end does not support XMPP version X and so there are some features that are
> not supported. 

Technically, we can already do that for each individual feature, thanks to 
XEP-0030 Service Discovery features. However, the trickiness is when Message 
Carbons, multiple devices and Message Archive Management come into play. 
Example:

You might detect that one of the two clients you’re currently talking to does 
not support Last Message Correction. Would you still allow the user to use 
LMC? The other device supports it; and since the messages will be archived, 
the user may be using other devices which support it, too.

> This also adds the abbility to generate some easy press
> coverage about the state of XMPP.

Possibly seconded.


I am still hoping for some feedback of the Council or other more experienced 
members of the community in regard to that.

kind regards,
Jonas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20180304/dfee5153/attachment.sig>


More information about the Standards mailing list