Re: Question regarding draft-ietf-ediint-req-05.txt

[Gunther Schadow <gunther@xxxxxxxxxxxxxxxxxxx>]

Bill Birkle is right. What we are missing is a way to sort a thread of
messages. I know, a lot of people would argue that this is an
apllication issue or handled by the EDI protocol. However, I disagree
with this argument. I want a powerful MIME EDI container that provides
all functions that are required to do a reliable secure EDI
communication. Bill's problem could be solved by defining headers for
the apllication/edi container:

content-id:  <msgid>
	assigns an object id to the current EDI message

in-reply-to: <msgid>
	gives the EDI message id that is replied to

refering-to: <msgid>
	lists all message ids that need to be known in order to make
	sense of this message

Thus the refering-to header allows to keep track of sequences. Suppose
the sender sent a sequence of messages A, B, C, where C depends on A
and B does not depend on A or C. The receiver receives the sequence C,
B, A. Now if message C showed a header "refering-to: A" but A is not
yet received, C is stored in a hold queue and is not processed. Now B
arrives and is processed as it does not depend on anything. Finally A
arrives and gets processed. C is still on the hold queue. If the
MIME/EDI processor is smart, it recorded the dependency of C on A and
while it processed A, it can process C next. If it is less smart, it
would just regularly scan through the hold queue finding all messages
whose dependencies are resolved already.

In a similar way we can protect against sequencing threads, or
"jackpotting". Jackpotting refers to ATM machines who upon reception
of a dispense-message would dispense money. Cool guys would intercept
the dispense message and replay it until the ATM is empty. In order to
protect against this thread, we have to keep a record of message id's
that have been processed already.

Note everyone that this is *not* an application issue, it is as
essential to secure transactions as digital signatures. Note also that
this must be handled within the application/edi container! We cannot
reuse the outer e-mail Message-id as this is not signed and thus can
be changed for each replayed message during jackpotting. Can we at
finally discuss an update of RFC1767?

> EDIINT Working Group,
>
> In this draft I did not find a statement indicating that there is the 
> possibility that messages sent could be received in a different order.
>
> With a packet taking routes through many different nodes,  isn't it possible 
> (and likely) that messages sent in a certain order could be received in a 
> different order?  This is of great importance for 'real time' EDI.  Messages 
> must be received in the same order that they are sent.  What would be the 
> result of receiving a canceled EDI transaction before the original 
> transaction?  Or, receiving change EDI transactions in the wrong sequence?