roster query result retains from attribute

[bmuller]

Per the example given at http://www.xmpp.org/rfcs/rfc3921.html#rfc.section.7.3 the iq can have a "from" attribute in the request to retrieve the roster. This from attribute and value are retained in the response. The from attribute should be removed, and a "to" attribute added.

For instance:

<iq from='blah@example.com/test' type='get' id='roster_1'><query xmlns='jabber:iq:roster'/></iq>

incorrectly returns

<iq xmlns='jabber:client' from='blah@example.com/test' type='result' id='roster_1'><query xmlns='jabber:iq:roster'/></iq>

when it should return

<iq xmlns='jabber:client' to='blah@example.com/test' type='result' id='roster_1'><query xmlns='jabber:iq:roster'/></iq>

Attached is a quick and dirty patch for mod_roster.c

[bmuller]

mod_roster.c patch

[smoku]

(In [252]) Corrected roster-get iq response. Fixes #94

[bmuller]

This is not fixed yet due to the pkt_tofrom not clearing out the from attribute (if a "to" attribute was not given, as in the example in the RFC). So given:

<iq from='blah@example.com/test' type='get' id='roster_1'><query xmlns='jabber:iq:roster'/></iq>

the result is now:

<iq xmlns='jabber:client' to='blah@example.com/test' type='result' id='roster_1' from='blah@example.com/test'><query xmlns='jabber:iq:roster'/></iq>

(note the from is still there).

Possible fixes would be to either clear the "from" attr in mod_roster or have pkt_tofrom check for NULL pkt->to or pkt->from and then clear the attribute.

[smoku]

Well...

http://www.xmpp.org/rfcs/rfc3920.html#rfc.section.9.1.2

When a server generates a stanza from the server itself for delivery to a connected client (e.g., in the context of data storage services provided by the server on behalf of the client), the stanza MUST either (1) not include a 'from' attribute or (2) include a 'from' attribute whose value is the account's bare JID (<node@domain>) or client's full JID (<node@domain/resource>).

So as it is now it is fully RFC compliant.