Excerpts from Peter Saint-Andre's message of Wed Apr 14 23:02:16 +0100 2010: > On 4/13/10 8:11 AM, Matthew Wild wrote: > > I (nobody ask me why) recently implemented a server-side IBB->TCP > > proxy. Everything went smoothly, and it actually maps quite nicely, > > given that it is already bidirectional. > > > > One noticeable thing lacking though is a way to close a stream with > > an error. I can add this data in a new namespace, but it struck me > > that it might be useful to specify either a way to add an error to a > > <close/> stanza, or simply (but perhaps less cleanly, as it only > > works in direct reply to an incoming data packet) specify that a > > stream is closed if any type="error" stanza is received in reply to a > > sent stanza. > > Seems reasonable to me. Can either party generate the close+error?
I think so, yes. > What errors do you think we need to support? > This part I'm undecided on. There are 2 options. We could re-use the stanza errors in xmpp-core, or define a new set of errors specifically for IBB. The former on sight may appear cleaner, and is certainly simpler. Though it suffers from the problem that many of those errors are XMPP-specific, so won't apply. There may also not be errors to cover all cases. The latter I worry would have the potential to turn into an ad-hoc wishlist of error conditions, though perhaps I'm being overly cautious. For my use case I don't really mind, since I'll likely be extending it with TCP errors in my own namespace. This would likely be overkill for most applications though. Perhaps better to simply define just a /way/ to add errors, leaving applications able to re-use the stanza errors, or define their own. What do other people think? Define IBB-specific errors, or no? Matthew
