I believe that the reason that client developers do not implement these particular JEP's is because there may be no demand for them at this time in their XMPP applications, not just because they are marked as 'experimental'. There are JEP's that have some value to me (pubsub, sasl, geoloc, CAP, JEP-0076), but others that I have no interest in currently (XHTML, client webtabs). This doesn't mean that those JEP's are worthless, but there may not be immediate value to implementing them in the near future. Other applications may find that these JEP's are critical.
I suggest as a first step we setup the client list to indicate what major features that each client supports (file transfer based on the correct JEP (bytestream?), MUC, etc). This should ensure that if a user grabs a client that claims to support file transfer, they can be reasonably assured that it will work with other clients that support that feature. I believe that stpeter was looking into doing this at some point. I think a certification program is a lot of work and can be considered later on if the client list reorganization doesn't solve the interoperability problems. ------------------- I think part of the point of all this -- at least over in the jdev chatroom, and in off-channel discussions -- is that the 'oh, experimental, bad don't touch it, it will bring plague upon your project aaaaugh' mindset is itself a bad thing and that maybe that language is a little too strong and too discouraging. It might be better to have something like: _______________________________________________ jdev mailing list [EMAIL PROTECTED] https://jabberstudio.org/mailman/listinfo/jdev
