Re: AS#2 Transport Protocol/Security

[rsedc@xxxxxxx (David Chia)]

> I think we are back to requirments again. What are the requirments for two
> WEB servers to exchange EDI in real time?

I prefer to think on along th line of using HTTP protocol. HTTP can be used
interactively or batch. WEB give the impression of person to machine.
Some would argue if we need another batch based protocol beside SMTP.
HTTP operates directly point to point and thus in general it will
perform better in 'real time' applications. SMTP has the advantage
when the network is not as reliable, retry can be auto initiated.
FTP has the advantage when the file to be transferred is large and
the network is not reliable, and retransmission can be resumed
from the interrupted point. Thus possible operations using HTTP are:

	1. person fill in the form, EDI message is produced and send to
	   the server via HTTP, the server pass EDI message to the
	   translator, and acknowledgement or reply is returned immediately.
	2. person specified preformated EDI file from localhost to be sent,
	   server pass EDI message to translator, and acknowledgement
	   or reply is returned immediately.
	3. customised EDI translator send message to HTTP server directly,
	   server pass EDI message to remote EDI translator, acknowldegement
	   or reply is returned immediately.

Note a customised HTTP server can encapsulate the EDI translator as a module
and thus it can deal with the EDI message directly. The responses can come
back in the format specified by the user in plain text, html, EDI, BSI
or excel.

Recent approach usually use pre-spawn multiple http servers. A HTTP server
is usually more light weight when compare to the the SMTP server.
Thus the processing rate for HTTP server is expected to be higher than
that for SMTP server. A pentium pro running commercial or free unix should
be able to handle more than 100,000 messages a day involving
encryption/decryption. (Unlike certain OS which arbitarily attempted to
limit 10 unique network connections per 10 minumtes and failed.)

If multiple HTTP servers are employed and extra efforts are required
to detect race or deadlock situations. Since messages arrived are
processed immediately, provision for queueing the job and auto reprocessing
the job after the depended messages have been cleared. Alarm will be raised
if the depended message do not arrived within a specified time.

> I would assume we need things like signature, encryptions, non repudiation
> of source WEB server, response-time expectations across all levels of the
> protocol stack. Do we need a secure channel between the two servers, in
> addtion to signature and encryption at the EDI message level?

Here we have to decide the following:
	1. the body of the message in MIME multi-part is exactly the same
	   as that for SMTP EDI message and the helper application deal
	   with the received MIME message, the MIME multi-part can be generated
	   by plug-in or imported, the IDs (keys) involved are that for the
	   server, browser or the application program, and the human,
	2. the server/client authentication and encryption mechanisms of
	   HTTP-SSL be employed, the plain EDI message is only protected
	   by the HTTP-SSL, customised browser is needed to export the
	   result of the authentication, the IDs involved are that for
	   server and browser/application-program,
	3. combination of the above.
	4. mechanism to allow for interactive EDI.

Free or reasonably priced secure HTTP servers using the standard port 443
for secure http are available. I am not sure what mechanism the Certification
Authorities will use if you want to verify the ID through the certification
tree.

Typical average response time for small message with lightly loaded machines
and good connectivity:
	1. HTTP - within a minute
		- longer if retry manually
	2. SMTP - within a minute if immediate send and receive
		- within 7.5 minutes average if email is batched and time
		  between email batch processing is 15 minutes
		- longer if retry or relay-hosts are needed

> Carl gave a list of requirements ealier...maybe we should vist them....I
> tried to get these by asking or brainstorming  on the subject....I am not
> sure it is working...Any feedback or suggestions...

Carl has good and knowledgeable ideas on electronic commerce, things
that I would do on a personally level. However the charter of this
work group has defined the scope of the study.

The work group should propose a framework to provide a smoother
transition for current EDI users, to provide a simpler framework for
new users, and to leave doors open so that any other simpler
standards can fit in at a latter stage. If the change is too drastic
existing users might not be willing to write off their current
investment in EDI.

There is at least one EDIFACT message that come with an associated
structured tagged email format with one to one correspondence to
the EDI format. Though it is not as readable as one would wish
the structured and tagged format could be proposed to be the
alternat transport format. However this will require additional
specification defined for many other EDI messages.

The area cover by display tags might not coincide with that for the
data extraction tags. Thus the combined file transferred could be
twice the respective size. If the transfer is between machines
then the display tags are useless. Hence it would be better if
the originator can select the format of the message to be received.
In fact in the http protocol the originator specifies the format
that it understands.

Many OS platforms have limitation on the length of command string
and hence the limitation on the total length of the field/value pairs
after the URL. Furthermore the above string will be stored in the
history file of the browser. A big no no if it contains sensitive
info.  Thus it will be more universal and safer to use the http post
method.



David Chia,
RMIT University.