powered by Jive Software

Customized IQ provider should be allowed to handle IQ with jabber:iq:auth sub-packets

The Smack does not allow extension on the IQ jabber:iq:auth packets. It seems contradictory to the rfc3921-im specification (copied below), where it basically says that IQ stanza can have any extended namespace. Since “jabber:iq:auth” is not reserved/defined namespace, the Smack implementation should allowed customized IQ provider to handle this namespace as well, if registered.

2.3. IQ Syntax

IQ stanzas provide a structured request-response mechanism. The

basic semantics of that mechanism (e.g., that the ‘id’ attribute is

REQUIRED) are defined in , whereas the specific semantics

required to complete particular use cases are defined in all cases by

an extended namespace (Section 2.4) (note that the ‘jabber:client’

and ‘jabber:server’ namespaces do not define any children of IQ

stanzas other than the common <error/>). This memo defines two such

extended namespaces, one for Roster Management (Section 7) and the

other for Blocking Communication (Section 10); however, an IQ stanza

MAY contain structured information qualified by any extended

namespace.

It may be that there is another handler already handling these iq’s.

Cheers,

Alex

Thanks Alex for the reply. The Smack PacketReader handles the jabber:iq:auth IQ packets. However, a customized IQ provider should also be allowed to handle them.

Here is the reason - the jabber:iq:auth is not reserved nor defined in the IM spec (See my original post). I’m running into the situation that a XMPP server implementation (other than Openfire) defined its own authentication IQ XML using the same jabber:iq:auth namespace, but with extra child nodes under iq/query. The default IQ handler (PacketReader) only takes the data it knows and ignores all the other, and it does NOT allow to plug-in a deferent handler to take care these jabber:iq:auth IQ packets. It makes the Smack NOT suitable as a base of the XMPP client implementation in the situation like this.

Let me emphasize that the Smack architecture is well designed and we like it very much. But this improvement can make it even better as a generic XMPP client library.

Given all this said, I have to admit that I’m new to Smack, as well as this community. If I’m missing anything, please let me know.

Thanks,

Jay

It is a simple change at PackageReader.parseIQ(XMLPullParser) method. By this change, customized IQ provider is allowed to handle IQ with jabber:iq:auth sub-packets. It matchs the specification better. Here is the code snippet to show the change:

// First, see if there is a registered provider for

// this element name and namespace.

Object provider = ProviderManager.getInstance().getIQProvider(elementName, namespace);

if (provider != null) {

if (provider instanceof IQProvider) {

iqPacket = ((IQProvider)provider).parseIQ(parser);

}

else if (provider instanceof Class) {

iqPacket = (IQ)PacketParserUtils.parseWithIntrospection(elementName,

(Class)provider, parser);

}

}

else if (elementName.equals(“error”)) {

error = PacketParserUtils.parseError(parser);

}

else if (elementName.equals(“query”) && namespace.equals(“jabber:iq:auth”)) {

iqPacket = parseAuthentication(parser);

}