[Jmap] WGLC review of draft-jmap-blob-07

Jim Fenton <fenton@bluepopcorn.net> Tue, 07 December 2021 00:42 UTC

Return-Path: <fenton@bluepopcorn.net>
X-Original-To: jmap@ietfa.amsl.com
Delivered-To: jmap@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 3FCB93A0C9E for <jmap@ietfa.amsl.com>; Mon, 6 Dec 2021 16:42:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=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=bluepopcorn.net
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 7CYtEAAOiNGJ for <jmap@ietfa.amsl.com>; Mon, 6 Dec 2021 16:42:48 -0800 (PST)
Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 6C20B3A0C9C for <jmap@ietf.org>; Mon, 6 Dec 2021 16:42:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bluepopcorn.net; s=supersize; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Date:Subject:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=qxmcevLEtfFD6q9q60fnMFLUFIVh605ml0Lt+3tU5UI=; b=ELZpGJZdmvwiWueousJfhwglrX 5kHrJtW1ZpPQD8pa/Du6I/DUeDEZuRIVwgWlC/siYxPNaSe0F74g3t94843P/Vr+6+njpFGZqLA5K uuJWAGejJSLONE4+MHNO7lB2QrTBZ7MZYp/LYnnuJnHBcfkopJmmKcI0M7mX6XI3xZYM=;
Received: from [] (helo=[]) by v2.bluepopcorn.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <fenton@bluepopcorn.net>) id 1muOZB-0003Ro-AC; Mon, 06 Dec 2021 16:42:45 -0800
From: Jim Fenton <fenton@bluepopcorn.net>
To: Bron Gondwana <brong@fastmailteam.com>
Cc: IETF JMAP Mailing List <jmap@ietf.org>
Date: Mon, 06 Dec 2021 16:42:44 -0800
X-Mailer: MailMate (1.14r5820)
Message-ID: <EA834DC9-333D-418A-B682-65C01EC01C0C@bluepopcorn.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; markup=markdown
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/F2IXvfCiLLaC0xxTkcnKvzLDpq4>
Subject: [Jmap] WGLC review of draft-jmap-blob-07
X-BeenThere: jmap@ietf.org
X-Mailman-Version: 2.1.29
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, 07 Dec 2021 00:42:51 -0000

I had a look at draft-ietf-jmap-blob-07, and have a few comments. Please bear in mind that I don’t have a great deal of experience with the other jmap documents, so some of this might be due to that.


I found the large number of examples in the document to be a little distracting. I would prefer to see them in a non-normative appendix. At a minimum, it should be made clear that they’re informative examples, so they aren’t depended upon in the event of a conflict between the normative text and the example.

Specific sections:

Section 3: This appears to be a normative reference to [RFC8620], so that document should be moved from informative to normative in the references.

Section 3.1: “This” is apparently a reference to the section title. What is it about “this” that represents support: I guess the advertisement of this string in the capabilities object? Please make that more specific so that the section fully specifies what happens. What happens if some of the parameters (e.g., MaxSizeBlobSet) aren’t included: do they assume default values are are the limits nonexistent? If this appears in accountCapabilities, I presume it also has to appear in capabilities; is that specified somewhere?

Section 4.1.1: Is this a subset of the Blob/set method, and if so how is it distinguished? “exactly one of”, “Also optionally” isn’t as formal a definition as I’m used to in IETF standards-track documents. Often, something like this is specified using ABNF. I don’t have a good idea if this is unambiguous or not.
“can not contain” -> “MUST not contain”

Sections 4.1.2, 4.1.3: will result -> MUST result

Section 4.2: Do the null meanings of offset and length have the same meaning as for create? Is it possible to request both data:asText and data:asBase64? Some of the requirements seem not to be in normative style, e.g. “the size value is always” might be stated as “the size value MUST be” and “the key isEncodingProblem is set to true” -> “the key isEncodingProblem MUST be set to true”

Section 6.3: I’m confused about creating a registry where the existing entries reference a number of different existing specifications. Is this a registry that was overlooked in the past? (If so, glad you’re adding it)


Is blob capitalized? It’s inconsistent but mostly capitalized here, but RFC 8620 doesn’t capitalize it.

Hope this helps,

-Jim (without hat)