[standards-jig] IBB: Making it all "go"
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
>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
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).
Software Engineer @ Splendo
More information about the Standards