On Tue, Apr 2, 2024 at 5:44 PM John C Klensin <john-ietf@xxxxxxx> 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:
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:
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
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
