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

[John C Klensin <[e-mail]>]

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
<[e-mail]> 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