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

[Tim Bray <[e-mail]>]

 I still think it’d be a good idea to reference 9413, but this section is
OK by me. Thanks!  -Tim

On Jun 6, 2024 at 6:51:16 PM, Neil Jenkins <[e-mail]> wrote:

> 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.
>