| s1 |
Section 2.2 |
Additional properties SHOULD* NOT be added to Statements unless explicitly allowed by this specification. |
Section 5.2.1 |
An LRP SHALL not add additional properties to Statements |
| s2 |
Section 2.2 |
Additional properties SHOULD* NOT be added to Statements and other objects unless explicitly allowed by this specification and the LRS SHOULD* reject Statements containing such additional properties. |
Section 5.2.1 |
An LRP SHALL not add additional properties to Statements |
| s3 |
Section 2.2 |
Additional properties SHOULD* NOT be added to Statements and other objects unless explicitly allowed by this specification and the LRS SHOULD* reject Statements containing such additional properties |
Section 4.2.1 |
An LRS shall reject a Statement with additional properties other than extensions in the locations where extensions are allowed |
| s4 |
Section 2.4 |
Additional properties not listed here SHOULD* NOT be added to this object and each property MUST occur only once. 3.14 |
N/A |
Removed as requirement is handled via other requirements (SHALLs) |
| s5 |
Section 2.4.3 |
When queried for Statements with a Format of ids, the LRS SHOULD* NOT include the "display" property |
N/A |
Removed as requirement is handled in the positive sense in other tables |
| s6 |
Section 2.4.3 |
When queried for Statements with a Format of canonical, the LRS SHOULD* return a canonical Display for that Verb. |
N/A |
Removed as requirement is handled in the positive sense in other tables |
| s7 |
Section 2.1.3 |
If the LRS maintains a canonical version of a language map, it SHOULD* return this canonical language map when canonical format is used to retrieve Statements |
Section 4.1.6.1 |
The LRS may maintain a canonical version of any language map and return this when canonical format is used to retrieve Statements. |
| s8 |
Section 2.1.3 |
The LRS SHOULD* return only one language within each language map for which it returns a canonical map. |
Section 4.1.6.1 |
The LRS shall return only one language within each language map for which it returns a canonical map. |
| s9 |
Section 2.4.4.1 |
The LRS SHOULD* NOT enforce character limits relating to response patterns. |
N/A |
Removed as a requirement |
| s10 |
Section 2.4.4.1 |
The LRS SHOULD* NOT limit the length of the correctResponsesPattern array for any interactionType |
N/A |
Removed as a requirement |
| s11 |
Section 2.4.7 |
The "timestamp" property SHOULD* be set by the LRS to the value of the "stored" property if not provided. |
Section 4.2.4.2 |
The LRS shall set the "timestamp" property to the value of the "stored" property if not provided. |
| s12 |
Section 2.4.7 |
An LRS SHOULD* NOT reject a timestamp for having a greater value than the current time, to prevent issues due to clock errors. |
Section 4.2.4.1 |
An LRS shall not reject a timestamp for having a greater value than the current time, within an acceptable margin of error (intentionally not specified in this document) |
| s13 |
Section 2.6 |
JWS Compact Serialization SHOULD* be used to create the JSON web signature. Use of JWS JSON Serialization is strongly discouraged, is unlikely to be interoperble with other systems, and will be forbidden in a future version of this specification. |
Section 4.2.6 |
JWS Compact Serialization shall be used to create the JSON web signature. Use of JWS JSON Serialization is strongly discouraged, is unlikely to be interoperable with other systems, and will be forbidden in a future version of this specification. |
| s14 |
Section 2.6 |
JWS Compact Serialization SHOULD* be used to create the JSON web signature. Use of JWS JSON Serialization is strongly discouraged, is unlikely to be interoperble with other systems, and will be forbidden in a future version of this specification. |
Section 5.2.6 |
JWS Compact Serialization shall be used to create the JSON web signature. Use of JWS JSON Serialization is strongly discouraged, is unlikely to be interoperable with other systems, and will be forbidden in a future version of this specification. |
| s15 |
Section 3.1 |
Metadata Providers defining new IRIs SHOULD* only use IRIs they control or have permission from the controller to use. |
Section 5.2.7 |
Learning Record Providers defining new IRIs should only use IRIs they control or have permission from the controller to use. |
| s16 |
Section 3.1 |
When re-using an existing identifier, Metadata Providers SHOULD* ensure that the exact character equivelent IRI is used. |
N/A |
Unclear and unnecessary. Requirement removed. |
| s17 |
Section 3.1 |
When storing or comparing IRIs, LRSs SHOULD* handle them only by using one or more of the approaches described in 5.3.1 (Simple String Comparison) and 5.3.2 (Syntax-Based Normalization) of RFC 3987, and SHOULD* NOT handle them using any approaches described in 5.3.3 (Scheme-Based Normalization) or 5.3.4 (Protocol-Based Normalization) of the same RFC, or any other approaches. |
Section 4.2.7 |
When storing or comparing IRIs, LRSs shall handle them only by using one or more of the approaches described in 5.3.1 (Simple String Comparison) and 5.3.2 (Syntax-Based Normalization) of RFC 3987 |
| s18 |
Section 3.1 |
LRSs SHOULD* apply the same IRI comparison and normalization rules with all IRIs in parameters and fields defined to contain IRIs. |
N/A |
Handled by change s-16 |
| s19 |
Section 4.5 |
A Timestamp SHOULD* be expressed using the format described in RFC 3339, which is a profile of ISO 8601 |
Section 5.2 |
A Timestamp shall be expressed using the format described in RFC 3339, which is a profile of ISO 8601. |
| s20 |
Section 4.5 |
A Timestamp SHOULD* include the time zone. |
Section 5.2.7 |
A Timestamp shall be formatted to UTC |
| s21 |
Section 4.5 |
If the Timestamp includes a time zone, the LRS MAY be return the Timestamp using a different timezone to the one originally used in the Statement so long as the point in time referenced is not affected. |
N/A |
Removed |
| s22 |
Section 4.5 |
The LRS SHOULD* return the Timestamp in UTC timezone. |
Section 4.2.7 |
An LRS shall convert Timestamps to UTC rather than rejecting Statements that send Timestamps not in UTC form |
| s23 |
Section 4.6 |
On receiving a Duration with more than 0.01 second precision, the LRS SHOULD* NOT reject the request but MAY truncate the "duration" property to 0.01 second precision |
Section 4.2.7 |
On receiving a Duration with more than 0.01 second precision, the LRS shall not reject the request but may truncate the "duration" property to 0.01 second precision. |
| s24 |
Section 4.6 |
When comparing Durations, any precision beyond 0.01 second precision SHOULD* NOT be included in the comparison |
Section 5.2.7 |
When comparing Durations (or Statements containing them), any precision beyond 0.01 second precision shall not be included in the comparison. |
| s25 |
Section 4.6 |
When comparing Durations, any precision beyond 0.01 second precision SHOULD* NOT be included in the comparison |
Section 4.2.7 |
When comparing Durations (or Statements containing them), any precision beyond 0.01 second precision shall not be included in the comparison. |
| s26 |
Section 1.3 |
The Learning Record Provider SHOULD* still include a Content-Type header (in the HTTP header) for this type of request with a value of 'application/x-www-form-urlencoded' |
Section 5.1.1 |
Clarified in new Headers section |
| s27 |
Section 1.3 |
The Learning Record Provider SHOULD* still include a Content-Type header (in the HTTP header) for this type of request with a value of 'application/x-www-form-urlencoded' |
Section 4.1.1 |
Clarified in new Headers section |
| s28 |
Section 1.3 |
The Content-Type form parameter SHOULD* specify the content type of the content within the content form parameter |
Section 5.1.1 |
Clarified in new Headers section |
| s29 |
Section 1.3 |
The Content-Type form parameter SHOULD* specify the content type of the content within the content form parameter |
Section 4.1.1 |
Clarified in new Headers section |
| s30 |
Section 1.3 |
The Learning Record Provider SHOULD* still include a Content-Length header (in the HTTP header) for this type of request indicating the overall length of the request's content |
Section 5.1.1 |
Clarified in new Headers section |
| s31 |
Section 1.3 |
The Learning Record Provider SHOULD* still include a Content-Length header (in the HTTP header) for this type of request indicating the overall length of the request's content |
Section 4.1.1 |
Clarified in new Headers section |
| s32 |
Section 1.3 |
The Content-Length form parameter SHOULD* specify the length of the content within the content form parameter and will therefore be a lower figure than the length listed in the Content-Length header |
Section 5.1.1 |
Clarified in new Headers section |
| s33 |
Section 1.3 |
The Content-Length form parameter SHOULD* specify the length of the content within the content form parameter and will therefore be a lower figure than the length listed in the Content-Length header |
Section 4.1.1 |
Clarified in new Headers section |
| s34 |
Section 1.5.2 |
When receiving a PUT or POST with a document type of multipart/mixed, an LRS SHOULD* accept batches of Statements which contain no Attachment Objects |
Section 4.1.3 |
When receiving a PUT or POST with a document type of multipart/mixed, an LRS shall accept batches of Statements that contain Attachments in the Transmission Format described above. |
| s35 |
Section 1.5.2 |
When receiving a PUT or POST with a document type of multipart/mixed, an LRS SHOULD* accept batches of Statements which contain only Attachment Objects with a populated fileUrl |
Section 4.1.3 |
When receiving a PUT or POST with a document type of multipart/mixed, an LRS shall accept batches of Statements which contain only Attachment Objects with a populated fileUrl. |
| s36 |
Section 2.1.1 |
If the LRS receives a batch of Statements containing two or more Statements with the same id, it SHOULD* reject the batch and return 400 Bad Request |
N/A |
Requirement removed |
| s37 |
Section 2.1.2 |
If the LRS receives a batch of Statements containing two or more Statements with the same id, it SHOULD* reject the batch and return 400 Bad Request |
Section 4.1.6.1 |
If the LRS receives a batch of Statements containing two or more Statements with the same id, it shall reject the batch and return 400 Bad Request. |
| s38 |
Section 2.1.3 |
The LRS SHOULD* include a "Last-Modified" header which matches the "stored" Timestamp of the Statement |
Section 4.1.6.1 |
The LRS shall include a "Last-Modified" header which matches the "stored" Timestamp of the Statement. |
| s39 |
Section 2.2 |
When returning a single document, the LRS SHOULD* include a "Last-Modified" header indicating when the document was last modified |
Section 4.1.6.2 |
The LRS shall include a "Last-Modified" header indicating when the document was last modified. |
| s40 |
Section 2.2 |
When returning a single document, the LRS SHOULD* include a "Last-Modified" header indicating when the document was last modified |
Section 4.1.6.5 |
The LRS shall include a "Last-Modified" header indicating when the document was last modified. |
| s41 |
Section 2.2 |
When returning a single document, the LRS SHOULD* include a "Last-Modified" header indicating when the document was last modified |
Section 4.1.6.6 |
The LRS shall include a "Last-Modified" header indicating when the document was last modified. |
| s42 |
Section 2.2 |
When returning multiple documents, the LRS SHOULD* include a "Last-Modified" header indicating when the most recently modified document was last modified |
N/A |
Removed. Handled by other requirements |
| s43 |
Section 2.5 |
If an LRS does not have a canonical definition of the Activity to return, the LRS SHOULD* still return an Activity Object when queried |
Section 4.1.6.4 |
If an LRS does not have a canonical definition of the Activity to return, the LRS shall still return an Activity Object when queried |
| s44 |
Section 3.1 |
A Client making a POST request to either the Agent Profile Resource or Activity Profile Resource SHOULD* include the "If-Match" header or the If-None-Match header |
Section 5.1.4 |
An LRP making a POST request to either the Agent Profile Resource or Activity Profile Resource shall include the "If-Match" header or the If-None-Match header. |
| s45 |
Section 3.1 |
A Client making a POST request to either the Agent Profile Resource or Activity Profile Resource SHOULD* include the "If-Match" header or the If-None-Match header |
Section 5.1.6.5 |
An LRP making a POST request to this resource shall include the "If-Match" header or the If-None-Match header. |
| s46 |
Section 3.1 |
A Client making a POST request to either the Agent Profile Resource or Activity Profile Resource SHOULD* include the "If-Match" header or the If-None-Match header |
Section 5.1.6.6 |
An LRP making a POST request to this resource shall include the "If-Match" header or the If-None-Match header. |
| s47 |
Section 3.1 |
A Client making a DELETE request to either the Agent Profile Resource or Activity Profile Resource SHOULD* include the "If-Match" header |
Section 5.1.4 |
An LRP making a DELETE request to either the Agent Profile Resource or Activity Profile Resource shall include the "If-Match" header. |
| s48 |
Section 3.1 |
A Client making a DELETE request to either the Agent Profile Resource or Activity Profile Resource SHOULD* include the "If-Match" header |
Section 5.1.6.5 |
An LRP making a DELETE request to this resource SHALL include the "If-Match" header. |
| s49 |
Section 3.1 |
A Client making a DELETE request to either the Agent Profile Resource or Activity Profile Resource SHOULD* include the "If-Match" header |
Section 5.1.6.6 |
An LRP making a DELETE request to this resource SHALL include the "If-Match" header. |
| s50 |
Section 3.1 |
An LRS responding to a POST or DELETE request SHOULD* handle the "If-Match" header as described in RFC2616, HTTP 1.1 if it contains an ETag, in order to detect modifications made after the Client last fetched the document |
Section 4.1.4 |
An LRS responding to a PUT, POST, or DELETE request shall handle the "If-Match" header as described in RFC2616, HTTP 1.1 if it contains an ETag, in order to detect modifications made after the document was last fetched. |
| s51 |
Section 3.1 |
An LRS responding to a POST request SHOULD* handle the "If-None-Match" header as described in RFC2616, HTTP 1.1 if it contains "*", in order to to detect when there is a resource present that the Client is not aware of. |
N/A |
Removed. Clarified in s-49 |
| s52 |
Section 3.1 |
If the header precondition in any of the POST or DELETE request cases above fails, the LRS:
-
SHOULD* return HTTP status 412 Precondition Failed.
-
SHOULD* NOT make a modification to the resource.
|
Section 4.1.4 |
Note: Combined with PUT section as they are now identical
If the header precondition in either of the request cases above fails, the LRS:
-
shall return HTTP status 412 Precondition Failed.
-
shall not make a modification to the resource.
|
| s53 |
Section 3.1 |
Clients SHOULD* use the ETag value provided by the LRS rather than calculating it themselves. |
Section 5.1.4 |
An LRP shall use the ETag value provided by the LRS rather than calculating it themselves. |
| s54 |
Section 3.1 |
An LRS responding to a GET request without using a transfer encoding or using the identity transfer encoding MUST calculate the value of the ETag header to be a hexadecimal string of the SHA-1 digest of the contents. This hexadecimal string SHOULD be rendered using numbers and lowercase characters only; uppercase characters SHOULD NOT be used. The requirement to calculate the ETag this way will be removed in a future version of the specification. |
N/A |
Removed |
| s55 |
Section 3.2 |
The LRS SHOULD* reject any request with 400 Bad Request status where the content type header does not match the content included in the request or where the structure of the request does not match the structure outlined in this specification for a particular content type. For example, if the content of the request is formatted as JSON, the content type is expected to be application/json. If the content type is application/x-www-form-urlencoded it is expected that the request will include a method parameter as outlined in Alternate Request Syntax. |
N/A |
Removed |
| s56 |
Section 3.2 |
The following requirements exist for the purposes of conformance testing, to ensure that any limitations or permissions implemented by the LRS do not affect the running of conformance testing software.
-
The LRS SHOULD* be configurable not to reject any requests from a particular set of credentials on the basis of permissions. This set of credentials SHOULD* be used for conformance testing but MAY be deleted/deactivated on live systems.
-
The LRS MUST be configurable to accept Attachments, Statements or documents of any reasonable size (see above).
-
The LRS MUST be configurable to accept requests at any reasonable rate.
|
Section 4.1.5 |
Appropriate handling of these requirements is now included in the Error Codes section of the new standard |
| s57 |
Section 4.1 |
Requests SHOULD* include headers for HTTP Basic Authentication based on a username and password each consisting of an empty string. In this case the HTTP Basic Authentication header will be Basic followed by a base64 encoded version of the string :. This results in the string Basic Og==. |
N/A |
Removed and under consideration in the cybersecurity xAPI sub-group |
| s58 |
Section 2.3.2 |
Upon receiving a Statement that voids another, the LRS SHOULD NOT* reject the request on the grounds of the Object of that voiding Statement not being present. |
Section 4.2.4.1 |
The LRS shall not reject a Statement that uses the voided verb if it cannot find the id of the Object of that Statement (nor does the LRS have to try to find it) |