Re: [Jmap] I-D Action: draft-ietf-jmap-blob-11.txt

Bron Gondwana <brong@fastmailteam.com> Tue, 19 April 2022 23:20 UTC

Return-Path: <brong@fastmailteam.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 A1F3E3A0E38 for <jmap@ietfa.amsl.com>; Tue, 19 Apr 2022 16:20:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=tPwN6v29; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ydlGhFS1
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 4SEoGUIqEdkG for <jmap@ietfa.amsl.com>; Tue, 19 Apr 2022 16:20:47 -0700 (PDT)
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE2653A0E2B for <jmap@ietf.org>; Tue, 19 Apr 2022 16:20:47 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 16ECE320206E for <jmap@ietf.org>; Tue, 19 Apr 2022 19:20:44 -0400 (EDT)
Received: from imap43 ([10.202.2.93]) by compute4.internal (MEProxy); Tue, 19 Apr 2022 19:20:45 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm2; t=1650410444; x= 1650496844; bh=YxA11ewrgl68wAoZ/4svuGJvqcTRmInrC6S30vFDYCQ=; b=t PwN6v29miBs/XZUXQge5Np2Rrwu5TlJhgB8izAagbxc6p6n3Mh6mM5sX9GBL6MVW P/TCtcHeErnxSq1TARfKPVeU9uXJNp24VgiPEIHK1PK2L47rxNvrdAyht6wYNmMS vxhFpKp8Io9KDoJ3h8b6G/3ELxaNi3gidDmMFmwmOFMFF9BgtWhbO9IRSD4VUk1O uhQ4NeosntPynOWRsYEafF/YZn3v8xmvRLgBkWWlslzhuJluD103A/tNtWv+ZeCt PgZfHREcWrnaAJ2vQx4qe3rkG5fcuZU9HqFgRjDB+3NfD3unjtW+G9wXe4TQuV3O Qn4n7Xr16unUJqPdtEDJg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date: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=fm1; t=1650410444; x= 1650496844; bh=YxA11ewrgl68wAoZ/4svuGJvqcTRmInrC6S30vFDYCQ=; b=y dlGhFS1i9ToEEWHFyAXrmzBhHZgyvPJs22/TLIWZnvyAql7CD2egxxqQBgUSps7x 5QyIVBGoGcYJTvJ95U3hw6jk2ynP6Vyk6VHDCchUM94KQOZKImAVkDxS52Gg4HH6 Hq5x2FmQ3cBFpWNWJ3RwYlG1uooWpm6skE+GKxMSHS3PkIPhuOARkZrpC+JkQecc chwdJKkDKqYx2x7nDopr99m15KNuzyYcT9HhhhTz3Mrh7jymon73uydqbMLJzhMU Ww9frFxsCp4xY+Ic8XIhrD3pG0S6g2ZwlkaUFpoUiF1CuW6SLpqGa2Fou9MV5qbT cQRdGdnxQ51iSu1uJC8Sg==
X-ME-Sender: <xms:zENfYmLknr4ZQSdAlVqHJxrhQUEHB4kpGn97zIaBqjgCZU852o8AuQ> <xme:zENfYuJlJblpURoaaWha2FoT7cWKpkw5ArYv4ZdhmQezjvmmoyMGHMD7o4rIjDzJI cCPdExPfKY>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrvddtgedgvdduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerreejnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeffvdekfeegle eiueettddtffehveevffefkeduvddttdekiefgjeduvdfhvdduleenucffohhmrghinhep ihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm
X-ME-Proxy: <xmx:zENfYmvFLU7Ak2Iy2ljB5ojFko_vrwLASDE1RKILrE9bUSVjhJoAHA> <xmx:zENfYracYnYaCPE14ZYU_BINtc4N5bLtDtwbaS4RMOFYqFJeNtQFaQ> <xmx:zENfYtYB1IhtvesNckSmZQDhhzXt-B_4Gy6FOnViTbTYU6LDW51D7w> <xmx:zENfYmm5zq5IAdSIquY1s_AESm2_gFccObqHGDsIfVBoMWtZJk8HzA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 430F1AC0E98; Tue, 19 Apr 2022 19:20:44 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.7.0-alpha0-568-g521196dd5d-fm-20220414.001-g521196dd
Mime-Version: 1.0
Message-Id: <9328540d-78ea-4570-9ed9-dae0c1797d4c@beta.fastmail.com>
In-Reply-To: <d1c81dfe-f552-48bc-9365-5c3d2ad4b36f@dogfood.fastmail.com>
References: <164840486711.29024.8028686731542270779@ietfa.amsl.com> <d1c81dfe-f552-48bc-9365-5c3d2ad4b36f@dogfood.fastmail.com>
Date: Wed, 20 Apr 2022 09:20:24 +1000
From: Bron Gondwana <brong@fastmailteam.com>
To: jmap@ietf.org
Content-Type: multipart/alternative; boundary="c9995e58156a452798f1b8ac85ae062f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/WoWSEHVIQVAYnsHjr7Cm89wHdnM>
Subject: Re: [Jmap] I-D Action: draft-ietf-jmap-blob-11.txt
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, 19 Apr 2022 23:20:53 -0000

Thanks Neil, I'll put together an updated draft and answer all these points soon.

Bron.

On Tue, Apr 19, 2022, at 16:14, Neil Jenkins wrote:
> A few comments on this draft:
> 
> It seems to use the type signature conventions of the core spec, but doesn't explicitly say this in the "Conventions Used in this Document" section. Presuming this is the intention thoughm the type for `supportedTypeNames` should be `String[]|null`
> 
>> *4.1 The result is the same as for Foo/set in RFC8620* […]
> 
> I think this could be clearer. Specifically, it's not the same as a standard `/set` in that there are no state strings in the response (as well as no updated/destroyed of course).
> 
>> *NOTE: Servers MUST set the creationIds value to the blobId returned in any successful Blob/upload's created response to allow backreferences, as that is the main purpose of this extensions.*
> 
> Again, I feel like this could be clearer. It's really saying an entry must be *added* to the `createdIds` map in the request for each successful upload, so the blob id may be used via back reference in a subsequent method call.
> 
>> data: `[DataSourceObject]`
> 
> Should be `DataSourceObject[]`. (There are a number of other instances like this in the spec; I won't keep listing them here)
> 
>> Exactly one of:
>>  * data:asText: String|null
>>  * data:asBase64: String|null
> 
> These are missing descriptions to specify exactly how they are to be interpreted.
> 
>> or a blobId source:
>>  * blobId: Id
>>  * offset: UnsignedInt|null (MAY be zero)
>>  * length: UnsignedInt|null (MUST NOT be zero)
> 
> Why must length not be zero? You are allowed a zero length blob. Also
> 
>> If `null` then length is the remaining octets in the blob.
> 
> So what if there are zero octets remaining?
> 
>> 4.1.2. Blob/upload complex example 
> 
> Still has properties from `/set` in the responses that should not be there.
> 
>> 6.3. Creation of "JMAP Data Types" Registry 
> 
> There's no documentation here on how to add or modify entries in this registry in the future.
> 
> Cheers,
> Neil.
> _______________________________________________
> Jmap mailing list
> Jmap@ietf.org
> https://www.ietf.org/mailman/listinfo/jmap
> 

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com