Re: draft-freed-smtp-limits
"Murray S. Kucherawy" <[email protected]> Fri, 4 Aug 2023 14:36:16 -0700
| Newsgroups | gmane.ietf.smtp |
|---|---|
| Message-ID | <CAL0qLwbmaHbSdcEZ4zm65rwat24i-gByFEgiKAn8FYfU6oqgbQ@mail.gmail.com> |
--===============2734437081132994668== Content-Type: multipart/alternative; boundary="00000000000088329d06021fb07c" --00000000000088329d06021fb07c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Speaking only as a participant here: On Fri, Aug 4, 2023 at 1:49=E2=80=AFPM John C Klensin <[email protected]> w= rote: > 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 --00000000000088329d06021fb07c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr">Speaking only as a participant here:</div= ><div dir=3D"ltr"><br></div><div dir=3D"ltr">On Fri, Aug 4, 2023 at 1:49=E2= =80=AFPM John C Klensin <<a href=3D"mailto:[email protected]">john-ietf@= jck.com</a>> wrote:</div><div class=3D"gmail_quote"><blockquote class=3D= "gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2= 04,204,204);padding-left:1ex">p.s. I've gotten several other comments f= rom Murray.=C2=A0 </blockquote><div><br></div><div>That guy's the worst= .</div><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"marg= in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e= x">>> * The whole business about caching (Section 3.8). Dave pointed<= br> >> out an issue or two in November and Murray pointed out a<br> >> different set in an AD review of the draft.=C2=A0 I fixed the issu= e<br> >> Dave raised that was obvious, but then there are the others.<br> >> While I've been trying to ignore the issues, that clearly will= <br> >> not work.=C2=A0 Those issues include conditions under which the<br= > >> cached data should be reset, what a new EHLO command in the<br> >> same session, or a different session, in which the extension<br> >> is not mentioned means (including where a server response<br> >> should include limit values or whether that is optional, etc.<br> >> Options that I can see now include just dropping the<br> >> subsection or trying to identify and cope with all of the<br> >> cases the current text leaves uncertain.=C2=A0 The latter would<br= > >> take us into "what would Ned have wanted" territory as w= ell<br> >> and some non-trivial technical issues.=C2=A0 Thoughts?<br></blockq= uote><div><br></div><div>The more I think about how caching could work, the= more I'm bothered by the ambiguity of it.=C2=A0 For instance:<br><br><= /div><div>* Do we have any advice about how long caching should be done?=C2= =A0 Should I be free to reuse limits I saw a year ago?<br><br></div><div>* = What should the client do when LIMITS is present during session #1 but abse= nt from session #2?=C2=A0 This has ambiguous meaning, i.e., the client does= n't know if the server means "Use standard SMTP limits for this se= ssion" by omitting the extension; applying cached limits could mean an= unnecessarily degraded session.</div><div><br></div><blockquote class=3D"g= mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204= ,204,204);padding-left:1ex">>> There is also an odd complication with= the IANA considerations<br> >> and registration of new limits (See Section 7.2).=C2=A0 The text<b= r> >> says "Specification Required" but the current registry a= nd<br> >> subregistry for Service Extensions and their parameters<br> >> specify Standards Action or IESG-approved Experimental.=C2=A0 We<b= r> >> went through the problems that causes, and why Specification<br> >> Required isn't a good answer either, in EMAILCORE and I think<= br> >> the two-model system specified there is probably right for<br> >> this case, especially since approval of 5321bis will change<br> >> the requirements for those registries.=C2=A0 So, unless we want<br= > >> LIMITs and its parameters to be unique among extensions,<br> >> either I need to write some tricky text, or we need to create<br> >> a normative reference to 5321bis (holding up publication of<br> >> this), or the either long-promised revision to 8126 or the<br> >> long-threatened update to it to include just that option (an<br> >> I-D I started on two weeks ago when I noticed the "need to do= <br> >> something about this" note in 5321bis).=C2=A0 =C2=A0Thoughts?= <br></blockquote><div><br></div><div>I like the idea of a registry that acc= epts provisional registrations under FCFS and permanent ones under IETF Rev= iew, or something of that ilk.</div><div><br></div><div>-MSK, hatless<br></= div></div></div> --00000000000088329d06021fb07c-- --===============2734437081132994668== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ietf-smtp mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-smtp --===============2734437081132994668==--