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

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

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
> <[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.

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.

Peter