ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] Adding a new value to the WITH protocol type subregistry

2018-07-12 17:40:48


--On Thursday, July 12, 2018 13:29 -0700 Dave Crocker
<dhc(_at_)dcrocker(_dot_)net> wrote:

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

Indeed.

Over time, my own views have changed.  Where I currently sit
is that we need to avoid conflating 'registration' with
'quality assessment'.

Yes, as have the views of several of us.  IIR, the first
document that changed a registry from strong IETF approval
requirement was the one for media types in March 1994 (RFC
1590), which gives partial credit to me, so I've been singing
that song for a rather long time.

While I think most registries that do not involve a small range
of possible values should work that way, I believe that "most"
and "small" may involve multiple issues that should be discussed
on a case by case basis.   Saying that "capture the value and a
contact and move on" or "give an opportunity for community
review but don't prevent registration if the applicant declines
that or does not agree with the community comments" should be
the default for those cases seems fine too, but I still believe
the registration procedures and issues should be looked at one
protocol at a time. 
 
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 things:

    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.

I note that, unless I am misinterpreted the trend, the IESG has
started to prefer "stable document" over "accountable entity",
especially if that entity is an individual.   Again, I think
that is a fine default but that, when we create registries or
revise the rules for them, we should be prepared to hear
arguments that more restrictive rules are appropriate and to
consider them carefully.

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.

An entirely reasonable position, but one that I hope can either
be supported or challenged and discussed when and if there is a
specific proposal to revise RFC 5321 to change the requirement.

best,
    john

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp

<Prev in Thread] Current Thread [Next in Thread>