Re: [ietf-smtp] Possible cont4ibution to moving forward with RFC5321bis SMTP

Dave Crocker <dcrocker@bbiw.net> Fri, 03 January 2020 03:41 UTC

Return-Path: <dcrocker@bbiw.net>
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 4274D12004E for <ietf-smtp@ietfa.amsl.com>; Thu, 2 Jan 2020 19:41:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 X4QNlKsWZqVE for <ietf-smtp@ietfa.amsl.com>; Thu, 2 Jan 2020 19:41:01 -0800 (PST)
Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FDCE12004D for <ietf-smtp@ietf.org>; Thu, 2 Jan 2020 19:41:01 -0800 (PST)
Received: from [192.168.1.85] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 0033felD025623 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 2 Jan 2020 19:41:41 -0800
To: John Levine <johnl@taugh.com>, ietf-smtp@ietf.org
Cc: arnt@gulbrandsen.priv.no
References: <20200102223338.18A2211EB91B@ary.qy>
From: Dave Crocker <dcrocker@bbiw.net>
Organization: Brandenburg InernetWorking
Message-ID: <022185c5-073d-d8d8-7fc4-3858e13d2041@bbiw.net>
Date: Thu, 02 Jan 2020 19:40:42 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <20200102223338.18A2211EB91B@ary.qy>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/MaOmXZut2nvKroM_MvLhDX7v7Fs>
Subject: Re: [ietf-smtp] Possible cont4ibution to moving forward with RFC5321bis SMTP
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: Fri, 03 Jan 2020 03:41:03 -0000

On 1/2/2020 2:33 PM, John Levine wrote:
> If a host doesn't get v4 connections, it doesn't need to recognize v4
> address literals.  Similarly, if it doesn't get v6 connections it
> doesn't need to recognize v6 literals.  Standards are about
> interoperation, and cases that never happen don't matter for interop.


For defining a common core, the question is what is to be supported by 
everyone, all the time.  Supported is not the same as used, thereby 
distinguishing between requirements for interoperability technical 
specifications versus constraints of operational policy.

Is there any believe that any version of SMTP will be expected to 
operate without support for domain names?  (Again note, I said support, 
not use.)  Without support for IPv4?  v6?

These questions need to be answered in terms of what is desired for 
products being offered, not for operational choices in particular 
environments.

For example, if there really is a view that some SMTP products 
reasonably could operate only supporting IPv6 address, then after we get 
through the discussion of pragmatics that justify recommending 
standardization of that choice, we should consider how to create a 
common SMTP that works for that choice as well as the more general, open 
Internet use.

For this particular example, I'd say that the base protocol spec would 
have to say something generic like 'text' and then leave the constraints 
on the text to particular specifications that tailor things.  mumble...

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net