[standards-jig] IBB Again
temas at box5.net
Mon May 5 15:47:07 UTC 2003
I suggest reading the logs from the protocol discussion last week where
we discussed REL.
On Sat, 2003-05-03 at 08:59, Tijl Houtbeckers wrote:
> Justin Karneges <justin-jdev at affinix.com> wrote on 3-5-2003 9:01:01:
> >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.
> And why *wouldn't* we need REL? I doubt there is a shortage of usecases
> for it. For example it would solve the IBB discussion, use IQ based IBB
> now (wether it comes out standards-track, informational or rejected)
> and switch over to message based IBB when there are standards and
> server implementations that make this possible.
> The JEP currently reads:
> Reliable Entity Link (or simply 'REL'), is a system for coordinating
> reliable bytestreams between two Jabber entities. By 'reliable', we
> mean that the bytestream transport handles all data delivery issues,
> such that an application need not worry about them (a good example of
> such a protocol would be TCP). "
> If you'd drop the "reliable" parts in this, it could also be used for
> the things Rachel just mentioned (webcam, voice, etc). Applications
> will know wich protocols to advertise during the feature-negotiation
> step, as well as wich one they prefer.
> For example it will not advertise any irreliable UDP-like protocol for
> filetransfers, and it will prefer something such as SOCKS5-Bytestreams
> over IBB in most cases. For a webcam stream it would prefer an UDP-like
> protocol, though it might prefer an OOB TCP-like protocol before going
> IB in any case.
> Like this I fail to see how REL could be something "too far ahead". It
> sounds more like something we should have had for a while now :)
> Maybe it could even be extended to dynamic switching between protocols
> (it wouldn't be *that* hard), though that may be out of scope for the
> JEP (it could be solved on the application level or through a different
> JEP as well). In any case, REL will make this more easy and generic.
More information about the Standards