Re: [Last-Call] Artart last call review of draft-ietf-jmap-contacts-06

[Carsten Bormann <[e-mail]>]

This review is informed by a discussion we are having on the art@ list about what to recommend to protocol designers with respect to the use of Unicode and specifically UTF-8.

Unicode is complex, and it has become the norm that designers of protocols like the one being discussed here essentially leave all the details to the implementer.  It is entirely impossible that each protocol designer can answer all the questions coming up (to many of which even Unicode experts have no ready answer).
Trying to cram some version of a specific understanding into each protocol definition is likely to fail and lead to a myriad of incompatible restrictions between which data is now hard to interchange.

So generally, protocol designers have not attempted to import all details of Unicode into their specification, generally not even the low-hanging fruit such as excluding non-characters.
(What is the point?  These never cause interoperability problems.)

PRECIS was an attempt to provide a referenceable standard in this space, but it is dependent on the Unicode version and has stopped following Unicode at 6.3.0.  Its status is pretty much an expression of the problems listed above, except there was an attempt to register a small number of variants, thwarted by the need for constant maintenance.

I do believe there are a few items that a protocol designer has to address (e.g., at the representation level: are BOMs allowed?  They are discouraged, but not disallowed by STD 63 (RFC 3629).  At the semantic level: What about RTL?).  But the current noise about character repertoires is not conducive to making progress on these.

What will happen in practice is that implementers will use whatever Unicode library they have conveniently available to them, which creates large islands of interoperability, but no perfect result.  Some form of soup (RFC 9413 “protocol decay”) will ensue, but the situation will not be much worse than the ecosystem into which these protocol definitions go.

Obviously, the specific editorial problems identified here should be addressed, but this effort should not be conflated with a PRECIS++ attempt.

Grüße, Carsten



[1]: https://www.rfc-editor.org/rfc/rfc9413.html#name-protocol-decay