[Jmap] [Technical Errata Reported] RFC8620 (6603)

RFC Errata System <rfc-editor@rfc-editor.org> Wed, 09 June 2021 03:42 UTC

Return-Path: <wwwrun@rfc-editor.org>
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 E9C153A10E3 for <jmap@ietfa.amsl.com>; Tue, 8 Jun 2021 20:42:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 8TcI7-P-m70N for <jmap@ietfa.amsl.com>; Tue, 8 Jun 2021 20:42:00 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC6803A10BA for <jmap@ietf.org>; Tue, 8 Jun 2021 20:41:59 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id CF4E9F4073B; Tue, 8 Jun 2021 20:41:28 -0700 (PDT)
To: neilj@fastmailteam.com, chris.newman@oracle.com, superuser@gmail.com, francesca.palombini@ericsson.com, brong@fastmailteam.com, fenton@bluepopcorn.net
X-PHP-Originating-Script: 1005:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: neilj@fastmailteam.com, jmap@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20210609034128.CF4E9F4073B@rfc-editor.org>
Date: Tue, 8 Jun 2021 20:41:28 -0700 (PDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/qJwK4vQpwFm9C6yi0lYtYbNdU2Y>
Subject: [Jmap] [Technical Errata Reported] RFC8620 (6603)
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: Wed, 09 Jun 2021 03:42:14 -0000

The following errata report has been submitted for RFC8620,
"The JSON Meta Application Protocol (JMAP)".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6603

--------------------------------------
Type: Technical
Reported by: Neil Jenkins <neilj@fastmailteam.com>

Section: 5.6

Original Text
-------------
In the "upToId" request argument definition:

      If the sort and
      filter are both only on immutable properties, this allows the
      server to omit changes after this point in the results, which can
      significantly increase efficiency.  If they are not immutable,
      this argument is ignored.

In the "removed" response argument definition:

      If the sort and filter are both only on immutable properties and
      an "upToId" is supplied and exists in the results, any ids that
      were removed but have a higher index than "upToId" SHOULD be
      omitted.

In the "added" response argument definition:

      If the sort and filter are both only on immutable properties and
      an "upToId" is supplied and exists in the results, any ids that
      were added but have a higher index than "upToId" SHOULD be
      omitted.

Corrected Text
--------------
In the upToId argument definition:

      The server may be able to omit added or removed items that are 
      after the client's last cached id, making the update more efficient.

In the "removed" response argument definition:

      If an "upToId" is supplied and existed in the old results, any ids
      that were removed but had a higher index than "upToId" in those
      results SHOULD be omitted.  If the server cannot calculate this,
      the "upToId" MUST be ignored.

In the "added" response argument definition:

      If an "upToId" is supplied and exists in the new results, any ids
      that were added but have a higher index than "upToId" SHOULD be
      omitted.

Notes
-----
This errata fixes two issues with the upToId definition:

1. Using upToId doesn't require immutable properties in some server implementations; this is an implementation detail. The important thing is it's an optional optimisation that the server can ignore if it does not have the data to calculate it. The text has been updated to reflect this.

2. Clarify that for the "removed" argument, the indexes we are comparing for the upToId optimisation are of the ids in the *old* results. The original text is unclear and seems to imply you might compare with the index of the id in the new results, which will give an incorrect result.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC8620 (draft-ietf-jmap-core-17)
--------------------------------------
Title               : The JSON Meta Application Protocol (JMAP)
Publication Date    : July 2019
Author(s)           : N. Jenkins, C. Newman
Category            : PROPOSED STANDARD
Source              : JSON Mail Access Protocol
Area                : Applications and Real-Time
Stream              : IETF
Verifying Party     : IESG