Re: AS#2 - Internet Draft Proposal - 0/3

[rsedc@xxxxxxxxxxxxxxxxxxxxxxx (David Chia)]

> This is the number three deliverable...Many don't think that the HTTP is
> rich enough to handle server to server EDI.  I don't think that the HTTP
> standards can support our "requirement" .....those we developed over the
> last few months.... Read the requirments.....se what you think....let me
> know......Thanks...David..later...rik

OK, assuming that the extention to the work group charter can be extended.

As Carl has pointed out many of the functionality defined can be
obtained from existing RFCs. The ranges of functionality defined are
also remained at the level of file transfers, the standards referenced
are all file transfer and messaging standards, no EDI or Electronic
Commerce business operation views or requirements are presented or
discussed, thus is it appropriate to call it:

>             Electronic Commerce Transfer Protocol (ECTP)

Why the 'Simple Green Commerce Protocol' from N.S. Borenstein and
M. T. Rose (though it did not graduate to become a RFC) or RFC 1898
Cybercash Protocol (I know it ony deal with financial transaction),
or the extentions to them be discussed ? Incidentally, if SSL is
mentioned why wasn't it properly referenced ? Why an established
RFC 2015 for PGP/MIME was not referenced and yet S/MIME with
no RFC standing was mentioned ?

>From the proposal it appeared that the 'ECTP' server will be operating
at the same level as the equivalent SMTP, NNTP or HTTP servers. The
mode of operations for these servers are different, e.g. SMTP server
will reply only after the data has been processed and saved to disk
whereas HTTP server will response as soon as it can. So how will the
ECTP server behave?

Will the ECTP server able to write to any users' directories (i.e. root
priviledge) ? Will it trigger execution of application programs similar
to the email filter or the HTTP CGI ?

SMTP or HTTP related applications will only reply after the entire
input has been processed. So please elaborate the 'real time
conversation interaction' between processes across locations
beside using the standard defined commands. Do the conversations
have to be wrapped between DATA and .<CRLF> ?

As defined in the proposal the conversational reply is established from
a seperate connection. How do the originating host know which process
the connection should direct to ? Example:

host A process 100 port 1024 --> host B process 200 ECTP port,
host A process 110 port 1025 --> host B process 210 ECTP port,
host A ECTP port (or any other port, but how does host B knows which to use?)
  receive connection request from host B process 210 port 2024,
  how does host A knows which process should receive the connection?
  Is the protocol consistent and complete ?

Is the ECTP server suppose to be a single application server (like
the NNTP server) ? If not how do the ECTP server know what NEXT means
without referring to the appropriate applications ? The next item
in the catalog or the next cargo shipment ? If the NEXTs are meant
for the applications then why direct them towards the ECTP server ?
Or are they just dumb transfer of files between two servers ?
If so why is it called ECTP ?

On the other hand if the 'ECTP' servers are built into the
many diff bussiness applications, then how many ports need
to be registered as standard ports ? Otherwise how do the
originating clinets know where to go ?

The proposal assumed that there is a universal trading partner
ID system (at least it appeared to be so from the example).
Interestingly even the US government recognizes and uses these ID sys:
	Taxpayer ID no. (TIN)
	employer's ID number or social security no.
	DUNS
	CAGE
	CEC
There will be a similar & diff list from Australia or any other countries.

Oops, exceeded my two page limit. Bye...


David Chia,
RMIT University