Re: [ietf-smtp] Fwd: I-D Action: draft-melnikov-smtp-metadata-00.txt

"John Levine" <johnl@taugh.com> Sun, 22 March 2015 20:16 UTC

Return-Path: <johnl@taugh.com>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AEFE1A1A6C for <ietf-smtp@ietfa.amsl.com>; Sun, 22 Mar 2015 13:16:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.862
X-Spam-Level:
X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=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 OcWWcjsnFYvP for <ietf-smtp@ietfa.amsl.com>; Sun, 22 Mar 2015 13:16:55 -0700 (PDT)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15B081A1AA1 for <ietf-smtp@ietf.org>; Sun, 22 Mar 2015 13:16:54 -0700 (PDT)
Received: (qmail 5204 invoked from network); 22 Mar 2015 20:16:53 -0000
Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 22 Mar 2015 20:16:53 -0000
Date: Sun, 22 Mar 2015 20:16:31 -0000
Message-ID: <20150322201631.37192.qmail@ary.lan>
From: John Levine <johnl@taugh.com>
To: ietf-smtp@ietf.org
In-Reply-To: <4175cf7b-c14e-455d-bd6b-0903d9de6194@gulbrandsen.priv.no>
Organization:
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf-smtp/xPmoGyBtWjom0oPhqs2b1KZ3wK0>
Cc: arnt@gulbrandsen.priv.no
Subject: Re: [ietf-smtp] Fwd: I-D Action: draft-melnikov-smtp-metadata-00.txt
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 22 Mar 2015 20:16:56 -0000

In article <4175cf7b-c14e-455d-bd6b-0903d9de6194@gulbrandsen.priv.no> you write:
>I'm not sure this is constructive, but it's meant to be helpful.
>
>AFAICT RFC3030 has not been widely adopted in practice. Why, do you think? 

I think it's because networks have gotten fast and reliable enough
that 8BITMIME and various ways to encode binary data (qp and base64)
are good enough.

An alternative to what this draft does is to define some new MIME
multipart types and wrap everything in a new message.  That has the
disadvantage that it's ugly, but the advantage that MTAs including
relays don't need to know about it and it's arguably* faster.

So I think it would work fine if people implemented it, but unless
there's a very concrete use case and people ready write and deploy
those implementations, I wouldn't bother.

R's,
John

* - arguably due to more round trips for more commands, arguably
mitigated by pipelining