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

[drummond@xxxxxxxxxx (Rik Drummond)]

the standard will support signed-receipt the techical basis for NRR.
later...rik

At 3:25 PM 12/9/96, Jacky, William wrote:
>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
>>
>>

------------------------------------------------------
|         Rik Drummond - The Drummond Group          |
|   5008 Brentwood Ct., Ft. Worth, TX 76132   USA    |
|      Voice: 817 294 7339    Fax: 817 294 7950      |
------------------------------------------------------