# EMAILCORE Interim, March 2023 {#emailcore-interim-march-2023} * Date: Tuesday, March 7th, 2023 (1-1.5 hour) * Time: 17:00-18:30 (UTC) * Meetecho: https://meetings.conf.meetecho.com/interim/?short=ee23ecd5-4be3-4309-93cc-cf2ce800f83a * Notes: https://notes.ietf.org/notes-ietf-interim-2023-emailcore-01-emailcore ### Chairs {#chairs} * Alexey Melnikov alexey.melnikov@isode.com * Todd Herr todd.herr@valimail.com ### Scribe {#scribe} * Todd Herr ### Attendees {#attendees} * Barry Leiba * Dave Crocker * John Klensin * John Levine * Kenneth Murchison * Pete Resnick * Oooonduke (wanzerbusi@yahoo.co.jp) * Robert Stepanek ### Minutes {#minutes} #### #74 Syntax of Received header field need to be clarified {#74-syntax-of-received-header-field-need-to-be-clarified} * https://github.com/ietf-wg-emailcore/emailcore/issues/74 * Resnick - Fine with proposed text * Klensin - Fine with proposed text * Crocker - Small issue with layer confusion due to cross-referencing * Resnick - 5322 has no normative reference to 5321 #### #83 Should rfc5322bis "generate" grammar allow for non trace header fields between trace and resent block {#83-should-rfc5322bis-generate-grammar-allow-for-non-trace-header-fields-between-trace-and-resent-block} * https://github.com/ietf-wg-emailcore/emailcore/issues/83 * Melnikov - Rev -05 of 5322bis removed first "optional-field" - https://mailarchive.ietf.org/arch/msg/emailcore/3xPbVYbbBxtCrTRztXSx5\_KWOLk * Resnick - Explains reasoning for said removal: optional-field really didn't add anything, because anything being generated is already syntactically valid so might as well get rid of it. In particular there is already extensibility in the Trace block definition. * Crocker - Not sure what problem this is fixing? * Resnick - We were rash in adding this in 5322 and taking it back out was the right solution * Crocker - So all new header fields are now Trace header fields? * Resnick - No; there's a second optional-field at the bottom of the definition that's been left intact. (It didn't fit on the slide) * Melnikov - Asks for consensus that current version of 5322bis (-05) is what will remain for this field. Consensus in the interim room achieved. #### #81 IANA registration procedure for Trace Header Fields? {#81-iana-registration-procedure-for-trace-header-fields} * https://github.com/ietf-wg-emailcore/emailcore/issues/81 * Melnikov - We need to decide where this registration will live. * Klensin - Encouraged by note at bottom of slide recommending placement in 5322bis, but believes 5321bis is the right place * Resnick - Not dying on this hill, but feels that it shouldn't be in 5322bis, but in A/S. * Crocker - A/S should talk about application; should not be a spec for core technology. * Crocker - Time and resources spent on discussion of trace fields makes issue of defining registry "small potatoes" in comparison. Seems simplest to have it be flag in existing registry. * Klensin - 100% agreeement with Crocker on what goes into A/S and what goes into specs. * Resnick - Now convinced it doesn't belong in the A/S. Unsure of whether it belongs in 5321bis or new document; thinks there's more to it than just defining a flag in the registry. Happy to put it in 5322 if everyone believes it's just a couple of sentences. * Melnikov - Interested in seeing these documents completed. Suggests that text be proposed for 5322 and we go from there. * Klensin - Concerned, like Resnick, about how this is interconnected with 5321 and operational considerations. * Melnikov - Let's stay with idea to put text in 5322, remove it from 5321, and see where we land. #### #75 G.21. Appendix B and Message Submission {#75-g21-appendix-b-and-message-submission} * https://github.com/ietf-wg-emailcore/emailcore/issues/75 * Proposal is that current text is correct and should be left as is. * Klensin - Topic posted to mailing list long ago, drew no discussion then, but wants to be clear that we're done here. * Melnikov - Asks for volunteers other than chairs and editors to double-check text. * Levine and Murchison volunteer. #### #82 G.24. Describing the "Operational Requirements" Loopholes {#82-g24-describing-the-operational-requirements-loopholes} * https://github.com/ietf-wg-emailcore/emailcore/issues/82 * Mailing list discussion of topic is here - https://mailarchive.ietf.org/arch/msg/emailcore/Zv7XtCUPavpacrLslgDiK7M-FJ8 * Melnikov - Thinks text is okay, asks for volunteers to review. * Levine and Murchison volunteer. * Melnikov to send note to list with deadline for review of text from issues 75 and 82 #### #85 Add text to A/S about what mail agents should do/not do with Received header fields {#85-add-text-to-as-about-what-mail-agents-should-donot-do-with-received-header-fields} * List discussion here - https://mailarchive.ietf.org/arch/msg/emailcore/gQ8VfvHRhpDhuWzsfvaF0W640t8 * Levine - Finds Trace Header fields useful for sorting * Crocker - Suggests that text should be clarified to define received header fields and volunteers to propose alternative text. #### #84 Add text about handling of Trace Header Fields by MUAs {#84-add-text-about-handling-of-trace-header-fields-by-muas} * Proposed text in https://github.com/ietf-wg-emailcore/emailcore/issues/84 * Levine - Text isn't wrong, but there are other fields to strip as well (e.g. Date), not just Trace Header fields * Crocker - Agreed that text isn't wrong, but doesn't go far enough * Klensin - Will propose text that extends text to cover non-trace header fields #### #86 Expand on operational meaning of being a trace header field {#86-expand-on-operational-meaning-of-being-a-trace-header-field} * https://github.com/ietf-wg-emailcore/emailcore/issues/86 * Resnick - What about operational considerations for trace header fields? * Melnikov - Can't cover all examples * Klensin - Can work with Resnick to pull together existing text from 5321 and 5322 to get us 90% of the way there * Resnick - So long as trace field is clearly defined to limited scope, happy to put that in, but not sure what column in the registry buys us at that point * Klensin - Believes that minimal text can be written without spinning off into separate document * Resnick - Willing to give it a shot #### #80 G.6. Clarify where the protocol stands with respect to submission and TLS issues {#80-g6-clarify-where-the-protocol-stands-with-respect-to-submission-and-tls-issues} * https://github.com/ietf-wg-emailcore/emailcore/issues/80 * Melnikov - Asks for volunteers to review text * Klensin - Volunteers to review text in A/S and take another look at the text; wants to make sure we tread carefully and don't overpromise #### #38 Possible clarification of 78 octet limit versus the 998 line length limit) {#38-possible-clarification-of-78-octet-limit-versus-the-998-line-length-limit} * https://github.com/ietf-wg-emailcore/emailcore/issues/38 * Removed from agenda #### Final Notes {#final-notes} * New drafts anticipated shortly. Will ask for detailed review of both at that time. * Request made for participant "oooonduke" to identify themselves; participant declined. #### Chat log {#chat-log} John Levine chat testing 1..2..3 12:01:35 Kenneth Murchison Hi John 12:01:42 Pete Resnick Is meetecho being very slow for others? Taking me forever to get in the room. 12:03:10 Kenneth Murchison Was ok for me 12:03:20 Barry Leiba It was slow for me as well. 12:03:32 Pete Resnick Shwew! Finally in! 12:04:01 Barry Leiba And now I hear no audio. 12:04:34 John Levine audio OK for me 12:05:29 Todd Herr Who is "oooonduke"? 12:05:34 Pete Resnick Now is for me too 12:05:36 Dave, do you think more text is needed to make clear it is only an example? 12:11:22 Kenneth Murchison Alexey, you're muted 12:21:07 Pete Resnick Damn. Lost audio. 12:21:08 Ah! 12:21:14 John Klensin (Nodding vigorously) 12:26:57 John Levine I'll do it 12:32:45 Kenneth Murchison I will as well 12:32:55 John Levine I can look at that too 12:35:00 Dave Crocker A/S. Yes, I missed that this was for that. I think that only modifies my comment to the extent that the A/S document is /much/ free to engage with these issues. 12:45:12 Alexey Melnikov Pete, lost your sound 12:50:34 Pete, reset your sound? 12:50:47 John Klensin If I am not disqualified by nominally being an author on the A/S, I'll volunteer to go back through this 12:56:44 Alexey Melnikov As you didn't write the text, I think it is fine 12:58:18 Kenneth Murchison This co-author of A/S is grateful for all of the suggested text that has been promised 12:59:39 John Levine email is wanzerbusi@yahoo.co.jp 13:02:47 Kenneth Murchison bye all 13:03:24 Pete Resnick Excellent! Thanks! 13:03:29 Alexey Melnikov Thank you all! 13:03:39