[Standards] Call for new compliance suites author

Kevin Smith kevin.smith at isode.com
Mon Mar 19 10:48:17 UTC 2018


On 17 Feb 2018, at 16:58, Jonas Wielicki <jonas at wielicki.name> wrote:
> 
> 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.

I think a XEP that describes what we think is needed to implement Right Now, with a stable number but unstable version, has value. I think it also satisfies the ‘marketing checkbox’ that people like the compliance suites for.

/K


More information about the Standards mailing list