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

[Rob Sayre <[e-mail]>]

On Tue, Apr 2, 2024 at 5:44 PM John C Klensin <[e-mail]> wrote:

> It seems to me that your conclusion depends on an assumption
> about "the JMAP community" that might be questionable.  An
> analysis of the JMAP specification leads me to a slightly
> different conclusion; inline below.
>

At the risk of repeating myself, I don't think PRECIS really does the trick
here, even though it's easy to see it does work sometimes (I went and
looked at the "Referenced By" stuff in the datatracker). The document is
"Preparation, Enforcement, and Comparison of Internationalized Strings
Representing Usernames and Passwords".

But there are other problems that will come up, like writing street
addresses in Japanese, Thai, etc., as written here:

https://datatracker.ietf.org/doc/draft-ietf-calext-jscontact/

So, while PRECIS might apply cleanly to this draft, I think the JSON
implementations will be facing much more varied content.

That's why I prefer the approach here:

https://datatracker.ietf.org/doc/draft-bray-unichars/

It's also realistic about the fact you will get the so-called "toxic waste"
from whatever JavaScript's JSON.parse and JSON.stringify do. This way is
even better as it relates to "any UTF-8 string", because the Unichars draft
covers escape sequences. The issue in JSON or XML is that you can send
perfectly valid UTF-8, but there might be escape sequences that represent
total garbage from a Unicode perspective. The Unichars draft provides some
usefully adversarial examples.

thanks,
Rob