RFC Errata
Found 6 records.
Status: Verified (1)
RFC 8620, "The JSON Meta Application Protocol (JMAP)", July 2019
Note: This RFC has been updated by RFC 9404
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
Note: This RFC has been updated by RFC 9404
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.