[standards-jig] JEP-0047 (IBB) Updated

Thomas Muldowney temas at box5.net
Mon Apr 7 17:11:56 UTC 2003


Ok, I've been trying to work on this in a more private forum for a
while, but apparently some of the concepts aren't getting through.  So,
it's time to be more public with my JEP-0047 problems.

First, let's start with the session id.  It needs to be immaculately
clear that a session id is bound to a JID.  As it stands right now I
could infer that the session id is only related to the stream and that
multiple sources (jids) could contribute to the stream.  While this could
possibly be an interesting application/extension to file transfers or
other stream users, it would need to be clearly layerd into the next
level of protocol.  You need a clear concept of JID <=> session id
mappings.

Next up is the seq and prevseq mess.  A mess you say?  Yes, a mess.  The
wording is still extremely weak, and allows for such diverse usage that
you would not get consistent implementations, and it would cause a
constant source of nightmares for implementors.  The source of all my
nightmares is that we actually have a limitted set of sequence numbers.
Granted, we can't have an unlimitted set, but I'll propose a solution
after laying down the problem.  Because we have a limitted set of
numbers we actually have to take some amount of framing into mind.
seq='1' in frame 1, seq='1' in frame 2, and so on.  I know you are
thinking we'll rarely ever reach a new frame, right?  Wrong.  The
wording currently doesn't state that we have to go all the way to the
maximum number, rather we can use prevseq to make whatever relations we
want.  So we could send like this (s is seq, p is prevseq):  s0, s1, s0
p1, s1, s0 p1, s1.  Yuck, or even worse, to explode our framing:  s0, s0
p0, s0 p0, s0 p0, s0, p0.  That's just not pretty.  I think the wording
around that section allows for even more extraneous usage but I'll leave
that up to your imagination.

So how do we solve the seq mess?  The solution that myself and a few
others have been suggesting is that packets are not sent with a sequence
number, but rather a high resolution (millisecond) timestamp of when the
packet was transmitted.  This allows us to make full use of the XMPP
ordered packets and ignore the crazy frames that most (all?) sequence
number systems will cause.  The only drawback is that you could send
only one packet per microsecond.  I suggest you read that again though.
That's one packet per microsecond, still a whole lot of packets.  This
gives us a _near_ infinite number of packets since the system has to
keep time itself.

On to the next problem, <iq/> usage.  I feel that we should be usinge
<iq/> for the state transfers, and then <message/> for the actual data
passing.  I don't see a need for an ack with every single packet sent in
the stream.  XMPP is guaranteeing the ordered packet delivery, and error
conditions when a packet can not be delivered, so why are we adding all
this overheard?  Further, the current JEP-0047 says we can hold off on
sending acks until the stream is complete, but that's ridiculous and
creates a DoS on both the server and sender for long lived streams.  The
only credible anti-<message/> statement I've heard is the offlining of
messages.  I would consider this a feature, but JEP-0047 could easy
mention JEP-0023 (Message Expiration) if that is not the intended
behaivour.

My last issue is with the current state control of JEP-0047.  I think it
would be extremely helpful to implementors and help clean up the overall
flow if the state was explicitly clear in JEP-0047.  I would suggest 5
states, negotiation, beginning, transmission, closing and error.  I
would also suggest that the states not actually be mixed, as is
currently done in Section 3 Example 8.  The error state really needs a
lot of flushing out still, such as what to do when an error is
encountered in the middle of a transmission by the sender (bounced
packet).

As it stands I don't feel the JEP is anywhere near a +1 or 0 vote from
me.  That shouldn't be taken as a threat, but rather that there are
clear issues that I feel I've outlined.  If there is a concensus in
another direction for this JEP, I would like to hear some clear
arguments showing why that direction is better so I can clearly cast my
vote on this JEP.

On another note, once JEP-0047 is cleared up we'll update file transfer
and push it through the process.

--temas


On Sun, Apr 06, 2003 at 05:07:29PM -0700, Justin Karneges wrote:
> Hi everyone,
> 
> I have updated JEP-0047 (found below until it is made official)
> http://www.affinix.com/~justin/jep-0047.html
> 
> I think this addresses the remaining issues.  All it needs now is dressing, 
> which hopefully Peter can aid with so it follows the style of JEP-0065.  I'd 
> also like to see a similar naming convention (both for the prototol and 
> namespace) of these two JEPs.
> 
> -Justin
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20030407/bb6e8cb4/attachment.sig>


More information about the Standards mailing list