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

[Douglas Foster <[e-mail]>]

Something is badly broken here.    How many years have been spent on a
charter to update a document but do nothing creative?   This document has
been essentially done for a year but the WG cannot finish because of  the
SHOULd instructions?

How many IEEE specifications have been meaningfully upgraded in the same
timeframe?    Clearly, if the world can wait indefinitely for a document
with perfect verbal nuance, this document must have very low importance.



On Thu, Aug 27, 2026, 5:25 AM Eric Vyncke (evyncke) <evyncke=
[e-mail]> 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
> --
> Emailcore mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>