Tomasz Sterna wrote:
Hi.I was looking for an information whether the IQ-set sent on ones behalf (to change its own settings) may or may not have the "to" attribute and how should it be processed by the server.
We had some discussion about this a while back, and I tried to incorporate the results into the bis drafts. But maybe I didn't do a good job. :)
http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-04.html#stanzas-attributes-to-c2s "2. A stanza sent from a client to a server for direct processing by the server (e.g., presence sent to the server for broadcasting to other entities) SHOULD NOT possess a 'to' attribute."It says that it SHOULD NOT posses a 'to' attribute.
I think that one should be MUST NOT. Otherwise, how will the server know the presence is intended for broadcasting?
But what to do if it does? Let's search further... http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-04.html#rules-local-node "3. If the JID is of the form <[EMAIL PROTECTED]> and there exists at least one connected resource for the node, the recipient's server SHOULD deliver the stanza to at least one of the connected resources if the stanza is a message or presence stanza and SHOULD handle it directly on behalf of the node if the stanza is an IQ stanza." OK. This says that the server should process the IQ on behalf of the "to" entity instead of forwarding to the client for processing. But I still am not sure what to do if the "to" is client's own bare JID. The real life case is XEP-0054: "A user may update his or her vCard by sending an IQ of type "set" to the server, following the format in the previous use case. If a user attempts to perform an IQ set on another user's vCard, the server MUST return a 403 "Forbidden" error." The "previous use case" does not contain a "to" attribute, so jabberd2 implementation checks whether it is not set. If it is - returns forbidden-error.
The phrase "send an IQ-set to the server" is ambiguous. It could mean:1. send an IQ-set over the stream you have established with your server but don't include a 'to' attribute"
or 2. send an IQ-set with to='yourserver.tld' I think here (1) is intended but I can clean that up.
Logic says that for IQs if "to" attribute is set to ones bare JID it should be handled like "to" was not set. But I cannot find a rule that says so in our protocol documentation.
I agree that we need to explicitly state that rule. I'll work it into the stanza handling rules.
"In the face of ambiguity, refuse the temptation to guess." - PEP-0020
Good advice. :) Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
