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

["Jacky, William" <william.jacky@xxxxxxxxxxxx>]

Bill Jacky                             E 
I do have the documents in question.  Consider Question one below
answered.

Bill Jacky
Electronic Data Systems
>----------
>From: 	Jacky, William
>Sent: 	Monday, December 09, 1996 2:14 PM
>To: 	'ietf-ediint@imc.org'
>Subject: 	FW: AS#2 - Internet Draft Proposal - 0/3
>
>I have a few questions on this ongoing discussion.  Forgive my ignorance in
>advance:
>
>1).	I have not found the documents being discussed here, so I am at a
>distinct disadvantage.
>	Where are these documents being discussed?
>2).	Based on the initial requirements of this task force, it appears to me
>non-repudiation is a
>	required topic; the standard must enforce non-repudiation.
>3).	The protocol should be between the application layer and the network
>layer.  Many of
>	the comments here seem to forget that.  
>
>Bill Jacky
>Electronic Data Systems
>
>----------
>From: 	rsedc@urgento.gse.rmit.EDU.AU[SMTP:rsedc@urgento.gse.rmit.EDU.AU]
>Sent: 	Monday, December 09, 1996 12:12 AM
>To: 	ietf-ediint@imc.org
>Subject: 	Re: AS#2 - Internet Draft Proposal - 0/3
>
>> 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
>
>