[Emailcore] Registration is for coordination, not coercion

[Dave Crocker <[e-mail]>]

(Subject line changed, to focus on a basic point of concern.)


On 7/11/2021 1:44 PM, Ned Freed wrote:
> SMTP extensions are another matter. SMTP clients and servers both
> have to be modified in an interoperable way, and to deploy an
> extension to any significent extent likely means modifying more than
> one of each. And for the rare extension that does deploy and which do
> something people want, tracking down information on them in other to
> "keep up" can be a bit of pain.


The IETF has always been a bit confused about enforcement. The use of 
normative language encourages the misguided view that authors have a 
force of law over other folk.  This then extends into the realm of 
registration.  And yet the IETF's success did not come from coercing use 
but from satisfying needs.

When there is limited space for registration, figuring out a 
possibly-restrictive policy for allocations is required.  In other 
cases, it probably isn't.

The view that restrictive registration policies are otherwise necessary 
seems to come from a failure to distinguish tasks.  Standardization is 
where community 'approval' lies.  Not registration.  Registration is for 
disciplined administerion of an identification space.

We invoke a vague fear of potential harm from an allocation that 
involves activity that is not properly vetted.  So we require a 
specification, or even that it be standardized.  But the danger of 
requiring neither lacks a demonstrable danger.  Intuitively, the fear is 
reasonable, but, well... you know... theory vs. practice...

Say a random SMTP extension name is registered, and it has no 
specification.  As long as the meta-rule is "ignore what you don't 
understand", what is the danger?  And note that this case is already 
present, for UNregistered identifiers.  So, really, the question is what 
is the incremental danger from registering such allocations?

Say a random SMTP extension name is registered and has an associated 
specification that is crappy.  For this to cause meaningful damage both 
client and server implementers must fail to see how crappy it is. 
Again, this case already happens, such as with some 'experimental' 
specifications that actually do get IETF approval; and maybe even some 
standards track ones.  Again, what is the danger?

There is an absolute, community good to encouraging registration, 
because it makes it unlikely there will be name collisions; it 
advertises the existing of an extension activity, and it makes clear who 
is in charge of use of the name.

Even requiring a published specification decreases that good.

IETF standards do not succeed because their use is required but because 
the community likes the standards.  Registration should use the same model.

It's not that associating a specification isn't also a good.  And it 
isn't that standardization isn't a good.  It's that making them barriers 
to entry into a registration space is a bad.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net