Re: [ietf-smtp] Mail Transfer Protocol over ACP 142

Dave Crocker <dhc@dcrocker.net> Fri, 11 August 2017 17:08 UTC

Return-Path: <dhc@dcrocker.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 5D97C13219E for <ietf-smtp@ietfa.amsl.com>; Fri, 11 Aug 2017 10:08:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dcrocker.net
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 grZr2KvMHwXo for <ietf-smtp@ietfa.amsl.com>; Fri, 11 Aug 2017 10:08:33 -0700 (PDT)
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 959CC132198 for <ietf-smtp@ietf.org>; Fri, 11 Aug 2017 10:08:33 -0700 (PDT)
Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v7BH93IB005773 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 11 Aug 2017 10:09:03 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1502471344; bh=LMZ9DRnoAr9V6YtJ32RJrsgTC/cRspnLnUM3LrulrX4=; h=Reply-To:Subject:To:References:From:Cc:Date:In-Reply-To:From; b=crYCyDVhdu0VToZv0cHTNAT8ZFJJ4BoUnp04HHBoc+9ZD/zNbKD0BMmTFOwLwSkEl BGU9RYVk/88Bcf8nUc9IanQnI77Lonb9Zx7482kbkoHwIcqN7e3lANtltoNXj9AVif KEsCH2fG6tOGGgMu58iYMWPsgrAK0zy0dWmtlLlo=
Reply-To: dcrocker@bbiw.net
To: Alexey Melnikov <alexey.melnikov@isode.com>
References: <fd285cfd-7dc2-6de4-6226-b2e32da2755e@isode.com>
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
Cc: ietf-smtp@ietf.org
Message-ID: <f7243870-e0f7-d50d-3349-71edbd1e3857@dcrocker.net>
Date: Fri, 11 Aug 2017 10:08:26 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <fd285cfd-7dc2-6de4-6226-b2e32da2755e@isode.com>
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/iQT8XtxqrGiiBuC2JqeEUafW7II>
Subject: Re: [ietf-smtp] Mail Transfer Protocol over ACP 142
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.22
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, 11 Aug 2017 17:08:35 -0000

On 8/11/2017 9:30 AM, Alexey Melnikov wrote:
> Hi,
> 
> Based on some work that Isode is doing with gatewaying Internet email to 
> ACP 142 (*) environments, I wrote a draft 
> <https://datatracker.ietf.org/doc/draft-melnikov-email-over-pmul/?include_text=1>. 
> If people can review and provide feedback, that would be much appreciated.
...
> (*) - ACP 142 defines a transport protocol for reliable multicast in 
> bandwidth constrained and delayed acknowledgement environments


The draft does not provide a usable citation to 142.  Online search 
doesn't either.  The best I can find is:

    jcs.dtic.mil/j6/cceb/acps/acp123/ACP123B2014.pdf

but it produces a failure sequence that displays a yahoo search page.


Although the document asserts delays in responses, it doesn't seem to 
have any discussion about how that affects overall message transfer 
interactions between client MTAs and server MTAs.  So the document 
provide necessary 'syntax' for the configuration but seems not to 
provide a complete 'system' specification that adequately explains 
overall transaction flow.

d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net