Subject: RE: Gunther and MIME structures for "turnaround" replies to POST

From: "Dale Moberg" <[email-masked]>
Date: Thu, 25 Feb 1999 13:35:54 -0500

Hi Gunther,

By a "turnaround" reply I mean the MIME data returned in response to the POST to
the service process. AS#2 recommends using this feature to return the requested
MDN.
HTTP allows any valid MIME part in this role. So an EDIINT client must be
capable of the
minimal response of not crashing under the weight of returned parts. So it must
be able
let us say to pick out the MDN or the signed MDN no matter how embedded in MIME
it has
become-unless we start disallowing HTTP legal PDUs.

Carl has suggested making it explicit how the turnaround extension can be used.
He has in mind a request-for-quote to quote interchange. Gunther has specific
hl7
cases about how the signature needs to work for his scenarios. I want
here to express my doubts about how universal these use cases are. To do so
we need an "enriched diet of examples".

First, is it safe to assume that in every turnaround, there will be a business
requirement
or operational need to have a single signer on the data? Second, is it safe to
assume
that in every turnaround the EDI document included with the MDN will be related
to
the POSTED document?

I think neither of these assumptions is safe (I think it is not even safe to
assume that end users
of an EDIINT app would only return only EDI. The quote may be accompanied by a
CAD CAM
drawing etc.--but let us ignore that can of worms here.)

The Case of the Opportunistic Invoice Return: Large Purchaser posts a torrent of
850 Purchase Orders
for JIT inventory to happy Suppliers. Suppliers return MDNs. Purchaser wants
Invoice next day. Overnight
batch job assembles invoice and signs the hash with accounts receivable's
private key (and forms
a multipart/signed). The turnaround process always checks directory for the
invoice. When available,
it puts it in multipart/mixed with signed MDN as other part. For the MDN, the
signature must be by the
manufacturing scheduling division according to TP contracts and agreements.

Far fetched? Not at all. Yet both assumption about  turnaround are violated.
The business requirements demand different signing agencies.
The second data part is not specifically tied to what has just been posted.

(On Sundays, a special null PO is used to kick off Saturday;s invoice by the
way...)
I was going to give another case involving 850, 855, 857, 855, 810, and a 860...
However,

My point is that no matter how imaginative we think we are, since the turnaround
mechanism allows end users to assemble a turnaround
that fits their business and operational requirements, applications
will need to have workarounds on the restrictions.
I hope we can suggest the areas of extensibility and configurability
for a given sector approach and that will help vendors architect
what is needed to be site specific configurable (that is, when you are going
beyond the vanilla POST EDI and get REPLY MDN.) Specific scenarios
for industries can then be packaged up as informational documents.

PS: Here is Gunther's quite reasonable discussion that I am responding to:

>The reason for using multipart/related type="edi-response"; instead of
>a mere multipart/mixed is to allow special processing of the entire
>multipart object by an EDI/mail agent. If you receive a
>multipart/related type="edi-response" you know exactly that you can
>expect the MDN receipt first followed by the EDI response. You
>check the digital signature over both and can supply the EDI processor
>with necessary context from the MDN receipt.

Bye
Dale Moberg
.

---

From: "Carl Hage" <[email-masked]>
Date: Thu, 25 Feb 1999 12:02:10 -0800

From:           	"Dale Moberg" <[email-masked]>

> or operational need to have a single signer on the data?

I don't think there needs to be or should be a restriction on signing. 
A message/response with a multipart could have a combined or 
separate signature. However, if a multipart is routed to separate 
gateways for processing, a TP might require separate signaures on 
the parts. The spec needn't make a restriction.

An EDIINT processor should be able to parse the MIME 
components, authenticate signed data, match up MDNs with prior
messages, and dispatch recognized content-types for processing.
Unrecognized content-types might be handled as an error. The 
EDIINT processor also needs to recognize error retries and to 
reissue a transmission if the MDN is not obtained.

A deficient EDIINT processor would not handle multiparts or would 
require a signature to be at the top level only.

> Second, is it
> safe to

In Gunther's proposal other documents are related if and only if the 
mixed/related form is used.
--------------------------------------------------------------------------
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