On 2/21/10 8:18 AM, Sebastiaan Deckers wrote: > On Sun, Feb 21, 2010 at 2:21 AM, Waqas Hussain <[email protected]> wrote: >> There are a number of algorithms an XMPP developer needs to deal with, >> either directly or through a library. Some of these are defined in XEPs, >> while some are external specifications which we work with. >> >> These include: >> >> * DIGEST-MD5 >> * SCRAM >> * Entity capabilities hashing >> * JID escaping >> >> Over the years, I’ve seen people trying to implement these through trial and >> error, and frequently getting them done only partially correctly. After >> helping people fix their DIGEST-MD5 implementations at least a dozen times, >> I think we have a problem. >> >> I propose that we start a small project to act as an aggregator for existing >> open source implementations which could be used as references. Once we have >> that going, an implementation selected for its readability could become the >> (official?) reference implementation. >> >> What this would achieve: >> >> 1. It would save people writing new implementations hours and hours of >> guesswork >> 2. It would make new implementations more interoperable, reducing the chance >> of mistakes >> 3. It would make existing implementations more visible, improving the chance >> of mistakes being found and reported, and implementations being reused >> 4. For experimental XEPs this would give direct evidence of how simple or >> complex an algorithm is, what the edge cases are, and if it could be >> simplified without losing its important characteristics >> >> In fact I wouldn’t mind it being required that any XEP moving beyond >> Experimental have implementations available for the algorithms it defines, >> under a permissive license. >> >> I’m hoping to not be the only one who sees this as a problem we should >> solve. What does everyone else think? > > > > Problems with reference implementations: > - Programming language dependent (eg. does a Python reference > implementation help an Erlang developer?) > - Platform dependent > - Not subject to same design goals as other implementations > - Impossible to create one software which implements every XEP. > Compatibility issues between various "references." > - Huge resource sink (time spent on an implementation that may not be > used by many) > - Will still have bugs which may then become de-facto standard > - (Perceived) reduction in openness of XSF and XEP process > - Political fighting over which is the "official" implementation
That's a good list. In the future if someone asks me about a reference implementation I shall point them at your message. :) > The only meaningful references are open standards and protocol/data > specs. I agree that there are many compatibility problems, because > specs are not easy to understand, but that's a fact of life in such a > heterogeneous community as XSF. > > IMO the most effective answer to these problems is testing. Create a > list of challenge/response cases for servers or clients, validate > logged XMPP data in all XEP namespaces, write functional tests for > XMPP libraries, and so on. The topic of protocol test suites has come > up often but I don't know of any real progress. I think we need a good, cross-platform test harness. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [email protected] _______________________________________________
