[standards-jig] Jidlink revisited

Justin Karneges justin-jdev at affinix.com
Mon Apr 7 00:51:03 UTC 2003


We have both direct and inband client-to-client bytestream efforts (which I 
refer to as S5B and IBB), however I think in the majority of use-cases, these 
should be interchangable to the application.  They have the same input (a 
peer JID) and the same output (a reliable bidirectional bytestream).

I tackled this issue last year with Jidlink:
http://www.jabber.org/jeps/jep-0041.html

There was criticism with Jidlink, because it involves an extra 'key' and 
iq-exchange process.  I even have my own criticism of it, which is that it 
must explicitly mention the layers that it can work with.

Perhaps a better way would be to have some sort of inheritable layer that S5B 
and IBB can both say they build from.  An example of such inheritance can be 
found in the W3C's XML Encryption, where EncryptedData and EncryptedKey are 
both considered to be EncryptedType, and thus can be used wherever 
EncryptedType is allowed.  Maybe Jidlink could just be the properties of a 
reliable bytestream (ie, the input/output I described at the top of my 
message), which S5B/IBB could inherit.

Of course, this still doesn't solve how to choose which layer to use in a 
given scenario.  Maybe you can't avoid an extra iq for that.

Another thought: maybe the protocol namespaces could be:
  http://jabber.org/protocol/bytestreams#ibb
  http://jabber.org/protocol/bytestreams#s5b
This way the common foundation is even more clear.  'Bytestreams' could be the 
new name for JEP-0041, to describe it.

Anyway, thoughts?

-Justin



More information about the Standards mailing list