AS2 Optional Profiles are additional functionality requested by various industry associations and end users. Participation in Optional Profiles is strictly voluntary as software companies enrolled in AS2 interoperability testing are NOT required to undergo any of the Optional Profiles testing. Only those products which successfully pass the Optional Profiles will be announced to the public - failures will not be reported on the website or in the Final Report.
Some test profiles certifications are InSitu automated for testing. InSitu® is Drummond Group's test automation tool. In the Queue (ITQ) testing is Drummond Group's pre-testing required to prepare your product for certification. For more information about: AS2, InSitu, and In-The-Queue.
Path to Completing AS2 Optional Profile Certification:
If NEW to AS2 Certification and All Profiles
Step One. Participants are required to enter any testing with a product that has completed their own internal development and implementation.
Step Two. Complete the "In the Queue (ITQ) testing" for AS2 to prepare your product for the upcoming Interoperability certification.
Step Three. Complete InSitu Development for AS2 certification and InSitu enable for any chosen Optional Profile certifications.
Step Four. Complete ITQ Optional Profiles selected to prepare for Certification Run.
Step Five. AS2 Interoperability test will include a certification run for all the Optional profiles.
Step Six. Upon passing the profile and AS2 Interoperability certification, your product will be listed as having passed the specific profiles tested.
If NEW to a Respective Profile but Drummond Certified for AS2 in past test rounds:
Step One. Participants are required to enter any testing with a product that has completed their own internal development and implementation.
Step Two. Complete ITQ Optional Profiles selected to prepare for Certification Run.
Step Three. AS2 Interoperability test will include a certification run for all the Optional profiles.
Step Four. Upon passing the profile and AS2 Interoperability certification, your product will be listed as having passed the specific profiles tested.
IETF Drafts
Please note that these profiles are based on underlying specifications which have been submitted as IETF internet draft versions. Each individual version is valid for six months on the IETF website. Drummond Group Inc. also makes available these draft documents for your convenience.
Certificate Exchange Management (CEM)
Overview: CEM is now an Internet-Draft within the IETF. There is growing interest and demand from supply chains (namely retail and consumer products goods) for CEM because of the significant time savings it provides by automating the manual effort of managing certificates that are about to expire. Certificates can be specified for use in digital signatures, data encryption or SSL/TLS over HTTP (HTTPS)
InSitu enabled: NO
Background Information
Requirements:
- Participants new to CEM must complete development CEM on their own (estimated to take 2-3 months) prior to entering a DGI administered "CEM ITQ testing."
- Products-with-versions which have previously been certified on CEM do not have to undergo CEM ITQ but will have to participate in the CEM Certification during the AS2 Interoperability test to maintain their CEM Certification status
- CEM is not InSitu enabled at this time.
Technical Specifications
Critical Rules: "CEM ITQ testing" consists of testing against reference products administered by DGI. Note, given the large manpower and development time required to implement CEM, DGI recommends that for this round you limit participation in Optional Profiles to just CEM unless the participant is able to provide additional resources to participate simultaneously in other Optional Profiles.
Filename Preservation (FN)
Overview: The banking industry (specifically FSTC) relies on filenames being communicated between trading partners. AS2 vendors are currently certifying that implementation of filename communication conforms to the standard and is interoperable. There are two test profiles for filenames: FN and FN-MDN. FN specifically refers to the filename preservation profile WITHOUT MDN responses.
InSitu enabled: Yes, Insitu enablement of FN is required.
Background Information
Requirements:
- Products-with-versions new FN must complete development of FN on their own and implement InSitu enable for FN prior to entering MA ITQ.
- Products-with-versions previously certified on FN but NOT yet FN InSitu enabled must enroll in FN ITQ
- Products-with-versions which have previously been certified on FN and which are FN InSitu enabled do not have to undergo FN ITQ but will have to participate in the FN Certification during the AS2 Interoperability test to maintain their FN Certification status
Technical Specifications
Filename MDN (FN MDN)
Overview: Refers to the Filename preservation WITH an associated MDN error or warning response notification. Some banks were interested in software that provided an MDN response, therefore a distinction was made for the buyers
InSitu enabled: NO
Background Information
Requirements:
- Products-with-versions new to FN MDN must also implement Filename Preservation (FN) to their products to qualify for FN MDN. Participants expected to develop and implement FN MDN feature into their product prior to FN MDN ITQ.
- Products-with-versions which have previously been certified on FN MDN do not have to undergo FN MDN ITQ but will have to participate in the FN MDN Certification during the AS2 Interoperability test to maintain their FN MDN Certification status
Technical Specifications
Critical Rules: The Debug Phase testing will not be extended for participants who bring in products unable to keep pace during the Debug Phase.
Reliability
Overview: The AS2 Reliability Profile addresses duplicate message elimination and standardizes mechanisms for retrying and resending AS2 Messages and MDNs which are crucial to reliable operation of production AS2 installations. This feature may be utilized by any industry but the standards work has been undertaken by eCommerce Technology Group (eTG) under GS1. Starting in 2007, DGI began a phased approach to testing the Reliability standard and the participation has been high by users and vendors alike. There are several phases of implementing this profile over the next couple of years:
- Phase One - AS2 Reliability testing in the AS2-3Q07 test round will ONLY focus on reusing "same AS2 message" as originally packaged and attempted be retried or resent This implies the MessageID as originally provided will also be reused and allows the receiving side to detect duplicate messages based on the MessageID and eliminate."
- NOTE: Phase two and Phase three have not gone through final reviews with users or vendors and therefore these are just DRAFT Test Proposals at this writing.
- Phase Two - DRAFT PROPOSAL: For consideration in AS2-Q08 are Very Large Messages, meaning messages with a very large payload. Large and larger payloads are being exchanged in AS2 communities, and DGI will introduce payloads in the 100's of MB to one or several GB. Reliability Phase One functionality will be required for entry into Reliability Phase Two
- Phase Three - DRAFT PROPOSAL: For consideration is introducing AS2 Reliability configuration requirements from the AS2 Reliability Draft, such as number of retries and interval of retries.
InSitu enabled: Yes, Insitu enablement of Reliability is required.
Background Information
Requirements:
- Products-with-versions new to Reliability Phase One must complete development of Reliability on their own prior and implement InSitu enable for Reliability prior to entering Reliability Phase One ITQ.
- Products-with-versions which have previously been certified on Reliability Phase One do not have to undergo Reliability Phase One ITQ but will have to participate in the Reliability Certification during the AS2 Interoperability test to maintain their Reliability Certification status.
Technical Specifications
Critical Rules:
AS2 Reliability testing in the AS2-3Q07 and AS2-1Q08 test rounds will ONLY focus on the MessageID requiring the originally sent MessageID to be reused on retries and resends. The AS2 Reliability draft addresses this issue.
Multiple Attachments (MA)
Overview: Multiple Attachment (MA) capability is the ability to transfer multiple documents within a single AS2 message. This feature may be useful for any industry, but it is extensively used by the Petroleum Industry Data Exchange (PIDX)
InSitu enabled: Yes, Insitu enablement of MA is required.
Background Information
Requirements:
- Products-with-versions new to MA must complete development of MA on their own and implement InSitu enable for MA prior to entering MA ITQ.
- Products-with-versions previously certified on MA but NOT yet MA InSitu enabled must enroll in MA ITQ
- Products-with-versions which have previously been certified on MA and which are MA InSitu enabled do not have to undergo MA ITQ but will have to participate in the MA Certification during the AS2 Interoperability test to maintain their MA Certification status
Technical Specifications
|
