On 7/12/2018 1:20 PM, John C Klensin wrote:
There were, IIR, two major concerns. One was to get at least a
clarity and minimum technical review on gateway specs because
real problems could be caused, on both sides of the gateway by
sloppy work, security-, content-type-, or identity-related
assertions that didn't hold up, etc. Those issues would
obviously not be a problem for the keyword itself, but, because
we've published very few proprietary (or even public, but
non-SMPT) mail transport specs in the RFC Series, the gateways
seemed to be a way to get a handle on the problem, references to
the transport specs, etc. Would some people ignore the rules
and simply use their own? Sure, but that would give anyone who
cared about "with" a possible clue about trust, which would not
be a bad thing.
So, let's wander down this path a bit. It sounds plausible and, more
importantly, I think it summarizes a style of thinking about
registrations that has been common in the IETF (including mine, fwiw.)
Over time, my own views have changed. Where I currently sit is that we
need to avoid conflating 'registration' with 'quality assessment'.
It makes sense to merge them when there is serious danger in registering
use of a bad spec, but I believe those cases are extremely rare.
My view for registration is that it typically needs to accomplish two
1. Reserve a name, to avoid collisions
2. Identify an accountable entity for use of the name, typically
through an accessible document controlled by that entity.
For something like the WITH parameter, I think the issue is being able
to track down the defined meaning of the parameter, rather than trying
to make sure that conduct a quality assurance process on the
specification of that meaning. This latter task is what standardization
is for, not registration.
ietf-smtp mailing list