custom IQ message stanza

[Mark Macumber]

Im trying to send a custom IQ from a client written in Java to another client in .NET

I thought I could just easily customise the payload of the IQ stanza, but Im never receiving the message, and in the logs I can see errors.

The errors are as follows:

Aug 07 17:28:34 c2sa3b910       debug   Received[c2s]: <iq id='cJu0j-4' type='set' from='te...@mydomain.com.au'>

Aug 07 17:28:34 stanzarouter    debug   Stanza of type iq from c2s has xmlns: urn:ietf:params:xml:ns:xmpp-stanzas

Aug 07 17:28:34 stanzarouter    debug   Unhandled c2s stanza: iq; xmlns=urn:ietf:params:xml:ns:xmpp-stanzas

Aug 07 17:28:34 socket  debug   server.lua: client 192.168.1.53:58056 read error: closed

Aug 07 17:28:34 c2sa3b910       info    Client disconnected: closed

Aug 07 17:28:34 c2sa3b910       info    Destroying session for te...@mydomain.com.au/Smack (te...@mydomain.com.au)

Aug 07 17:28:34 sessionmanager  debug   All resources of test2 are now offline

Aug 07 17:28:34 c2sa3b910       debug   Received[c2s]: <presence type='unavailable'>

Aug 07 17:28:34 socket  debug   server.lua: closed client handler and removed socket from list

My code is as follows (Java)

IQ iqMessage = new IQ() {

@Override

public String getChildElementXML() {

return "<MyMessage xmlns=\"urn:ietf:params:xml:ns:xmpp-stanzas\"><Callout><Add Id=\""+guid+"\" Value=\""+val+"\" MetaData=\"Roma\" /></Callout></MyMessage>";

}

};

iqMessage.setType(IQ.Type.SET);

iqMessage.setFrom("te...@mydomain.com.au");

//iqMessage.setTo("te...@mydomain.com.au");

connection.sendPacket(iqMessage);

Note that I am not adding the TO to the message, but it doesnt work either way.

The errors say: Unhandled c2s stanza: iq; xmlns=urn:ietf:params:xml:ns:xmpp-stanzas but does this mean that my server is not configured correctly? Or that something else is wrong?

I have tried many different xmlns attributes too, but nothing seems to work.

Any help is greatly appreciated

Mark

[Lance Stout]

On Aug 16, 2013, at 11:02 PM, Mark Macumber <mark.m...@gmail.com> wrote:

> //iqMessage.setTo("te...@mydomain.com.au");


The issue is that for an IQ stanza to be delivered to another client, it needs
to be addressed to a full JID with a resource.

An IQ sent to a bare JID, or with no 'to' attribute at all, gets processed
by the server instead (ie, the IQ was addressed to a user's 'account',
not a connected client).


-- Lance

[Mark Macumber]

Hi Lance,

Thanks for the reply, yeah the To field was just a test, it seems to be more associated with the xmlns?

Whatever I seem to do always fails with the error:

Unhandled c2s stanza: iq; xmlns=my namespace goes here

I am trying to extend IQ and send my own payload, like this:

<iq id="abcdefh" to="te...@mydomain.com.au" type="set">

  <mypayload xmlns="http://www.mything.com.au" />

</iq>

should I need to enable anything in prosody to do this?

[Waqas Hussain]

On Sat, Aug 17, 2013 at 1:06 PM, Mark Macumber <mark.m...@gmail.com> wrote:
> Hi Lance,
>
> Thanks for the reply, yeah the To field was just a test, it seems to be more
> associated with the xmlns?
>
> Whatever I seem to do always fails with the error:
>
> Unhandled c2s stanza: iq; xmlns=my namespace goes here
>
> I am trying to extend IQ and send my own payload, like this:
>
> <iq id="abcdefh" to="te...@mydomain.com.au" type="set">
> <mypayload xmlns="http://www.mything.com.au" />
> </iq>
>
> should I need to enable anything in prosody to do this?
>

Prosody is behaving as it should be, like Lance mentioned.

<iq to="node@host"> is handled by the server itself, and the server
doesn't know how to handle your specific element and namespace, so it
replies with a service-unavailable error, and logs a message. Such an
IQ is not broadcasted to other connected clients.

<iq to="node@host/resource" would be forwarded to your client, this is
what you need.

From RFC6121:

"8.5.2.1.3. IQ

