With thanks to John Klensin for some of the text I adapted, I have added the following:
Internationalisation considerations
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 [RFC7564], Section 4.3 may 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 first option is to simply strip the forbidden characters and store the resulting string. This is likely to be appropriate for control characters for example, where they can end up in data accidentally due to copy-and-paste issues, and are probably 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.
Do the concerned parties feel this addresses the issue sufficiently?
I have also rewritten the AddressBook "name" definition to be clearer the restrictions are purely about length. It now reads:
name:
The user-visible name of the AddressBook. This MUST NOT be the empty string and MUST NOT be greater than 255 octets in size when encoded as UTF-8.
StringThe user-visible name of the AddressBook. This MUST NOT be the empty string and MUST NOT be greater than 255 octets in size when encoded as UTF-8.
Cheers,
Neil.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
