Subject: RE: AS2 XML requirements (was Re: HL7 Standards Process)

From: [email-masked] (Chris Davenport)
Date: Tue, 28 Nov 2000 10:48:03 +0000 (GMT)

>> > supported in AS1. The AS1 specification is tightly intertwined with
>> > references to RFC 1767 and all examples are based on RFC 1767 payloads.
>> Now is the time to add this definitive text to AS1.
>
>I totally agree. For consistency I suggest using similar text as what
>appears in section 2 on page 6 of AS2.

This is not a simple change to AS1.  I believe the text you are referring
to is: (section 2, page 6 of AS2-07):

    In addition to the enveloping and MIME media type options defined in
    sections 4.2.x and 4.3.x of "MIME-based Secure EDI" [AS1], this
    specification enables the transport of payload objects containing
    other MIME media types. Implementors are to follow the
    appropriate specifications identified under "References"
    in [MIME-TYPES], for the type of object being transmitted.

Putting this into AS1 would contradict RFC1767 which says that if the
payload is not X12 or EDIFACT then it must be transported as
application/EDI-consent.  In effect RFC1767 would need to be rendered
obsolete and I think this would involve more that the simple addition
of a few paragraphs to AS1.  Is this what you had in mind?

I'm quite happy to see the EDI-consent sub-type disappear.  As Gunther
was at pains to point out a couple of years ago, it raises important
interoperability issues.  How does an AS1 application know what to do
with a payload that arrives as EDI-consent?  It doesn't know whether
to pass it to an XML parser, an HL7 application or whatever.  The answer
given at the time was that it would be decided by a trading partner
agreement but this has always seemed unsatisfactory to me.

The text quoted above also seems to imply that AS1 is restricted in the
types of payloads that it can transport.  As I understand it the only
"restriction" over and above AS2 is that binary types must have a
mail-safe content transfer encoding applied (eg. base64).

Am I reading this wrong?

Regards,

Chris.

--
Chris Davenport              [email-masked]
Davros Computer Systems

---

From: "Dick Brooks" <[email-masked]>
Date: Tue, 28 Nov 2000 07:45:20 -0600

Chris, see comments inline.

>of a few paragraphs to AS1.  Is this what you had in mind?

I worked on the development of RFC 1767 and was at the IETF meeting in
Seattle
when Mike Odell suggested EDI-consent. The intent behind EDI-consent was to
provide a means to identify proprietary EDI formats/syntax (e.g. flat
files).

I don't believe the suggested inclusion of wording from AS2 will render
RFC 1767 obsolete. The RFC1767 defined media type of EDI-consent would still
be "available" to those parties interested in classifying their payloads as
"EDI" as opposed to "text/plain; charset=us-ascii", in the case of an
ascii flat file. AS1 needs to be "reworked" to be become a "generic" secure
transport
standard which supports all MIME media types as payloads. Contradictory
statements,
such as the one you cited would be eliminated and some non-RFC1767 examples
should
be included (perhaps an XML example would help).

>agreement but this has always seemed unsatisfactory to me.

The answer is implied in the name; two parties agree beforehand and have a
mutual
understanding of the semantics. The "message processing engine" within their
message handling products must process EDI-consent, text/xml, image/jpeg,
etc. data
properly for each trading partner relationship.

>Am I reading this wrong?

At the time AS2 was originally created the "then current" AS1 draft
(draft-ietf-ediint-as1-09.txt)
did not contain explicit support for non-RFC1767 MIME types. There is a
generic statement in section 2.1
of AS1 indicating support for all electronic commerce, but this could be
interpreted to indicate AS1's support for
the EDI-consent type as opposed to other, non-RFC1767 media types. By adding
explicit support
for non-RFC1767 types AS1 will take on a broader context, that of a secure
transport loop for any type of payload.
AS2 already defines a secure transport loop for all MIME media types, this
inclusion will align the two specs.

Dick Brooks
http://www.8760.com/

---

From: Stacy Thurston <[email-masked]>
Date: Tue, 28 Nov 2000 10:27:57 -0800

Hi all,

----------------------------------------------------
Question:

Could AS2 be restated as: Email messages sent/received using HTTP protocol?

AS2  =  Email + Security + Web server + Web browser

Example, To Send:
1. Use all the normal email standards to create the email message file,
2. then use the an HTTP "POST" to send the file.
3. Then once recieved, use all the normal email standards to "decode" the email
message file.
4. To know what kind of file you have received, check the MIME type (e.g.
EDIX12-850 means you have received an X12-850 purchase order document), then
process appropriately.

