**Session Date/Time:** 17 Jan 2025 16:00 # [EMAILCORE](../wg/emailcore.html) ## Summary The EMAILCORE working group met to discuss the status of the SMTP Message Format and SMTP Applicability Statement (AS) documents, focusing heavily on feedback from the IESG and IANA. Key discussions revolved around making the AS reference normative in the SMTP Message Format, clarifying IANA registration procedures, and addressing various editorial and technical comments related to registry management. Several decisions were made regarding IANA text and the path forward for both documents, with a clear intent to move the AS document towards working group last call soon. ## Key Discussion Points * **SMTP Message Format (v39) Status:** The document has been posted and underwent IESG review, receiving four discusses, two of which have been cleared. The document is considered close to being ready for IETF Last Call. * **Applicability Statement (AS) Reference:** A significant portion of the discussion centered on a proposal to make the reference to the AS document normative within the SMTP Message Format specification. * This change is expected to address a discuss raised by Paul Hoffman. * Concern was raised regarding whether all individuals who supported Paul's discuss would be comfortable with this resolution, given that it implies a "nose-holding exercise" for some. * The pragmatic view expressed was that making the AS reference normative would link the publication schedules of 5321, 5322, and the AS, which is preferable for finalization. * A "downref" issue exists as a Full Standard (5321) would reference a Proposed Standard (AS), which needs to be noted in any announcement. * **AS Document Readiness:** There was differing optimism regarding the AS document's readiness for IESG review. * Concerns were voiced that the AS might require significant review, especially concerning security considerations related to STARTTLS, SPF, and DKIM, if strong requirements or endorsements are to be included. * The existing AS document already contains extensive discussions on STARTTLS, DKIM, SPF, and authentication, but tuning the level of requirements vs. recommendations may be needed. * **Appendix E Review:** Volunteers were sought to review Appendix E of the SMTP Message Format document, which details changes from RFC 5321. * **IANA Registration Procedures (RFC Types):** Discussion on Roman Danyliw's comments regarding the two registration models: "IETF Review" and "First-Come-First-Serve (FCFS)". * Concerns were raised about "mushy language" like "approximately equivalent to IETF review" and "in rare cases specifically approved by ISG" for informational RFCs. * Three options were considered: reverting to only Standard Track and Experimental for IETF Review, clarifying existing language for ISG discretion, or dropping the "rare cases" phrasing. * **IANA "Legacy" Category:** Discussion on the necessity of a "Legacy" category for historical SMTP extensions (e.g., VFRB, 1X) vs. folding them into the FCFS model. The historical nature and lack of formal documentation for these entries were key points. * **IANA Registration Template Details:** * The level of technical detail and cross-referencing needed in IANA registration templates, particularly for fields like "EHO parameter" linking to ABNF definitions. * IANA's preference for separate "Contact" and "Change Controller" fields. * Potential redundancy between "Description" and "Behavior and Impact" fields. * RFC Editor/IANA's request to clarify the creation history of existing registries (e.g., "created by RFC 5321" vs. by the current document). * IANA's reluctance to decide on the validity of "reference" fields in existing registrations, specifically regarding the phrase "unless other information is readily available, the reference field should point to 5321". * The need for a clear statement instructing IANA to update registry pointers from RFC 5321 to the new document. * **"First-Come-First-Serve" (FCFS) Language:** Whether to describe FCFS as a "variation" and the need to encourage registrants to consult Model 2 for guidance even with FCFS. * **Normative "SHOULD" capitalization:** IANA's preference for lowercase for non-testable "should" vs. uppercase for interoperability issues. * **Sentence Removal:** Consideration of removing a wishy-washy sentence: "Implementations MUST support the use of multiple domains in the SMTP server name...". ## Decisions and Action Items * **Normative AS Reference:** The reference to the Applicability Statement (AS) document in the SMTP Message Format specification will be made normative. * **Action Item (Chairs):** Double check with Deb and Roman on their comfort with this solution regarding Paul Hoffman's discuss. * **Action Item (Chairs):** Ensure the announcement of IETF Last Call notes the downref from a Full Standard (5321) to a Proposed Standard (AS). * **Appendix E Review:** * **Action Item (Todd, Pete):** Review Appendix E of the SMTP Message Format document within 1-2 weeks. * **IANA Registration Procedures (RFC Types):** The IETF Review model will be limited to Standard Track and Experimental RFCs. For other RFC types (e.g., Historic, Informational), the First-Come-First-Serve (FCFS) model can be used. * **Action Item (John Klensin):** Draft text clarifying how FCFS can be used with other RFC types and post it to the mailing list for discussion before implementation. * **IANA "Legacy" Category:** * **Action Item (John Klensin):** Add text to the document clarifying that "Legacy" entries cannot be updated. * **IANA Registration Template Details:** * **Action Item (John Klensin):** Add a cross-reference for the "EHO parameter" in the IANA registration template to its ABNF definition. John will also check if other fields require similar cross-references. * **Action Item (John Klensin):** Separate "Contact" and "Change Controller" fields in the IANA registration template. * **Action Item (John Klensin):** Combine "Description" and "Behavior and Impact" into a single, expanded "Description" field. * **Action Item (John Klensin):** Re-assess the implications of referencing RFC 5321 directly. The intent is to clarify that registries were "created by prior documents" (without specific RFC numbers) on a per-registry basis, rather than direct references to 5321. * **Action Item (John Klensin):** Remove the clause "unless other information is readily available, the reference field should point to 5321" regarding IANA's handling of existing registrations. * **Action Item (John Klensin):** Add a statement that IANA should update all registries currently pointing to RFC 5321 to point to the new document. * **"First-Come-First-Serve" (FCFS) Language:** The document will not refer to FCFS as a "variation". * **Action Item (John Klensin):** Add text to the FCFS section encouraging registrants to consult Model 2 for important information. * **DKIM/SPF:** No changes are needed in the DKIM/SPF section as the relevant discuss has been cleared. * **Normative "SHOULD" capitalization & Sentence Removal:** * **Action Item (Alexey Melnikov):** Send the specific points regarding "SHOULD" capitalization and the removal of the "Implementations MUST support the use of multiple domains in the SMTP server name..." sentence to the mailing list for further discussion. ## Next Steps * **Document Revisions:** John Klensin and Ken Murchison are to perform a revision of the AS document incorporating the decisions made, including adding a reference to STARTTLS and clarifying its mandatory implementation on the server side. * **Working Group Last Call (WG LC):** The goal is to initiate a Working Group Last Call for the AS document within a couple of weeks after the new version is posted. * **Interim Meeting:** Another interim meeting will be scheduled to discuss the remaining Applicability Statement issues. The target is the week of February 10th, avoiding the week of February 17th. * **Action Item (Chairs):** Schedule the interim meeting and poll participants for availability.