[Standards] IQ Pubsub again (was Re: Fwd: Meeting minutes 2010-02-15)

Peter Saint-Andre stpeter at stpeter.im
Fri Feb 19 04:44:31 UTC 2010

On 2/18/10 9:35 PM, Joe Hildebrand wrote:
> On 2/18/10 3:10 PM, "Tuomas Koski" <koski.tuomas at gmail.com> 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
      <user at domain> as described in the next section (but without
      modifying the value of the 'to' attribute).


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6820 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20100218/6e9e54e1/attachment.bin>

More information about the Standards mailing list