[Standards-JIG] how to handle IQ while invisible

[Olivier Goffart]

Le mardi 22 août 2006 15:48, Ian Paterson a écrit :

> 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 don't like this option because it's hard restrictions. XML allow space 
between element in non mixed contents.  Clients and server uses different 
existing library that have different behavior (argument ordering, 
indentation, ....) 

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

I have not strong argument against this.

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

Yes, 2. is better.

Anyway, all theses solutions still have a flaw.
I can imagine that it would be possible to determine the presence by measuring 
the average reply time.

So i suggest also
4.  While the user contact set him in invisible mode, the server MUST 
automatically reject with the <service-unavailable/> error all <iq/> 
dirrected to the contact from a contact which is 'not authorized' (i.e., the 
client has not leaked presence with message or iq directed to him)

That's in accordance with the "complexity in the server" rule, and i think 
this is fine. 
I don't think that a contact which has set in invisible or blocking mode need 
to receive <iq/>, or which one ?

--
Olivier
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.jabber.org/pipermail/standards/attachments/20060822/8d99b8b7/attachment.pgp