Subject: [Emailcore] Relaxing the IANA registration requirement for SMTP Extensions in rfc5321bis

From: John C Klensin <[email-masked]>
Date: Tue, 22 Mar 2022 08:52:10 -0400

Hi.

Having become increasingly convinced over the years that high
barriers to IANA registrations (of most types) don't necessarily
improve quality but definitely discourage registrations and that
the primary value of registrations is to prevent the same
keyword accidentally being used for different things, I'm in
favor of relaxing the requirements somewhat from Standards Track
or IESG-approved Experimental.

However, I'm afraid of losing something else in the process.
One of the key points in the early work on SMTP extensions was
the observation (I think first due to Marshall Rose), that too
many of them is a bad thing and that each new one poses
interoperability challenges.   That principle appears in 5321bis
in  the last two paragraphs of Section 2.2.1. 

The requirement for IETF consensus (or, with current IESG
procedures, at least a Last Call and opportunity for serious
discussion) provided, in addition to the presumed gatekeeping,
an opportunity for an IETF discussion and decision about whether
the extension is worth the trouble.  Dropping the registration
threshold even as far as Specification Required eliminates the
opportunity for that community discussion which has proven
helpful to authors of other registrations. We should mitigate
that loss by at least requiring the would-be registrants to
explain themselves.  That should not be a barrier to any serious
extension proposal but might, almost as a side effect, raise the
bar for silly vanity registrations.  The latter would presumably
be A Good Thing if it did not cause other problems.
 
Suggestion: RFC 5321 Section 8, IANA Considerations, describes
the three registries but does not actually specify what goes in
them, nor does it follow what is now the normal practice of
providing a specific registration template or list of fields and
descriptions of possible values [1].  For the SMTP Extensions
Registry, we should consider either specifying a template or a
list of things required in an application for a Service
Extension.  We could then require that the  registration
application (or other documentation) explain the problem that
the new extension is solving and the reasons why its benefits
outweigh the possible costs.

The idea above is compatible with either of the options in the
meeting slides (at least the last time I looked at them).

    --john

[1] Should the IESG decide to impose current standards, it is
fairly clear to me that Section 8 of RFC 5321 is not in
compliance with Section 2 of RFC 8126/ BCP 26.  So, unless
people are convinced that it will slip through because of the
older document(s), we may want to think about revising that
section anyway.

---

From: "John Levine" <[email-masked]>
Date: 22 Mar 2022 12:38:38 -0400

>or IESG-approved Experimental.

My inclination is somewhere between specification required and
expert review, with the understanding that the point of the review
is just to see that the specification is at least superficially
plausible.  We have our share of unused extensions (MTRK, CONNEG, ...)
and I'm not worried that there is a flood of worse ones waiting.

>Extension.

That would be a good idea.  Yesterday Alexey and I realized that
5321 says VRFY is a service extension that somehow never made it
into the registry.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Fri, 25 Mar 2022 01:12:29 -0400

--On Tuesday, March 22, 2022 12:38 -0400 John Levine
<[email-masked]> wrote:

>> favor of relaxing the requirements somewhat from Standards
>> Track or IESG-approved Experimental.
> 
> expert review, with the understanding that the point of the
> review is just to see that the specification is at least
> superficially plausible.  We have our share of unused
> extensions (MTRK, CONNEG, ...) and I'm not worried that there
> is a flood of worse ones waiting.

The cases that have gotten me concerned are variations of some
of the recent discussions about media types.  RFC 8494 opened
the door to specialized uses of SMTP, uses that an Expert or
Expert team might not fully understand.  While 8494 (IMO) does
not have that problem and does not introduce any new extensions
(as far as the extension system is concerned, it is basically a
profile).  I don't think it is hard to imagine some specialized
use coming along that involves a new extension or two for which
the descriptions could be entirely plausible but
incomprehensible to most of us.  My instinct is that figuring
out a way to do a community Last Call in conjunction with Expert
Review -- Murray and I have kicked that back and forth a bit and
probably the right way to do it is to stick with IESG review but
involve the Designated Reviewers in the evaluation of the
document and the Last Call and have the IESG's role be mostly
pro-forma.

>> the three registries but does not actually specify what goes
>> in them, nor does it follow what is now the normal practice of
>> providing a specific registration template or list of fields
>> and descriptions of possible values [1].  For the SMTP
>> Extensions Registry, we should consider either specifying a
>> template or a list of things required in an application for a
>> Service Extension.

> That would be a good idea.  Yesterday Alexey and I realized
> that 5321 says VRFY is a service extension that somehow never
> made it into the registry.

I think that is a separate problem.  I wish 5321 was more clear
(and hope we can fix that) but VRFY support is (modulo the usual
loopholes) required by 5321 but still required to be listed in
EHLO responses.   That makes it a required feature that is
treated as a service extension (and, if you and Alexey found
statements that seem to contradict other statements... well, I
would not be terribly surprised). From the standpoint of the
registry, especially in the days when there was no such thing as
a required extension, that means is it not an extension at all
and should not be listed.  From the standpoint of common sense
and minimization of confusion, it should clearly be in the
registry, perhaps with a brief note.

best,
   john