Ok. I've also just changed my address on the ietf-smtp list to
allow me to post to that list as well as
draft-klensin-smtp-521code.all from the same address.
I consider Tony's "transcription error" to be definitive unless
someone speaks up RSN. Pearl, that means "X.10.1" should indeed
Unless someone (particularly Barry) objects within the next
couple of hours, I will post draft-klensin-smtp-521code-06,
which reflects this change and other changes that seem to be
agreed upon, later this evening or early tomorrow. The major
change is a rewrite to the discussion of code 556 to make the
client and server relationships more clear as discussed on-list
--On Tuesday, April 14, 2015 17:35 -0400 Barry Leiba
I'm tired of having to approve every post for having "implicit
destination", so please reply to this one if there's further
discussion; I've added the ietf-smtp list explicitly.
On Tue, Apr 14, 2015 at 5:30 PM, Tony Hansen <tony(_at_)att(_dot_)com>
John, you made a transcription error. The code should be
In draft-ietf-appsawg-nullmx-10, it's listed as 5.1.TBD, and
IANA assigned a 10 to the TBD.
On 4/14/15 4:38 PM, John C Klensin wrote:
--On Tuesday, April 14, 2015 12:21 -0700 Ned Freed
No doubt I'm missing something obvious, but where do I see
this comments on the new datatracker?
In the "History" tab. Trouble is that the IANA review
isn't well marked (never has been).
So today's message refers to the comments made two weeks
This seems odd, but OK.
Ned (and others),
That aside, the real issue here is that someone needs to
check the extended code and either reassure IANA that it is
correct (and that the document should say "register the
code") or tell them (and me) that I made a typographical or
transcription error. As I've told Barry and a few others,
my IETF time is completely tied up with URNBIS, some
closely-related issues (including whether or note the URI
scheme registration document has important side-effects),
and some IAB-related stuff. If I'm not actually on travel,
I would have time to patch some text into the
otherwise-ready-to-go -06 of this document, but not the
bandwidth to study the extended codes. If someone who is
closer to them than I am could do that, we could probably
get this document cleared rather than wondering what is
happening with it.
ietf-smtp mailing list
ietf-smtp mailing list