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

From: "Rik Drummond" <[email-masked]>
Date: Thu, 18 Feb 1999 12:06:24 -0600

I am ready to give this to the rfc editors... comments?  Rik

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Thursday, February 18, 1999 11:32 AM
To: IETF-Announce: ;
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-ediint-as2-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Electronic Data Interchange-Internet
Integration Working Group of the IETF.

	Title		: HTTP Transport for Secure EDI
	Author(s)	: C. Shih, D. Moberg, R. Drummond
	Filename	: draft-ietf-ediint-as2-03.txt
	Pages		: 9
	Date		: 17-Feb-99

This document describes how to exchange EDI documents securely
using http transport for EDI data that is packaged in MIME messages
that use public key security body parts.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ediint-as2-03.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ediint-as2-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ediint-as2-03.txt".

NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Dale Moberg" <[email-masked]>
Date: Mon, 22 Feb 1999 15:14:22 -0500

Hi Dick,

The response must conform to the HTTP 1.1 RFC 2068 rules on entity bodies. So if
I got
these right, there needs to be an entity header with a Content-type value. The
values for
this field are "Internet Media Types" and in section 3.7 it says "Use of
non-registered types
is discouraged." But the types are so open anyway I really can't imagine that
you can't find
one you could fit your data into. Can you explain why the data doesn't fit a
type?
 If that is not the problem, maybe you could follow RFC 2048 and register a new
one?
Anyway I doubt that we would ever get this our of I-D state if we were to
indicate we had
a profile for HTTP that violated its rules...  Maybe I need to be told a little
more about
what the response data is like.
Bye
Dale Moberg

Dick Brooks <[email-masked]> on 02/20/99 04:58:39 PM
Ext: Unknown

To:   Dale Moberg/Sterling Commerce@Sterling Commerce, [email-masked],
      [email-masked], [email-masked]
cc:   [email-masked]
Subject:  RE: LAST CALL - I-D ACTION:draft-ietf-ediint-as2-03.txt

On the topic of response data - would it be possible to support a non-mime
response format? I'm thinking of some e-commerce systems currently using
another standard.

Dick Brooks                            [email-masked]
Tel. 205-250-8053               Birmingham, Alabama
Group 8760 LLC                         WWW URL:  http://www.8760.com/
SECURE ELECTRONIC COMMERCE SOLUTIONS FOR HEALTHCARE AND NATURAL GAS INDUSTRIES

---

From: Dick Brooks <[email-masked]>
Date: Tue, 23 Feb 1999 12:29:32 -0600 (CST)

Carl, I will provide the group with a reference to the GISB Electronic 
Delivery Mechanism STANDARD. This document describes the
protocol used in exchanging EDI over the Internet using HTTP.

As I stated in my earlier posting, there are hundreds, literally hundreds 
of existing implementations on the Internet. Whatever future changes will be
made to this standard must be done through the standard GISB process. The 
GISB standard is not currently an IETF effort. That's not to say this will
always be the case, in fact I was hoping the as2 effort might provide
the common ground. 

One thing I've learned over the past years working on these standards efforts
is the need for people on all sides to be open minded. While working at 
DEC several years ago I was assigned to work on RFC 1767 with Dave Crocker, et
al, when at the Seattle IETF meeting in 1993 Einar Stefferud made the comment 
that OSI was a wonderful dream and TCP/IP was living that dream. You may recall
that OSI had both broad industry and international support with the standards
bodies (ISO). Stef was right on! 

