Hi Tim,
Thank you for your review.
On Sun, 19 May 2024, at 04:29, Tim Bray via Datatracker wrote:
1. There is a reference to "control characters" without any citation, and thedefinition is not as obvious as one might think. A good reference is [UNICODE]section 23.1, which may be summarized as "65 code points in the rangesU+0000-U+001F ("C0 Controls") and U+0080-U+009F (“C1 Controls”), plus U+007F,"DEL"2. This section might benefit from a reference to RFC9413, which has athorough discussion of dealing with input data that is invalid for some reason.3. There are 3 options when receiving a message with invalid characters: deletethem, replace them (Unicode provides U+FFFD for this purpose), or reject themessage. The draft mentions two of these but not the replacement option. Is itnever appropriate in the JMAP context?
Right, this is also a valid option. I have updated the Internationalisation Considerations section to read:
Experience has shown that unrestricted use of Unicode can lead to
problems such as inconsistent rendering, users reading text and
interpreting it differently than intended, and unexpected results when
copying text from one location to another. Servers MAY choose to
mitigate this by restricting the set of characters allowed in otherwise
unconstrained String fields. The FreeformClass, as documented in [RFC8264], Section 4.3 might be a good starting point for this.
Attempts
to set a value containing code points outside of the permissible set
can be handled in a few ways by the server. The server could choose to
strip the forbidden characters, or replace them with U+FFFD (the Unicode
replacement character), and store the resulting string. This is likely
to be appropriate for non-printable characters — such as the "Control
Codes" defined in [UNICODE] Section 23.1, excluding newline (U+000A), carriage return (U+000D), and
tab (U+0009) — which can end up in data accidentally due to
copy-and-paste issues, but are invisible to the end user. JMAP allows
the server to transform data on create/update, as long as any changed
properties are returned to the client in the /set response, so it knows what has changed, as per [RFC8620], Section 5.3. Alternatively, the server MAY just reject the create/update with an invalidProperties SetError.
Cheers,
Neil.
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
