On 2/18/10 9:35 PM, Joe Hildebrand wrote: > On 2/18/10 3:10 PM, "Tuomas Koski" <[email protected]> wrote: > >> I have to admit that I have forgotten these use cases too. How ever >> here are my reasons why I'm sending events in IQs: >> * to be 100% sure that the events don't go to offline storage > > <message type='headline'/>
That's not a MUST in 3921bis, and even if we make it so (right now it's
defined as up to service policy) many servers don't honor that logic now
and probably won't for a long time, so a pubsub service can't depend on it.
>> * To have "acks" without implement XEP-0184 Message Receipts or similar
>
> What do you do if you don't receive the ack? Resend?
IQs MUST be acked or errored according RFC 3920. Bad client, bad!
Now the ack or error might be lost. Again, there are no guarantees here.
But it's more likely that the subscriber supports 3920 semantics for IQs
than that it supports XEP-0184.
>> * I'm connected with a JID with multiple resources (/a and /b for
>> example). I want to send events only to resource /a. When the
>> resource /a for some reason disappears some servers starts to route
>> message stanzas sent to resource /a to resource /b.
>
> Headlines to unknown resources aren't well-defined. To be logically
> consistent, they should be dropped.
Yes, that needs to be clarified in 3921bis. Currently it says the
following for the case of message to full JID, no such resource:
o For a message stanza of type "chat", "headline", or "normal", the
server SHOULD treat the stanza as if it were addressed to
<u...@domain> as described in the next section (but without
modifying the value of the 'to' attribute).
/psa
smime.p7s
Description: S/MIME Cryptographic Signature
