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

[Dave Crocker <[e-mail]>]

On 8/6/2023 8:33 PM, John C Klensin wrote:
> --On Sunday, August 6, 2023 18:36 -0700 Dave Crocker
> <[e-mail]> wrote:
>> I think that having two registries confuses tasks and meaning,
>> and makes it more effort to get registered and ambiguous to
>> use.
> While 5321bis (through -19) allows for the possibility of two
> registries (following some of the provisional/permanent splits)
> there is nothing in that draft that requires anything more than
> a single registry with a flag that indicates which option was
> chosen.

By option I assume you mean the distinction between permanent and 
provisional.  My point is that that distinction is the problem.

Having it presumes operational benefit that must be embedded in the 
registration process and display of the registration.  My point is that 
there isn't any, although it /does/ add hassle to making and using a 
registration.


>> ...
>> Making registration effort higher makes it more likely people
>> won't bother to register.
> And that was exactly what drove the formation of the hybrid
> model.
>
>> The confusion of goals is thinking that there is benefit in
>> conflating registration with quality control.  There isn't.
>> (Well, almost never and certainly not in this case.)
> It isn't "quality control".  It could be (and, back when
> "Standards Track or..." was first specified for those
> registries, was), about genuine interest on the part of would-be
> registrants for getting input and suggestions from the
> community.  I've just looked through a number of early media
> type registrations from long ago; many of them would have been
> much worse -- requiring new keywords, registrations, and
> documents somewhere-- had they not gone through the
> standardization process.

Quality, status, and usage information about something that is 
registered belongs with the specification, not the registration.

To the extent there are cases that warrant such information as part of 
the registration, my point is that this isn't one of them.

The distinction is similar to the one that motivated defining the X-* 
header field name construct.  And it suffers the same problems.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@[e-mail]