[Jmap] Httpdir early review of draft-ietf-jmap-rest-00
Mark Nottingham via Datatracker <noreply@ietf.org> Thu, 22 February 2024 05:01 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: jmap@ietf.org
Delivered-To: jmap@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 39AB9C1519BB; Wed, 21 Feb 2024 21:01:39 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Mark Nottingham via Datatracker <noreply@ietf.org>
To: ietf-http-wg@w3.org
Cc: draft-ietf-jmap-rest.all@ietf.org, jmap@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.5.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <170857809922.36013.3477270772418859864@ietfa.amsl.com>
Reply-To: Mark Nottingham <mnot@mnot.net>
Date: Wed, 21 Feb 2024 21:01:39 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/wAZ_HHzoH-n7GZ2dNed7Z1hngK4>
Subject: [Jmap] Httpdir early review of draft-ietf-jmap-rest-00
X-BeenThere: jmap@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 22 Feb 2024 05:01:39 -0000
Reviewer: Mark Nottingham Review result: On the Right Track This specification defines a very small mechanism to expose JMAP via HTTP (although JMAP uses HTTP already, it does so in a highly specialised way that is not accessible to most HTTP clients). As a general comment, I wonder whether it's helpful to have "REST" in the title, since this is clearly a minimal API that happens to be exposed over HTTP; it has more to do with RPC than REST. Perhaps "JMAP HTTP Resource", "JMAP HTTP Interface" or similar? Two specific issues to consider: * Section 1.3 seems to implicitly reinvent RFC 6570. Have you considered using that syntax instead? * Section 2 always uses POST. Is it possible to map some calls to GET to obtain benefits such as caching, idempotence, retry ability, etc.?
- Re: [Jmap] Httpdir early review of draft-ietf-jma… Joris Baum
- [Jmap] Httpdir early review of draft-ietf-jmap-re… Mark Nottingham via Datatracker
- Re: [Jmap] Httpdir early review of draft-ietf-jma… Mark Nottingham
- Re: [Jmap] Httpdir early review of draft-ietf-jma… Neil Jenkins