[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

!!!! EDIINT AS#2 - Requirement Voting



Below is the list of requirements we gathered during the last three months
for WEB (server based / process-to-process / not SMTP based) EDI exchanges.
Now it is time to decide if they are "Requirements" or "Nice to haves". Let
vote using the following format.


                     Required: 1.0

       Means category 1.0 below is a requirement. We can NOT get along without
       it.

                     Nice: 2.6

       Means category 2.6 is not a requirement for process-to-process EDI,
but a
       "nice to have". It means we can get along without it.


Please make the return message look like this. It is much easier to
tabulate because we can sort the responses.



         Subject: RE:!!!! EDIINT AS#2 - Requirement Voting

         Required: 1.1
         Required: 2.3
            .
            .
         Required: 3.6
         Nice: 2.2
         Nice: 2.4
           .
           .
         Nice: 3.3


There are 36 items. Please state whether they are "Nice" or "Required".
Lets do this by Nov. 19, 1996.  At that time we will tally the responses
the publish the requirements.



Thank....Rik



DRAFT V1.0

                         AS#2 Requirements

1.0 General Requirement
1.1 An open, interoperable, point-to-point protocol that allows
 applications to exchange standard EDI data or proprietary data in the
 following ways:simple sending,simple receiving, real-time, conversational,
 interactive, and query.

2.0 Data Content
 2.1 No limitations
 2.2 Assumes MIME
 2.3 Traditional Batch EDI
 2.4 Proprietary
 2.5 Standardization of Web-forms (cgi) to EDI Format
 2.6 Protocol not limited to specific application domain

3.0 Connectivity
 3.1 Direct realtime exchanges
 3.2 Immediate access to underlying operational systems totally
     eliminating the need for store and forward systems
 3.3 Built in error detection and retransmission of ordered data (TCP)
 3.4 Connection-oriented service
 3.5 Private Virtual network

4.0 Security services
 4.1 Ability to implement session logging with signatures
 4.2 Documents/services based on ID
 4.3 Confidentiality
 4.4 Signatures for authentication and non-repudiation
 4.5 Encryption for privacy
 4.6 Transaction level and server-to-server level security and signature
 4.7 Assured delivery

5.0 Basic functions
 5.1 Send and receive data objects
 5.2 Ordered delivery of data objects
 5.3 Enumeration and then retrieval of specific items
 5.4 Server data object enumeration
 5.5 Nexting support for data objects
 5.6 Nexting support for enumerations (partial lists)
 5.7 Possible to enumerate services implemented
 5.8 Need to specify one-to-many messaging procedures, e.g. RFQ, product
     catalogs.
 5.9 GET functionality for EC -- robots browsing through vendor
     catalogues in search for the right products/prices is necessary
 5.10 Exchange of partial EDI transactions between servers
 5.11 Receiver establishes document priority
 5.12 Sorting the Mail

6.0 Acknowledgments and tracking
 6.1 Supports immediate response acknowledgment
 6.2 Possible to record and audit individual activities
 6.3 Negotiated possibility to send to server at startup
 6.4 Feedback from the initial message in the form of another
 6.5 Establish unique dialogue identifiers

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