On Mon, Feb 22, 2010 at 1:26 PM, Simon Josefsson <si...@josefsson.org> wrote: > Waqas Hussain <waqa...@gmail.com> writes: > >> 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. > > I believe maintaining pointers to existing implementations (in various > languages), and publishing interop details between those > implementations, would help more than selecting one implementation as a > "reference" implementation. >
This would help a lot. That's basically what I end up doing when tracking down compatibility issues between Prosody and other software (which happens much more frequently than I'd like). > In my experience, selecting one reference implementation have a tendency > to lead to software mono-culture, which eventually may lead to less > interop, in particular between existing deployments and newly written > software from the specification. > > So I'm strongly in favor of helping XMPP implementers find good security > and i18n libraries to use (gsasl and libidn! :)) but I wouldn't support > focusing on just one implementation. > I partially agree. My goal wasn't an implementation which everyone would reuse. It was an example which everyone could look at when they wrote their own implementation. Specifications tend to be difficult to read (thankfully those generated by the XSF are exceptions). Even something like pseudocode or a step by step tutorial would be better than nothing. I originally intended to do just that myself, i.e., write a couple tutorials describing steps in simple enough language that you'll have a hard time getting them wrong, and with warnings against potential pitfalls, but decided to post here to see what others thought. The most frequently used DIGEST-MD5 guide seems to be this: http://web.archive.org/web/20050224191820/http://cataclysm.cx/wip/digest-md5-crash.html I wouldn't be surprised to know that a large number of implementations follow it rather than the RFCs. That's because a large number of implementations tend to have the incorrect behavior it describes... -- Waqas Hussain
