[standards-jig] JEP-0047 (IBB) Updated

Thomas Muldowney temas at box5.net
Mon Apr 7 18:11:59 UTC 2003

What I'm trying to say is that you are always (I haven't seen a case
yet) going to have another layer above the stream.  You have some sort
of negotiation and then decode rules.  Using the FT example, you might
have a SHA1 to use on the data to ensure that it is all there after
transfer.  Chess would probably have a protocol for saying who is what
color, and then you would have to know how to decode each packet, you
would have to know if you use a stream per packet, or how to delimit
packets.  The streams are like TCP, you have to have something else on
it, so the meta data is probably encoded in the stream, not actually
along side the encoded data.  Is that clear at all?


On Mon, Apr 07, 2003 at 01:49:44PM -0400, Matt Tucker wrote:
> Temas,
> > That functionality should happen on another level such as 
> > JEP-0052 (File Transfer).
> So, I assume JEP-0052 would be updated to add support for IBB at some point? I guess that would mean negotiating a file transfer and
> then using the uid of the IBB stream to actually send the data? In any case, transferring a file was perhaps a bad example. From the
> > It could also be useful for any kind of low-bandwidth activity, such 
> > as a chess game or a shell session
> In this type of case, some meta-data associated with the stream would be extremely useful. I guess what I'm really looking for is
> what I've already implemented in Smack (Java client lib). You can attach properties to packets that look like the following:
> <!-- All properties are in a x block. --> 
> <x xmlns="http://www.jivesoftware.com/xmlns/xmpp/properties">
>   <!-- First, a property named "prop1" that's an integer. --> 
>   <property>
>     <name>prop1</name>
>     <value type="integer">123</value>
>   <property>
>   <!-- Next, a Java object that's been serialized and then converted
>        from binary data to base-64 encoded text. -->  
>   <property>
>     <name>blah2</name>
>     <value type="java-object">adf612fna9nab</value>
>   <property>
> </x>
> More info at: http://www.jivesoftware.com/xmpp/smack/documentation/properties.html
> One of the property types is binary data, but I see IBB as a much better for sending large chunks of data. All of this is very
> useful for people doing machine to machine Jabber communication. Without meta-data of some sort, it's pretty difficult for two
> applications to negotiate about the data they're going to send back and forth unless they use a custom namespace for particular
> data. This sucks for people that want to just grab a Jabber library and code at a higher level. Perhaps this is too much complexity
> for the IBB JEP? It's certainly possible, but simple meta-data does seems fairly useful to me.
> Regards,
> Matt
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20030407/0a5dd405/attachment.sig>

More information about the Standards mailing list