2009/4/30 Remko Tronçon <[email protected]>: >> 1. Who has implemented XEP-0138? Please note that the protocol must be >> implemented in at least two separate codebases (and preferably more). > > I implemented it in Psi, and reimplemented it from scratch in Swift. > So that's 2 implementations ;-)
One more implementation is Lampiro, so it works also with the most sluggish mobile platform, i.e. j2me. >> 2. Have developers experienced any problems with the protocol as defined >> in XEP-0138? If so, please describe the problems and, if possible, >> suggested solutions. > > The protocol itself is simple enough to not have problems with. I > tested the compression part itself with several server > implementations, and had no problems. Except for Openfire. It used to > work fine up to a certain version, and after that it went wrong. The > stream starts out fine, but after a while gets scrambled, typically > after a burst of stanzas. Smells like a buffer overrun. [...] I confirm the problem related to Openfire implementation, with all other test servers it is a piece of cake > >> 3. Is the text of XEP-0138 clear and unambiguous? Are more examples >> necessary? Is the conformance language (MAY/SHOULD/MUST) appropriate? >> Have developers found the text confusing at all? Please describe any >> suggestions you have for improving the text. > > I don't recall any confusion over the protocol. I've just a problem with the business rules, specifically these ones # TLS compression and stream compression SHOULD NOT be used simultaneously. # If both TLS (whether including TLS compression or not) and stream compression are used, then TLS MUST be negotiated first, followed by negotiation of stream compression. The above business rules don't forbid but discourage to fall back to stream compression after TLS has been established but no compression has been activated. I see no harm in telling that stream compression MAY be offered after TLS if TLS doesn't succeed in activating compression (so far we haven't been able to to it with any server) -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: [email protected]
