Hi Peter, thank you for your considered response, and apologies for letting the Easter holidays get in the way. I continue to believe that the work, i.e., to understand the semantics of the Unicode usage of jmap-contacts and related drafts from an internationalized interoperability perspective, needs to be done. But I also agree that the IESG processing of this specific document is not the occasion to do that, and simply adding a reference to one of the documents that we have been discussing will not actually do that work. (While I wrote modern-network-unicode mainly to be useful as guidance for specifying new protocols, applying internationalized interoperability thinking to what is currently underspecified Unicode usage might be another useful application of such a document.) One first step of doing such work might be to attempt extracting some of the tacit knowledge embedded in implementations of these JMAP-related standards, and making it explicit by writing it up in a descriptive document. This will combine elicited knowledge about libraries that are available on various platforms and applicable to this processing, with elicited knowledge about considerations specific to contacts and events. Then we could consider turning some of this knowledge (and maybe an appraisal of the successes and failures incurred) into prescriptive documents. Again, this is clearly out of scope from the focus of the present last-call, but that doesn’t mean that such work isn’t possible or will be fruitless. It certainly never will be perfect, and we may need to adjust our expectations a bit if we want to achieve anything at all here. Grüße, Carsten > On 28. Mar 2024, at 00:59, Peter Saint-Andre <stpeter@xxxxxxxxxx> wrote: > > On 3/23/24 5:56 AM, Carsten Bormann wrote: >> Hi Peter, >>> On 23. Mar 2024, at 10:47, Peter Saint-Andre <stpeter@xxxxxxxxxx> wrote: >>> >>> It's also true that we have not done as good a job of that due diligence as we could have (discouraged in part by the IAB statement [1] issued in 2015), but RFC 9233 remedied that oversight for IDNA and we're working on a similar Internet-Draft for PRECIS. >> Thank you for updating me on the PRECIS efforts. >> Given that we are discussing this in the context of draft-ietf-jmap-contacts: >> Do you believe we should force this and similar specs to normatively reference PRECIS and use this to create more detailed definitions of the text-based data items? > > Your most recent note prompted me to re-read your review, which seems to talk at a high level of generality about protocol design but which doesn't seem to make a specific recommendation about the text-based data items in draft-ietf-jmap-contacts. Do you believe we should force this spec to normatively reference draft-bray-unichars or draft-bormann-dispatch-modern-network-unicode? > > Reading your review then further prompted me to look at draft-ietf-jmap-contacts. As far as I can see, this document mentions internationalization only in relation to the "name" property of the AddressBook object, specifying that it "may be any UTF-8 string of at least 1 character in length and maximum 255 octets in size." > > Although that strikes me as rather loosely specified, I don't know enough about the context in which it might be used to make off-the-cuff recommendations. Section 3.3.1 describes various filtering operations involving name constructs, but those seem to be performed on ContactCard objects, not AddressBook objects. ContactCard objects seem to adhere to the JSContact Card format defined in Section 2 of draft-ietf-calext-jscontact (which is in the RFC Editor queue). And these filtering operations seem to occur in the context of a standard "/query" method as described in RFC 8620, which in turn is based on JSON. > > Thus even this very cursory examination reveals that there might be a whole bunch of underlying assumptions made by protocol designers and implementers in the JMAP community. Specifying at this late stage that, say, the name property of the AddressBook object should adhere to the PRECIS IdentifierClass might not be all that helpful. Moreover, I don't know if in practice JMAP systems have run into i18n-related issues that might lead folks in this community to tighten up their definitions (e.g., confusing results in filtering operations or data queries). Absent detailed knowledge, I would hesitate to graft new i18n rules in a "leaf" spec when the roots (JSON) and branches (JMAP and Calext) might make very different assumptions. As one example, draft-ietf-calext-jscontact could have used the PRECIS FreeformClass in Section 1.6.1, but instead it says that "free-form text values MAY contain any valid sequence of Unicode characters encoded as a JSON string". > > tl;dr: multiple ships have sailed. > > Peter > > _______________________________________________ > art mailing list > art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/art -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
