[Jmap] Re: Artart telechat review of draft-ietf-jmap-contacts-09

[Neil Jenkins <[e-mail]>]

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 the
> definition 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 ranges
> U+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 a
> thorough discussion of dealing with input data that is invalid for some reason.
> 
> 3. There are 3 options when receiving a message with invalid characters: delete
> them, replace them (Unicode provides U+FFFD for this purpose), or reject the
> message. The draft mentions two of these but not the replacement option. Is it
> never 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 <https://www.rfc-editor.org/rfc/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 <http://www.unicode.org/versions/latest/>] 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 <https://www.rfc-editor.org/rfc/rfc8620.html>], Section 5.3. Alternatively, the server MAY just reject the create/update with an invalidProperties SetError.

Cheers,
Neil.