-----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: >> The problem, I think, is that <service-unavailable/>, potentially >> <remote-server-not-found/>, and maybe more might not make sense as type >> "cancel" since they're frequently generated for transient errors (the >> service is temporarily offline, as you say). I see two options off the top >> of my head (which hasn't had its coffee yet): >> >> 1) Add transient versions of at least <service-unavailable/> with an >> error of type "wait." To distinguish the permanent vs. transient conditions >> a server would only need to know if it's configured to allow for that >> component to connect although it might not be at the time (potentially >> <recipient-unavailable/> would due here), or, > > Yep, reviewing error conditions I think that ejabberd (the server I'm > using) is sending a service-unavailable instead of > recipient-unavailable which makes more sense. Opening a ticket... :)
Perhaps we need to clarify in 3920bis what we mean by transient and permanent errors. >> 2) Have the server which handles the component save the messages >> until the component connects, akin to offline delivery. > > I prefer 1), since the pubsub service may decide which is the best > strategy for delivering items to temporary unavailable recipients, > instead of relying on a spool where it has no control and where there > are potential denials of service If your server is returning a fatal error to you because a component connection went down temporarily, then your server has bugs, IMHO. 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/ iEYEARECAAYFAkquycQACgkQNL8k5A2w/vxNZQCePeiFpAxorHDZ1Nzo58TeamJ/ 1PMAoPLOcgbxc6GJx0iSU2v2B+J6mlZY =fzwe -----END PGP SIGNATURE-----
