Re: Gen-ART LC review of draft-leiba-5322upd-from-group-06

ned+ietf@mauve.mrochek.com Thu, 18 October 2012 00:40 UTC

Return-Path: <ned+ietf@mauve.mrochek.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3348521F8625 for <ietf@ietfa.amsl.com>; Wed, 17 Oct 2012 17:40:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nROKzA7B+pZi for <ietf@ietfa.amsl.com>; Wed, 17 Oct 2012 17:40:38 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 75E5321F8622 for <ietf@ietf.org>; Wed, 17 Oct 2012 17:40:38 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OLJ9JD42OW0005HX@mauve.mrochek.com> for ietf@ietf.org; Wed, 17 Oct 2012 17:35:20 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OLDMMCPN8G00008S@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ietf@ietf.org; Wed, 17 Oct 2012 17:35:14 -0700 (PDT)
From: ned+ietf@mauve.mrochek.com
Message-id: <01OLJ9JAK8SQ00008S@mauve.mrochek.com>
Date: Wed, 17 Oct 2012 17:18:37 -0700
Subject: Re: Gen-ART LC review of draft-leiba-5322upd-from-group-06
In-reply-to: "Your message dated Wed, 17 Oct 2012 16:19:06 -0700" <507F3CEA.2010306@dcrocker.net>
MIME-version: 1.0
Content-type: TEXT/PLAIN; format="flowed"
References: <010301cdac4d$cfa70060$6ef50120$@gmail.com> <01OLIW8VNVCU00008S@mauve.mrochek.com> <507EF95D.5090007@dcrocker.net> <01OLIXV2SU4O00008S@mauve.mrochek.com> <5B0F81787945877A5CC3794B@JcK-HP8200.jck.com> <01OLJ38YAL9600008S@mauve.mrochek.com> <507F3CEA.2010306@dcrocker.net>
To: Dave Crocker <dhc@dcrocker.net>
Cc: Ned Freed <ned.freed@mrochek.com>, draft-leiba-5322upd-from-group.all@tools.ietf.org, ned+ietf@mauve.mrochek.com, gen-art@ietf.org, John C Klensin <john-ietf@jck.com>, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Oct 2012 00:40:39 -0000

> On 10/17/2012 2:32 PM, Ned Freed wrote:
> > Channeling my inner Maslow, I see the present text as best, an additional
> > sentence or two as next best, a sentence and a cite to the downgrade doc next
> > in line, and including actual EAI examples in this doc as the worst choice.


> The problem I have with the current text is that it says 'what'
> motivated the change, but not how it is useful for the intended class of
> uses.  The reader is left entirely to guess.

> Self-actualization among the inadequately-informed invites fantasy more
> than it invites utility.

That depends on both the utility and the desirability of repeating the existing
use case, doesn't it? The EAI use case of downgraded messages is one that only
exists because of a nasty confluence of restrictions and which we absolutely do
not want to see repeated in any other context.

If you really think this is important to explain why we're making this change
against the overall context of RFC 5322 - and I most certainly do not agree
that it is important to do so - then the best "use case" to add is the negative
one: The elimination of an unnecessary restriction that isn't followed in
practice.

I see no way to explain the narrow EAI use case in this context without either
dragging in a whole bunch of EAI that has no business being here or leaving
various things dangling. Either way the average reader looking at general
message usage isn't going to get it, and the more you try and waltz around this
the more likely you are to get exactly the outcome you fear: Someone is going
to see some sort of parallel with some problem they are trying to solve (some
sort of deliberate form of address obfuscation scheme immediately comes to
mind) and proceeds to make a mess of things.

				Ned

P.S. It really would be best if this could wait until there was an update
to RFC 5322. But that's not how the timing has worked out, so this is the
best alternative available.