[apps-discuss] Splitting RRVS

"Murray S. Kucherawy" <superuser@gmail.com> Thu, 27 March 2014 21:42 UTC

Return-Path: <superuser@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 378DC1A0692 for <apps-discuss@ietfa.amsl.com>; Thu, 27 Mar 2014 14:42:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 eCQyKEcmsZQn for <apps-discuss@ietfa.amsl.com>; Thu, 27 Mar 2014 14:42:42 -0700 (PDT)
Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3BF1A03C7 for <apps-discuss@ietf.org>; Thu, 27 Mar 2014 14:42:41 -0700 (PDT)
Received: by mail-wi0-f171.google.com with SMTP id q5so64677wiv.16 for <apps-discuss@ietf.org>; Thu, 27 Mar 2014 14:42:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=yjQf4tgnGN2SM2tex9E/1rWGtF7CeHcyDeExiaQ3+5c=; b=SbmF+UtiNAvOa2vu/1/LQjyGOLKOOJC53HGQnpBm2sM1QWR0iiMj0Lq/kJcTLvCBXc fwWqOOI0QLJrE4Y1Hyc4zbwih3rB9BXROn17WKxGOrB8JjKzVly6pnXZLfh9IADY6sFb pZTAZaRIDCziP5/y9kbY1wIQ5LiB95kOBiTWcu4pEZdwCZ/Wc/WPMuxARkWIBEHCcm+u s9DnBPmq3tBdSnerfWBbBkHrzB9sPEiQWa1yMuhMQ+sphgMDe00xZfwn8Zc//GAYWqk6 JMxqW9vErdJGFwrwPHWF+BboD+GHjJYxyDhWQWAyQp29heqDCqK3Kwxff+FGI2h6zG8J 5B6w==
MIME-Version: 1.0
X-Received: by 10.180.187.237 with SMTP id fv13mr8072677wic.26.1395956559728; Thu, 27 Mar 2014 14:42:39 -0700 (PDT)
Received: by 10.180.90.140 with HTTP; Thu, 27 Mar 2014 14:42:39 -0700 (PDT)
Date: Thu, 27 Mar 2014 14:42:39 -0700
Message-ID: <CAL0qLwbzh3fM3EqwAvCi0VSSv2PkrcvLWAUa44A_sx5KwAgFrA@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: IETF Apps Discuss <apps-discuss@ietf.org>
Content-Type: multipart/alternative; boundary="001a11c25a9cdd57dc04f59d7685"
Archived-At: http://mailarchive.ietf.org/arch/msg/apps-discuss/Fh-7U8hSjnwUBsXo-YEQyQXUm8A
Subject: [apps-discuss] Splitting RRVS
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Mar 2014 21:42:45 -0000

Colleagues,

The IESG Evaluation of draft-ietf-appsawg-rrvs-header-field has resulted in
the draft being sent back to the working group for reworking.  In the same
manner as the MT-PRIORITY work, they would like us to split the document
into a standards track document that defines the SMTP extension independent
of the header field, and a document not on the standards track that defines
the header field as it relates to the extension.

Fortunately, most of the text that goes into both of the documents already
exists in the one we have now.  Some of the points raised during evaluation
that will need to be considered in the split are:

1) More attention should be paid to the issue of invalidating content
signatures when the header field gets removed.

2) The potential for revealing information unnecessarily to end users when
the message is relayed to non-participating MTAs needs to be underscored.

3) There should be a mechanism for the sender to request that the message
be bounced when a relay that doesn't support the SMTP extension is
encountered, rather than encouraging the tunneling option.

4) There should be stronger discouragement, possibly even a MUST NOT, for
the multiple recipients case.

5) When using the header field version, there's no guarantee at all that
downstream agents actually understand and will respect the semantics.  In
that scenario the sender is essentially tossing the message over the wall
and hoping for the best.  Even if the first hop supports the SMTP
extension, there's no guarantee that a downstream MTA won't downgrade and
be sloppy about it.

To minimize the impact of this, I plan to try to produce the two documents
this weekend and get them available to the WG for review.  Assuming we can
come to consensus quickly (the text changes shouldn't be too huge), we
should be able to send this back to the IESG in just one or two telechat
cycles.

There's a separate issue in general about better guidance around when to
use SMTP extensions vs. header fields.  I tried to address that in
draft-kucherawy-email-caps, which also needs some work after some review
comments I've received.  I'll try to do all three this weekend.

Barry and Pete, please add or correct anything above as necessary.

-MSK