Gunther Schadow | 2 Nov 17:12 2000

Re: EDIINT and HIPAA

Dick, 

I appreciate your warning. Please me (and others) understand ...

You say:
> AS2 contains two distinctly different  ways to package and send EDI
> and other data over HTTP:
> 
> 1. The HTTP standard approach,  ref: HTTP spec (www.ietf.org/rfc/rfc2616.txt),
> Multipart/form-data spec (www.ietf.org/rfc/rfc2388.txt formerly rfc 1867) and
> HTML 4.0 spec (http://www.w3.org/TR/REC-html40/)
> This is the approach used by GISB and the Automotive Industry (AIAG E5)
> 
> 2. E-mail based packaging as specified in EDIINT AS1
> (http://www.ietf.org/internet-drafts/draft-ietf-ediint-as1-11.txt ).

Hmm, my understanding is that, while AS#1 uses SMTP (which I still believe
is good ... but we had enough of that discussion :-), both AS#2 and the GISB
profile use HTTP. The difference may be the payload of the HTTP request.

Isn't it true that both AS#2 and GISB use the MIME security wrappers?

Isn't the only difference that AS#2 uses RFC1767 application/EDI-*
payload while GISB use multipart/form-data?

Since you use form data, does that mean that GISB's operational model
is that of a user interacting with a web-based e-commerce system
directly (i.e. filling out an HTML form?)

Most of X12, HL7, and NCPDP, certainly do not work with direct user
(Continue reading)

Dick Brooks | 2 Nov 19:26 2000

RE: EDIINT and HIPAA

Gunther,

In my travels I've realized there is a great deal of confusion regarding
AS2, your questions/comments are a great lead-in to help clear up some of
the misunderstandings. I apologize for sending such a long e-mail but I
think it is necessary at this point. I've provided my responses inline
bounded by <DB> </DB>, so here goes:

> -----Original Message-----
> From: Gunther Schadow [mailto:gunther <at> aurora.regenstrief.org]
> Sent: Thursday, November 02, 2000 10:13 AM
> To: Dick Brooks
> Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth Morrow;
> David <at> Drummondgroup. Com; GISB1 <at> aol.com; ietf-ediint <at> imc.org
> Subject: Re: EDIINT and HIPAA
>
>
> Dick,
>
> I appreciate your warning. Please me (and others) understand ...
>
> You say:
> > AS2 contains two distinctly different  ways to package and send EDI
> > and other data over HTTP:
> >
> > 1. The HTTP standard approach,  ref: HTTP spec
> (www.ietf.org/rfc/rfc2616.txt),
> > Multipart/form-data spec (www.ietf.org/rfc/rfc2388.txt formerly
> rfc 1867) and
> > HTML 4.0 spec (http://www.w3.org/TR/REC-html40/)
(Continue reading)

pbyrne | 2 Nov 20:36 2000

Re: EDIINT and HIPAA


Greetings from Pennsylvania.  For what it is worth, the regulated electric
utilities in PA exchange X12 EDI data with energy suppliers using the "old" GISB
method; i.e. X12 EDI transactions encrypted with PGP and transported via
batch-mode HTTP POST method.  The transaction volume averages in excess of one
million EDI transactions per month.

Many of the utilities have already declared their intention to migrate to
AS2-compliant GISB as soon as the software is commercially available.

The GISB method, whether "old" or AS2-compliant, is content neutral.  It will
transport data of any size, shape, color, or flavor, whether X12, HL7, or any
other.  In addition, it supports unattended, batch processing (which is how my
company uses it).

Hope this helps.

Pete Byrne
GPU Energy EC/EDI
and
Chair, Utility Industry Group

Gunther Schadow <gunther <at> aurora.regenstrief.org> on 11/02/2000 11:12:44 AM

                                                              

 To:      dick <at> 8760.com                                       

 cc:      Rik Drummond <rvd2 <at> worldnet.att.net>, Kepa Zubeldia 
          <Kepa.Zubeldia <at> claredi.com>, CLEM                   
(Continue reading)

Terry Harding | 2 Nov 22:51 2000

Re: EDIINT and HIPAA

Dick,

This may have been mentioned in your email, but i must ask.

You mentioned within your email, that AS2 supports two distinct types of
packaging,
a  GISB style and an AS1 style. EDIINT(AS1) also specifies two packaging
standards,
one based around S/MIME(RSA) and another around openPGP(PGP).

Will the gas industry support an AS2 compliant product which produces a GISB
style message using RSA security, or must the security layer be PGP as in
your example...

Terry Harding
Cyclone Commerce

----- Original Message -----
From: "Dick Brooks" <dick <at> 8760.com>
To: "Gunther Schadow" <gunther <at> aurora.regenstrief.org>
Cc: "Rik Drummond" <rvd2 <at> worldnet.att.net>; "Kepa Zubeldia"
<Kepa.Zubeldia <at> claredi.com>; "CLEM" <clem <at> regen.rg.iupui.edu>; "Gary Crough"
<gcrough <at> cyclonecommerce.com>; "Beth Morrow" <Beth <at> drummondgroup.com>;
"David <at> Drummondgroup. Com" <david <at> drummondgroup.com>; <GISB1 <at> aol.com>;
<ietf-ediint <at> imc.org>; "Dick Brooks" <dick <at> 8760.com>
Sent: Thursday, November 02, 2000 11:26 AM
Subject: RE: EDIINT and HIPAA

> Gunther,
>
(Continue reading)

Dick Brooks | 3 Nov 00:55 2000

RE: EDIINT and HIPAA

Terry, my answers are inline:

> This may have been mentioned in your email, but i must ask.
>
> You mentioned within your email, that AS2 supports two distinct types of
> packaging,
> a  GISB style and an AS1 style. EDIINT(AS1) also specifies two packaging
> standards,
> one based around S/MIME(RSA) and another around openPGP(PGP).
>
> Will the gas industry support an AS2 compliant product which
> produces a GISB
> style message using RSA security, or must the security layer be PGP as in
> your example...

GISB has been using PGP to encrypt and sign EDI data since 1997 so this will
remain their "crypto" standard. GISB REQUIRES the use of RSA public key
algorithms to process EDI data. RSA algorithms are supported in PGP.

The GISB/AS2 interoperability profile packages "PGP processed" data inside a
multipart/signed or multipart/encrypted MIME envelope, in accordance with
AS2 specifications. The entire multipart/* MIME envelope and encrypted data
is then placed inside a multipart/form-data package. Here is what the entire
package looks like when it's all put together (indention used to indicate
layering only):

Content-Type: multipart/form-data; boundary="foo"

  message headers are packaged here (To=XXX, From=YYY, etc.)

(Continue reading)

K.W. Chan | 3 Nov 01:57 2000
Picon

RE: EDIINT and HIPAA

Hi,

I am a new comer to this group. Can anyone kindly point to me some useful sources to study how XML influences the development of Internet EDI? In various places, I see mentioning that EDI is dead because of the proliferation of XML. I don't understand this. Conventional EDI requires translators to integrate with backend applications. XML will not do away with this, but will perhaps make it easier for organizations to write their own translators.

Is XML a hype or really a catalyst for next generation of EDI?

K. W.

-----Original Message-----
From: Dick Brooks [mailto:dick <at> 8760.com]
Sent: Friday, November 03, 2000 7:55 AM
To: Terry Harding; Gunther Schadow
Cc: Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth Morrow; David <at> Drummondgroup. Com; GISB1 <at> aol.com; ietf-ediint <at> imc.org

Subject: RE: EDIINT and HIPAA


Terry, my answers are inline:

> This may have been mentioned in your email, but i must ask.
>
> You mentioned within your email, that AS2 supports two distinct types of
> packaging,
> a  GISB style and an AS1 style. EDIINT(AS1) also specifies two packaging
> standards,
> one based around S/MIME(RSA) and another around openPGP(PGP).
>
> Will the gas industry support an AS2 compliant product which
> produces a GISB
> style message using RSA security, or must the security layer be PGP as in
> your example...

GISB has been using PGP to encrypt and sign EDI data since 1997 so this will
remain their "crypto" standard. GISB REQUIRES the use of RSA public key
algorithms to process EDI data. RSA algorithms are supported in PGP.

The GISB/AS2 interoperability profile packages "PGP processed" data inside a
multipart/signed or multipart/encrypted MIME envelope, in accordance with
AS2 specifications. The entire multipart/* MIME envelope and encrypted data
is then placed inside a multipart/form-data package. Here is what the entire
package looks like when it's all put together (indention used to indicate
layering only):

Content-Type: multipart/form-data; boundary="foo"

  message headers are packaged here (To=XXX, From=YYY, etc.)

  Content-Type: multipart/encrypted; boundary="foo2";
  protocol="application/pgp-encrypted"

     Content-Type: application/pgp-encrypted

     Content-Type: application/octet-stream

         Content-Type: application/EDI-X12 (signed/encrypted using PGP)

                ISA*.....X12 data              (signed/encrypted using PGP)

With regard to an earlier reference to the AS1 packaging style within AS2; I
believe the new AS2-To and AS2-From header fields are incompatible with AS1
so we might want to refer to this "new packaging style" as the AS2/email
packaging style in the next version of the AS2 spec and remove references to
AS1. Would you agree?

Regards,

Dick Brooks
Group 8760
110 12th Street North
Birmingham, AL 35203
dick <at> 8760.com
205-250-8053
Fax: 205-250-8057
http://www.8760.com/

InsideAgent - Empowering e-commerce solutions

ned.freed | 3 Nov 08:20 2000

AD review of EDIINT documents (was RE: Status and Future of EDIINT)

> well it is not dead. the spec is in the loop for rfc approval... and we now
> have 12 vendors supporting as1 and 9 supporting as2. these are all
> interoperable. if we don't get something back from the ietf shortly it might
> be wise to go the ansi route... rik

Well, as it happens I've been working on the AD review of these documents. I
just completed that review today. I've attached my review comments below.

Sorry it took so long.

				Ned

------

AD review of draft-ietf-ediint-req-08.txt:

I started to write a bunch of comments on this document, but then decided
against it. The basic problem is that due to the substantial amount of time
that has passed since this text was written (through no fault of the authors or
the WG, I hasten to add), quite a bit of it seems dated. For example, a
discussion of the use of VPNs in contrast to VANs would seem appropriate. Some
of the symmetric cipher discussion is likely dated as well. But given that it
is informational I see little harm in publishing it as-is. Note that it may end
up with an IESG note pointing out the timing issue, however.

AD review of draft-ietf-ediint-as1-11.txt:

This is where the issues are. Some are very minor, but a couple must
be addressed.

Security considerations section. The word "Technologies" is
capitalized when it should not be.

The security considerations section is normally at the end of the
document. It also should cover actual considerations rather than
restating what the document is about.

1.0 Introduction, first paragraph. The impression is given here
that this is purely an Applicability Statement. However, the
very next paragraph then indicates otherwise. I suggest that
this be clarified by referring to "the bulk of this document
is an Applicability Statement", or something similar.

1.0 Introduction, second paragraph. There's a reference to section
3.1.8, which does not exist in the current document. I believe this
is supposed to be 5.3.1.

1.0 Introduction, third paragraph. "Used" -> "used".

2.1. Reference to "standard" is premature. I suggest saying
"document" instead.

2.2.2, first paragraph. "The functional requirements document, [9]
"Requirements for Inter-operable Internet EDI" (can be found at
www.ietf.org)," needs to be rewritten as a reference to an RFC-to-be.

2.2.2, first paragraph, "Provides" -> "provides".

2.2.2, second paragraph. Use of the term "transport" here is
confusing. I suggest "environment" or something similar
instead.

2.2.2, last paragraph. "Satisfy" -> "satisfy".

2.2.3, first bullet item. This section doesn't identify RFC 2298 as
the mechanism being used to request EDI receipts. Suggest making it
clear here rather than having to get further into the document to find
out.

2.3.2, fourth bullet item. Now that PGP itself is an IETF standard,
should reference RFC 2440 as well as RFC 2015 here and elsewhere in
the document.

2.3.2, fourth bullet item. REQUIRES is not a keyword on the 2119 list;
suggest rewording to use REQUIRED instead.

5.4.1, first paragraph. The phrase

   Using message, "partial",

should be

   Using message/partial

5.4.1, second paragraph. The phrase "so that if fragmentation does occur,"
isn't right in this context. I suggest "so that if fragmentation is needed"
instead.

5.4.1. Recommending that partial be used but saying that support for it
is optional could lead to interoperability issues. I suggest that you
add that in the absence of knowledge that the recipient supports partial
it SHOULD NOT be used.

5.4.1, last paragraph. This is the biggie. Saying it is OK to use
content-encoding in email even as an option just isn't acceptable. The
problem is one of interoperability: An unextended agent that receives
a message with, say, a content-encoding of gzip won't recognize the
field for what it is and will cheerfully decode the base64 expecting to
find text or whatever. Instead it will find garbage.

Unfortunately, the only way to add compression to email in a backwards
compatible way is to define new content-transfer-encodings. If this is a
real issue this is the mechanism that needs to be pursued.

Note that it is fine to recommend use of content-encoding if the
transport is HTTP. Content-encoding is well-defined there and agents
are required to check for it and handle it.

Finally, this document defines new disposition-notification-options
and a new MDN field received-content-mic. Both of these things
require IANA registration. It is customary in standards track documents
to do this with an appendix containing the appropriate registration
forms. This needs to be done per sections 10.2 and 10.3 of RFC 2298.

That's it!

Rik Drummond | 3 Nov 11:55 2000
Picon
Picon

RE: AD review of EDIINT documents (was RE: Status and Future of EDIINT)

thanks, ned. we will get the changes in asap.  bty the as2 document does not
show it is being worked. i looked at all the minutes of over the last year
and did not see it mentioned at all since january... best regards, rik

-----Original Message-----
From: ned.freed <at> innosoft.com [mailto:ned.freed <at> innosoft.com]
Sent: Friday, November 03, 2000 1:20 AM
To: Rik Drummond
Cc: ietf-ediint <at> imc.org
Subject: AD review of EDIINT documents (was RE: Status and Future of
EDIINT)

> well it is not dead. the spec is in the loop for rfc approval... and we
now
> have 12 vendors supporting as1 and 9 supporting as2. these are all
> interoperable. if we don't get something back from the ietf shortly it
might
> be wise to go the ansi route... rik

Well, as it happens I've been working on the AD review of these documents. I
just completed that review today. I've attached my review comments below.

Sorry it took so long.

				Ned

------

AD review of draft-ietf-ediint-req-08.txt:

I started to write a bunch of comments on this document, but then decided
against it. The basic problem is that due to the substantial amount of time
that has passed since this text was written (through no fault of the authors
or
the WG, I hasten to add), quite a bit of it seems dated. For example, a
discussion of the use of VPNs in contrast to VANs would seem appropriate.
Some
of the symmetric cipher discussion is likely dated as well. But given that
it
is informational I see little harm in publishing it as-is. Note that it may
end
up with an IESG note pointing out the timing issue, however.

AD review of draft-ietf-ediint-as1-11.txt:

This is where the issues are. Some are very minor, but a couple must
be addressed.

Security considerations section. The word "Technologies" is
capitalized when it should not be.

The security considerations section is normally at the end of the
document. It also should cover actual considerations rather than
restating what the document is about.

1.0 Introduction, first paragraph. The impression is given here
that this is purely an Applicability Statement. However, the
very next paragraph then indicates otherwise. I suggest that
this be clarified by referring to "the bulk of this document
is an Applicability Statement", or something similar.

1.0 Introduction, second paragraph. There's a reference to section
3.1.8, which does not exist in the current document. I believe this
is supposed to be 5.3.1.

1.0 Introduction, third paragraph. "Used" -> "used".

2.1. Reference to "standard" is premature. I suggest saying
"document" instead.

2.2.2, first paragraph. "The functional requirements document, [9]
"Requirements for Inter-operable Internet EDI" (can be found at
www.ietf.org)," needs to be rewritten as a reference to an RFC-to-be.

2.2.2, first paragraph, "Provides" -> "provides".

2.2.2, second paragraph. Use of the term "transport" here is
confusing. I suggest "environment" or something similar
instead.

2.2.2, last paragraph. "Satisfy" -> "satisfy".

2.2.3, first bullet item. This section doesn't identify RFC 2298 as
the mechanism being used to request EDI receipts. Suggest making it
clear here rather than having to get further into the document to find
out.

2.3.2, fourth bullet item. Now that PGP itself is an IETF standard,
should reference RFC 2440 as well as RFC 2015 here and elsewhere in
the document.

2.3.2, fourth bullet item. REQUIRES is not a keyword on the 2119 list;
suggest rewording to use REQUIRED instead.

5.4.1, first paragraph. The phrase

   Using message, "partial",

should be

   Using message/partial

5.4.1, second paragraph. The phrase "so that if fragmentation does occur,"
isn't right in this context. I suggest "so that if fragmentation is needed"
instead.

5.4.1. Recommending that partial be used but saying that support for it
is optional could lead to interoperability issues. I suggest that you
add that in the absence of knowledge that the recipient supports partial
it SHOULD NOT be used.

5.4.1, last paragraph. This is the biggie. Saying it is OK to use
content-encoding in email even as an option just isn't acceptable. The
problem is one of interoperability: An unextended agent that receives
a message with, say, a content-encoding of gzip won't recognize the
field for what it is and will cheerfully decode the base64 expecting to
find text or whatever. Instead it will find garbage.

Unfortunately, the only way to add compression to email in a backwards
compatible way is to define new content-transfer-encodings. If this is a
real issue this is the mechanism that needs to be pursued.

Note that it is fine to recommend use of content-encoding if the
transport is HTTP. Content-encoding is well-defined there and agents
are required to check for it and handle it.

Finally, this document defines new disposition-notification-options
and a new MDN field received-content-mic. Both of these things
require IANA registration. It is customary in standards track documents
to do this with an appendix containing the appropriate registration
forms. This needs to be done per sections 10.2 and 10.3 of RFC 2298.

That's it!

Rik Drummond | 3 Nov 11:55 2000
Picon
Picon

RE: EDIINT and HIPAA

bty, we are in the final edit phase of making as1 an rfc. after this goes
through, as2 (which is based on as1) is next.... thanks for the note pete!
best regards, rik

-----Original Message-----
From: pbyrne <at> gpu.com [mailto:pbyrne <at> gpu.com]
Sent: Thursday, November 02, 2000 1:36 PM
To: Gunther Schadow
Cc: dick <at> 8760.com; Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth
Morrow; David <at> Drummondgroup. Com; GISB1 <at> aol.com; ietf-ediint <at> imc.org
Subject: Re: EDIINT and HIPAA

Greetings from Pennsylvania.  For what it is worth, the regulated electric
utilities in PA exchange X12 EDI data with energy suppliers using the "old"
GISB
method; i.e. X12 EDI transactions encrypted with PGP and transported via
batch-mode HTTP POST method.  The transaction volume averages in excess of
one
million EDI transactions per month.

Many of the utilities have already declared their intention to migrate to
AS2-compliant GISB as soon as the software is commercially available.

The GISB method, whether "old" or AS2-compliant, is content neutral.  It
will
transport data of any size, shape, color, or flavor, whether X12, HL7, or
any
other.  In addition, it supports unattended, batch processing (which is how
my
company uses it).

Hope this helps.

Pete Byrne
GPU Energy EC/EDI
and
Chair, Utility Industry Group

Gunther Schadow <gunther <at> aurora.regenstrief.org> on 11/02/2000 11:12:44 AM

 To:      dick <at> 8760.com

 cc:      Rik Drummond <rvd2 <at> worldnet.att.net>, Kepa Zubeldia
          <Kepa.Zubeldia <at> claredi.com>, CLEM
          <clem <at> regen.rg.iupui.edu>, Gary Crough
          <gcrough <at> cyclonecommerce.com>, Beth Morrow
          <Beth <at> drummondgroup.com>, "David <at> Drummondgroup.
          Com" <david <at> drummondgroup.com>, GISB1 <at> aol.com,
          ietf-ediint <at> imc.org(bcc: Pete Byrne)

 Subject: Re: EDIINT and HIPAA

Dick,

I appreciate your warning. Please me (and others) understand ...

<snip>

regards
-Gunther

dick | 3 Nov 14:58 2000

Re: EDIINT and HIPAA

Rik,

I agree, the original AS2 spec was based on AS1, but there were problems
discovered during AS2 interoperability testing (using RFC 822 (email) style
packaging)  related to "To" and "From" headers, which resulted in the creation
of two new headers specific to AS2, "AS2-To" and "AS2-From".  We (as the authors
of AS2) will have to provide details of  these new routing headers and cannot
depend entirely on AS1, as we had originally.

AS1 and AS2 (using RFC 822 (email) packaging) will be VERY similar, but not
exactly alike. I believe AS2 will have to stand on its own through the IESG
review process and we'll have to provide "complete"  technical specifications in
AS2 to satisfy IESG requirements.

Ned, am I correct in this postulation?

Regards,

Dick Brooks
http://www.8760.com/

----- Original Message -----
From: Rik Drummond <rvd2 <at> worldnet.att.net>
To: <pbyrne <at> gpu.com>; Gunther Schadow <gunther <at> aurora.regenstrief.org>
Cc: Dick Brooks <dick <at> 8760.com>; Kepa Zubeldia <Kepa.Zubeldia <at> claredi.com>; CLEM
<clem <at> regen.rg.iupui.edu>; Gary Crough <gcrough <at> cyclonecommerce.com>; Beth
Morrow <Beth <at> drummondgroup.com>; David <at> Drummondgroup. Com
<david <at> drummondgroup.com>; <GISB1 <at> aol.com>; <ietf-ediint <at> imc.org>
Sent: Friday, November 03, 2000 4:55 AM
Subject: RE: EDIINT and HIPAA

> bty, we are in the final edit phase of making as1 an rfc. after this goes
> through, as2 (which is based on as1) is next.... thanks for the note pete!
> best regards, rik
>
> -----Original Message-----
> From: pbyrne <at> gpu.com [mailto:pbyrne <at> gpu.com]
> Sent: Thursday, November 02, 2000 1:36 PM
> To: Gunther Schadow
> Cc: dick <at> 8760.com; Rik Drummond; Kepa Zubeldia; CLEM; Gary Crough; Beth
> Morrow; David <at> Drummondgroup. Com; GISB1 <at> aol.com; ietf-ediint <at> imc.org
> Subject: Re: EDIINT and HIPAA
>
>
>
>
> Greetings from Pennsylvania.  For what it is worth, the regulated electric
> utilities in PA exchange X12 EDI data with energy suppliers using the "old"
> GISB
> method; i.e. X12 EDI transactions encrypted with PGP and transported via
> batch-mode HTTP POST method.  The transaction volume averages in excess of
> one
> million EDI transactions per month.
>
> Many of the utilities have already declared their intention to migrate to
> AS2-compliant GISB as soon as the software is commercially available.
>
> The GISB method, whether "old" or AS2-compliant, is content neutral.  It
> will
> transport data of any size, shape, color, or flavor, whether X12, HL7, or
> any
> other.  In addition, it supports unattended, batch processing (which is how
> my
> company uses it).
>
> Hope this helps.
>
> Pete Byrne
> GPU Energy EC/EDI
> and
> Chair, Utility Industry Group
>
>
>
>
>
>
> Gunther Schadow <gunther <at> aurora.regenstrief.org> on 11/02/2000 11:12:44 AM
>
>
>
>  To:      dick <at> 8760.com
>
>  cc:      Rik Drummond <rvd2 <at> worldnet.att.net>, Kepa Zubeldia
>           <Kepa.Zubeldia <at> claredi.com>, CLEM
>           <clem <at> regen.rg.iupui.edu>, Gary Crough
>           <gcrough <at> cyclonecommerce.com>, Beth Morrow
>           <Beth <at> drummondgroup.com>, "David <at> Drummondgroup.
>           Com" <david <at> drummondgroup.com>, GISB1 <at> aol.com,
>           ietf-ediint <at> imc.org(bcc: Pete Byrne)
>
>
>
>  Subject: Re: EDIINT and HIPAA
>
>
>
>
>
>
>
>
> Dick,
>
> I appreciate your warning. Please me (and others) understand ...
>
> <snip>
>
> regards
> -Gunther
>
>
>
>
>


Gmane