Minutes interim-2023-emailcore-01: Tue 17:00
minutes-interim-2023-emailcore-01-202303071700-00

Meeting Minutes Revision of core Email specifications (emailcore) WG
Date and time 2023-03-07 17:00
Title Minutes interim-2023-emailcore-01: Tue 17:00
State Active
Other versions markdown
Last updated 2023-03-08

minutes-interim-2023-emailcore-01-202303071700-00

EMAILCORE Interim, March 2023

Chairs

Scribe

  • Todd Herr

Attendees

  • Barry Leiba
  • Dave Crocker
  • John Klensin
  • John Levine
  • Kenneth Murchison
  • Pete Resnick
  • Oooonduke (wanzerbusi@yahoo.co.jp)
  • Robert Stepanek

Minutes

#74 Syntax of Received header field need to be clarified

#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?

  • 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

  • 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

#85 Add text to A/S about what mail agents should do/not do with Received header fields

#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

  • 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

#38 Possible clarification of 78 octet limit versus the 998 line length limit)

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

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