Re: IMAP4 for Real time EDI

[Erron Criddle <ejc@xxxxxxxxxxxxxxx>]

At 08:17 AM 7/7/97 -0500, Rik Drummond <drummond@xxxxxxxxxx> wrote:

<snip>

>So our main option, with a application protocol seems to be http/post
command. Any objections to focusing on this one?

I don't mind :)

Carl sent a previous e-mail with a procedural outline of an interactive
exchange that we may be able to use as an reference to create an overall
framework for interactive EDI, totally independent of the protocol.

The example Carl gave is:

  - TP listens for connections on IP port XXX.
  - Sender initiates connection and writes the X12 interchange to
    the socket.
  - Sender waits and reads an interchange as a reply. If no reply is
    received within a timeout period, assume a failure, drop and 
    retry.
  - Recipient accepts a connection, and reads the X12 interchange 
    data.
  - Recipient responds with an interchange containing a 997 
    Functional ACK, and optionally another transaction, e.g. a
    PO Reply, in response to the interchange.
  - Sender reads the reply interchange, and checks the transactions.
  - If the reply contains only a 997, the sender drops the 
    connection.
  - If the reply read by the Sender contains a non-997 transaction,
    the role of Sender-Recipient reverses, and processing continues
    as described above, where the original Sender must respond with
    a 997 and optional additional message in the "conversation".

If we take the above and create a more generic interactive language that
includes encryption, signatures, non-repudiation, sequence numbers and a
host of other requirements mentioned in the requirements doc, then a high
level "interactive protocol" can be defined that can then be used with
either HTTP, SMTP or whatever (forget the low level protocol differences
for now).

If one TP wants to "talk" to another TP, then they could send an _initial_
e-mail to the TP in the form of:

to: edi@xxxxxxxxxxxx
subject:edi protocols supported

and the response may contain the the body of the e-mail, the actual
protocols supported, ie:

IMAP4
HTTP 1.1
X12
EDIFACT
BSI

etc
etc
etc

Based on the received response, the initiator could then determine what
protocol would be best to use and use that protocol.

If we can define a generic framework that caters for X12/EDIFACT/BSI or any
other "data exchange standard" and can also define the requirements for
(maybe starting with IMAP4) a couple of protocols, then we should be
heading in the right direction...

Am I heading in the right direction or should I read the requirements doc
again?


Regards



Erron Criddle                                    ejc@xxxxxxxxxxxxxxx
Techrron Holdings                         http://www.techrron.com.au
5 Forsyth Street
O'CONNOR  WA  6163                             Fax: + 61 8 9328 6579
Australia                                      Tel: + 61 8 9227 6579