[Emailcore] Re: Éric Vyncke's Discuss on draft-ietf-emailcore-as-29: (with DISCUSS and COMMENT)

[Alexey Melnikov <[e-mail]>]

Eric,

Please help me understand what needs doing to satisfy your DISCUSS.

Would a new table in Section 2.4. (Use of SMTP Extensions) listing reasons for each extension that is listed as a SHOULD? For example, for PIPELINING it would say that the extension improves performance, but lack of its support doesn't break interoperability? If this doesn't work, please give me an example?

Thank you,
Alexey

On Thu, Aug 27, 2026, at 10:25 AM, Eric Vyncke (evyncke) wrote:
> Alexey, John, and others,
> 
> Thanks for the -30 revision as it addresses some of my COMMENT-level concerns.
> 
> Alas, it does not address the core of my blocking DISCUSS issues even if the text in A.31 contains `Modified most SHOULD and SHOULD NOT recommendations to explain the reasons.  Ones that were already explained are untouched.` as I failed to spot these explanations.
> 
> Perhaps a PR that was not merged ?
> 
> Regards,
> 
> -éric
> 
> 
> *From: *Eric Vyncke (evyncke) <[e-mail]>
> *Date: *Thursday, 16 July 2026 at 16:03
> *To: *Alexey Melnikov <[e-mail]>; The IESG <[e-mail]>
> *Cc: *[e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; Murray S. Kucherawy <[e-mail]>; David Lawrence <[e-mail]>
> *Subject: *Re: [Emailcore] Éric Vyncke's Discuss on draft-ietf-emailcore-as-29: (with DISCUSS and COMMENT)
> 
> Hi Alexey,
> 
> About the SHOULD in section 2.4, the 'compatibility' issue is part of the IESG statement: see "
>  • Sometimes these key words are used as a way to allow for backward compatibility when introducing a change into an existing deployment. If this is the case, document authors should make it explicit that this is the reason these are used. Additional text explaining that this is the only legitimate reason to deviate from the normative advice is preferred. An alternative approach is to stipulate “All new implementations MUST do $NEW_WAY but SHOULD also accept $OLD_WAY [for some period of time] for backward compatibility”.
> "
> 
> Using a similar text in the I-D would fully address this DISCUSS issue.
> 
> Regards
> 
> -éric
> 
> 
> *From: *Alexey Melnikov <[e-mail]>
> *Date: *Thursday, 16 July 2026 at 15:40
> *To: *Eric Vyncke (evyncke) <[e-mail]>; The IESG <[e-mail]>
> *Cc: *[e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; Murray S. Kucherawy <[e-mail]>; David Lawrence <[e-mail]>
> *Subject: *Re: [Emailcore] Éric Vyncke's Discuss on draft-ietf-emailcore-as-29: (with DISCUSS and COMMENT)
> Hi Éric,
> Thank you for your review. Replying only to the DISCUSS portion of your ballot below:
> 
> On Thu, Jul 2, 2026, at 1:57 PM, Éric Vyncke via Datatracker wrote:
> > Éric Vyncke has entered the following ballot position for
> > draft-ietf-emailcore-as-29: Discuss
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> >
> > # Éric Vyncke INT AD comments for draft-ietf-emailcore-as-29
> > CC @evyncke
> 
>  [snip]
> >
> >
> > ## DISCUSS (blocking)
> >
> > As noted in
> > https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/,
> > a DISCUSS ballot is a request to have a discussion on the points below;
> > I
> > really think that the document would be improved with a change here,
> > but can be
> > convinced otherwise.
> >
> > ### Section 2.4
> >
> > Why not a "MUST" in `All of those SHOULD be supported` as this sounds
> > like a
> > good action. See also:
> > https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/
> 
> This was a very deliberate choice by the WG and I would like to push back on this.
> 
> SHOULD level requirements are things that would improve performance (e.g. PIPELINING), functionality (Internationalized Email) or error reporting/debuggability (e.g. Enhanced Status Codes). However they are not universally available. As much as we would like to encourage their use, things mostly work without them, thus use of SHOULD.
> 
> Existing implementations already have to cope with their absence.
> 
> > ### Section 3.3
> >
> > Why not a "MUST" in `When performing such functions, the MUA SHOULD` as
> > this
> > sounds like a good action. See also:
> > https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/
> 
> The basic point of this section: if you create a new message from a template, strip/sanitize all data that you don't understand or which are known to be transport related (e.g. Received).
> 
> I think the WG felt that there were more advanced versions of this functionality where some information might be worth preserving contrary to the above advice.
> 
> Best Regards,
> Alexey