Subject: Re: AS2, HL7,GISB, E5, others?

From: Gunther Schadow <[email-masked]>
Date: Wed, 24 Feb 1999 11:48:57 -0500 (EST)

Dave,

O.K. I agree that AS#2 should go out doing a minimalistic job. AS#2
should simply translate AS#1 for HTTP (for what it is worth :-). All
the extensions we are now talking about are applicable for both AS#2
and AS#1. Therefore it would be unfortunate if we even mentioned those
in AS#2 but not in AS#1. This would create the impression that those
extensions would be HTTP specific in any way, which they are not. 

So my vote is to steer AS#2 clear of any extensions above AS#1. As an
alternative we could work mentioning of the extensions in to AS#1 as
well. But that would open up a new round and delay everything. I would
really hope that AS#1 and REQ could be finally flushed down the drain
to RFCs. Then we can all take a deep breath and see what's next.

> [...] mentioned and the procedures, but indicate some specific areas
> (like those that Carl Hage suggested) in which extensions are to be
> expected and the types of extension mechanisms employed.

don't even do that in AS#2 since it would require doing the same in
AS#1 for consistency ...

> Then each particular group (health, gas, auto, ...) can write up its
> own Internet-Draft referencing its relation to the basic
> specifications and its extensions. For health, the hl7 draft has
> already done so I guess.

Yes. However, many of the additions that we made in the HL7 draft are
not at all healthcare specific or HL7 specific. So we should still
watch out for convergence between the different sector specific
EDI/MIME profiles. The big promise of EDIINT is that there will be
generic software equally and painlessly useful for X12, EDIFACT, GISB,
HL7, you name it.

> [...] But the specific semantic values used (like multipart/related
> type="edi-response") are ones that, I think, should go in the more
> specific Internet Drafts.

dito. General solutions to general problems should not remain in
sector-specific profiles.

> As a start on the list of mechanisms I have:

> 1. Embedding the EDIINT patterns within other MIME structures (as in
>    Carl's and Gunther's HTTP reply mechanisms.) Maybe some other
>    examples are needed for sending including the "application/formdata" in
>    multiparts also; I am still looking at the new v2 E5 website.

> 2. Adding new header parameter values (like "type=edi-response")
>    By the way, this can also be done for "application/edi-x12". You could
>    add, for example, version=4010 ; transactiontype="850";  TPsender=Dunsid;
>    TPreceiver=Dunsnumber

yes, yes! That's what I have tried to preach for years. And again,
here we also should make sure to generalize and not to be sector
specific in order to maximize leverage of the commercial
implementations.

>  3. Adding new content-types in place of the EDI types (for example,
>     "text/xml" and "application/xml" formdata, and so on.

I guess this exceeds our scope as EDI-Int. I guess what you really
want is to support different presentation syntaxes for EDI
standards. For instance, HL7 will define XML presenation of it's
messages. We are demonstrating XML messaging at HIMSS as we speak. The
right way to handle this is not by ``text/xml'' but by
``application/edi-hl7 syntax="xml";''

RFC 1847 is available for other groups. So, if some XML folks have
things to add, they would write their own REQ/AS#1. It's not our
business.

> 4. Using multipart/alternative when alternative mechanisms are
>    deployed (MDN vs the GISB response)

May be we can do a little use case analysis and come up with one
preferred way of doing things. I still have an open issue to revise
RFC 1767 to do secure transaction tracking (Content-Id, In-Reply-To).

> I would like to do this before the Minneapolis meeting so that we
> can wrap AS2 up.

so, will we convene again? I would hope that we can wrap up AS#2 as
is. Let's finally flush this stuff, it has been around in draft status
for long enough. All the extensions are AS1/AS2 independent ... I
repeat myself.

greetings
-Gunther

Gunther Schadow ----------------------------------- http://aurora.rg.iupui.edu
Regenstrief Institute for Health Care
1001 W 10th Street RG5, Indianapolis IN 46202, Phone: (317) 630 7960
[email-masked] ---------------------- #include <usual/disclaimer>

---

From: "Carl Hage" <[email-masked]>
Date: Wed, 24 Feb 1999 11:53:05 -0800

Date sent:      	Wed, 24 Feb 1999 11:48:57 -0500 (EST)
From:           	Gunther Schadow <[email-masked]>

> extensions would be HTTP specific in any way, which they are not. 

There are a couple of alternatives:
 - Make AS2 superceed AS1, combining SMTP and HTTP-based 
transfer in the same RFC.
 - Add AS3 which defines the semantics and usage of multiparts 
and conversional mode exchanges.

It may be sufficient to mention that this startard does not restrict 
the response to only an MDN, and other valid MIME wrappers are 
possible.

In any case, some mention of error recovery is important, 
particularly with HTTP.

-------------------

I can't really comment on GISB without a URL to the spec.

-------------------
From:           	"Gary Morin" <[email-masked]>

> Sorry if I stomp on in here but the Automobile Industry Action 
Group (AIAG) has
> a guideline for doing EDI over HTTP which is about one year old 
and which we
> refer to as E-5 ...  http://www.efive.com.

Note that the EDIINT EDI over HTTP does something completely 
different than standards that address data exchange/operation
using standardized HTTP &var=xxx query variables. Standardizing 
HTTP queries is a useful thing to do (particularly since it addresses
human-computer interaction), but that is not the realm of EDIINT.

The EDIINT spec addresses secure, reliable message exchange 
with non-repudiation, and has formats that work across gateways
and mixed transfer methods (SMTP+HTTP+NNTP...). Even though 
https uses certificates and signatures, no current HTTPS 
transaction has non-repudiation since the data exchanged is not 
signed. (Many people do not realize this.)

Though it would be possible to wrap HTTP-CGI queries (&var=...)
with MIME signatures, etc. is doesn't make much sense since the
purpose of HTTP queries is to work with HTML browsers. Using 
EDIINT MIME wrappers for XML data makes a lot more sense, e.g. 
a java applet which can form a message, sign, and transmit it.

The current E-5 spec seems to be standardized HTML/HTTP-CGi 
query parameters (a good thing), which doesn't apply to EDIINT. 
Your next generation XML-based standard could use the MIME 
wrappers as defined in EDIINT to package the XML. Rather than 
transmit just XML, you could obtain authentication, non-
repudiation, and audit capability by adding standard MIME 
wrappers.

The part I like about EDIINT (which is really just a 
repeat/explaination of other established MIME standards) is that 
message logs retain all the authentication/non-repudiation 
capability formatted with standard MIME wrappers. Thus any 
software that works with MIME works with EDIINT message logs.

> Gary Morin
> Co-Chair AIAG Message Routing Work Group

--------------------------------------------------------------------------
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: Dave Van Noord <[email-masked]>
Date: Wed, 24 Feb 1999 17:31:44 -0500

See Inline:

Carl Hage wrote:
.
.
.

> repudiation, and audit capability by adding standard MIME

I would be interested in see an example of how this could be done.  The
current V2.0 draft is using a single HTTP parameter to pass the XML
which does
define the parameters.  It uses a multi-part document to "attach" the
EDI (or
other) document.  The multi-part may not be necessary depending on the
status
of sending binary in XML.   We are also looking digitally signing the
documents sent with the XML headers.

> software that works with MIME works with EDIINT message logs.

...

Thanks, Dave

<mailto: [email-masked]>
Dave Van Noord
CMI-Competitive Solutions, Inc.