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.

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. 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.

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.

"In the face of ambiguity, refuse the temptation to guess." - PEP-0020


-- 
  /\_./o__ Tomasz Sterna
 (/^/(_^^' http://www.xiaoka.com/
._.(_.)_   im:[EMAIL PROTECTED]

Reply via email to