Use of feature jabber:iq:registered

Openfire Plugins Kraken - IM Gateway
1

I’m using Openfire 3.3.1, Gateway plugin 1.0.2, Smack 2.2.1. (I’m aware that these are all old versions.)

I’m following XEP-0100. In the discovery response I see a feature jabber:iq:registered.

I got the impression I can use this to determine whether a username is already registered with a gateway transport, & I’d like to use this rather than my current implementation in which I register usernames with gateway transport whenever I login the Openfire user.

I used the Ad-hoc message tab of the debugger to send an IQ GET using the jabber:iq:registered namespace to the gateway transport, but it returns error code 503 (service unavailable). The same procedure gives sensible results for namespaces jabber:iq:version & jabber:iq:gateway, also listed in the discovery response, so I feel I’m on the right track.

Is my interpretation of jabber:iq:registered correct?

From poking around a little more, I’ve found that when I send an IQ GET for jabber:iq:register, the response contains username & password of the registered gateway transport user if any; is this how I’m supposed to determine whether a transport user is already registered? Is this the semantics implied by the jabber:iq:registered feature?

Thanks

– Richard

2

jabber:iq:registered is something we made up that Spark makes use of. It is basically just a flag to indicate that you are registered with a transport so that a client -could- do a disco info query against the transport to see ahead of time if the user is registered or not. It’s not been submitted as a formal thing for XEP-0100. (it may or may not ever be, depends on what we decide to do with it really =) )

3

Thanks for the prompt reply.

So the IQ jabber:iq:register GET returning any existing registration isn’t part of the standard but can be relied on when using Openfire and the gateway plugin?

4

jabber:iq:register’s get is part of the standard

jabber:iq:registered is the one that’s not =)