** If this is the case, GREAT!
This allows us to use all our current programs (technologies) to securely and
confidentially: send, receive and process documents through firewalls that have
an HTTP opening.

Use:
1. Our email (SMTP) client to create "email file messages"
2. Our batch oreinted "Browser" client to send the "email file messages" using
HTTP POST.
3. Our web server (HTTP) to receive documents
4. * Here we need to write a plugin or cgi to pass the file to the email client.

5. Our email (POP) client would decode the "email file messages" as it would any
email message.
6. We already have the programs to process the files based on sender, receiver
and MIME type.
7. Our email client can create an "MDN file message".
8. * Here we need to write a program to pass the "MDN file message" to the batch
oreinted "Browser" client that would send the "MDN file message" using HTTP
POST.
9. Repeat steps 3, 4, 5 and 6

*** And all of our current security programs remain the same (e.g. SMIME,
digital signatures and encryption).

File - Email client - Batch web browser - Internet - Web server - Email client -
File

This will be easy for us to create an AS2 peer to peer system :)

Thanks for the conversations,
Stacy Thurston, iPlanet (SUN|Netscape) Product Manager
http://www.iplanet.com/products/ecommerce/ecxpert/ecxpert.html

----------------------------------------------------
Background:

I work with a product dedicated to sending & receiving documents.  We add
communication "agents" (programs/connectors) to do the sending and receiving.

Example:
* "Browser" client to send documents
* HTTP server to receive documents
* POP client to get documents
* FTP client to get and put documents

We have found that:
1. Email messaging standards are adequate to send/receive/process documents:
* SMTP/POP, multipart, SMIME, digital signatures & RSA encryption
* Note, mulitpart is rich enough to allow us to tell what kind of file is being
sent to us, i.e. MIME type is the document type.
2. And the HTTP protocol is adequate for file transport.

----------------------------------------------------
eom

---

From: "Dick Brooks" <[email-masked]>
Date: Tue, 28 Nov 2000 15:38:24 -0600

>3. Then once received, use all the normal email standards to "decode" the
email message file.

No, this doesn't work. The HTTP standard defines headers that "collide" with
e-mail headers (e.g. From). The next version of the AS2 spec will contain
two new headers, AS2-To and AS2-From which will replace the To and From
headers used in e-mail. There are also some encoding differences between
SMTP and HTTP.

Dick Brooks
Group 8760
110 12th Street North
Birmingham, AL 35203
[email-masked]
205-250-8053
Fax: 205-250-8057
http://www.8760.com/

InsideAgent - Empowering e-commerce solutions

  -----Original Message-----
  From: [email-masked]
[mailto:[email-masked]]On Behalf Of Stacy Thurston
  Sent: Tuesday, November 28, 2000 12:28 PM
  To: [email-masked]
  Subject: AS2 = Email & HTTP

  Hi all,

  Could AS2 be restated as: Email messages sent/received using HTTP
protocol?

  Example, To Send:
  3. Then once recieved, use all the normal email standards to "decode" the
email message file.

  ** If this is the case, GREAT!
  This allows us to use all our current programs (technologies) to securely
and confidentially: send, receive and process documents through firewalls
that have an HTTP opening.

  Use:
  1. Our email (SMTP) client to create "email file messages"
  2. Our batch oreinted "Browser" client to send the "email file messages"
using HTTP POST.
  3. Our web server (HTTP) to receive documents
  4. * Here we need to write a plugin or cgi to pass the file to the email
client.
  5. Our email (POP) client would decode the "email file messages" as it
would any email message.
  6. We already have the programs to process the files based on sender,
receiver and MIME type.
  7. Our email client can create an "MDN file message".
  8. * Here we need to write a program to pass the "MDN file message" to the
batch oreinted "Browser" client that would send the "MDN file message" using
HTTP POST.
  9. Repeat steps 3, 4, 5 and 6

  File - Email client - Batch web browser - Internet - Web server - Email
client - File

  I work with a product dedicated to sending & receiving documents.  We add
communication "agents" (programs/connectors) to do the sending and
receiving.

  Example:

  We have found that:
  1. Email messaging standards are adequate to send/receive/process
documents:
  * SMTP/POP, multipart, SMIME, digital signatures & RSA encryption
  * Note, mulitpart is rich enough to allow us to tell what kind of file is
being sent to us, i.e. MIME type is the document type.
  2. And the HTTP protocol is adequate for file transport.