[standards-jig] IBB: Making it all "go"

Daniel Chote daniel at chote.net
Thu Apr 10 03:30:33 UTC 2003


reply on both Rachel Blackman and this message:

I dont "disagree" with this, but as you see, untill the whole world 
upgrades their jabber servers to a version that will support these 
changes needed, it will be an issue.. even tho XMPP is trying to become 
more than IM, and this I am glad... Jabber is still nothing but IM with 
a few bells...

Tijl Houtbeckers wrote:

> Daniel Chote <daniel at chote.net> wrote on 10-4-2003 2:36:06:
> 
> 
>>Now, i know that if the server implementations worked properly, other 
>>than the offline storage issue from the s2s latency, it would be 
>>reasonable.. but, still very irrelevant to the definition of the 
>><message/> packet.
> 
> 
> Straight from the still fresh XMPP core draft 08:
> 
> About the message "stanza".
> 
> "
> Message stanzas in the 'jabber:client' or 'jabber:server' namespace are 
> used to "push" information to another entity. Common uses in the 
> context of instant messaging include single messages, messages sent in 
> the context of a chat conversation, messages sent in the context of a 
> multi-user chat room, headlines, and errors. These messages types are 
> identified more fully below. " 
> 
> We are "pushing" information here, so that would fit the description. 
> 
> However, we want more then just that, in many cases we want to have 
> things like flow rate control, 100% reliability, and we only want our 
> packets to be delivered to the same resource and client that we started 
> the streams with and we want no offline storage (as an extra it might 
> be nice in some cases though). I think we *all* agree on this? 
> 
> All this can be done today, right now, with <iq> and it can not be done 
> with <message>. 
> 
> XMPP core on the <iq> stanza, agrees with Rachel:
> "
> Info/Query, or IQ, is a request-response mechanism, similar in some 
> ways to HTTP[24]. "
> Wich to me doesn't sound like it would exclude IBB.
> 
> So I'd say, if there is a group wich has reached consencus that for 
> whatever reason we should use message instead of IQ stanzas they (we'll 
> all help as ussual ofcourse) start fixing <message/> till it can fill 
> at least the same basic requirments that <iq/> already handles (most 
> likely using JEP 22 and 23 as a starting point). Until they do, or at 
> least state to do so , I see no reason for Justin K. to incorperate 
> <message/> into his JEP, or the council/JEP-editor to tell him to do 
> that, unless it is their believe that Justin is also responsible for 
> fixing problems concering the message stanza. 
> 
> Then I'd like to add one more thing the discussion, and that thing is 
> XMPP. Using the <iq/> stanza the JEP would depend merely on XMPP Core 
> (wich is nice cause it's not necisarly IM centric). I don't know what 
> the chances are for JEP 22 and 23 or simulair functionality (needed for 
> IBB) making it into XMPP Core (slim?), but I think if IBB would depend 
> on it, it should at be included in the final XMPP IM spec. If the 
> message stanza is meant for this type usage the tools to do so should 
> be part of standard functionality. 
> 
> 
> 

-- 
Daniel Chote
Developer/Designer and typical drunk!
email/jabber: daniel at chote.net
blog: http://daniel.chote.com
website: http://www.chote.com





More information about the Standards mailing list