Re: [ietf-smtp] draft-freed-smtp-limits

["Murray S. Kucherawy" <[e-mail]>]

Speaking only as a participant here:

On Fri, Aug 4, 2023 at 1:49 PM John C Klensin <[e-mail]> wrote:

> p.s. I've gotten several other comments from Murray.


That guy's the worst.


> >> * The whole business about caching (Section 3.8). Dave pointed
> >> out an issue or two in November and Murray pointed out a
> >> different set in an AD review of the draft.  I fixed the issue
> >> Dave raised that was obvious, but then there are the others.
> >> While I've been trying to ignore the issues, that clearly will
> >> not work.  Those issues include conditions under which the
> >> cached data should be reset, what a new EHLO command in the
> >> same session, or a different session, in which the extension
> >> is not mentioned means (including where a server response
> >> should include limit values or whether that is optional, etc.
> >> Options that I can see now include just dropping the
> >> subsection or trying to identify and cope with all of the
> >> cases the current text leaves uncertain.  The latter would
> >> take us into "what would Ned have wanted" territory as well
> >> and some non-trivial technical issues.  Thoughts?
>

The more I think about how caching could work, the more I'm bothered by the
ambiguity of it.  For instance:

* Do we have any advice about how long caching should be done?  Should I be
free to reuse limits I saw a year ago?

* What should the client do when LIMITS is present during session #1 but
absent from session #2?  This has ambiguous meaning, i.e., the client
doesn't know if the server means "Use standard SMTP limits for this
session" by omitting the extension; applying cached limits could mean an
unnecessarily degraded session.

>> There is also an odd complication with the IANA considerations
> >> and registration of new limits (See Section 7.2).  The text
> >> says "Specification Required" but the current registry and
> >> subregistry for Service Extensions and their parameters
> >> specify Standards Action or IESG-approved Experimental.  We
> >> went through the problems that causes, and why Specification
> >> Required isn't a good answer either, in EMAILCORE and I think
> >> the two-model system specified there is probably right for
> >> this case, especially since approval of 5321bis will change
> >> the requirements for those registries.  So, unless we want
> >> LIMITs and its parameters to be unique among extensions,
> >> either I need to write some tricky text, or we need to create
> >> a normative reference to 5321bis (holding up publication of
> >> this), or the either long-promised revision to 8126 or the
> >> long-threatened update to it to include just that option (an
> >> I-D I started on two weeks ago when I noticed the "need to do
> >> something about this" note in 5321bis).   Thoughts?
>

I like the idea of a registry that accepts provisional registrations under
FCFS and permanent ones under IETF Review, or something of that ilk.

-MSK, hatless