[standards-jig] IBB: The options

Dave Smith dizzyd at jabber.org
Thu Apr 10 13:06:09 UTC 2003


On Thursday, Apr 10, 2003, at 02:58 America/Denver, Richard Dobson 
wrote:

> Ok now here is a summary of the options I think we now have.
>
> 1) Stop work on IBB and start work on a new JEP for fix message 
> delivery
> problems, this MUST be done before IBB can proceed any further along 
> the
> message data transmission path, and MUST be finished first. Also must 
> make
> x:events standards track if IBB is going to rely on it for acks.

Obviously, I don't agree that the message delivery fix MUST be done 
before IBB is fixed -- this isn't a problem of mutual exclusivity. The 
Right Thing (tm) to do is proceed with IBB using <message> and start a 
new JEP in parallel to address <message> problems. Creating multiple 
JEPs (one w/  and one w/o IQs) creates even MORE backwards 
compatibility issues.


> Now I would vote for option 2 since it seems to match the requirements 
> much
> more than message does, this is something which you should always do in
> projects before you go too far, a requirements analysis, and according 
> to a
> requirements analysis IQ seems to fit the bill, also the discussion I 
> have
> seen about the meaning of the word message is not really relevant to 
> this in
> my eyes since all you should really be doing is an analysis of the
> capabilities of the packets and see which fits the bill not what the 
> word
> literally means what if the name of the message packet was chat or 
> something
> else silly?? would you still want to analyse the meaning of the word 
> over
> what its capabilities are??.

With all due respect, I would reiterate that this isn't just about the 
"name" of the stanza/packet. There IS a problem with <message> -- we 
can't use it as it was originally meant to be used. This means there is 
a bug in the protocol that should be fixed. Making the right choices 
for protocol clarity and uniformity is a critical part of the JSF's 
function. If we are serious about wanting to build a long-lived 
protocol we MUST be concerned with making changes that match the 
original intent and goals of the protocol.

Diz




More information about the Standards mailing list