--On Saturday, April 6, 2024 15:57 -0600 Peter Saint-Andre <stpeter@xxxxxxxxxx> wrote: > Hi John, thanks for sharing your perspective. Comments inline. > > On 4/2/24 6:43 PM, John C Klensin wrote: >> 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. > > Formally speaking, I don't disagree with anything you've said, and > I too would like to see more careful text regarding i18n matters in > the JMAP specs. However, I'm not in a position to speculate about > how, informally speaking, the JMAP spec authors and implementers > perceive themselves and function as a group (e.g., do they hold > interop events outside the context of IETF meetings where they > compare notes and discuss implementation issues?). In my > experience, this informal sense of "community" can have a > significant impact on exactly how specs are translated into code > and vice-versa. Well, yes, but... "Standards track" is a strong assertion about IETF Community Consensus, not (just) the consensus of some other body or community. So either: * This is an IETF specification and IETF consensus about, e.g., statements and requirements about i18n apply. Those statements could be stated as warnings and accompanied by observations that some (or all) JMAP implementers are not supporting those provisions rather than in BCP 9 normative form, but they should be there. * This is really a JMAP community specification that the IETF is being asked to publish for the convenience of the broader community. That makes it an Informational document and probably suggests that all other JMAP specs should be reviewed to figure out whether they represent IETF consensus or merely IETF community not carefully examining the details of those specs. It also suggests that the charter of the JMAP WG should be revised to specify that the WG is responsible for reviewing specifications developed elsewhere and refining the documentation for IETF Informational publication. Having just reread the charter, I think the latter situation -- including the need to revise the charter and downgrade specs-- if not appropriate, or even tenable. But, if that is the case, then, while it would be reasonable for a spec to explicitly discuss, e.g., what JMAP implementers are doing, an IETF Standards Track spec should still be specifying The Right Thing to Do rather than ignoring that and specifying current implementation practice alone. This is not just about formalities. As has been pointed out elsewhere, unrestricted use of arbitrary UTF-8 strings will last in a particular context up to the point that some problem occurs that receives wide publicity and perhaps ridicule for the implementers. It would be far more appropriate (and desirable) for the IETF to specify what should be done when (and if) people get the message than to say nothing and be among the ridiculed. If we know the potential problems, let's not put those implementers in the position of being able to say "no one ever told us about that". best, john -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
