-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/14/09 8:08 PM, Brian Cully wrote: > On 14-Sep-2009, at 18:56, Peter Saint-Andre wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 8/29/09 6:52 AM, Fabio Forno wrote: >>> On Sat, Aug 29, 2009 at 2:11 PM, Brian Cully<[email protected]> wrote: >>>> >>>>> Another thing: I think that the option of delivering items via <iq/> >>>>> has already been discussed many times, but I don't find any reference >>>> I don't remember seeing this. All I remember is retrieving >>>> items by >>>> iq, which is described in XEP-0060 s6.4. >>> >>> Perhaps it was discussed in the summit ad Bruxelles, but since we were >>> split in small groups on different topics I missed the discussion. The >>> fact is that when you want reliable delivery it is much easier to rely >>> on direct acks than waiting for possible errors. Since it is all an >>> internal thing we're going with <iq/> delivery, I was just wondering >>> if it makes sense to make it a standard delivery option in node >>> configuration. >> >> Yes, I think it makes sense to add this. However, the pubsub service >> would need to know the full JID of the recipient. How does it behave if >> it does not have that information? Does it not send a notification? Does >> it spool up notifications for when it next knows a full JID for the >> subscriber? > > If you were to allow delivery via IQ I think you'd have to mandate > subscription by full JID only.
Hmm, so it seems. Then the pubsub service would need to reject subscription requests from bare JIDs. And if the node owner toggled the notification delivery method from message to IQ, the service would need to unsubscribe the old bare-JID subscribers, or retrieve a full JID from them. In automated systems this might not be a big deal (nothing says that a subscriber needs to be a human user), but I see potential problems with those pesky humans. > I can't figure how the pubsub service > would suss out a full JID from a bare without doing unseemly things. Agreed. > In > any event it would not be fun to implement at all. > >> Further: how much core delivery logic are we forcing onto the pubsub >> service? > > In the case of IQ delivery, if the problems with bare JIDs can be > solved somehow (including not allowing them to subscribe to nodes > configured to deliver via IQ) then any existing XMPP fabric should be > able to handle the routing normally, and the pubsub service would only > need to handle IQ related errors in addition to their current chores. Correct. That is the appeal. > All that being said, I'm not thrilled with the idea of IQ delivery. > I'd think if you needed something like this then you should use some > kind of message delivery verification (I know, I know, we've been over > this a million times), presence based subscriptions, or something similar. /me nods I think those who care strongly about this option need to argue for it and provide text for inclusion in the spec, because there's a big can of worms here. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqvxdYACgkQNL8k5A2w/vwomACg1AsE2Bo0QqD8W8V+/pt+Bc53 5zIAoOXdqMXFHM81jVoTCJ3c4UUCNeut =kCdh -----END PGP SIGNATURE-----
