RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 6 records.

Status: Verified (1)

RFC 8620, "The JSON Meta Application Protocol (JMAP)", July 2019

Source of RFC: jmap (art)

Errata ID: 5791
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Neil Jhaveri
Date Reported: 2019-07-02
Verifier Name: Alexey Melnikov
Date Verified: 2019-09-23

Section 2.1 says:

"capabilities": {
  "urn:ietf:params:jmap:core": {
    "maxSizeUpload": 50000000,
    "maxConcurrentUpload": 8,
    "maxSizeRequest": 10000000,
    "maxConcurrentRequest": 8,
    "maxCallsInRequest": 32,
    "maxObjectsInGet": 256,
    "maxObjectsInSet": 128,
    "collationAlgorithms": [
      "i;ascii-numeric",
      "i;ascii-casemap",
      "i;unicode-casemap"
    ]
  },
  "urn:ietf:params:jmap:mail": {}
  "urn:ietf:params:jmap:contacts": {},
  "https://example.com/apis/foobar": {
    "maxFoosFinangled": 42
  }
}

It should say:

"capabilities": {
  "urn:ietf:params:jmap:core": {
    "maxSizeUpload": 50000000,
    "maxConcurrentUpload": 8,
    "maxSizeRequest": 10000000,
    "maxConcurrentRequests": 8,
    "maxCallsInRequest": 32,
    "maxObjectsInGet": 256,
    "maxObjectsInSet": 128,
    "collationAlgorithms": [
      "i;ascii-numeric",
      "i;ascii-casemap",
      "i;unicode-casemap"
    ]
  },
  "urn:ietf:params:jmap:mail": {},
  "urn:ietf:params:jmap:contacts": {},
  "https://example.com/apis/foobar": {
    "maxFoosFinangled": 42
  }
}

Notes:

In the capabilities section of the example Session Resource response, "maxConcurrentRequest" should be "maxConcurrentRequests".

In addition, the following line is missing a trailing comma:
"urn:ietf:params:jmap:mail": {}

Status: Reported (5)

RFC 8620, "The JSON Meta Application Protocol (JMAP)", July 2019

Source of RFC: jmap (art)

Errata ID: 6603
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Neil Jenkins
Date Reported: 2021-06-09

Section 5.6 says:

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.

It should say:

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.

Errata ID: 6604
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Neil Jenkins
Date Reported: 2021-06-09

Section 5.6 says:

   If it *splices out* all ids in the removed array that it has in its
   cached results, then:

      removed = [ "id2", "id31", ... ];
      fooIds => [ "id1", null, null, "id3", "id4", null, null, null ]

   and *splices in* (one by one in order, starting with the lowest
   index) all of the ids in the added array:

  added = [{ id: "id5", index: 0, ... }];
  fooIds => [ "id5", "id1", null, null, "id3", "id4", null, null, null ]

It should say:

   If it *splices out* all ids in the removed array that it has in its
   cached results, then:

      removed = [ "id2", "id31", ... ];
      fooIds => [ "id1", null, null, "id3", "id4", null, null, null ]

   and if any of the "removed" ids were not found, invalidates all
   cached ids after the first gap in the sparse array:

       fooIds => [ "id1", null, null, null, null, null, null, null ]

   and *splices in* (one by one in order, starting with the lowest
   index) all of the ids in the added array:

   added = [{ id: "id5", index: 0, ... }];
   fooIds => [ "id5", "id1", null, null, null, null, null, null, null ]

Notes:

Adds a critical step that was omitted from the description for how a client should process a "/queryUpdates" response. Without this step, the client could end up with ids in incorrect positions in its cached query results.

Errata ID: 6605
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Neil Jenkins
Date Reported: 2021-06-09

Section 5.5 says:

   o  position: "UnsignedInt"

      The zero-based index of the first result in the "ids" array within
      the complete list of query results.

It should say:

   o  position: "UnsignedInt"

      The zero-based index of the first result in the "ids" array within
      the complete list of query results.  If the "ids" array is empty,
      the value is undefined and MUST NOT be used by the client.

Notes:

The position response argument in "/query" is only defined when there is at least one id returned in the response. Make it clearer that when there are no ids returned, the client cannot rely on it being any particular value.

Errata ID: 6606
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Neil Jenkins
Date Reported: 2021-06-09

Section 3.3 says:

o  using: "String[]"

      The set of capabilities the client wishes to use.  The client MAY
      include capability identifiers even if the method calls it makes
      do not utilise those capabilities.  The server advertises the set
      of specifications it supports in the Session object (see
      Section 2), as keys on the "capabilities" property.

It should say:

o  using: "String[]"

      The set of capabilities the client wishes to use.  The client MAY
      include capability identifiers even if the method calls it makes
      do not utilise those capabilities.  The server advertises the set
      of specifications it supports in the Session object (see
      Section 2), as keys on the "capabilities" property.  The
      "urn:ietf:params:jmap:core" capability represents this document
      and MUST be included in the "using" list.  This is to allow a
      smooth upgrade path for future revisions to the core JMAP
      specification with different capability identifiers.

Notes:

The original text was unclear on whether the capability for this document (JMAP core) had to be included in the "using" list, or just those of extensions to JMAP core. Clarify that the "core" capability must also be included, and give the rationale.

Errata ID: 6607
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Neil Jenkins
Date Reported: 2021-06-09

Section 5.3 says:

   [...]                             In the case of records with
   references to the same type, the server MUST order the creates and
   updates within a single method call so that creates happen before
   their creation ids are referenced by another create/update/destroy in
   the same call.

It should say:

   [...]                             In the case of records with
   references to the same type, the server MUST order the creates and
   updates within a single method call so that creates happen before
   their creation ids are referenced by another create/update/destroy in
   the same call.

   A record may be updated/destroyed in the same request as it is
   created.  The update/destroy arguments may use creation ids as keys
   by prefixing the creation id with a "#".

Notes:

Clarify that it's explicitly permitted to update/destroy records created in the same request using the same mechanism as setting foreign keys in records.

Report New Errata