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

From: "Dale Moberg" <[email-masked]>
Date: Mon, 22 Feb 1999 18:03:24 -0500

>2.3 Other Reply Content

{omitted stuff)

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

Carl, this is a departure from our attempt to leave the data formats
in the smtp and http cases basically similar. I think you should
provide some more reasoning why the default case is to have
a multipart/signed over a multipart/mixed (including one part that
is a multipart/report and some other part(s)). The multipart/mixed
could consist of two multipart/signeds or just the signed MDN and
some other data relevant to the transaction for which no signature
is required by the TP agreement, and so on. Why not just leave
the extension open to any " legal" MIME and security multipart approach
since this is an extension to the core profiling of the EDIINT WG? So just
stop after noting that we need a multipart/mixed.

>2.4 Non-Repudiation of the POST Reply

OK

>2.5 Error Recovery

Response pending. Are Message IDs repeated in the SMTP case?  There is something
about repeating
POSTs somewhere. I have to find it and get back.

>Hmmm, that reminds me-- I wonder if it's worth mentioning other
>HTTP headers, e.g. no-cache.

I usually think of no-cache in a "GET" context and I think responses to POST are
not cacheable unless something
special is done (RFC 2068 p. 51 section 9.5)

---

From: "Carl Hage" <[email-masked]>
Date: Tue, 23 Feb 1999 11:36:00 -0800

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

> in the smtp and http cases basically similar.

That was not my intent-- I believe the data formats should be the 
same-- so comments apply to both. How is it different for smtp?

> I think you should
> is a multipart/report and some other part(s)).

This wouldn't be a requirement, so I suppose it could be left unsaid. 
I would say the default would be to sign after mixing just because 
it's one less signature.

> The multipart/mixed

Yes, I agree that 2 signatures or partial signature is a valid 
response. However, the spec should not require there be 2 
signatures.

Perhaps the best wording is to mention that the digital signature or 
signatures can occur either before or after combining with 
multipart/mixed.

I think it's good to be explicit about the alternatives rather than 
hope the implementor doesn't erroneously make an assumption 
that a particular case wouldn't occur, e.g. the sign before mixing 
and assume everyone else will do the same, or vice versa.

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