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

[John C Klensin <[e-mail]>]

--On Friday, August 4, 2023 14:36 -0700 "Murray S. Kucherawy"
<[e-mail]> wrote:

> 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.

Except that all of your comments were to the point, insightful,
and useful.  If you are aspiring to "worst", you have a long way
to go :-)

>> >> * 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.

Yeah.  See my note to Dave about taking it out, which the above
reinforces.

>>> 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.

What 5321bis sets up is that both are permanent, but the
registry identifies registrations based on the path they
followed (and allows FCFS ones to be reregistered by the
submitter under IETF review-like provisions).  That was a
pragmatic choice (possibly largely mine but the WG has not
objected) based on a desire to avoid figuring out what
"provisional" actually means and, in particular, sounding like
those FCFS registrations were not "real" until they were pushing
into IETF consideration.  Of course, identifying the model used
allows someone looking at the registry to tell the difference
between "someone's bright idea" and "something actually
considered by the IETF".  Presumably the latter still has value.

best,
  john