Subject: AS2-SPEC

From: "Shan Harter" <[email-masked]>
Date: Fri, 6 May 2005 12:57:52 -0700

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.

---

From: "Kyle Meadors" <[email-masked]>
Date: Fri, 13 May 2005 08:13:24 -0500

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

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

 

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 

header instead of 

 

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"

 

Regards,

Shan

Shan Harter
VP of Project Services
Systrends, Inc.
7855 South River Parkway
Tempe Arizona, 85284

 

 

 

 

 

 

Regards,

Shan

Shan Harter
VP of Project Services
Systrends, Inc.
7855 South River Parkway
Tempe Arizona, 85284

 

--
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