|
In the past, others have asked about basic
HTTP authentication within AS2. It is my understanding that HTTP authentication
was either beyond the scope of AS2 or considered unnecessary by the other
security features provided by AS2. However, I am sure something can be worked
on individually between trading partners if they wish to use it. On the issue with the required linking of
the AS2–To/AS2–From ids to the X12 ID, that is definitely an
implementation added requirement going beyond the standard (the spec does not
address X12 ID concerns). IMO, that should not be a restriction. Kyle Meadors DGI From:
owner-ietf-ediint@xxxxxxxxxxxx [mailto:owner-ietf-ediint@xxxxxxxxxxxx] On Behalf Of Shan Harter 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]*<---( connect )----- [Peer2] * Note: An AS2-MDN may be directed to a
different host than that of 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 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
fax: 480-756-9755, cell: 602-821-2951 Regards, Shan
fax: 480-756-9755, cell: 602-821-2951
-- -- |