Re: draft-freed-smtp-limits

--===============7036686901910967199==
Content-Type: multipart/alternative; boundary="000000000000ba446a06024b1f1b"

--000000000000ba446a06024b1f1b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Aug 4, 2023 at 3:10=E2=80=AFPM John C Klensin <[email protected]> w=
rote:

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

I think that sort of model is probably fine too.  My suggestion was just
based on other registries (header fields and URI schemes come to mind)
where the provisional/permanent model seems to have worked.

If this is a model that we think might be useful for other future
registries to follow, then getting it into 8126bis makes perfect sense to
me.  The provisional/permanent model is much older but since it's known to
work, we could talk about that approach as well.  What I don't know,
though, is timing; 8126bis has not, as far as I know, gotten off the ground
yet, and I wouldn't want to see 5321bis avoidably delayed.

-MSK

--000000000000ba446a06024b1f1b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Fri, Aug 4, 2023 at 3:10=E2=80=AFPM Jo=
hn C Klensin &lt;<a href=3D"mailto:[email protected]">[email protected]</a>=
&gt; wrote:</div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex">What 5321bis sets up is that both are permanent, but the=
<br>
registry identifies registrations based on the path they<br>
followed (and allows FCFS ones to be reregistered by the<br>
submitter under IETF review-like provisions).=C2=A0 That was a<br>
pragmatic choice (possibly largely mine but the WG has not<br>
objected) based on a desire to avoid figuring out what<br>
&quot;provisional&quot; actually means and, in particular, sounding like<br=
>
those FCFS registrations were not &quot;real&quot; until they were pushing<=
br>
into IETF consideration.=C2=A0 Of course, identifying the model used<br>
allows someone looking at the registry to tell the difference<br>
between &quot;someone&#39;s bright idea&quot; and &quot;something actually<=
br>
considered by the IETF&quot;.=C2=A0 Presumably the latter still has value.<=
br></blockquote><div><br></div><div>I think that sort of model is probably =
fine too.=C2=A0 My suggestion was just based on other registries (header fi=
elds and URI schemes come to mind) where the provisional/permanent model se=
ems to have worked.</div><div><br></div><div>If this is a model that we thi=
nk might be useful for other future registries to follow, then getting it i=
nto 8126bis makes perfect sense to me.=C2=A0 The provisional/permanent mode=
l is much older but since it&#39;s known to work, we could talk about that =
approach as well.=C2=A0 What I don&#39;t know, though, is timing; 8126bis h=
as not, as far as I know, gotten off the ground yet, and I wouldn&#39;t wan=
t to see 5321bis avoidably delayed.</div><div><br></div><div>-MSK<br></div>=
</div></div>

--000000000000ba446a06024b1f1b--


--===============7036686901910967199==
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

--===============7036686901910967199==--