Session Date/Time: 07 Dec 2022 16:30

EMAILCORE

Summary

The EMAILCORE working group discussed several IANA registry policies, including those for literal tags, transport types, "Via" clauses, additional registered clauses in message header fields, and SMTP extensions. The group made progress towards updating several registration policies, largely favoring "RFC Required" or a dual-track approach for new registrations to balance review with facilitation. Discussion on the Trace header field registration was deferred. The session also touched on Applicability Statement (AS) issues related to TLS, octet limits, and date/time semantics, with specific action items for follow-up.

Key Discussion Points

Trace Header Fields:
- The working group determined it was not yet ready for a full discussion on trace header fields due to ongoing mailing list and offline discussions.
- A design team will be formed to propose specific changes to RFC 5321 and RFC 5322 regarding trace header fields, building on discussions from IETF 115.
IANA Registry Policies:
- Literal Tags:
  - Currently, the policy is "standard section," with only IPv6 registered.
  - A strong sense of those present indicated that the policy should remain "Standards Action" to prevent the registration of non-standard or "nonsense" values like "ipd10," ensuring the integrity of the registry. It was noted that RFC 5321 already states "None are anticipated at this time."
- Transport Registries:
  - The current policy is "Standards Action or IESG Approved Experimental."
  - It was suggested that this phrasing predates "IETF Review" and that moving to "IETF Review" would be appropriate, leaving it to the IESG to approve informational documents.
  - The chair noted observations of unregistered values (e.g., HTTP, HTTPS) in use, suggesting a need for a pathway for informational registrations.
  - Discussion covered the balance between quality assurance and facilitating registrations. While some preferred "IETF Review" given IESG's stance on informational documents, a sense of those present leaned towards "RFC Required" or "Specification Required" to prevent duplicates and ensure some review, acknowledging that IANA faces challenges in recruiting and retaining experts for "expert review" policies. "RFC Required" was seen as a workable compromise.
- Via Registry:
  - Only two values are currently registered. It was noted that other transports (e.g., multicast email, QUIC) would benefit from registration.
  - There was a sense that the arguments made for "Transport Registries" also apply here.
  - A proposal for "RFC Required" for this registry was made.
- Additional Registered Clauses (in existing message header fields, e.g., Received):
  - There are four such values from existing RFCs.
  - This category was considered potentially more dangerous than other registries, as these are clauses within heavily used fields like Received. Concerns were raised about the potential for interoperability problems if new clauses are introduced without sufficient review.
  - A poll was taken, indicating a slight preference for "IETF Review." Some participants indicated that the bar for registration for these clauses should be higher (e.g., "Standards Action"), while others could live with "IETF Review." The extensibility of Received headers was noted, with some implementations handling new clauses, but also observed "brokenness."
- SMTP Extensions Registry:
  - The latest proposal in draft-16 introduces a dual-track approach: "Standard Track or IETF Approved Experimental" for those seeking community review, and "minimal effort first-come, first-served" where IANA ensures no name conflicts.
  - There was broad support for this proposal as it strikes a good balance between review and ease of registration.
Applicability Statement (AS) Issues:
- Relationship to TLS and Transport Security (Ticket 54):
  - Text from RFC 5321bis regarding TLS and Transport Security was identified.
  - It was suspected that the current document text is sufficient, but further mailing list discussion was requested to confirm if anything needs to be added.
- 78-octet limit versus 998-length limit (Ticket 78):
  - Some suggested text was proposed for clarifying the relationship between these limits.
  - Participants expressed general willingness to include clarifying text if a clear problem was being addressed, though some were inclined to leave it as is if no ambiguity was evident.
- Date/Time issues (Ticket 105):
  - Concerns were raised about potential conflicts or ambiguities with the sedate/calext working group regarding timezones and future dates, especially as current email specs typically treat Date fields as timestamps, while other specs might propose future dates.
  - A specific action was proposed to coordinate with sedate/calext to find a middle ground or ensure clear language in both the AS and sedate/calext specifications if differences persist.

Decisions and Action Items

Decision: Chairs to create a design team (including chairs and editors of RFC 5321/5322) to come up with specific changes for trace header fields.
- Action Item: Chairs to send a message to the mailing list seeking volunteers for the trace header fields design team. (Peter noted by email).
Decision: "RFC Required" is the proposed registration policy for the IANA "Via" Registry.
Decision: The dual-track registration approach for the SMTP Extensions Registry, as described in draft-16, was supported by the working group.
- Action Item: Chair to announce on the mailing list the intention to move forward with the SMTP Extensions Registry policy in draft-16, allowing 24 hours for responses before proceeding with document changes.
Decision: Discussion on the registration policy for "Trace" field declarations was deferred due to its interaction with other ongoing trace header field discussions.
Action Item: Chairs to post a suggested resolution for the "Additional Registered Clauses" policy (IETF Review) to the mailing list, asking for objections.
Action Item: The working group will discuss on the mailing list if any text needs to be added to the AS document regarding the relationship to TLS and Transport Security (Ticket 54).
Action Item: A small group (co-author of the future-looking date specification, AS editors, WG co-chairs, and Francesca from sedate/calext leadership) will be formed to address Date/Time issues (Ticket 105), specifically to find a middle ground or develop clear language for potential differences between email specifications and sedate/calext specifications regarding date semantics. Francesca will follow up on this.

Next Steps

The chairs will follow up on the action items regarding mailing list announcements and formation of the design team and the small group for date/time issues.
The chair will provide more information from parsing experiments of Received header fields in the coming weeks to the working group.