Subject: RE: Scope of ediint

From: Andrew Stickland <[email-masked]>
Date: Mon, 8 Nov 1999 09:07:04 -0000

Please don't take me wrong - as indicated in my e-mails, I know very
well what EDI is but there are a multitude out there who think that XML
etc. is not EDI and therefore EDI is dead. Having spent 3 days at the
eCommerce trade show last week, I can testify that I talked to at least
50 people who all had this misconception. We all know (I hope) that
EDIINT handles anything. I am simply concerned that this message is not
getting across to the business world and I don't think we can ignore the
problem.
Regards
Andrew Stickland

-----Original Message-----
From: Dick Brooks [mailto:[email-masked]]
Sent: Sunday, November 07, 1999 4:35 AM
To: Terry Harding; Andrew Stickland; 'Rik Drummond'; [email-masked]
Subject: RE: Scope of ediint

I agree with everything Terry said, with some clarification:

TH:  No, RFC 1767 does specify mime media types for standard EDI x12 and
EDIFACT
     documents

DB: RFC1767 also supports content-type:application/EDI-consent, which
allows
anybody to send
    anything. The end-points must be capable of interpreting the
proprietary
payloads.

TH: If a registered MIME type is not available for the
    type of media that you are sending (ex: xml),  products can use the
catch all MIME
    type of "application/octet-stream.

DB: There are MIME media types already defined for a large percentage of
the
commonly exchanged
    file types, including XML (text/xml and application/xml) so there is
no
need to use
    application/octet-stream in these cases. EDIINT AS2 is very specific
about how to package
    non-RFC1767 types. See EDIINT AS2 for details (search for MIME-TYPE
in
the document)
    http://www.ietf.org/internet-drafts/draft-ietf-ediint-as2-06.txt .

TH: EDIINT is non-transport specific, meaning any document packaged
under
    EDIINT can be sent to your TP using SMTP, HTTP, FTP or even MQ
Series.

DB: Technically Terry is correct, however if a trading partner were to
choose a protocol
    other than SMTP or HTTP (which have been defined by AS1 and AS2
respectively) the trading
    would have to make the necessary protocol adjustments to exchange
data.
For example,
    HTTP has no problem passsing binary data but SMTP cannot pass binary
data directly and
    requires all binary data to be encoded (base64 or uuencoded). FTP is
similar, the
    protocol engine must be "set" to transfer binary data (e.g. type
image)
before a
    transfer commences. Http doesn't support Content-transfer-encoding
mime
headers, where
    e-mail does.  In the case of MQ Series a translation to EBCDIC may
be
necessary (which is
    handled quite nicely by MQseries when you configure a channel), but
all
these issues must be
    "handled" by trading partners who choose to use transports which
have
not been defined
    in an EDIINT ASx specification.

TH: How is the business data packaged and how are acknowledgements
returned?
    All documents are packaged using the S/MIME standard for encryption,
    signatures, authentication etc.
    and the Message Disposition Notification specification is utilized
for
    acknowledgment receipts of data.

DB: Note that Terry is referring to Cyclones AS1 products with this
statement and not the
    EDIINT standard. The EDIINT AS1 and AS2 standards support BOTH
S/MIME
and PGP for
    cryptographic functions. Group 8760's EDIINT products support both
PGP
and S/MIME.

Dick Brooks
Group 8760
www.8760.com

-----Original Message-----
From: Terry Harding [mailto:[email-masked]]
Sent: Friday, November 05, 1999 3:24 PM
To: Dick Brooks; Andrew Stickland; 'Rik Drummond'; [email-masked]
Subject: Re: Scope of ediint

Lets try and clear up a few misconceptions.

What is EDIINT?
Electronic Data Interchange using the INTernet.
So if we look at the name, it indicates "electronic data being
interchanged
using the internet".

Can we send only EDI (X12, EDIFACT) documents?
No, RFC 1767 does specify mime media types for standard EDI x12 and
EDIFACT
documents, but
any registered MIME media type can be packaged according to EDIINT
specifications and sent
to your trading partners. If a registered MIME type is not available for
the
type of media that you are
sending (ex: xml),  products can use the catch all MIME type of
"application/octet-stream.

