Subject: RE: LAST CALL - I-D ACTION:draft-ietf-ediint-as2-03.txt

From: "Dale Moberg" <[email-masked]>
Date: Fri, 19 Feb 1999 09:46:55 -0500

Carl, is there a specific place where the suggestion would be best to insert?
There is no prohibition on sending other data back in the response, so it is
permitted now --
at least in the HTTP case.
It would get rather long to enumerate all the "turnaround" document cases --
would a parenthetical
remark that other MIME contents can also be returned (so the receiver should
have general
mime parsing and disposition capabilities...) be enough ?

"Rik Drummond" <[email-masked]> on 02/18/99 07:00:18 PM
Ext: Unknown

To:   "Carl Hage" <[email-masked]>, [email-masked]
cc:    (bcc: Dale Moberg/Sterling Commerce)
Subject:  RE: LAST CALL - I-D ACTION:draft-ietf-ediint-as2-03.txt

keep up the good work carl. dale do you have this?....rik

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Carl Hage
> Sent: Thursday, February 18, 1999 2:48 PM
> To: [email-masked]
> Subject: Re: LAST CALL - I-D ACTION:draft-ietf-ediint-as2-03.txt
>
>
> From:             "Rik Drummond" <[email-masked]>
> Date sent:        Thu, 18 Feb 1999 12:06:24 -0600
>
> > I am ready to give this to the rfc editors... comments?  Rik
> >http://www.ietf.org/internet-drafts/draft-ietf-ediint-as2-03.txt
>
> Is an MDN the only possible response to the POST operation?
> I would assume so because nothing else is mentioned but it
> doesn't state that explicitly.
>
> The reason I ask is that some EDI transactions could have a
> response transaction immediately upon processing, e.g. a quote
> might be the response for an RFQ. Conceivably, the response EDI
> transaction could be bundled (e.g. with a MIME multipart) with the
> MDN, though I would guess many people would believe this to be
> disallowed. It would be helpful to be explicit and allow or disallow
> other material in the response.
> --------------------------------------------------------------------------
> 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: "Carl Hage" <[email-masked]>
Date: Fri, 19 Feb 1999 11:13:41 -0800

From:           	"Dale Moberg" <[email-masked]>
Date sent:      	Fri, 19 Feb 1999 09:46:55 -0500

> Carl, is there a specific place where the suggestion would be best to

Oh, I thought of a few more issues, which I included below.

I would suggest a paragraph,

2.3 Other Reply Content

The response to the POST operation may include other MIME 
wrapped content besides an MDN Receipt. If a receipt was 
requested within the POST data, and additional content is to be 
returned, the receipt multipart/report MUST be combined with the
other data using a MIME multipart/mixed form. If the response 
includes a digital signature, the signed data SHOULD be the outer-
level multipart/mixed content.

Real-time EDI processing systems MAY use a MIME 
multipart/mixed to include a response EDI message, for example
a Quote in response to a Request-For-Quote transaction. In this
case, the EDI transaction is labelled with the "application" Content-
Type, combined with the MDN using a multipart/mixed, then
digitally signed using a multipart/signed.

2.4 Non-Repudiation of the POST Reply

If the reply to a POST operation requires a receipt for non-
repudiation (for example, the reply includes content other than
a receipt), the top-level headers in the response MUST include
the same headers required for POST data described above:
Disposition-Notification-To, Message-ID, From, and To. Other 
headers described above used in a MDN SHOULD be included,
for example Date and Subject.

The MDN receipt of the response data must be returned using
a subsequent POST operation. A POST operation used only
to transmit an MDN SHOULD not include the Disposition-
Notification-To receipt request, and only a 200 ("OK") response
would be expected.

An MDN in response to a reply may be combined with a 
subsequent EDI message sent with a POST operation, for example 
a Purchase-Order transaction in response to a Quote. The MIME
multipart/mixed form is used to combine the MDN with the other
data, the as for a POST reply.

2.5 Error Recovery

If the server connection fails during the POST transmission, or 
before the response data has been successfully received and 
processed, the POST operation with identical content (including 
Message-ID) SHOULD be repeated. The Message-ID on a POST 
operation MUST be identical to the Message-ID in another POST 
operation if and only if all of the content (including the original Date) 
is identical.

If a server receives a POST with a repeated Message-ID, then it 
should retransmit a reply previously created in response to that 
Message-ID.

------

Note this behavior is essentially equivalent to the SMTP protocol
using the TURN command.

Though having to deal with the possibility that a POST or response
can include multipart/mixed is somewhat more complicated, this
would enable efficient conversational-mode of a transaction 
sequence. It also opens the possibility for future-EDI protocols 
where supplementary (Non- application/EDI) data might be included 
out-of-band.

I realized that error-recovery was omitted from the spec, and I think 
is important to explicitly include. Repeating the transaction is the 
obvious fix for a transmission error.

Hmmm, that reminds me-- I wonder if it's worth mentioning other
HTTP headers, e.g. no-cache.
--------------------------------------------------------------------------
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