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

Tijl Houtbeckers thoutbeckers at splendo.com
Wed Apr 9 18:50:25 UTC 2003

Peter Saint-Andre <stpeter at jabber.org> wrote on 9-4-2003 20:45:32:
>On Tue, Apr 08, 2003 at 07:44:14PM -0700, Justin Karneges wrote:
>> I hate to wreck the party, but as much as I like these latest ideas, 
>> I think we may want to go back to just plain <iq> with wait-for-
>> result.  Sure, this has the downside of extra turn-around time per 
>> packet, but at least it is issue-free (no counters, no delivery 
>> problems). 
>Justin, the consensus of the list 

Consensus? I hope that if there is this consensus there is the same 
consensus that whatever JEP is gonna come out of this it should not 
depend on 2 JEPs that are still only informational. 

>is that using message is a superior
>technical solution. 

I can see reasonable consensus on the point that <message> is suited 
for data transfer, the issues of offline storage and flowrate control 
are still wide open. This could be fixed by putting JEPs 22 and 23 on 
the standards track, in wich we will see (as with any other JEP on the 
standards track) what issues those JEPS still have. Anyone who will 
write a standards track JEP that depends so heavily on informational 
JEPs will hopefully get voted out by the council. Some servers probably 
don't even support x:expire (isn't listed on the JOEY homepage for 

>The point of this list is to reach consensus on
>protocols. If you do not like the list consensus, that is your
>prerogative. However, it is also the prerogative of another community
>member to write a competing JEP that incorporates the consensus
>solution, and of the Council to approve that JEP rather than yours. You
>have been down this path before when Dave Smith wrote JEP-0065 because
>you would not change JEP-0046. Now JEP-0065 is one vote away from
>Council approval whereas JEP-0046 will be rejected by the Council when
>it has a chance to vote on it. You are free to pursue the same strategy
>with regard to JEP-0047, but I would not advise it, because the 
>Council will advance a proposal that has community consensus, and such 
>a proposal will emerge whether you author it or not. In particular, I 
>am most happy to author such a proposal myself.

I hope that last voter will consider the advantages of JEP-46 over JEP-
65, and will make sure there will be an update to JEP-65 for that. I 
have my doubts this will happen, since it's been discussed in lenght on 
this very same list and it's not in the JEP. 

I know I'd like to see JEP-46 implemented along with JEP-65 (if it 
stays like it is now) in the client I use, since in some aspects it's 
still superiour to JEP-65. I doubt any client developer would still 
implement it with a "No" from the council, but at least when these 
issues will come up when people will start to use JEP-65 in the real 
world we can say: "well at one time, we actually had a proposal that 
would have solved these issues, but you know how these things go..." ;) 
I can't blame Justin for taking this specific approach. 

I say this because community concensus or not, I'll be needing IBB 
within the next few months for a project, and I don't want to rely on 
two informational JEPs (wich could use some work anyway) for this. If 
these issues are not solved before then, I hope there will still be at 
least one JEP around that works *properly* I can use. 

I'll be looking forward to what the council has to say, both about JEP-
46 vs. JEP-65 and a potential IBB <iq> vs. <message> JEP, though I have 
no idea where to look for that kind of information (can you subscribe 
to Council minutes somewhere, or do I have to plow through groupchat 
logs somewhere? [...] After searching a bit http://www.jabber.
org/council/meetings/ looks like a good place to start though it has no 
mail-subscribe or xml-syndication available). 

Tijl Houtbeckers
Software Engineer @ Splendo
The Netherlands

More information about the Standards mailing list