Interoperability

Interoperability is where AS2 projects succeed or die: two RFC-compliant implementations can still fail to reconcile receipts because the RFCs leave real choices open (what exactly the MIC digests, how AES-GCM is encoded, which algorithm-name spellings appear on the wire). as2d’s approach: measure against live implementations, never assume.

The verification matrix

Every release exchanges live traffic — signed, encrypted, compressed, with signed MDN reconciliation — with seven independent implementations, each running unmodified in its own container:

Real-world compatibility built in

• BouncyCastle AES-GCM: the Java AS2 world encodes AES-GCM in a non-conformant way (plain EnvelopedData with the auth tag appended) that standard crypto libraries refuse. as2d receives that form transparently — with the tag still enforced — and can send it per partner (bc_style_gcm) while defaulting to the RFC 5084 conformant encoding.
• Algorithm-name spellings: RFC 5751 names by default, RFC 3851 (sha256 vs sha-256) per partner, and in-the-wild aliases accepted on input.
• Peppol: signer certificate embedded in signatures (default on).
• IBM Sterling: per-partner header-quoting and other switches.
• Per-partner content-transfer-encoding: binary (the wire default), base64, or quoted-printable outer encoding — different counterparts require different forms, and both are expressible per partnership.

Where a counterpart’s behavior makes strict receipt reconciliation impossible (for example, one product digests receipts without MIME headers on unsigned compressed messages), the exchange still completes and the divergence is documented in Working with specific products so your operators are never surprised by it in production.