[standards-jig] IBB Again

Rachel Blackman rcb at ceruleanstudios.com
Sat May 3 08:02:05 UTC 2003


> Most use-cases of IBB will need this semi-reliable behavior:  Avatar
> exchange,  File transfer, Games, Data tunneling, etc.  What kind of
> use-cases will need  unreliable behavior?

Webcam.  Voice chat.  Anything where UDP would be suitable.

Half of my objection to iq in the first place was that I /can/ conceive of
situations where I would want a UDP-style transport.  The other half is
that I still think that message is 'the right thing,' and it will take a
great deal to sway me.  I still think of IQ as http headers, and message as
the data stream. :)

> When I proposed JEP-0041 (REL) earlier this week, I was criticized for 
> thinking too far ahead.  In particular, pgm noted that we should create 
> protocol as needed, rather than try and make some perfect protocol that 
> covers cases we don't care about yet.  Keep this in mind when answering
> the  above.

I read pgm's statement as having been that we shouldn't think too far
ahead, but that when a need for a protocol /does/ arise, it should be done
right.  As protocol reveals additional needs, things adapt; as in this
case, the needs of a desired protocol forced the creation of message
delivery semantics, which I think are generally useful and will provide
other protocol options in the future.

Or to put it more concisely, I would argue that yes, there's a need for
this protocol...and now that the need has arise, it should be implemented
correctly with regard to the future.

> Acknowledgements, like message events?  I know there was some talk
> earlier  that IBB should not rely on a non-standards-track JEP (in this
> case, -22), so  maybe these same features should be rolled into -79 ?

Perhaps.  Or perhaps JEP-0022 should be made standards track?  I lean more
towards that, honestly...it is widely implemented and is useful enough that
it should be a standard feature.  'course, I'm obviously going to argue for
that since I'm the one who suggested using 0022 for flow control and still
believe it's not only a well-suited match, but utilizes existing protocol
and satisfies the aforementioned 'only redesign what's needed to do things
right.' ;)

-- 
Rachel Blackman <rcb at ceruleanstudios.com>
Trillian Messenger - http://www.trillian.cc/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20030503/2c1e9198/attachment.sig>


More information about the Standards mailing list