[Standards] Call for new compliance suites author

Jonas Wielicki jonas at wielicki.name
Sat Feb 17 16:58:10 UTC 2018

On Samstag, 20. Januar 2018 11:24:50 CET Stefan Hamacher wrote:
> Hi!
> Am 19.01.2018 um 22:46 schrieb Peter Saint-Andre:
> > Did the publication of compliance suites in 2007, 2009, 2010, or 2012
> > solve any of the issues we hope the 2018 suite will solve? If not, was
> > that because we didn't active tell developers about it?
> If I may just drop my 0.2c:
> In my opinion the concept of having another compliance suite every year
> may be one of the reasons they didn't help much.
> A (new) compliance suite with the current year in the title suggests,
> that this is the way to do XMPP in that year, indirectly saying that it
> may or may not be different in the next year and the year after that.
> From a developers point of view, who do not want to play around with
> this kind of technology just because they like it but because they need
> it to actually solve problems and offer a product in a certain area,
> this is not helpful.
> I think a common feature base for XMPP is very important and this should
> be as stable as possible, only change when absolutely necessary and be
> promoted as such.
> Why not do the following:
> 1. Create a general XMPP feature set which should be supported by any
> modern XMPP client. The goal should be that the feature set is stable
> and shouldn't change dramatically in the near and mid-term future.

I like this idea. Of course, it is very IM-Centric, but that isn’t necessarily 
a bad thing.

> 2. To address the problem of backwards compatibility, certain features
> should of course be in the feature set, but be marked as 'for backward
> compatibility only'.
> 3. Of course nothing stays the way it is, there will always be additions
> and changes required. There should then be a process of introducing
> modifications into these feature sets. The goal of this process should
> be to provide longevity and stability of XMPP.

As a tool for this, something like a Standards Track or Informational XEP 
comes into mind. Council could be approving body and thus govern changes to 
that document.

> 4. Finally, this information should be made more visible and advertised.
> Maybe even change the name, as "Compliance Suite" sounds bulky.
> Clients/servers shouldn't need to publish a list of 10-20 XEPs in their
> description. Maybe just say "This client supports XMPP 1.0" ?

The documents name could be something like "XMPP Instant Messaging Profile" 
and the XEP version-numbered in a meaningful way.

> Thinking about it, versioning XMPP in general might even get some
> essential attention in the media if it is announcend well. It's like
> saying "Hey, we are still there and finally came up with something good
> that we name XMPP 1.0 now".

Not sure. Especially since we would need a set of clients to show for.

The good thing about a single version number is indeed that it contains a lot 
of information as a baseline. Of course, clients can still advertise XMPP-
IM-1.2 + XEP-xyz. It would also give us an easy tool by which we could group 
clients, libraries and servers on the software pages on xmpp.org.

I’d like to hear more input on this, because I would prefer this over yearly 
compliance suites.

kind regards,
-------------- 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/20180217/d294fc3a/attachment.sig>

More information about the Standards mailing list