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