From:
owner-ietf-ediint@xxxxxxxxxxxx [mailto:owner-ietf-ediint@xxxxxxxxxxxx] On Behalf Of Shan Harter
Sent: Friday, May 06, 2005 2:58 PM
To: ietf-ediint@xxxxxxx
Subject: 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:
[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
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
Shan Harter
VP of Project Services
Systrends, Inc.
7855 South River Parkway
Tempe Arizona,
85284
ph: 480-756-6777 Ext 205,
