Subject: RE: Scope of ediint

From: Andrew Stickland <[email-masked]>
Date: Fri, 5 Nov 1999 14:52:15 -0000

Rick,
I concur with your statement that RFC 1767 deals purely with EDI objects
but this simply begs the question as to what is an EDI object. EDI means
Electronic Data Interchange and as such encompasses any data that is
exchanged electronically. Unfortunately, many people have come to
believe that EDI simply refers to the EDIFACT, ANSI-X12 etc. formats. As
a company with a long history of EDI, we have always used to term
to include what most believe to be EDI formats i.e. AECOM; AIRIMP;
AMEDIS; ANSI ASC X12; CARGOIMP; EDIFACT (including EANCOM); GALIA;
GENCOD; IATA; ICOM; ODETTE (both UN/ECE GTDI & EDIFACT Syntaxes); SEDAS;
SPEC 200A; SPEC2000 (C&G); SPEC2000M; TRADACOMS; TDCC (including UCS,
WINS, RAIL, VICS, OCEAN) and VDA.
This is by no means a complete list and faced with the need to send most
of these using RFC1767, we would be forced to used a content type of
application/EDI-CONSENT (which is not a problem). Since XML is just
another format for exchanging data albeit a powerful one, our intention
would be to place it under the same banner. 
My point is the concern that since the term EDI has been incorrectly
associated with everything that is bad, old fashioned etc. the EDIINT
project could get swept under the carpet as 'dead' when it should be
recognised as encompassing XML etc. I have just spent 3 days at an
eCommerce trade show at which several people were surprised to see us
and actually said that they thought we would not be around for much
longer. Putting them straight on the fact that we have expanded our
product to support XML changed their minds somewhat. Pointing out that
XML was simply a variant of SGML which has been around for over 10 years
and is therefore nothing new opened a few eyes as well. 
I realise that this is maybe not the proper forum for such a speech and
I apologise for getting on my soapbox but I am making similar statements
in other related forums as often as possible.
Finally, I would raise the question as to whether RFC1767 should be
revisited and expanded.
Regards
Andrew
 
-----Original Message-----
From: Rik Drummond [mailto:[email-masked]]
Sent: Friday, November 05, 1999 1:20 PM
To: Andrew Paterson; [email-masked]
Subject: RE: Scope of ediint

Everything is generic in the ediint spec, except the internal mime
object is rfc 1767 which is the edi mime object.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Andrew Paterson
Sent: Friday, November 05, 1999 6:26 AM
To: [email-masked]
Subject: Scope of ediint

In a message entitled "RE: EDI and Message Disposition Notifications",
Andrew Stickland wrote: 

> Much press is being made about EDI being dead! Or position is that 
> Electronic Data Interchange encompases all business to business 
> comminications which do not involve human intervention. Whilst XML may

> in time see the end of traditional EDI (i.e. EDIFACT, ANSI etc.), XML 
> is simply another structured method for communicating data between 
> businesses. 

This raises a question that I am sure must have been asked before but I
will ask again anyway: can the ediint framework be used for exchanging
business data other than "traditional" EDI (EDIFACT, X12 etc.)? What do
I need to do, if anything, to use the ediint framework for edi in
general rather than just EDI?

Ok, that is two questions but they are essentially asking the same
thing! 

TIA. 

Regards, 
Andrew Paterson 
[email-masked] 
All opinions are strictly my own (not that anyone else would take credit
for them anyway!) 

The information contained in this eMail message is intended for the
named recipients only.  It may contain privileged and/or confidential
information and if you are not the addressee or the person responsible
for delivering this to the addressee, you may not copy, distribute or
take action in reliance on it.  If you have received this message in
error, please notify us immediately by a reversed charge telephone call
to +44 (0)161 929-8673.  Any personal views and opinions expressed in
this eMail message are the sender's own and do not necessarily represent
the views and opinions of Burns.

---

From: "Dick Brooks" <[email-masked]>
Date: Fri, 5 Nov 1999 11:05:57 -0800

Within the context of RFC1767, it's quite possible for "consenting TP's" to
use a proprietary exchange format and label it as
Content-type:application/EDI-consent (thanks to Mike O'dell).

Additionally, within EDIINT AS2 it states:

    "In addition to the enveloping and MIME media type options defined in
    sections 4.2.x and 4.3.x of "MIME-based Secure EDI" [AS1], this
    specification enables the transport of payload objects containing other
    MIME media types. A listing of registered MIME media types is available
from
    the Internet Assigned Numbers Authority (IANA) at:
    http://www.isi.edu/in-notes/iana/assignments/media-types/media-types
    [MIME-TYPES].

    Implementors are to follow the appropriate specifications identified
under
    "References" in [MIME-TYPES], for the type of object being transmitted.
For
    example, to send an XML object, the MIME media type of text/xml is used
in
    the Content-type MIME header and the specifications for enveloping the
    object are contained in RFC2376, (e.g.  Content-type:   text/xml;
    charset="utf-8"). "

REF: http://www.ietf.org/internet-drafts/draft-ietf-ediint-as2-06.txt

Dick Brooks
www.8760.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Andrew Stickland
Sent: Friday, November 05, 1999 6:52 AM
To: 'Rik Drummond'; [email-masked]
Subject: RE: Scope of ediint

Rick,

-----Original Message-----

TIA.

Regards,
Andrew Paterson

---

From: "Terry Harding" <[email-masked]>
Date: Fri, 5 Nov 1999 16:24:07 -0700

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: "Dick Brooks" <[email-masked]>
Date: Sat, 6 Nov 1999 20:34:53 -0800

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?

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

What is EDIINT?

Terry Harding
Cyclone Software
www.cyclonesoftware.com