[standards-jig] IBB: Making it all "go"
rcb at ceruleanstudios.com
Wed Apr 9 17:35:32 UTC 2003
> This whole argument around <iq> and <message> almost makes me wonder if
> certain people would just prefer to get rid of <message> and mix all the
> semantics therein into the <iq> element. It doesn't make any sense to me.
It seems like the objections to using message are not because of the
inherent stanza itself, but because of worries about assumptions that
servers make about storing messages offline or delivering to alternative
resources. I can see the logic behind it, even if I don't think it's
necessarily as big a problem as some might believe.
I can see the problem if, for instance, I connect some poor WAP device and
am instantly flooded by 10 large IBB packets. However, I don't think this
problem is enough to warrant using IQ rather than message for IBB; presence
is used for presence things, IQ is used for query/reply/set type
situations, message is used for data transport. I'm not overlooking
I suspect if Jabber is used to transport other things, then this objection
will come up again in the future, since message is the appropriate method
for data transfer from everything I see.
If x:expire is not acceptable as a method of making messages transient for
whatever reason, it might be worthwhile to define a 'transient' (or
'direct' or something) message 'type' attribute? I.e.,
<message to='sparks at jabber.org/ibb-demo' type='transient'>
Since this really /isn't/ any other type of message, after all. Then, in
theory, a server could optionally toss all transient messages when the
resource went offline, rather than redirecting or storing offline. I can
see the objection to using x:expire and x:event (though I think they suit
the situation very well) since they are, in theory, optional JEPs.
I don't really like the 'type' solution, personally, because I think the
beauty of IBB as it stands is that there doesn't need to be any change to
the server, but if the problem with IBB packets going to a new resource
when they come online is a real one, it's at least one possible solution.
And it at least wouldn't /break/ existing servers, they just wouldn't have
a way to specifically expire transient messages. And in theory, it /would/
allow for this problem to be addressed when it inevitably comes up in some
other message-stanza-based transport. :)
I /do/, however, agree with Dave that this really is a tool for message,
either way. Message is a data transport as far as I understand it.
Whether it carries a text body, an event notification about messages,
encrypted binary code or some kind of physical description to use in a
matter replicator powered by Jabber... whatever it is, it's still data
being moved. :)
Rachel Blackman <rcb at ceruleanstudios.com>
Trillian Messenger - http://www.trillian.cc/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
More information about the Standards