Re: [Jmap] Artart last call review of draft-ietf-jmap-blob-17

Jaime Jiménez <jaime@iki.fi> Tue, 24 January 2023 13:19 UTC

Return-Path: <jaime@iki.fi>
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 692E0C152705; Tue, 24 Jan 2023 05:19:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.818
X-Spam-Level:
X-Spam-Status: No, score=-1.818 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NEUTRAL=0.779, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5s70oCfuL9l; Tue, 24 Jan 2023 05:19:36 -0800 (PST)
Received: from wforward5-smtp.messagingengine.com (wforward5-smtp.messagingengine.com [64.147.123.35]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F051C1524D9; Tue, 24 Jan 2023 05:19:34 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailforward.west.internal (Postfix) with ESMTP id 50A541AC1CD1; Tue, 24 Jan 2023 08:19:33 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Tue, 24 Jan 2023 08:19:33 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1674566372; x=1674652772; bh=qfbnUSeo78cjiPeVk7eg31acmhOX HfyVoaRlSC/FDOs=; b=atM0LPKrITpCRaFJ8oAjRoc4v33hjeH1KBThaQa5IyX+ Vc2WjwHIm7hv3n49hmTQBReV0ooKXpt2OUuGkLdZ0wsdZ/OBTrjJNgE0DRQ0HASR HGSuDkBYNU1H8uWnO3o+IX8rOoDz8oYCRlpF14bIESL5GCBrfUpoSu3qHLnLOCm/ scv+7zpwD0Xs8aGTq17I61VmJPa7ktdtEzma9GNBM4RGDB4or6iBtO5vyjY31ufn LXuGG0YycGtU3VPFRWz9gIcfVlZdYnDMqPod+nfjAvjOryXaFZ8wIX1Fz5rWTMP3 TplQwgnpFVEvgMOYQIBpprDJCHOO0cXol8xPiDEbHw==
X-ME-Sender: <xms:5NrPY4EA3xkGX-mmi4jB4uAYyzaMzl3_xn-x75K3z_WlJAI0Nb60sA> <xme:5NrPYxU5SfuHQaPeyn189nu-08SxuZ6kpYinE_MQfTLDEnOFX7uhWA71tcM3gBTrm z2Ycle-ugcWpjckjw>
X-ME-Received: <xmr:5NrPYyKEMpTBlIJSzYMwQxPIDDRPvySDF57IODvrQABXWQc3aqtmGHA4m9T4TX0T7q0KGYdaGJ-ftwZNl-24IHZcjDHko1Iaxiez>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedruddvtddggeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptgfkffggfgfuvfevfhfhjgesrgdtreertdefjeenucfhrhhomheplfgrihhm vgculfhimhornhgviicuoehjrghimhgvsehikhhirdhfiheqnecuggftrfgrthhtvghrnh eplefggfehleejheetveetueefhfetfedthfegtdfgfeduiedviedtiefhjeegueehnecu ffhomhgrihhnpehrfhgtqdgvughithhorhdrohhrghenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehjrghimhgvsehikhhirdhfih
X-ME-Proxy: <xmx:5NrPY6E6dAzeNtrdPCLWcoVE1rfCw9KdJt528NJHH78Tj5jnm1hL1Q> <xmx:5NrPY-Vg2aDrn4InVP4VwU99dtWVDuPgE-1PVm4apZCClcjwv_fdig> <xmx:5NrPY9ObnjPL1EalnQyxp63rZR6UqZ4ioCSK2KmPCwyaaXeqtahmWA> <xmx:5NrPY8xZeZgoTQQ07NrAIC0FaOD_R2TDHujhEg_dNR8Vl2jV6r6UdBmWo3c>
Feedback-ID: iabf94414:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 24 Jan 2023 08:19:30 -0500 (EST)
Content-Type: multipart/alternative; boundary="------------SYol5fQv12WxKoqzchqUnzAC"
Message-ID: <dbfeb67d-7ca7-2753-7e1c-11aed2c145e8@fastmail.com>
Date: Tue, 24 Jan 2023 15:19:29 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.5.1
Content-Language: en-GB
To: Bron Gondwana <brong@fastmailteam.com>, Jaime Jimenez <jaime@iki.fi>, "art@ietf.org" <art@ietf.org>
Cc: draft-ietf-jmap-blob.all@ietf.org, jmap@ietf.org, last-call@ietf.org
References: <167101110194.47914.6967125456851074004@ietfa.amsl.com> <fb09982f-79e3-4dcc-a0cd-b9253f88be88@app.fastmail.com>
From: Jaime Jiménez <jaime@iki.fi>
In-Reply-To: <fb09982f-79e3-4dcc-a0cd-b9253f88be88@app.fastmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/5j6-nz7ICSBarjn_DE7vShmQoV0>
Subject: Re: [Jmap] Artart last call review of draft-ietf-jmap-blob-17
X-BeenThere: jmap@ietf.org
X-Mailman-Version: 2.1.39
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, 24 Jan 2023 13:19:40 -0000

Hi Bron,

thanks for the thorough replies! I think the clarifications cover all of 
my comments.

I find the lookup part very interesting as it is also a common pattern 
in other areas like IoT resource discovery in CoAP. While I am not an 
expert in JMAP and am unsure about the specifics of the metadata or 
structure, my understanding is that linking (not nesting) would be used 
when an email contains a reference to another email, mailboxID being in 
URI format. It will be interesting to see how links and their metadata 
are discovered and navigated.

As for the ARTART review last call, I believe it is ready from my pov. I 
have not been following the JMAP mailing list, but if there is another 
review in a future draft version, I would be willing to do it.

Ciao!

Jaime

On 4.1.2023 8.22, Bron Gondwana wrote:
> On Wed, Dec 14, 2022, at 20:45, Jaime Jimenez via Datatracker wrote:
>> Reviewer: Jaime Jimenez
>> Review result: Ready with Nits
>
> Hi Jaime, thanks for your review and apologies for the delay in 
> replying through this holiday time.
>
>> In my opinion this draft is ready to be published. I found some nits and
>> comments that the authors may take into consideration.
>
> I will reply to each inline.
>
>> - Somewhere in the draft I would expect an indication that the 
>> request MUST be
>> of type "application/octet-stream". - I am not too familiar with JMAP 
>> but to my
>> understanding for any HTTP API you would need the URL for the 
>> resource path to
>> be well-defined. I assume that the definition of how the request URL is
>> constructed is out of the scope of this document and left to API
>> implementations or defined in RFC8620. Similarly how responses like
>> "notCreated" are carried over HTTP (e.g., 500 Error or similar) are to be
>> defined elsewhere, right? If they are defined on that RFC or 
>> elsewhere, it
>> might be good to add a reference in the document. If I am completely 
>> off, I
>> apologize cause I do not know the insides of JMAP well.
>
> Yes, the definition of how all the methods are carried is entirely 
> within RFC8620.  You can't really read this document without having 
> understood RFC8620, or implement it without an existing RFC8620 
> implementation, so re-describing all that would be redundant,  You 
> would hook the additional method handlers into your existing Blob/ 
> datatype handler that you had already implemented Blob/copy inside of, 
> but instead of copying from another account you would create a blob 
> the new datasources described by this document.
>
> The newly created blob would go into the same pool of unassigned blob 
> data that the JMAP upload endpoint defined in RFC8620 creates blobs 
> into, with the same expiry semantics.
>
>> - Another comment is
>> that the blob itself seems to carry CRUD operations but I only saw 
>> examples of
>> create or "Blob/upload" and read or "Blob/get". The draft indicates 
>> that blobs
>> "can't be updated or deleted" so I am wondering then if it is up to 
>> the server
>> to remove them over time and on which basis as the draft does not seem to
>> mention that. For example after a "blob lifetime", based on memory 
>> usage or
>> other.
>
> As above, this is covered in RFC8620 section 6: 
> https://www.rfc-editor.org/rfc/rfc8620#section-6
>
>     A blob that is not referenced by a JMAP object (e.g., as a message
>     attachment) MAY be deleted by the server to free up resources.
>     Uploads (see below) are initially unreferenced blobs.  To ensure
>     interoperability:
>
>     o  The server SHOULD use a separate quota for unreferenced blobs to
>        the account's usual quota.  In the case of shared accounts, this
>        quota SHOULD be separate per user.
>
>     o  This quota SHOULD be at least the maximum total size that a single
>        object can reference on this server.  For example, if supporting
>        JMAP Mail, this should be at least the maximum total attachments
>        size for a message.
>
>     o  When an upload would take the user over quota, the server MUST
>        delete unreferenced blobs in date order, oldest first, until there
>        is room for the new blob.
>
>     o  Except where quota restrictions force early deletion, an
>        unreferenced blob MUST NOT be deleted for at least 1 hour from the
>        time of upload; if reuploaded, the same blobId MAY be returned,
>        but this SHOULD reset the expiry time.
>
>     o  A blob MUST NOT be deleted during the method call that removed the
>        last reference, so that a client can issue a create and a destroy
>        that both reference the blob within the same method call.
>
> I have added some text to say that the created blob has the same 
> lifetime and expiry semantics.
>
>> - The Lookup operation might be underspecified IMO, as it is currently
>> stating: "The definition of reference is somewhat loosely defined, 
>> but roughly
>> means "you could discover this blobId by looking inside this 
>> object"". I think
>> that might not be clear enough for a developer implementing this but 
>> I leave it
>> to the group/authors to decide.
>
> It's kind of deliberately underspecified, to allow for future 
> extensions to make sense.
>
> I've clarified the text a bit.  If you are asking about threads, a 
> thread returns an emailId - and if the blob is referenced by one of 
> the emails, then the Thread references the Blob.
>
> BUT - if you fetch an email, it can contain a set of mailboxIds, and 
> if you then looked at all the OTHER emails inside each of those 
> mailboxes, and they contained the blob, then it wouldn't mean that 
> this email contained the blob... so you'd need to either have a 
> hierarchy of "contains" vs "references" which JMAP doesn't explicitly 
> define (but mostly I would expect developers to know), or you'd need 
> some kind of non-re-entrant rule, where you can look inside referenced 
> objects but not recuse back to the same object type again - so if it's 
> an email then if you find other emails by recursing then you stop.  
> Tricky.  But for a filesystem maybe you would want to recurse into 
> directories.
>
> Hence leaving it a bit loose.  But if the group think it needs to be 
> tighter, I could try to come up with a hierarchy for existing object 
> types and require that any future extension also define the blob 
> containing rules for it.
>
> Actually that's a nasty little question - does a Mailbox contain an 
> Email if it has children mailboxes and one of THEM contains the 
> Email.  I didn't define that clearly.  Damn.  I'll write a separate 
> email to the list about this.
>
>> Edits-nits:
>> The document contains apostrophes (can't, don't...). My understanding 
>> (which
>> might be mistaken) is that standards should not be coloquial, so 
>> maybe I would
>> expand those.
>
> Fair enough, whether it's a MUSTN'T or a SHOULDN'T, I've fixed all the 
> ones in the standard text itself.  I've left contractions in the 
> changelog, which will be removed before publishing.
>
> Cheers,
>
> Bron.
>
>
> --
>   Bron Gondwana, CEO, Fastmail Pty Ltd
> brong@fastmailteam.com
>
>
-- 
Jaime Jiménez