Said another way, a bunch of positive words and documentation alone does not 
make a standard, a standard is only a standard if the market makes it so. The 
GISB standard has a several things going for it that this group may want to 
capitalize on:

	- Hundreds of implementations
	- Supported by multiple industries
	- privacy via encryption (using PGP with RSA algorithms)
	- Message integrrity and Non-repudiation (using PGP Digital Signatures)
	- Layered approach to existing standards (IETF, W3C and GISB)
	- Based on:
		- HTTP 1.0 (RFC 1945) (1.1 didn't exist in 96)
		- RFC 1341 (the original MIME spec)
		- All interchanges are passed in Mime multipart/form-data
		  payloads using http POST method ref RFC 1867
	- Positive acknowledgement using a GISB specified message structure
	  that is HTML based (RFC 1866)
	- Authentication of trading partners using username/password (again 
	  using RFC 1945)
	- Key exchange procedures (GISB specified)
	- Time Synchronization (using NIST)
	- Clearly defined Error specifications (GISB specifications)
	- Supports both batch and interactive processing models
	- Proven interoperability
	- Model Trading Partner Agreements that follow the GISB standard
	- Well documented 
	- Multiple vendors offering GISB solutions
	- Momentum, Momentum, Momentum...!

If this group is genuinely interested in finding a path to common ground
then I am certainly interested in participating. If Carl's position that 
"the GISB standard should be revised to conform to the IETF-EDI standards-- 
not the other way around" is representative of the groups consensus then I'm 
less optimistic that consensus can be reached between the two groups. Keep in 
mind there are lots of GISB implementations that would be affected by radical 
upheaval and the GISB group simply cannot tell all these followers to abandom 
ship. I believe a methodical, migratory approach to standardization would be 
prudent.

---

From: "Dale Moberg" <[email-masked]>
Date: Tue, 23 Feb 1999 16:36:02 -0500

Gunther Schadow <[email-masked]> on 02/23/99 03:52:47 PM
Ext: Unknown
.
>-Gunther writes:

>Have you looked at the HL7 document (draft-ietf-ediint-hl7-00.txt)? We
>have had a similar discussion in fall 1997 about sending an EDI
>response message along with the MDN receipt in a multipart. However,
>after consulting with this group I came up with the proposal to use
>multipart/related to bundle MDN and EDI response. Carl, if you suggest
>such a thing to be done using multipart/mixed now, we (I) either made
>a mistake in fall 1997 or we are about to make a mistake today. I
>believe that all EDIINT standards should promote just one way of doing
>this.

Hi,

I think that most MIME handlers (the machinery that stores, views, or calls
applications on the data)
probably fall back to a multipart/mixed semantics when they hit a
multipart/related. In practice there
is probably not much difference in response to these (but for
multipart/alternative or mulitpart/signed
and others, the story is of course a lot different).

I am not certain why we need to promote just one way of doing this since we are
going to have general
MIME dispatching machinery (and associated flavors of crypto machinery) on each
end of EDIINT apps.
People previously commented that an EDIINT app needs to be able to handle the
EDIINT data formats
even when they are embedded as components of MIME structures. The profiling does
not allow you to ignore
the general rules of MIME-handlers in either the HTTP or SMTP transport case. So
we will have known interoperability
when things are restricted to the core EDIINT templates. In going beyond those
patterns and content types, the
responses may differ to different content types.

 I think we might need to have more paragraphs clarifying what an AS is doing.
We obviously
are not creating new IETF application protocols. We also do not wish to
encourage applications to take shortcuts on the
underlying protocols and just "do enough" to interpret the specifications. Yet
most EDIINT applications are not going
to support a wide range of content type "viewers" , for example, because they
are mainly for automated processing.
All non handled MIME types just go into a non-edi storage hopper of some sort.
Maybe then the questions about whether we
"can" do something that is clearly allowed by the standards but which we do no
specifically enumerate would get resolved.
Additionally, we could then focus on the core functionality that is needed for
interoperable automated secure operation.

Just a thought as we plunge back into the thicket of things again...

Bye
Dale Moberg

>regards
>-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: Gunther Schadow <[email-masked]>
Date: Tue, 23 Feb 1999 17:53:47 -0500 (EST)

Dale,

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.

If we had decided to use multipart/mixed, MIME handlers would need to
peek into the multipart to find out whether it conforms to the receipt
EDI message pattern. I believe multipart/related provides a cleaner
support for the use case.

I also believe that it is quite useful if we come up with one
canonical way of supporting this use case. Unfortunately it is too
late now to turn the HL7 document around. This topic has been
discussed in fall 1997 and the first Internet draft was issued in June
1998. Since then, nothing happened. The HL7 document is now being
balloted within HL7. It is too late now, I can not simply turn the
wheel into the other direction, unless someone shows up with the proof
that multipart/related is severely broken. I deliberately delayed the
ballot process for one year so that you IETF folks could
intervene. But I heard nothing back.

If you pick up this idea to piggy-back an EDI response on an MDN now
(which I appreciate) I would be happy if you would seriously consider
to stick to the multipart/related approach documented in the HL7
draft. You are right that generic MIME handlers could somehow support
both ways, but it is quite confusing. Remember that many EDI folks are
not necessarily too familiar with the MIME, SMTP, RFC822 and other
Internet standards. You can easily create confusion, or you can help
understanding through being consistent.

If you want to review the related sections in the HL7 draft, please
see

http://aurora.rg.iupui.edu/security

Section 3.2.2.4 (paragraph "non-repudiation of committment") and
Section 4.1.4.

thank you
-Gunther