[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AS#2 Requirements
All of the detail, on what they mean was part of the "EDIINT- AS#2
Requirement Consolidation /Comments" message I sent out about 10 days ago.
The short list is just the titles. I have re-included the detail below.
Hope that helps.
These are not Lincoln's requirments, these are requirement the ediint list
discussed, just in a somewhat organized form. So we need some way to sort
them out and see what everyone thinks are the most important. If they
respond has we asked we should be able to tabulate their wishes and move to
the next phase, writing the requirments up.
Lincoln's requirements are mostly thoses of "Kent Schwab". They both work
for the same place. Kent's requirement are below also.
Later,...Rik
>Rik,
>most of the real requirement section is impossible to evaluate,
>because I have no idea what they are talking about.
>What does "2.4 Proprietary" under "Data content" mean?
>
>"No limitations" (2.1) is simply a meaningless statement; there
>are ALWAYS limits. "Assumes MIME" is a constraint on the solution,
>not a requirement (if I read this right).
>
>I think it would be better if Lincoln sat down and thought up a
>consistent set of requirements for what HE wanted to use EDI
>over an interactive protocol for, grouped nicely into "must have"
>and "can live without" categories for various application areas,
>and then used the "raw requirements" document to find out whether
>he had forgotten anything.
>
>But a requirements doc MUST have enough text that the requirements
>are possible to evaluate.
>
>When is the rewrite of the first requirements doc coming along?
>
> Harald A
*********************************************
Date: Mon, 04 Nov 1996 15:06:56 -0800
From: lincoln@actracorp.com (Lincoln Yarbrough)
Organization: Actra Business Systems
MIME-Version: 1.0
To: Rik Drummond <drummond@onramp.net>
Subject: AS#2 Reqs V1.0
Rik,
Here is the first draft. Please comment...
Regards,
Lincoln
DRAFT V1.0
AS#2 Requirements
1.0 General Requirement
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 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
============ Appendix A - Consolidated Raw Requirements ==========
REQUIREMENT: Point-to-point protocol that supports Traditional Batch
EDI.
NAME: Kent Schwab
DESCRIPTION:
"CLIENT" "SERVER"
Batch Batch
Application Application
| |
EDI Translation EDI Translation
| |
New Protocol New Protocol
| |
SSL, s-http, etc. SSL, s-http, etc.
| |
--------------------------------------
The applications at each end are batch-oriented. The sending application
does not require an immediate or real-time response. It only requires an
indication that the transmission was successful.
The traditional exchange of EDI messages using an EDI VAN usually
involves sending documents to the VAN, as well as retrieving documents
from the VAN. Typical direct connect exchanges between trading partners
are usually "send only."
So, this scenario involves sending documents as well as retrieving
documents.
REQUIREMENT: Point-to-point protocol that supports Proprietary
Transaction Processing, not just traditional EDI standards.
NAME: Kent Schwab
DESCRIPTION:
"CLIENT" "SERVER"
On-line On-line
Application Application
| |
New Protocol New Protocol
| |
SSL, s-http, etc. SSL, s-http, etc.
| |
--------------------------------------
First, corporations are implementing intranets as their corporate
networks. There is a need to link internal legacy applications over the
intranet with a conversational protocol that supports interactive
processing. Typically, the data format would not be public EDI
standards.
Second, a Web application, such as a consumer-oriented catalog and
ordering system, needs to talk to another Web application, perhaps to
perform a distribution system inquiry that will enable the catalog
ordering system to return shipping schedule information to the consumer
while the customer is still on-line.
REQUIREMENT: Point-to-point protocol that supports Enumeration and Then
Retrieval of Specific Items.
NAME: Kent Schwab
DESCRIPTION:
"CLIENT" "SERVER"
Application
| Mailbox
EDI Translator Application
| |
New Protocol New Protocol
| |
SSL, s-http, etc. SSL, s-http, etc.
| |
--------------------------------------
This involves a scenario where documents are available for retrieval in
a "mailbox" within a trading partner's environment. The mailbox could
also be located within a third party service.
The client asks the server for the list of documents that are available,
and then begins retrieving specific documents, perhaps in some
intelligent order other than first in, first out.
REQUIREMENT: Point-to-point protocol that supports Immediate Response
Acknowledgment.
NAME: Kent Schwab
DESCRIPTION:
"CLIENT" "SERVER"
Application Application
| |
EDI Translation EDI Translation
| |
New Protocol New Protocol
| |
SSL, s-http, etc. SSL, s-http, etc.
| |
--------------------------------------
In this case, an EDI document is sent, and the sender waits until an EDI
acknowledgment such as an X12 997 or 824 is returned from the server.
This is important for time-critical documents such as Ship Notices.
REQUIREMENT: Ordered Delivery of Data Objects.
NAME: Kent Schwab
DESCRIPTION: In the datagram model, one has no surety that the order of
send is equal to the order of receipt. This as an essential requirement,
since many trading communities have rules governing the order of
document processing. When one establishes a connection, one should be
assured of the processing order since the client and server have an
active dialog.
REQUIREMENT: Client Can Send and Receive Data Objects.
NAME: Kent Schwab
DESCRIPTION: This is during the same session. As long as some trading
partners require dial-up communications, it is necessary for the client
to be able to demand receipt. If one is a dial-up client, and it secures
a connection to a given server, it wants the ability to request receipt
of all data objects destined for it in the same session in which it
sends.
REQUIREMENT: Server Data Object Enumeration.
NAME: Kent Schwab
DESCRIPTION: In the context of a client application, this means the
requesting of the ordered list of some server service, such as:
o the client sends an enumeration request to the server,
specifying selection criteria
o the server enumerates its data objects to the client, based
on the criteria.
If the client said 'show me all documents from x to y with status z'
then the server would produce a[n ordered] list, with the document
keys, for all documents meeting the criteria.
REQUIREMENT: Nexting Support for Data Objects.
NAME: Kent Schwab
DESCRIPTION: Nexting is a by-product of enumeration. Nexting can be
accomplished by requesting enumeration (a list) of all unreceived data
objects from the server, and then 'Getting' each object by key. This
means that the client must cache the list results, parse, and request.
Nexting would reduce the processing and caching load on the client.
REQUIREMENT: Nexting Support for Enumerations(Partial Lists)
NAME: Kent Schwab
DESCRIPTION: When a client makes an enumeration request of a server, it
is possible that the resultant list will be greater than what the client
is capable of handling. This may be because the end target for the
enumeration/query is a browser screen; the client would like a 'chunk'
of list entries, with no more than a specified maximum. Likewise, an
application on the client side may not be capable of allocating enough
memory to handle an entire enumeration list results for processing. The
requirement is for the protocol to support specification of a 'max hits'
for enumeration requests, allowing the client to receive a partial list.
The protocol must then support requesting the subsequent x-items in the
list, and so on, until the list is exhausted.
REQUIREMENT: Connection-oriented Service with Strong Security
NAME: Kent Schwab
DESCRIPTION: As discussed in earlier requirements, the target protocol
is intended for connection-oriented transports ONLY; there should be no
forwarding or distribution concepts in the protocol. This is for
point-to-point communications, and is NOT intended for a datagram
(postoffice) model. As such, the protocol needs to ride on top of a
transport which can support non-repudiation of sender and receiver, and
which can perform hashed, signed and encrypted data movement.
REQUIREMENT: Possible to Record and Audit Individual Activities
NAME: Kent Schwab
DESRIPTION: Like most all protocols (HTTP, for example), the server
implementation must be capable of recording all transaction-level
activities.
REQUIREMENT: Possible to Enumerate Services Implemented
NAME: Kent Schwab
DESCRIPTION: Like SMTP and NNTP, the client must be able to request the
services which are supported on the server. A protocol command should be
able to be issued which causes the server to enumerate those services
which it is capable of supporting.
REQUIREMENT: Documents/Services based on User ID
NAME: Kent Schwab
DESRIPTION: This is an essential ingredient. The server is, by
definition, capable of supporting multiple trading relationships. As
such, it must enumerate only those data objects based on the certified
identity of the client. The client's id must control the domain of
information available for inspection or retrieval.
REQUIREMENT: Protocol NOT Limited to Specific Application Domain
NAME: Kent Schwab
DESCRIPTION: After investing in implementing a protocol which meets the
immediate needs of the EDI community, I would hope that we could look
beyond the current operational model, and do nothing which would
restrict the protocol's applicability to new application domains. I am
reminded explicitly of NNTP which has some nice concepts and services,
but which is tied very tightly in nomenclature of the protocol to
News Group management.
REQUIREMENT: Negotiated Possibility to Send to Server at Startup.
NAME: Kent Schwab
DESCRIPTION: This does not mean that the client can query server for
"setup info". It is more like the NNTP model, and the negotiation of
services under Odette FTP, and implying that knowledge by the client at
startup whether it is in a send/receive or receive-only session is very
helpful.
REQUIREMENT: Need to specify one-to-many messaging procedures, e.g. RFQ,
product catalogs.
NAME: David Chia
DESCRIPTION: using HTTP queries and retrieval. A standardized frontend
form for HTTP queries will be nice. It could be just a simple wrapper to
use the extensive INN+OVERVIEW pattern search capability from INN.
REQUIREMENT: GET functionality for EC -- robots browsing through vendor
catalogues in search for the right products/prices is necessary
NAME: David Chia
DESCRIPTION: A large buyer that already has their inhouse EDI resource
wants a faster way to source products from the many suppliers which also
already have inhouse EDI resources. A transparent way is for the buyer
to send a single request using EDI or whatever to a independent
electronic broker which as client polls the suppliers using EDI or
whatever regard cost, availability, transport, etc and sends the three
best offers back to the buyer. The electronic broker, through its
operation already has built up a cache of information regarding the
cost, availability, etc of various products, will be able to do the job
more efficiently by just polling those suppliers whose data in the cache
have aged too much. The broker will also be the natural place for the
suppliers to announce any special product offers instead of broadcasting
them to every potential buyers.
REQUIREMENT: Require transaction level and server-to-server level
security and signature
NAME: UNKNOWN
DESCRIPTION: The message signature verifies the owner of the EDI
message. SSL authenticates the client/server. There is no certainty that
the owner of the EDI message is the one operating the client or server.
For example, in EDI-L it was revealed that many companies and some
packages do not use sequence number. In such case a signed EDI PO can be
captured and resent to the supplier many times from any hosts. Without
low level secure channel the signed message can even be spoofed to be
coming from the alleged host. A low level authentication, such as SSL,
should not and cannot be used for a high level requirement such as
verifying whether the content is not a "resent." Even with SSL verifying
the source of the content, how do you prevent a resent? High level
requirements have to be addressed in high levels.
REQUIREMENT: Realtime EDI Exchanges Without Intermediary
NAME: Rik Drummond
DESCRIPTION: Message bases, store and forward -- with a third party
involved, is not necessary (gets in the way) in many realtime,
short-confirmation-response requirements. These are often seen in the
area of JIT as used by the auto industry. Web base Serves exchanging EDI
directly offers a solution to the above requirement.
REQUIREMENT: Feedback from the initial message in the form of another
message
NAME: Robert Richter
DESCRIPTION: Response Message must interrogate an internal database,
execute logic, extract info and immediately transmit a context-sensitive
response, such as: - what is the status of the order, part, shipment,
etc., in question? - is this prospective patient really an active
subscriber of your health plan, and, if so, what is the nature of
his/her coverage so we (the hospital/dentist/doctor/practitioner) can
plan/execute treatment (while there is still life left)? Issues are:
volume considerations - with scores of thousands of subscribers,
what happens when hundreds of them (or the subscriber's dependents)
simultaneously inquire w/ an original message to a large regional
healthcare support organization? is the solution one of throwing
mainframes and trunklines at the problem or is this a new and different
requirement?
REQUIREMENT: The web can be used for the immediate access to underlying
operational systems totally eliminating the need for store and forward
systems.
NAME: Wayne Seifried
DESCRIPTON: Comments from Nortel - Web/ EDI Requirements
This ubiquitous access opens the doors for all sorts of new transaction
sets. As such we have to be careful to identify our scope on this
exercise precisely. We either limit ourselves to the existing EDI
message sets or we try to create a general set of guidelines/protocols
which can be applied on any transaction whether an EDI message exists
today for it or not. We basically have multiple types of transactions
happening here on the web in an electronic commerce/service context: 1)
exchange of information only - pricing, product availability, order
status 2) initiation of a legal commercial transaction - placing an
order, issuing an invoice, issuing payment. 3) initiating a request for
a service of some sort - send literature, answering questions about the
product, etc. These transactions can be a) machine to machine...ie from
a buyers purchasing system through a web based edi to a sellers order
management system directly, b) human to machine...ie from a buyer person
through the web to a sellers order management system. c) human to
human...ie from a buyer person through the web to a sellers customer
service rep. Some of these transactions will require security / some may
not. The sensitivity of the information or commercial nature may require
different degrees of security. Standards are required for security...ie
encryption, digital signatures, authentication. Response time required
will have a bearing on the degree of security chosen. We also have to be
aware of the overlapping activities such as the SET protocol from Terisa
systems and Mastercard /Visa ..where they have already set some
standards on electronic commerce protocols and security. Do we want to
build on their protocols or set different ones up for business to
business transactions.
REQUIREMENT: Confidentiality
NAME: Rik Drummond
DESCRIPTION: Transmit between servers, and between servers and browsers
the information in a confidential manner.
REQUIREMENT: Exchange Signatures
NAME: Rik Drummond
DESCRIPTION: Sign the exchange so that we may identify uniquely the
source and destination at the User agent and server level.
ISSUE: Will the server to server exchange be mime based, so that what we
develop in AS#1 will be useable or will it be something else?
REQUIREMENT: Residual Signature
NAME: Rik Drummond
DESCRIPTION: Sign and leave signed the exchanged documents so that we
may verify later that they were sent and receive by the indicated
parties. This could be the same as the "Exchange Signature" if we are
exchanging mime documents, if not it may be different.
REQUIREMENT: Exchange of partial EDI transactions between servers
NAME: Rik Drummond
DESCRIPTION: Support the exchange of partial EDI transactions (not
entire PO at once, but parts exchanged through an interactive dialogue
to create the whole), segments, such as is the case those used in the
hotel and auto-rental areas for reservations.
REQUIREMENT: Standardization of Web-forms (cgi) to EDI Format
NAME: Rik Drummond
DESCRIPTION: We need to standardize the data format of the fill-in-forms
so that the data will easily be transferred back and forth between EDI
and web-based-forms.
REQUIREMENT: Establish Unique dialogue identifiers
NAME: Rik Drummond
DESCRIPTION: We need to establish unique dialogue identifiers, like
those on an email message so that we coordinate responses using these
unique identifiers.
REQUIREMENT: Receiver establishes document priority
NAME: Paula Olson
DESCRIPTION: The receiver of a document needs to establish priority. For
example, distinguish 852 point of sale data for a Vendor Managed
Inventory system from an FYI 852. Or, pick out the Ship Notice that
matches the truck waiting at the door (or the companies that are closest
to the shipping destination/warehouse). Or the truck with the promotion
stuff on it. Hot PO's, etc. I imagine there must be healthcare
applications. Identify a document to route to a dept/application without
interrogating the content. May want to determine the size of a document.
Right now most of what we send EDI is pretty important, but eventually
we will need to sort the mail.
REQUIREMENT: Sorting the Mail
NAME: Jeff Jennings
DESCRIPTION: I believe that this can be done with current mail
"toolkits". We are testing one VB toolkit that allows us to interrogate
the subject line of the mail message and retrieve it. Mail may be
retrieved from the POP Server without deleting Out implementation of
EDI messages over the internet employs use of the subject line to
indicate the type of message. This way we can grab all of the FA's and
retrieve them quickly for processing before retrieving the larger
messages that have X12 messages as attachments.
REQUIREMENTS: Point-to-Point
NAME: Javed Chaudry
DESCRIPTION: I think PPTP(Point to Point Tunneling Protocol) would be a
suitable choice for Transport Layer. This will automatically provide a
minimum level of encryption/security. Major software companies are
already working on developing this communications standard. Currently,
Microsoft supports this in Windows NT and Digital Equipment Corp. is
offering a number of tools to implement this technology. Related
acronyms: VPN (Virtual Private Network) I think SSL is a suitable
choice, but PPTP or any VPN protocol is not suitable for EDI TP-TP
boundaries. PPTP is designed for WANs, etc. which allow *all* kinds of
packet data, including hacking. This is really designed to provide a
bridge between two remote LANs. You don't want to bridge the LANs of two
TPs. SSL, in contrast is an encryption wrapper on a single socket
connection, i.e. a single application-application connection, not a
LAN-LAN connection.
REQUIREMENTS: Direct real time application-application transfer
NAME: Carl Hage
REQUIREMENTS: Built in error detection and retransmission of ordered
data (TCP)
NAME: Carl Hage
REQUIREMENTS: Encryption for privacy and assured delivery
NAME: Carl Hage
REQUIREMENTS: Signatures for authentication and non-repudiation
NAME: Carl Hage
REQUIREMENTS: Ability to implement session logging with signatures
NAME: Carl Hage
REQUIREMENT: Virtual Network
NAME: UNKNOWN
DESCRIPTION: PPTP, or maybe something closer to the IPSec spec (or S/WAN
from RSA) the IETF is working on, would be excellent choice to establish
a "VIRTUAL NETWORK of Trading Partners". SSL could be used within the
VPN for added security of specific transactions. With a VPN and IPSec we
will have the capability to establish secure networks within networks -
it will enable "GLOBAL INTRAnetworking of Trading Partners". The ability
to link desktops globally across company and country boundaries is a
powerful concept!! VPN/IPSec further enables the trend toward the
"VIRTUAL WORKPLACE" or the "VIRTUAL CORPORATION". Any technology that
contributes here will be of extreme importance and interest to many
enterprises all over the world.
REQUIREMENT:
An open, interoperable protocol which allows applications to exchange
standard EDI data or proprietary data over SSL in the following ways:
- simple sending,
- simple receiving,
- real-time, conversational, interactive, and query.
NAME: Kent Schwab
--
Lincoln Yarbrough Email: lincoln@actracorp.com
Actra Business Systems Tel#: 1.408.542.3261
610 Caribbean Drive Fax#: 1.408.542.3210
Sunnyvale, CA 94089
------------------------------------------------------
| Rik Drummond - The Drummond Group |
| 5008 Brentwood Ct., Ft. Worth, TX 76132 USA |
| Voice: 817 294 7339 Fax: 817 294 7950 |
------------------------------------------------------