--On Thursday, July 12, 2018 16:58 +0100 Alexey Melnikov
<alexey(_dot_)melnikov(_at_)isode(_dot_)com> wrote:
Hi,
I would like to add a new value to the "WITH protocol types"
subregistry (see
<https://www.iana.org/assignments/mail-parameters/mail-paramet
ers.xhtml#mail-parameters-5>) which is not going to be
specified in an IETF Stream RFC. The current registration
policy is defined in RFC 5321 as "Standards Action or
IESG-Approved Experimental RFC". Is the registration policy
too strict and should it be relaxed to allow something like
"Specification required" choice, so that registrations can be
added by, say, Independent Stream RFCs?
Alexey,
Valdis's concerns aside (personally, I would not want to see a
"with" value in the registry unless it could point to a
well-documented and publicly available specification of the
gateway, not just the "SMTP over..." specification), I see two
nearly-procedural issues with your question.
First, we cannot just agree to make this type of change to the
registry requirements. It would have to be done via a
standards-track update to RFC 5321. Just my opinion (although
based on experience), but I believe that embarking on such an
update would create some pressure to review the errata file and
update 5321 to fix other issues that have been identified along
the way (including addressing the ""@domain issue in 5321 and
5322 and possibly some other areas of overlap) and would also
bring people out of the woodwork who would say "if you are
updating 5321, I have the final ultimate solution (FUS) to XYZ
that should be included in the update".
It is not clear to me that there is sufficient energy to open
those cans of worms. Speaking personally and as editor of
5321, I could find the energy for the first, although I would
probably push for a complete 5321 update/replacement at the same
time (actually less work for me given the way I've kept notes on
errata) but don't have much energy for dealing carefully and
respectfully with trolls, purveyors of FUS ideas, and people
with bright ideas who don't understand Internet mail well enough
to put those ideas in context.
Second, your question is, through little fault of your own,
badly-timed. The IESG has an appeal in front of it because the
IESG concluded that a document, processed as an Independent
Submission, should not be published because it interacted with
IETF work, despite the IANA Considerations sections of the
relevant documents not calling for IETF or IESG review of any
sort. My understanding at this point (and I am thoroughly
confused about the IESG's reasoning, so this may not be correct)
is that the reasoning was that the extension implied by the
specification in that document could change the character of the
underlying standard (or non-IETF work) sufficiently that its
publication without IETF review and action was inappropriate.
Against that backdrop, an attempt to shift anything that the
community concluded, in a standards-track document that is
rather clear about it, required IETF review and action --
presumably at least for clarity, completeness, and
appropriateness -- into the Independent Stream seems wildly
unwise, at least until the IESG responds to the appeal by
clarifying where the boundary of what is acceptable for
Independent Stream publication lies and that the boundary isn't
just about excuses to try to suppress documents some or all IESG
members don't like (the latter would almost certainly lead to
more appeals or serious unpleasantness).
So my suggestion is that you put this question aside until at
least after the situation that caused the appeal is clarified
and, if the outcome of the RFC++ BOF is, as some of the
suggestions on that mailing list have suggested, that the
Independent Stream be discontinued, exported, or changed in
other significant ways, where that discussion is headed.
In that context, I wonder if the Independent Stream would look
equally attractive for this purpose if its documents were not in
the RFC Series. I also whether the IESG is prepared to launch
work to update every document whose IANA Considerations says
"Informational or Experimental RFC", "including Independent
Stream publications", or the like to allow for new labels and
new terminology?
best,
john
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp