[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
EDIINT Status / Vision ?Charter
Several of the message over the last two weeks or so have brought to my
attention that it is time to review our charter, what we have done so far
and anticipate the next phase of our project.
(Raised voice for emphasis -- not yelling! )
PLEASE TAKE THE TIME TO READ THIS THOROUGHTLY, IF WE AGREE WE ARE ALL ON
THE SAME TRACK.
IF NOT AGREE WE WILL NEED TO STOP AND ADDRESS DIRECTIONAL/PROCESS ISSUES.
***********************************************************
********************************
*** Contents of this message ***
********************************
- Original EDIINT Charter Statement
- Requirement List
- Required Decision Description
- Decision Status
- Summary
**********************************
*** Original Charter Statement ***
**********************************
-------------------------------------------------------------
Electronic Data Interchange - Internet Integration (EDIINT) Charter
-------------------------------------------------------------
------------------------------------------
Description of Working Group:
------------------------------------------
Electronic Data Interchange (EDI) is a set of protocols for conducting
highly structured inter-organization exchanges, such as for making
purchases or initiating loan requests. The initial RFC1767 defined the
method for packaging the EDI X12 and UN/EDIFACT transactions sets in a MIME
envelope. However, several additional requirements for obtaining
multi-vendor, inter-operable service, over and above how the EDI
transactions are packaged, have come to light since the effort concluded.
These currently revolve around security issues such as EDI transaction
integrity, privacy and non-repudiation in various forms. Standards in
these and other areas are necessary to ensure inter-operability between EDI
packages over Internet. Various technologies already exist for these
additional features and the primary requirement is to review and select a
common set of components for use by the EDI community when it sends EDI
over the Internet. In effect, the effort is to provide an EDI over the
Internet Requirements Document.
Efforts by the working group will focus on a single deliverable:
-------------------------------------------------------------
Define the use of security and associated processes for exchanging EDI
transactions in MIME in a manner which supports core, functional, transport
services requirements.
Goals and Milestones:
---------------------
March 1996 - Submit Internet-draft outline for requirements document
(This is IETF04.DOC / IETF04.TXT)
July 1996 - Submit Internet-draft for requirements document.
October 1996 - Submit requirements document for proposed standard.
************************
*** Requirement List ***
************************
We spent four or five weeks brainstorming requirements that must be
addressed to facilitate EDI over Internet. Below is the list in the
priority you chose.
These areas are now the major sections of the outline/draft,
IETF04.DOC/IETF04.TXT, which is currently out for your review.
The draft is no where near finished. Five decisions must be made to finish
the draft. Let me categorize the decisions that need to be made to solve
the list below - the list of requirements you identified earlier.
1 - Standard Encryption Scheme (1)
2 - Non-Repudiation Of Receipt (4)
3 - Transaction Privacy (1)
4 - Content Integrity (1)
5 - Authentication (1)
6 - Acknowledgments/Delivery Notification (4)
7 - Detection Of Missing, Duplicate And ...... (5)
8 - Worldwide Encryption (1)
9 - Non-Repudiation Of Origin (1)
10 - Key Management (2)
11 - Edi Object Boundaries (3)
***********************************
** Required Decision Description **
***********************************
* Those marked with the (1) are all solved when we pick one MOSS, S/MIME or
PGP/MIME as or primary (the choice does not preclude others in the future)
encryption scheme.
* Those marked with (2) are solved when we pick the CA (Certificate
authority) methodology. A short term one is suggested in IETF04.DOC that
is very workable.
* Those marked with the (3) are issues which do not match our charter of
staying at the MIME transport level.
* Those marked with (4) Non-repudiation of receipt and delivery are not
covered in MOSS, S/MIME or PGP/MIME. They must be address separately.
However, I believe this will be solved with a standard MIME envelope and
not one specific to EDI. A new IETF workgroup is working the isssue. I
have contacted Ned Freed the lead.
* Those marked with (5) are not covered in MOSS, S/MIME or PGP/MIME. These
issues are separate from the 1, 2, 3, and 4 above -- the solution is still
a generic MIME type solution -- that we must solve for our proposed RFC to
be complete.
**********************
** Decision Status **
**********************
- Decision (1) - Selecting MOSS, S/MIME, and PGP/MIME will require
comparing the functionality of these three. Mats, Chuch and I will work on
this one. Others are invited.
- Decision (2) - I believe the suggestion made in the IETF04 paper is the
one we wish to go with.
- Decision (3) - Is not part of this charter
- Decision (4) - Receipts and Delivery notices. These must be covered and
are not currently in the area of decision (1). Who would like to drive the
search for a resolution on this one?
- Decision (5) - This is a separate effort from decision (1) also which
Chuck, Mats and I will work on. Others are invited
*****************
** Summary **
*****************
In summary, our objective is recommend standards which support
Interoperability ASAP, The assumption is that we recommend and incorporate
existing standards and efforts when ever possible.
We developed requirement, prioritized them, captured the issues in the
IETF04 working paper that is out for your review. We believe only five
decision areas need to resolved before we complete this paper and get it
out for wider review. They are all listed above.
I hope we are focused in the same direction. If not please let me know.
(Lets not change or add to the existing process if you can live with it
as-is -- changes may cause us to miss our target delivery dates.) Currently
five people are working the issues: Chuck Shih, Mats Jannson, Rik Drummond,
Linclon Yarbrough and Dave Darnell. Others are welcome.
A final point: If we solve this with MIME we solve the issue in a transport
independent way which means email, ftp and http type protocols could use
the same mechanism for transporting EDI.
Enjoy working with each of you on this.
Later....
Rik
------------------------------------------------------
| Rik Drummond - The Drummond Group |
| 5008 Bentwood Ct., Ft. Worth, TX 76132 USA |
| Voice: 817 294 7339 Fax: 817 294 7950 |
------------------------------------------------------