RE: AS2-SPEC

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: [email protected] [mailto:[email protected]]
On Behalf Of Shan Harter
Sent: Friday, May 06, 2005 2:58 PM
To: [email protected]
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:

 

 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

 

 


--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.11.5 - Release Date: 5/4/2005



-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.11.9 - Release Date: 5/12/2005