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
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
