[standards-jig] IBB Again

Thomas Muldowney 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 mailing list