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

Justin Karneges justin-jdev at affinix.com
Mon Apr 7 22:41:52 UTC 2003


> 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

The XML notation is exactly the same as JEP-0065, perhaps I should read that 
JEP again to see how they clarified this.

> 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?

Since XMPP guarantees the order of packet delivery, there is not even the need 
for a timestamp or a seq# or anything.  I was not aware of such a guarantee 
until just a moment ago, when I chatted with Peter.

Assuming we switch to messages, this is what I propose for the data packet 
format:

  <message to="joe at blow.com/Home" id="inband_2">
    <x xmlns="http://jabber.org/protocol/ibb" sid="mySID">
      <data>A1B2C3D4E5F6</data>
    </x>
  </message>

The only real identifier is the 'id' attribute, which can be used for 
detecting errors.  On error, the sender should consider the IBB stream 
closed.  There is no need to send a <close/> command to the peer, since we 
know it won't be delivered anyway.  In the event there was just a momentary 
lapse in s2s, and one side thinks the stream is closed while the other does 
not, an entity should bounce the messages itself to indicate error.

Also, switching to <message> means some extra rules:
- If the entity goes unavailable, STOP sending packets
- When the entity returns, it may receive some spooled IBB packets.  It should 
drop them (this should naturally happen anyway).

> 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).

Yes, this needs to be done..

-Justin



More information about the Standards mailing list