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