IETF Logo Mail Archive

Re: [Jmap] blob API in draft-ietf-jmap-{core,mail}-01

Ted Lemon <mellon@fugue.com> Tue, 05 September 2017 15:21 UTC

Return-Path: <mellon@fugue.com>
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 D21F1132D52 for <jmap@ietfa.amsl.com>; Tue, 5 Sep 2017 08:21:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
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 gQIfPC_-ikNT for <jmap@ietfa.amsl.com>; Tue, 5 Sep 2017 08:21:29 -0700 (PDT)
Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A55D132D5E for <jmap@ietf.org>; Tue, 5 Sep 2017 08:21:29 -0700 (PDT)
Received: by mail-pg0-x22f.google.com with SMTP id d8so9978952pgt.4 for <jmap@ietf.org>; Tue, 05 Sep 2017 08:21:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zk/X/acFoQYL6gtHUCGhqNcZQgg37fWAQdvBGaCcN0k=; b=o8tdw6BE/aHTpJqHGGFDda+X2Aa1IZMVIxi5WYCQpln37oQ1sEi6GYo0/a6xM0ULHL pry9UvAb241UJ9vKVzrCgzxHClRTx7CAfHJuIe6vJna/0NLShlP9qxKA3ryVLAhxKoeA v2jUsnjZFSaswysqoEW69w4ORaFAxwi1ip384SL276rui2A5K2n+NfsRsIbyHePZOkvg 17ebWk+EPm7gS3BQKJt3v7LPjoin4gbBEPUAeHqenpIdzTlcXa+Kl6x27VXQjd77CO/t 5kUAUa989p5OI9Km1CqErGDjCIqldYKBrMjsjiQNq2lwP+u9MNJhzAo4SzNFrMf6V1k/ 9s5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zk/X/acFoQYL6gtHUCGhqNcZQgg37fWAQdvBGaCcN0k=; b=qoDLAcCIz3vlJZCokzLCgUmEYMriDpUcDgG2VgGKONO1G+IsA2Q8MopoduIko2w77e Cn/KPijbYPBxlLpbAlvHTpDlXbBu6LlxLFmupuyE6lHNyjFR6VdFM5VGzlgGxDCMhDAn v8UCUjFOM40RPUL3iOmOR1agQGWciS1HuJ0jJJRpJsDxC3eQY15j0XpaO8tb9EQd224y 88dYcqBJBrP5K4EuvnwgWLG7YuSrW0uzjSXm/jr7M6TFn8xJA2Bed+dCfkx5fdn8vMex 4vfJmKzW4flo6LWKufwy4lSwwbaf4Wqm2QvrGlCQ80DdujSOoPMkIubjMt4JVP/FxMo4 Wd+A==
X-Gm-Message-State: AHPjjUj2eN7z3jUrK0ND22r1zj56CBLb2PpmsELY7uyw8gMxYHWbyOkC htbCInWF2g3SsMmDRZG87wx57fi6xb0m
X-Google-Smtp-Source: ADKCNb4S4nOTMbSVZGuY/20VGR6hmf9zwgmBM30r0DpQAcoHLv8CvtR9KjELnC4k7EK3HxqbM3P/W4L4712cWtWijwY=
X-Received: by 10.84.210.161 with SMTP id a30mr1020753pli.220.1504624889043; Tue, 05 Sep 2017 08:21:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.152.98 with HTTP; Tue, 5 Sep 2017 08:21:28 -0700 (PDT)
Received: by 10.100.152.98 with HTTP; Tue, 5 Sep 2017 08:21:28 -0700 (PDT)
In-Reply-To: <20170905073906.GA1284@meili>
References: <20170726141022.GA1352@meili> <1504489191.1465021.1094157200.41D034D1@webmail.messagingengine.com> <02189C60-EF3C-4F0A-8C7D-7FAB1AE2DCA3@fugue.com> <1504529043.2496090.1094621608.37C42330@webmail.messagingengine.com> <20170905073906.GA1284@meili>
From: Ted Lemon <mellon@fugue.com>
Date: Tue, 05 Sep 2017 11:21:28 -0400
Message-ID: <CAPt1N1mmxtFePpSCapC2GwxOA4vAcvMGVCbqYeaJy9=3r7GHfA@mail.gmail.com>
To: Josef 'Jeff' Sipek <jeff.sipek@dovecot.fi>
Cc: Bron Gondwana <brong@fastmailteam.com>, IETF JMAP Mailing List <jmap@ietf.org>
Content-Type: multipart/alternative; boundary="001a114d5232083082055872c86c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/pyQIuGYn6bEPbv9NFiKXNusv_Tk>
Subject: Re: [Jmap] blob API in draft-ietf-jmap-{core,mail}-01
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: Tue, 05 Sep 2017 15:21:32 -0000

ISTM that if you do not require that the same bits have the same blob id,
you are asking for there to be subtle implementation differences that will
be inexplicable to the end user.

ISTM also that the time when you want this to happen is when you want to be
able to hang different metadata off the same bits in different contexts. So
it's not that we should choose on behavior or the other. Both are valid.
They just mean different things. Leaving this up to the implementation is
therefore asking for interop woes.

On Sep 5, 2017 3:39 AM, "Josef 'Jeff' Sipek" <jeff.sipek@dovecot.fi> wrote:

> On Mon, Sep 04, 2017 at 22:44:03 +1000, Bron Gondwana wrote:
> ...
> > I'd be happy for the wording to say MUST NOT ever use the same blobId
> > for different bytes.
>
> Sounds good.
>
> Specifically:
>
> * if the bytes are different, the server MUST NOT use the same blobId
> * if the bytes are the same, the server MAY use the same blobId
>
> Jeff.
>
> --
> Research, n.:
>   Consider Columbus:
>     He didn't know where he was going.
>     When he got there he didn't know where he was.
>     When he got back he didn't know where he had been.
>     And he did it all on someone else's money.
>
> _______________________________________________
> Jmap mailing list
> Jmap@ietf.org
> https://www.ietf.org/mailman/listinfo/jmap
>

v2.46.0 | Report a Bug | By Email | System Status