**Session Date/Time:** 24 Jul 2026 14:00 # [EDIINT](../wg/ediint.html) ## Summary The EDIINT Working Group met at IETF 126 to discuss the modernization of the AS2 specification, focusing on the active working group document [draft-ietf-ediint-rfc4130bis](https://datatracker.ietf.org/doc/draft-ietf-ediint-rfc4130bis/). The presentation and subsequent discussions centered around balancing modernization with backward compatibility, choosing discovery mechanisms, addressing cryptographic hygiene, and determining the overall document structure and standards track status. ## Key Discussion Points ### Working Group Administration The Chairperson opened the meeting with the [Chair Slides](https://datatracker.ietf.org/meeting/126/materials/slides-126-ediint-chair-slides-00), presenting the Note Well, resources, and the agenda. ### Presentation: RFC 4130bis Deborah presented the [RFC 4130bis](https://datatracker.ietf.org/meeting/126/materials/slides-126-ediint-rfc-4130bis-00) slide deck, detailing four key structural and technical issues that require working group consensus: 1. **Backward Compatibility Placement**: Whether to keep backward compatibility normative within the document or place it in a non-normative appendix/separate document. 2. **AS2 Compatibility Discovery Mechanisms**: Utilizing automated discovery via well-known URIs versus using a simpler HTTP GET method. 3. **RFC 4130 Fallback Strategy**: Deciding on normative fallback rules versus treating legacy support as secondary, and handling weak cryptography. 4. **Document Structure**: Determining whether to split the protocol modernization and legacy compatibility into separate documents. ### Discovery Mechanisms * **Andrew Newton** raised concerns that using an HTTP GET method with a fixed path would receive significant pushback from the HTTP Directorate (HTTPDIR), recommending well-known URIs instead. * **Orie Steele** (via chat) and **Ori Finkelman** supported utilizing well-known URIs for discovery. ### Backward Compatibility, Fallback, and Cryptographic Hygiene * **Andrew Newton** proposed that the working group does not need to explicitly obsolete or update RFC 4130. Instead, the new document should define how to run AS2 cleanly on the modern Internet. Modern clients can attempt to discover modern AS2 endpoints via well-known URIs and fall back to RFC 4130 code paths if not found. * **Ori Finkelman** recommended keeping [draft-ietf-ediint-rfc4130bis](https://datatracker.ietf.org/doc/draft-ietf-ediint-rfc4130bis/) strictly focused on the modern protocol and moving compatibility/migration guidance into a separate, informative document. * **Marc Blanchet** and **Orie Steele** pointed out that retaining weak cryptographic algorithms (such as Triple DES/3DES and RC2) with "SHOULD NOT" language would not pass IESG review. They agreed that weak cryptography should be entirely omitted from the modern specification. * **Orie Steele** (via chat) suggested limiting optionality in the new version since there are no current deployments of the updated version, deferring legacy compatibility to an informative document. ### Document Intended Status * **Andrew Newton** pointed out that the draft currently lists its status as Informational, whereas it should be Standards Track. * **Marc Blanchet** noted that the original RFC 4130 was published as Informational due to historical IESG circumstances. * **John Klensin** (via chat) confirmed that Applicability Statements are definitely intended for the Standards Track. ### Document Reviews and Technical Enhancements Alexei raised several technical points regarding the current draft text: * **References**: Several references need to be modernized (e.g., updating HTTP/1.1 references from RFC 2616 to the current revised RFCs). * **ABNF**: The draft still uses old BNF notation (characterized by vertical bars for alternatives) which introduces whitespace ambiguity. Alexei recommended migrating to ABNF to prevent future implementation bugs. * **S/MIME Options**: The document currently permits compression both before and after signing. Alexei suggested selecting a single sequence to reduce interoperability testing complexity, though he acknowledged legacy deployments might make this difficult. * **AS2 Extensibility**: Alexei noted he would review whether the draft's ABNF productions align correctly with the extensibility model of the AS2 specification. ### Implementation Context * **Deborah** shared that the Drummond Group works with many clients running legacy RFC 4130 systems who want an updated standard. Over the last 25 years, features like compression, reliability, and restart capabilities have been widely implemented but remain undocumented in the original RFC. Including these features in a modern, open specification ensures all vendors can achieve interoperability without relying on proprietary testing programs. ## Decisions and Action Items ### Decisions * **Document Focus**: [draft-ietf-ediint-rfc4130bis](https://datatracker.ietf.org/doc/draft-ietf-ediint-rfc4130bis/) will focus cleanly on the modern protocol. Weak cryptographic algorithms (like 3DES) will be omitted. * **Discovery**: Well-known URIs will be utilized for automated capability discovery instead of a fixed GET path. * **Intended Status**: The draft's intended track will be changed from Informational to Standards Track. ### Action Items * **Alexei** to subscribe to the mailing list, send a detailed list of reference updates, and assist Deborah with converting the specification's grammar from BNF to ABNF. * **Working Group Chairs** to send an email to the mailing list to recruit co-authors to assist Deborah with the draft. * **Working Group Chairs** to distribute the meeting minutes and recording link to the mailing list. ## Next Steps * **Deborah** to update [draft-ietf-ediint-rfc4130bis](https://datatracker.ietf.org/doc/draft-ietf-ediint-rfc4130bis/) based on the agreed-upon single-document focus, removing references to legacy weak cryptography and incorporating ABNF improvements. * The working group will continue discussing the potential split of legacy fallback guidance into a separate informative document on the mailing list.