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

From: Dick Brooks <[email-masked]>
Date: Wed, 24 Feb 1999 11:54:40 -0600 (CST)

Dale, I agree with your position that the AS2 document should remain 
minimalistic in its requirements. This is the same position taken with RFC 1767.
In keeping with this minimalistic approach it would benefit the community at 
large to incorporate as much of the existing HTTP capabilities/flexibility as 
possible.  For example, AS2 could explicitly adopt use of text/html as a valid 
content-type in the outermost header. This would accommodate those parties
interested in deploying interactive e-commerce (AIAG, GISB, ATIS) using the 
EDIINT standard.

I sense a deep desire to keep AS2 in sync with AS1 as much as possible, and
I believe this would have certain benefits. But I believe it is equally
important that the hundreds of existing de facto HTTP implementations also 
be given serious consideration in the development of AS2. 
That's not to say we don't follow the precendence set by Gunther,
using separate documents representing "profiles" of EDIINT implementations
to accommodate GISB, AIAG, ATIS (the Telecomm Industry group), etc.
But to do so requires changes to the current AS2 document to explicitly support 
packaging using HTTP specific content-types, non-MDN structures, use of
authentication schemes (basic auth), that are not currently supported 
in AS1.

Dick

---

From: "John Tsucalas" <[email-masked]>
Date: Wed, 24 Feb 1999 13:30:36 -0600

All,

I have been following some recent activities of this group, but have not
been adding much to the discussion. Sorry if I don't have the jargon or
process 'down pat'.

I have been participating in the GISB definition process since the
inception. The 'GISB' standard for EDI transmission (known as GISB EDM/EDI)
has been in use across our industry for several years, and as has been mentioned
here, has influenced several other industry standards.  Additionally, we have
seen
segments of other industries adopt our standard, verbatim.

HOWEVER, many of us would like to see a more globally accepted specification
for performing these functions in the future.  This means that we would like to
see a
fusion of best practices result in a single workable specification rather than a
collection of documents that would embody the current usages.  This would result
in
that  "big promise of EDIINT" coming true.

John Tsucalas

---------------------- Forwarded by John Tsucalas/ET&S/Enron on 02/24/99 12:40
PM ---------------------------

Gunther Schadow <[email-masked]> on 02/24/99 10:48:57 AM

To:   [email-masked], [email-masked]
cc:   [email-masked], [email-masked], [email-masked],
      [email-masked], [email-masked], [email-masked],
      [email-masked] (bcc: John Tsucalas/ET&S/Enron)
Subject:  Re: AS2, HL7,GISB, E5, others?

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: Dick Brooks <[email-masked]>
Date: Wed, 24 Feb 1999 15:20:42 -0600 (CST)

See inline

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

If the goal is to simply replace SMTP with HTTP for transporting AS1
then I would agree. I'm not altogether sure why this would be desireable,
It seems to me that SMTP is a fine transport and AS1 provides a good 
solution for e-mail based EDI. But for those looking to take advantage of
HTTP's advanced features, it would seem that a Internet EDI standard using
HTTP would be built to support those features.

>to RFCs. Then we can all take a deep breath and see what's next.

Again, if this is all about closure on a specification of how one moves 
AS1 over HTTP then ditto. However, I do not believe this is what an Internet 
HTTP EDI standard would look like, if we were starting from scratch and could 
leverage the full power and capabilities of HTTP.

>don't even do that in AS#2 since it would require doing the same in

I disagree. The AS2 standard should allow implementers to leverage the 
capabilities of HTTP in their E-commerce sites, many already are doing so.
AS1 is a good solution for SMTP based systems, AS2 should be allowed to become
a good solution for HTTP based solutions.

>generic software equally and painlessly useful for X12, EDIFACT, GISB,

If the HL7 spec contains features that are not specific to HL7 or healthcare
why weren't these enhancements brought into the core standard? It appears
these additions have the potential to benefit e-commerce in general.

>sector-specific profiles.

I second that.

>specific in order to maximize leverage of the commercial

These standards should not be sector specific (which is the current track),
but rather "technology specific". There should be a SMTP based EDIINT
solution and a HTTP based EDIINT solution. Each should be allowed to evolve
unincumbered by the other.

>RFC 1767 to do secure transaction tracking (Content-Id, In-Reply-To).

This is an excellent idea, I can provide some real world use cases from
existing GISB implementations.

---

From: "Carl Hage" <[email-masked]>
Date: Wed, 24 Feb 1999 16:35:03 -0800

Date sent:      	Wed, 24 Feb 1999 17:26:53 -0500
From:           	Dave Van Noord <[email-masked]>

> > Your next generation XML-based standard could use the MIME
> > wrappers as defined in EDIINT to package the XML. ...
> 
> 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.

You mean you use the HTML forms/CGI, e.g. &data=<xml...?

According to EDIINT, you don't translate the data to an HTML2 
form response. Instead, you first add a MIME header that specifies
the content type. If you have XML data plus binary data external to 
the XML, you could use a MIME multipart to combine the XML with 
other data. Next you use MIME to add a digital signature creating a 
multipart/signed. Finally, you send the data via POST, inserting 
some addiional headers including Message-ID, From, To, etc.

Rather than just a number response, the HTTP server returns a 
digitally signed receipt including the message ID and hash of the 
posted data.

Copies of the posted data and reply data are valid MIME messages,
and can be processed by general MIME software. This includes all
signatures for non-repudiation and auditing.

--------------------------------------------------------------------------
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