AS2-SPEC

There is some ambiguity when setting up a return MDN that is not to be
returned to the same server as originally sent and I am hoping that I
can get a response from the group regarding that setup.
For now we will use the same basic authentication setup as is from the
source and not a new basic auth. I list two other minor issues that
should be considered as well but the most important is the first one.
 
Reference to the MDN returning to a different URL than the sender sent:
 
If we specify a different host, then we must consider
 
1. Allowances for different basic authentication (base64 encoded user
name and password) for the NEW destination based on
 Receipt-Delivery-Option: return-URL if the return-URL is not the same
as the source. For now we can assume the same user id and password. From
the AS2 draft 20 spec:
 
 Asynchronous AS2-MDN
 
   [Peer1] ----( connect )----> [Peer2]
   [Peer1] -----( send )------> [Peer2]   [HTTP Request [AS2-Message]]
   [Peer1] <---( receive )----- [Peer2]   [HTTP Response]
 
   [Peer1]*<---( connect )----- [Peer2]
   [Peer1] <--- ( send )------- [Peer2]   [HTTP Request [AS2-MDN]]
   [Peer1] ----( receive )----> [Peer2]   [HTTP Response]
 
   * Note: An AS2-MDN may be directed to a different host than that of
   the sender of the AS2 message. It may utilize a different transfer
   protocol than that used to send the original AS2 message.
 
 
2. There is nothing distinguishing in the AS2-Messages that is
"required" significantly different from an Asynchronous MDN Message in
the HTTP header. Because of this
the lower level message must be processed in order to "discover" its
content. Since the MDN is not encrypted itself, might be nice to create
an MIME header that
a) either ONLY exists in an AS2 message or b) a MIME header that is
unique to MDN.
 
 
3. This is a note to future processing of EDI-X12 MIME content types and
AS2: Nothing in the specification (draft 20) links "Content-type:
application/EDI-X12;" to AS2-From/AS2-To to ANSI X12 ISA header ID
qualifier and ID (a.k.a DUNS). But in some currently approved AS2
applications, to get this header back you MUST pair the ID+DUNS which
"forces" the trading partner to use the AS2-From that the AS2
application specified. This is not in the AS2 spec and is believed to be
product specific implementation not documented in the standard. The
work-around is to create a setup that allow that application to create a

 
Content-Type: application/octet-stream; name=Test.edi
Content-Transfer-Encoding: binary
Content-Disposition: attachment; filename=Test.edi
 
header instead of 
 
Content-Type: application/EDI-X12; name=Test.edi
Content-Transfer-Encoding: binary
Content-Disposition: attachment; filename=Test.edi
 
 
which really is not true because we know its X12. Because of the paring
of ISA07+ ISA08 = AS2-To, the receiving partner MUST setup their system
as ISA07+ ISA08 = AS2-To in order to receive the MIME header
"Content-Type: application/EDI-X12; name=Test.edi"
 
typical ISA header example:
 
ISA*00*          *00*          *01*1232456789      *14*987654321
*040413*1136*U*00401*000000348*0*T*>
 
 
 
Regards,
 
Shan

Shan Harter
VP of Project Services
Systrends, Inc.
7855 South River Parkway
Tempe Arizona, 85284
ph:  480-756-6777 Ext 205, 
fax: 480-756-9755, cell: 602-821-2951
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Regards,
 
Shan

Shan Harter
VP of Project Services
Systrends, Inc.
7855 South River Parkway
Tempe Arizona, 85284
ph:  480-756-6777 Ext 205, 
fax: 480-756-9755, cell: 602-821-2951
 

CONFIDENTIALITY NOTE:
This message and any of the attached documents contain privileged and 
confidential information only for the use of the individual or entity 
that was the intended recipient.  If you are not the  intended recipient 
you may not read, copy, distribute, retain or use this information. If 
you have received this message and any of the attached documents in 
error, please immediately notify the sender by reply e-mail and then 
delete this message.  Thank you.