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

["Dick Brooks" <dick@xxxxxxxx>]

Chris, see comments inline.


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

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

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

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/