--On Friday, May 15, 2015 01:04 +0000 Amanda Baber via RT
<drafts-approval(_at_)iana(_dot_)org> wrote:
Dear Author:
ATTENTION: A RESPONSE TO THIS MESSAGE IS NEEDED
Amanda and IANA colleagues,
I don't know who sees "draft-klensin-smtp-521code.all" so am
taking the liberty of copying Tony Hansen and John Levine on
this because some of the comments below may be relevant to them.
I am also copying Alex van den Bogaerdt to prevent a loop and to
note that this IANA action may not be an appropriate place to
ask for a registry change that is not associated with the
approved I-D in question.
Comments inline below.
We've completed the IANA Actions for the following RFC-to-be:
draft-klensin-smtp-521code-07
ACTION 1:
IANA has updated the "Associated basic status code" and
"Reference" fields for the following Enumerated Status Code:
Code: X.3.2
Sample Text: System not accepting network messages
Associated basic status code: 453, 521
Description: The host on which the mailbox is resident is not
accepting messages. Examples of such conditions include an
immanent shutdown, excessive load, or system maintenance. This
is useful for both permanent and persistent transient errors.
Reference: [RFC3463] (Standards Track);
[RFC-klensin-smtp-521code-07] (Standards Track) Submitter: G.
Vaudreuil
Change Controller: IESG
I don't know where "immanent" came from, but it wasn't from
either draft-klensin-smtp-521code-07.txt or RFC 5321. It is
clearly an error, because none of the definitions I can find for
"immanent" make any sense at all in this sentence. It does
appear in RFC 3463, so is an error there that was copied into
the registry. I suspect that "imminent" was intended, but the
question of what procedure you need to fix that error is outside
my authority. If you are going to continue to list Greg as the
responsible party for these codes even after you make changes to
them, you might ask him, but I don't think that would be very
productive.
In any event, because, as your description above indicates,
draft-klensin-smtp-521code-07 does not change that "Description"
field and you have not done so, I suggest that you mark this
change correctly completed as far as
draft-klensin-smtp-521code-07 is concerned and then sort the
spelling error out with the IESG at your mutual convenience
(Alex, please see note at end).
I hope we do not need to file an erratum on RFC 3463 and push it
through the system to get that fixed.
From the perspective of draft-klensin-smtp-521code-07, the only
registry change associated with that entry is in adding "521" to
the "Associated Basic Status Code" column; that changes was
implemented correctly.
Please see
http://www.iana.org/assignments/smtp-enhanced-status-codes
ACTION 2:
IANA has updated the "Reference" columns for the following
Enumerated Status Code:
Code: X.1.10
Sample Text: Recipient address has null MX
Associated basic status code: 556
Description: This status code is returned when the associated
address is marked as invalid using a null MX. Reference:
[RFC-ietf-appsawg-nullmx-10] (Standards Track);
[RFC-klensin-smtp-521code-07] (Standards Track) Submitter:
J. Levine, M. Delany
Change Controller: IESG
Please see
http://www.iana.org/assignments/smtp-enhanced-status-codes
The "reference" change is correct and is correctly implemented.
I am agnostic as to which names you list in your "Submitter"
column, i.e., listing Levine and Delany is fine with me although
I can argue it either way.
Please let us know whether the work described above was
completed correctly. As soon as we receive your confirmation,
we'll notify the RFC Editor that the document's IANA Actions
are complete.
The work has been completed correctly, see above.
We'll update the references when the RFC Editor notifies us
that they've assigned a number.
thanks,
john
Alex: draft-klensin-smtp-521code was written ("thrown together"
might be more accurate) for the convenience of the community to
eliminate a procedural problem and avoid wasting time. You are
sort of an innocent victim, but I'm going to be quite resistant
to the introduction of extraneous issues that cause further
delays. Again, there is no question that "immanent" was an
error, but it is not one that is associated with this IANA
action and, while it is probably good that the error be caught
and fixed, I actually wonder why Amanda included fields in her
note that IANA did not change in any way.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp