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

[Peter Saint-Andre <[e-mail]>]

On 3/23/24 5:56 AM, Carsten Bormann wrote:
> Hi Peter,
> 
>> On 23. Mar 2024, at 10:47, Peter Saint-Andre <[e-mail]> 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