[Jmap] message vs. annotation

Dave Crocker <dhc@dcrocker.net> Fri, 31 March 2017 23:23 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: jmap@ietfa.amsl.com
Delivered-To: jmap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A31B3127863 for <jmap@ietfa.amsl.com>; Fri, 31 Mar 2017 16:23:17 -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_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 SAO7ERO9ZDtj for <jmap@ietfa.amsl.com>; Fri, 31 Mar 2017 16:23:16 -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 374AF127078 for <jmap@ietf.org>; Fri, 31 Mar 2017 16:23:16 -0700 (PDT)
Received: from [192.168.1.158] (50-232-11-130-static.hfc.comcastbusiness.net [50.232.11.130]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v2VNPM7I012933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for <jmap@ietf.org>; Fri, 31 Mar 2017 16:25:22 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1491002722; bh=NqKY3HbqiWdeePS6+tfwI5zCPhoLQsNgCLsCvhml/qI=; h=Subject:References:Reply-To:From:To:Date:In-Reply-To:From; b=Nogos2eJd16X7x83rC+BUnZxgQ3a47u1U9oVXLOVWS0Ebv2jjekwqDBDtwKkD8bzv 4FdSwpFd+TR/jXFX2mV90PgbEd1A1b5emLCcheC24mcT5phdiakksXLh+KmHcNXo5Q KjRkBsEKQ2SEc3SnB6saQodBwMdbPiwLhzD8UtXM=
References: <148716911729.17277.15371202023742081890.idtracker@ietfa.amsl.com>
Reply-To: dcrocker@bbiw.net
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
To: jmap@ietf.org
Message-ID: <b7ec34d3-3aaf-82af-3663-5b0966c83ff0@dcrocker.net>
Date: Fri, 31 Mar 2017 18:23:13 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <148716911729.17277.15371202023742081890.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/XEEX4dOr4ptMTPV3Lv9VaaOG5zU>
Subject: [Jmap] message vs. annotation
X-BeenThere: jmap@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: JSON Message Access Protocol <jmap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jmap>, <mailto:jmap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jmap/>
List-Post: <mailto:jmap@ietf.org>
List-Help: <mailto:jmap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jmap>, <mailto:jmap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Mar 2017 23:23:18 -0000

G'day,

The working group meeting discussion about a static message, dynamic 
annotation, etc., resonated with a variety of similar discussions I've 
been around over the years (dating back to the mid-1970.)

A simpler version equates the constructs of message and document, as two 
views of the same thing.  (Ie, Document with attributes; Message with a 
body.)

The essence is to consider the nature and relationship of the objects, 
possibly permitting different semantics for the same set of objects, 
according to different applications or roles.

That is, there can be a variety of constituent objects that are 
associated and can be viewed according to different semantics (or 
views)...  So a message, a document, a calendar entry, a series of 
comments, etc.  Each object has associated processing rules (eg, static 
vs. editable vs. executable; constrained choice of values; organization 
into folders or other schemas...)

An environment like this can  be powerful and very appealing.  The 
challenge tends to be staying practical:  With no effort at all it 
devolves into an abstract computer science exercise.  Some of that is an 
efficiency issue(*) but I think it's mostly about the human 
manageability for design and operations.

Based on both the years of commercial use and the public commentary 
about the performance, I've no doubt the fastmail system does not suffer 
these downsides.  But it's a potential that this re-casting through the 
IETF could easily suffer.

I'm posting this note partly because I think it would exciting to 
produce specs that permit a degree of flexibility that such an approach 
permits, but also wanted to cite the dangers.

At the moment, I'm guessing there needs to be a small number of basic 
object types and a small number of 'relationship' types that define the 
association between objects.  These could then be combined into 
higher-order, formal organizations/semantics the define an application 
semantic (mail, calendar, whatever.)


d/

(*) A system I did in 1977 has a little bit of this and the extremely 
pure design produced impressively horrible performance.

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net