Re: What real users think [was: Re: pgp signing in van]

Dave Crocker <dhc@dcrocker.net> Mon, 09 September 2013 21:26 UTC

Return-Path: <dhc@dcrocker.net>
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 873EE11E815E for <ietf@ietfa.amsl.com>; Mon, 9 Sep 2013 14:26:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YW4wRZTwzsRG for <ietf@ietfa.amsl.com>; Mon, 9 Sep 2013 14:26:15 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8489D11E80E9 for <ietf@ietf.org>; Mon, 9 Sep 2013 14:26:14 -0700 (PDT)
Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r89LQ97Z002655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <ietf@ietf.org>; Mon, 9 Sep 2013 14:26:12 -0700
Message-ID: <522E3CDF.8040000@dcrocker.net>
Date: Mon, 09 Sep 2013 14:25:51 -0700
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: IETF discussion list <ietf@ietf.org>
Subject: Re: What real users think [was: Re: pgp signing in van]
References: <m2zjrq22wp.wl%randy@psg.com> <2309.1378487864@sandelman.ca> <522A5A45.7020208@isi.edu> <CA2A6416-7168-480A-8CE1-FB1EB6290C77@nominum.com> <522A71A5.6030808@gmail.com> <6DE840CA-2F3D-4AE5-B86A-90B39E07A35F@nominum.com> <CAPv4CP_ySqyEa57jUocVxX6M6DYef=DDdoB+XwmDMt5F9eGn1A@mail.gmail.com> <18992.1378676025@sandelman.ca> <8D23D4052ABE7A4490E77B1A012B63077527BC7A@mbx-01.win.nominum.com> <13787.1378730617@sandelman.ca> <8D23D4052ABE7A4490E77B1A012B63077527C8AB@mbx-01.win.nominum.com> <522E2AE4.6010908@gmail.com> <522E2C78.4050706@dcrocker.net> <F17097BC-AAD6-48EA-80D3-202DC45F7C70@shinkuro.com> <522E3141.5060609@dcrocker.net> <D47C01B0-D846-4130-9F23-8EC71E269E72@shinkuro.com> <522E3425.8070009@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077527D8F9@mbx-01.win.nominum.com>
In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077527D8F9@mbx-01.win.nominum.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 09 Sep 2013 14:26:12 -0700 (PDT)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
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: Mon, 09 Sep 2013 21:26:20 -0000

>> Indeed. How one achieves such a fresh start is unclear.
>
> G+, Facebook, etc.   There's no shortage of fresh starts in the
> personal communication space.   They just don't typically look like
> typical SMTP/rfc822 email.   And of course, they substitute central
> control for a distributed key model.


Let's try to avoid that line of thinking quickly:

   1.  Starting fresh means ceasing to interoperate (well) with Internet 
Mail.  We had quite a lot of exemplars of this when the Internet was 
starting to be commercial; semantics matching was often awkward.

   2.  UI differences can be important but they do not change 
interoperable semantics (or formats).  And no matter what internal 
formats a site uses, if it is to interoperate with Internet Mail with 
high resolution in the semantics, it's conforming to rfc822/2822/5322.

   3.  There are a number of features already available in email 
standards that might be relevant to this topic, but they haven't gained 
much adoption. So they were 'thought of' and even 'made possible' but 
the market chose not to pursue them.  Encapsulating a forwarded message 
in a MIME body-part is such an example; indeed, some MUAs do provide 
that option, though users typically don't take advantage of it.

d/

ps.  All of this is no doubt entertaining, but the original comment was 
about history, not about starting fresh.  My response was posted about 
that history.

pps. An example of getting the "fresh start" idea fundamentally wrong is 
with efforts to define IPv6-based email as having different semantics 
from IPv4, rather than as the transparent extension it needs to be.

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net