Peter, 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. --On Tuesday, April 2, 2024 16:46 -0600 Peter Saint-Andre <stpeter@xxxxxxxxxx> wrote: > On 4/1/24 8:39 PM, Neil Jenkins wrote: >> Is there a conclusion that we need to make any kind of change >> here? > > I don't think so. > > As Carsten said in his latest message, if folks in the JMAP > community were interested in taking inventory of their > specifications from an internationalization perspective, that > could be done. But from what I can tell from the outside, it > doesn't appear that there's a pressing need to do so. [1] As a slightly different perspective, if the IETF is positioning itself as following the JMAP community (or the JSON community more generally), creating small supplemental specifications for whatever those communities decide to do, then, with one qualification, there is nothing to do here. However, the existence of RFC 8620 as a Proposed Standard defining JMAP itself implies that the IETF in in charge of the JMAP definition and has change control. If there is some other "community" that really has final responsibility, then it seems to me that 8620 should have pointed that out, which it does not appear to do. Nor, of course, does draft-ietf-jmap-contacts-06 appear to point to any other authoritative specification. Absent an explanation in this document, I don't believe we are say "the JMAP community, as the responsible party, doesn't care so we don't either" because the JMAP community appears to be a subset of the IETF community and the IETF appears to be the responsible party. If the IETF really is responsible and we believe the many pieces of work done in the IETF or in progress (including PRECIS, the still-useful parts of RFC 5198 (if there are any), the two proposals discussed during ALLDISPATCH at IETF 119 -- all of which suggest that "just allow any UTF-8 string" is inappropriate without an explanation -- then this document would appear to need * A more restrictive definition of "string" than the one that RFC 8620 inherits from RFC 8259 and clarification of the syntax for AddressBook name and/or * An "Internationalization considerations" section, as called for by RFC 2277, that provides advice on why unrestricted UTF-8 strings (even ones that are valid under current Unicode specs and/or RFC 3629 (STD 63)) are not a good idea and should be avoided if possible. >... > [1] Until and unless an i18n-related issue results in an > exploitable security vulnerability, at which point interest > will skyrocket. :-) Yeah. And, when some of the likely sources of such problems / vulnerabilities are known, then a standards track document should contain at least a pointer to the issues involved. best, john -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