For an IQ stanza, the server itself MUST reply on behalf of the user
with either an IQ result or an IQ error, and MUST NOT deliver the IQ
stanza to any of the user's available resources. Specifically, if the
semantics of the qualifying namespace define a reply that the server
can provide on behalf of the user, then the server MUST reply to the
stanza on behalf of the user by returning either an IQ stanza of type
"result" or an IQ stanza of type "error" that is appropriate to the
original payload; if not, then the server MUST reply with a
<service-unavailable/> stanza error." - this is what is happening.

So you need to include the resource, which makes the rules in section
8.5.3.1 apply.

--
Waqas Hussain

[Mark Macumber]

Hi Waqas,

I hoesntly dont really understand what the sentence means... but your resolution worked for me, I added the Resource to the TO field and it worked, thanks again!

[Mark Macumber]

I actually need to follow this up again, although I have the IQ message being sent, and I even have a reply IQ being sent back to the first client, which is great...but....with each IQ message I send from one of the clients (which makes it to the other client) I also get an error IQ message, but I dont know why.

I have re-read the doco that you listed and I can see that both parties need to subscribe to each other to send an IQ, so (from what I can tell) I had to ensure that the 2 clients had subscribed to each other, which I think is the case.

From 8.5.3.1

"

      For an IQ stanza of type "get" or "set", if the intended recipient
      does not share presence with the requesting entity either by means
      of a presence subscription of type "both" or "from" or by means of
      directed presence, then the server SHOULD NOT deliver the IQ
      stanza but instead SHOULD return a <service-unavailable/> stanza
      error to the requesting entity.  This policy helps to prevent
      presence leaks (see Section 11).

"

so I think I have fulfilled this requirement, however, now I get an IQ error back like so:

<iq to="te...@mydomain.com.au/TestClient" id="JN_4" type="error" from="te...@mydomain.com.au/Callout">

<error />

<error type="cancel" code="501">

<feature-not-implemented xmlns="urn:ietf:params:xml:ns:xmpp-stanzas" />

</error>

<MyMessage xmlns="http://www.mydomain.com.au/xmlns">

<Callout>

<Add MetaData="Roma" Id="1" Value="Mark" />

</Callout>

</MyMessage>

</iq>

Can someone shed some light on this for me? Very confused and for now my apps work, but I just ignore the IQ error, which is not ideal

Thanks a lot for any help you can give here,

Mark

[Waqas Hussain]

You are getting an IQ error reply. This error is not generated by
Prosody, Prosody is merely forwarding it. The error is coming from
"te...@mydomain.com.au/Callout", which is your other client. Your
other client is getting the request IQ. I assume you are using some
XMPP library? Perhaps that library is auto-responding with an error
for anything it doesn't understand. I'd guess you would need to handle
the IQ with that library by adding some stanza event handler or
something.

--
Waqas Hussain

[Waqas Hussain]

Is this error reply coming in addition to the expected reply? That
might indicate that your stanza handler needs to somehow notify the
XMPP library that you have handled the stanza. e.g., Prosody's
internal stanza event handlers are required to "return true",
otherwise Prosody auto-responds with an error. Your XMPP library may
be similar.

--
Waqas Hussain

[Mark Macumber]

Alright, so I was not aware that the library may automatically send stanzas like that, I am using Jabber.net at the moment, but also Smack for Java/Android

So if you are correct, perhaps what is happening is that the IQ I am creating is being sent, but when jabber.net sends it it also automatically sends another one with the error I described? If this is the case, then I just need to figure out how to let my libraries know that my custom IQ queries are OK.

Is that correct? (or at least the current running theory)?

I have seen this in the FAQ:

https://code.google.com/p/jabber-net/wiki/FAQ_Packets

Would that be what it is talking about?

[Mark Macumber]

Ok, so I figured it out, with Jabber.net at least, it turns out that there is a hidden "feature" in jabber.net that states that if your incoming IQ message is not marked as "Handled = true", then it will continue to forward on an error message after processing of the original IQ message...

[Waqas Hussain]

On Tue, Aug 20, 2013 at 4:00 AM, Mark Macumber <mark.m...@gmail.com> wrote:
> Ok, so I figured it out, with Jabber.net at least, it turns out that there
> is a hidden "feature" in jabber.net that states that if your incoming IQ
> message is not marked as "Handled = true", then it will continue to forward
> on an error message after processing of the original IQ message...
>

A, nice, you figured it out. This sort of thing is common in event
systems, e.g., Javascript DOM events have a preventDefault() and
stopPropagation() for similar reasons. Unless you indicate an event is
handled, the default behavior takes effect, which in an XMPP stanza's
case is to return an error saying you couldn't handle the stanza.

--
Waqas Hussain

[Mark Macumber]

Yeah, I dont have an issue with the pattern, like you said its quite common, just a lack of documentation really...