Application/octet-stream is the mime type that was used during the
interop
testing to send non-edi
documents, (ex: a Word file) to our testing TPs.

So EDIINT does not restrict the types of business data that can be
transferred between TPs.
EDIINT also does not dictate how these documents will be handled by your
TP - business rules.
EDIINT does however dictate the packaging format, encryption algorithms,
signature verification and
notification formats and procedures that a product must be implement to
be
EDIINT compliant.

Is EDIINT SMTP transport specific?
No, EDIINT is non-transport specific, meaning any document packaged
under
EDIINT can be sent
to your TP using SMTP, HTTP, FTP or even MQ Series.  The document AS1
does
indicate the
required protocol headers and notification procedures using SMTP, as AS2
specifies the required protocol
headers and notification procedures for http.  It is possible we may
also
see an AS3 document for ftp and
an AS4 document for MQ Series. Even thou all the documents talk about
data
transfer using different protocols, the underlying packaging of the
business
data remains the same.

Currently, interoperable EDIINT compliant products all use
SMTP.  Several of the vendors with EDIINT compliant products also
support
the other transports, but
no interoperability testing has yet occurred using the other transports.

How is the business data packaged and how are acknowledgements returned?
All documents are packaged using the S/MIME standard for encryption,
signatures, authentication etc.
and the Message Disposition Notification specification is utilized for
acknowledgment receipts of data.

Does S/MIME care what type of data is being packaged?
No.

Does EDIINT care what type of data is being packaged?
No.

Does an EDINT compliant product care what kind of data is being
packaged?
Possible,  EDIINT does not specify or control the business logic that a
vendor may
implement inside it's product.

I hope this sheds some light on the misconceptions of EDIINT.

Terry Harding
Cyclone Software
www.cyclonesoftware.com

---

From: "Terry Harding" <[email-masked]>
Date: Mon, 8 Nov 1999 07:38:59 -0700

> etc. is not EDI and therefore EDI is dead.

Andrew,

Any previous emails were for the benefit of those on the list, who may not
fully
understand the capabilities of EDIINT.

Terry Harding
Cyclone Software

---

From: "Carl Hage" <[email-masked]>
Date: Mon, 8 Nov 1999 16:33:08 -0800

From:           	Andrew Stickland <[email-masked]>

> ... but there are a multitude out there who think that XML

Another issue is that there are a number of efforts underway to address 
electronic filing, and other kinds of business transactions that fall 
outside X12/EDIFACT or for that matter, XML. For example there is a 
pilot project in the San Francisco area dealing with electronic building
permits. In this project, they are trying to figure out how to use digital
signatures and exchange information. Of course there are various 
companies trying to push proprietary ways to address these issues.

The IETF-EDI standard (AS1 but maybe not AS2) works well for
electronic filing and data exchange. One important aspect is that 
EDIINT is compatible with generic email software. Netscape 4 and 
above and IE 4 (or 5?) can create digitally signed email, which conform 
to the IETF and IETF-EDI standards.

For example, an architect could file for a building permit by pasting
a textual template of an application form into an email message,
attach CAD drawing files, enable a digital signature and send it to the 
city building inspection department. The city can issue an MDN receipt
completing the legal non-repudiation.

The email message is IETF compliant (other than the EDI mime type
which indicates X12 or whatever data), but more importantly, the
signed email and receipt has non-repudiation features which are not 
present in a SSL web-based form.
--------------------------------------------------------------------------
Carl Hage                                              C. Hage Associates
<mailto:[email-masked]> Voice/Fax: 1-408-244-8410      1180 Reed Ave #51
<http://www.chage.com/chage/>                          Sunnyvale, CA 94086

---

From: "Terry Harding" <[email-masked]>
Date: Mon, 8 Nov 1999 19:39:25 -0700

Carl,

Excellent point.

Using S/MIME compliant email applications to send encrypted/signed documents
to
EDIINT applications and receiving notification of their receipt is a side
benefit which is often overlooked.

We have clients who use this feature to allow their travelling staff to
securely send
documents back to the company.

Terry Harding
Cyclone Software