[Standards-JIG] how to handle IQ while invisible

[Ian Paterson]

I agreed with all of Andrew's post.

Andrew Plotkin wrote:
> I did some quick IQ tests -- sending a Jabber-RPC query to different 
> clients and servers. I saw a <service-unavailable> from one server, 
> <feature-not-implemented> from another, <item-not-found> from another. I 
> assume there are still old servers that return <error code="..."> with no 
> specific error element.

XMPP-IM specifies that the server MUST reply with a <service-unavailable/> 
stanza error. So it's important that the server implementors fix those bugs.

> Then there are differences in attribute ordering. And in element ordering.
> Conclusion: there is no good way for a client to mimic an arbitrary 
> server's "you can't do that" response.

But do we have a better way? Here are some (unpleasant) options:

1. The mimic option above. i.e. Specify that servers SHOULD always report 
<service-unavailable/> errors using minimal canonical XML (i.e. without any 
unnecessary whitespace or 'code' attribute or <text/> element or 
application-specific condition element), with the <error/> element after the 
sender XML (<query/>). And, to ensure clients are able to confidently mimic 
these errors, specify that servers SHOULD NOT rewrite the content of error 
stanzas received from their clients before forwarding them.

2. Specify that servers SHOULD rewrite the XML of all <service-unavailable/> 
errors received from their clients according to their own 'style' before 
forwarding them (without adding or removing content). And specify that 
servers SHOULD always report their own <service-unavailable/> errors without 
any 'code' attribute or <text/> element or application-specific condition 
element.

3. Define a new protocol that enables a client to ask the server to send a 
<service-unavailable/> reply for it. (IMHO this is the worst option, since 
it would break the fundamental XMPP stanza routing rules.)

> (I suppose the client could send a badly-addressed IQ packet to its own 
> server, store the error response, and use that as a template. I think it's 
> safe to say that's a terrible solution.)

Or choose a template from a hardcoded list according to its server's 
response to a "jabber:iq:version" query.

Yes these are both terrible solutions, but AFAIK they are the only practical 
way that clients can protect their users' privacy today.

There seem to be no good solutions, but RFC 3921bis must address this 
important issue.

> 9/11 did change everything. Since 9/12, the biggest threat to American
> society has been the American president. I'd call that a change.

- Ian