Skip to main content

Minutes interim-2022-emailcore-03: Wed 16:30

Meeting Minutes Revision of core Email specifications (emailcore) WG
Date and time 2022-12-07 16:30
Title Minutes interim-2022-emailcore-03: Wed 16:30
State Active
Other versions markdown
Last updated 2023-02-28


Emailcore Interim - 7 December 2022

  • Recording of meeting is here -

  • Review of Agenda

  • No bashing to be heard

  • Announcement of design team to address trace header field issue and run it to the ground

  • Initial team members are Melnikov, Klensin, Resnick, Herr
  • Additonal volunteers sought
  • Melnikov action to send message to list about design team

  • G.22 IANA Registration Model for Registries Other Than Service Extensions (5321bis)


    • 8.1.2 Address Literal Tags

    • Klensin: Leave this alone ("Standard Track RFC") as a means of avoiding DoS attacks
    • Crocker: Question about "none are anticipated at this time". Is that text for 5321 or just text for the slide?
    • Answer: This text was already in RFC 5321.
  • Mail Transmission Types - Standards Action, IESG approved Experimental, or just
    IETF Review? (5321bis)

  • WITH protocol: Standards Action, IESG approved Experimental, or just IETF Review?

    • Leiba: IESG approved Experimental is phrasing from before IETF Review existed.
    • Klensin: No strong feeling about this issue.
    • Resnick: Would be ok with "RFC Required"
    • Crocker: Concerned about higher bar being imposed on registration process.
    • Lieba: Agrees with Resnick, would also be good with "Specification Required"
      Also agrees with Crocker, we're better off encouraging registrations.
    • Resnick, from chat:
      Agree with Dave on the principle. The reason header fields should be FCFS is
      because a new one doesn't really effect (sic) the interoperability of anybody else.
      Putting new things in here (marginally) increases that risk.
    • Klensin: Doesn't want to go below RFC Required. Specification Required would
      be a challenge due to lack of resources (human) at IANA.
    • Vote taken for RFC Required - 7 yes, 0 no
  • VIA link types: Standards Action, IESG approved Experimental, or just IETF Review?

    • Melnikov and Leiba: Recommend RFC Required
    • Klensin: Supports RFC Required
    • Consensus to propose RFC Required
  • Additional Registered Clauses: Standards Action, IESG approved Experimental, or just IETF Review?

    • Klensin and Resnick support perhaps something stronger than RFC Required
      for additional clauses
    • Vote conducted in chat - 3 in favor of IETF Review, one in favor of status
      quo (Standards Action or Experimental)
    • Leiba asks Klensin if he can live with IETF Review
    • Klensin: Can live with it, but requests that it be taken to the mailing list.
  • Relax IANA registration policy for SMTP extensions (5321bis)

  • Latest proposal is to define two registration models - IETF Review and FCFS
  • Latest version of SMTPbis has draft text for both models.
  • Leiba: Likes having both registration models, as he has stated on-list
  • Melnikov experiences audio issues, asks Leiba to repeat his above support for both registration models.
  • Klensin will update text to incorporate both models

  • Separate Registry for Trace Header Fields? Dual registry like with extensions?

  • Klensin: Concerned that things can be made trace fields simply by author
    declaration. Suggests dual track model, where nothing can be declared trace
    fields except by IETF Review.
  • Melnikov: Seems clear group is not quite ready for discussion of this topic
    so tabling for now.

  • Clarify where protocol stands with respect to submission and TLS issues (A/S)

  • Melnikov requests specific text to be posted to mailing list

  • 78 octet limit versus 998 line length limit (A/S)

  • Melnikov suggested some text in private message, asks Resnick for opinion
  • Resnick invites Murchison to speak; happy with A/S to contain text for this
    issue. Resnick isn't sure what's desired.
  • Murchison also isn't sure what problem is being addressed, but is happy with
    Melnikov's text

  • Timezones in Date and Received (A/S)

  • No consensus on mailing list to add any text
  • Resnick: I don't understand ambiguity that's at issue here. Not clear what
    might help people do the right thing. Inclined to leave it alone, but open
    to get clarifying text.
  • Klensin: Concerned we have another working group that's busy with timezones
    and other things, such as future dates. If we're going to differ from them,
    we should be explicit about it. Specific suggestion that emailcore chairs and
    relevant editors get together with sedate and calext working groups and come
    to agreement.
  • Melnikov, Herr, Palombini and others to discuss the above further.

Meeting concludes