Registration Mecanism

Dear All,

Following article in I had difficulties to implementation in my code.

I made jabber client application in J2ME, I need to give my user register form in order to able registering their accounts (what ever they have IM Account: YM, MSN, ICQ). I have planned my user just one time to register they IM account.

Some body helps me to give me step by step to do this.

What kind IQ’'s should send to wildfire server? What kind the response?

In simple question, how the flow to do this?

Thank you

Howdy! In general, that XEP document (XEP-0100) that you indicated specifies the exact procedure for registration. That said, here is a general overview of how transport registration is normally handled from start to finsh. I shall use the term USER to represent the actual real person, the term CLIENT to represent the XMPP client the USER is using, the term SERVER to represent the Wildfire server (or really any XMPP server), and the term TRANSPORT to represent any given transport (any given transport would be AIM, or ICQ, or MSN, or whatever). Also, obviously, I’'m only highlighting the parts of this conversation that I think are important to this discussion. Clearly lots more goes on when a CLIENT connects to a SERVER. =)

  1. USER logs into SERVER via CLIENT

  2. CLIENT sends a disco items query to SERVER

  3. SERVER responds with list of services it provides, which should include aim.whatever, icq.whatever, etc

  4. CLIENT sends a disco info query to each service, we shall now label aim.whatever as TRANSPORT

  5. TRANSPORT responds to disco info query with features, one of which should be jabber:iq:register

  • aside: at this point CLIENT has a list of services the SERVER provides, and what features they support -
  1. USER wants to register with TRANSPORT, USER uses whatever disco browser type interface that CLIENT has and finds TRANSPORT jid. USER right clients on TRANSPORT jid and chooses Register.

  2. CLIENT sends an IQ get request in the jabber:iq:register namespace

  3. TRANSPORT sends back a form to fill out, so to speak, outlined in the XEP-0100 document

  4. USER fills out necessary fields in form and submits

  5. CLIENT send IQ set request with filled in form to TRANSPORT

  6. TRANSPORT performs registration activities on it’'s end, sends back a success or failure response

  7. TRANSPORT sends a presence probe to CLIENT to ask if it’‘s online or not, and auto logs in if they’'re online

The interface information is primarily based off Psi, which is sort of how a lot of clients work. Some clients, like Spark and Pandion, aim to make it “nicer” to register with transports by providing alternate interfaces than disco browsers and such. Either way, this procedure is outlined in XEP-0100, section 4.1. There’‘s a little more to the conversation than what I outlined above. The IM Gateway plugin behaves slightly differently in that it automatically does step 7. I may change that as, now that I’‘m reading it, I’‘m noting that I’'m kind of forcing the theoretical flow of this.