Re: [ietf-smtp] SMTP Reply code 1yz Positive Preliminary reply

John C Klensin <john-ietf@jck.com> Sun, 08 March 2020 18:12 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0354A3A0E7F for <ietf-smtp@ietfa.amsl.com>; Sun, 8 Mar 2020 11:12:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LgBTstkQtiX6 for <ietf-smtp@ietfa.amsl.com>; Sun, 8 Mar 2020 11:12:43 -0700 (PDT)
Received: from bsa3.jck.com (bsa3.jck.com [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA5DF3A0E7E for <ietf-smtp@ietf.org>; Sun, 8 Mar 2020 11:12:43 -0700 (PDT)
Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1jB0Pq-000H00-EH; Sun, 08 Mar 2020 14:12:42 -0400
Date: Sun, 08 Mar 2020 14:12:37 -0400
From: John C Klensin <john-ietf@jck.com>
To: hsantos@isdg.net
cc: ietf-smtp@ietf.org
Message-ID: <C0154AAD9F5BFF3C532635CB@JcK-HP5.jck.com>
In-Reply-To: <5E651680.2040401@isdg.net>
References: <1583290845.3368.15.camel@gmail.com> <aedd19df-c406-2513-934e-4498ae159964@pscs.co.uk> <5E6128C8.7070001@isdg.net> <5E613D31.70301@isdg.net> <CFEDA025D86BD13BB8D15A56@PSB> <5E61B94D.9020104@isdg.net> <466b05c4-8db2-b0d8-8e87-8e8034aea97b@pscs.co.uk> <5E626AB7.60201@isdg.net> <077D34FA57C4F80562C7AF83@PSB> <5E651680.2040401@isdg.net>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/XQe9HIDc0X1xA4pRlYiJRFGpilQ>
Subject: Re: [ietf-smtp] SMTP Reply code 1yz Positive Preliminary reply
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-smtp/>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Mar 2020 18:12:45 -0000

(top post)

Hector,

Ok.   Unless someone has a convincing reason wh7 not and
expresses it before I get around to it, -03 will be posted
before the deadline.  I-Ds are cheap and I don't need to do a
lot of work to get from the current XML to a posted version.

The note at the end of the Acknowledgments section started out
as strictly a comment about errata.  I've changed the date,
rather arbitrarily, to 1 July.   I am keeping a list although it
is currently scattered through the document and my internal
comments.  I actually have a reason for not including a specific
list at this time:  Suppose someone suggested modifying 5321bis
to require the use of DNSSEC records and validation before an MX
record could be believed.  Because I'm trying to not make
judgments, I would include that request in Appendix G even
though I can predict with great confidence that it would swiftly
be taken off the list for 5321bis when a WG reviews (or triages)
it.  I would like to discuss with the WG whether the person and
others who made similar suggestions (but were otherwise not
influential in contributing  to the document) should be included
in the acknowledgments.  If the conclusion after that WG
discussion is "no", I don't want to remove names between
versions of the I-D.  So, until there is a WG, no explicit
acknowledgments.  One that the WG does the triage and has that
discussion, you and others will be picked back up and, if the WG
so concludes, I'll copy the whole lists of those who contributed
to 2821 and 5321 into this document as well.

best,
   john


--On Sunday, 08 March, 2020 12:00 -0400 Hector Santos
<hsantos@isdg.net> wrote:

> Hi John,
> 
> On 3/6/2020 11:24 AM, John C Klensin wrote:
>> A placeholder for whether we need to review some of all of the
>> timeouts has been added to the working copy of 5321bis-03.  As
>> with all of the other Appendix G entries for which there is
>> not already text in the I-D (text that was inserted either as
>> an obvious fix or after extended discussion on this list), I
>> am taking no position about what, if anything, should be
>> done: I'm just keeping a list.  One implication of that is
>> that, if anyone is going to suggest something that they don't
>> think belongs on the list... well, either say that or don't
>> suggest it.
> 
> You have much in Appendix G. All appears to be legit issue to
> review.   Thanks for the addition of my recent comments. The
> only thing that stood out and can't get it out of my mind, is
> the change to the Acknowledgments. I personally don't feel
> good about it. But as part of my stress reduction therapy, I
> just deleted a paragraph describing my feeling about that
> change. I will just say, it has served as a "small badge" of
> honor to be recognized as a long time participant and
> implementor of SMTP for a number of decades.
> 
>> Question for this list: I have not planned on posting -03
>> until we have a WG.  It differs from the current draft on the
>> servers (-02) only in that Appendix G has been expanded a
>> bit, most recently with the "1yz" and timeout topics.  If
>> anyone thinks having it posted before IETF 107 would be
>> helpful, e.g., to facilitate any informal conversations that
>> might occur then, please say so and say so soon.
> 
> +1 I think I-D -03 should be submitted before IETF 107 for the
> reasons you stated.