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

[Bron Gondwana <brong=40fastmailteam.com@xxxxxxxxxxxxxx>]

On Mon, Apr 8, 2024, at 01:09, John C Klensin wrote:

Having just reread the charter, I think the latter situation --

including the need to revise the charter and downgrade specs-- if not

appropriate, or even tenable.  But, if that is the case, then, while

it would be reasonable for a spec to explicitly discuss, e.g., what

JMAP implementers are doing, an IETF Standards Track spec should

still be specifying The Right Thing to Do rather than ignoring that

and specifying current implementation practice alone.  

This is not just about formalities.  As has been pointed out

elsewhere, unrestricted use of arbitrary UTF-8 strings will last in a

particular context up to the point that some problem occurs that

receives wide publicity and perhaps ridicule for the implementers.

It would be far more appropriate (and desirable) for the IETF to

specify what should be done when (and if) people get the message than

to say nothing and be among the ridiculed.   If we know the potential

problems, let's not put those implementers in the position of being

able to say "no one ever told us about that".

There's a related issue here which is that jmap-contacts is largely transporting jscontact, which is a format from the CALEXT working group, where there's a requirement to be cross compatible with VCARD (RFC 6350), an existing IETF format which has this to say about UTF-8:

3.1.  Charset

   The charset (see [RFC3536] for internationalization terminology) for
   vCard is UTF-8 as defined in [RFC3629].  There is no way to override
   this.  It is invalid to specify a value other than "UTF-8" in the
   "charset" MIME parameter (see Section 10.1).

   NON-ASCII = UTF8-2 / UTF8-3 / UTF8-4
     ; UTF8-{2,3,4} are defined in [RFC3629]

   VALUE-CHAR = WSP / VCHAR / NON-ASCII
     ; Any textual character

In order to round-trip values between VCARD and jscontact, it is necessary to be able to represent values found in arbitrary real-world VCARDs.

...

Meanwhile, there is the issue of the fields which are specific to jmap-contacts and other future JMAP specs.  On the one hand, we could specify a restricted character set range for these free-text fields (being aware that servers may also have their own stricter restrictions on legal values for various reasons); however this would create a distinction between free text fields in these specs and free-text fields in other already published JMAP specs, increasing the complexity for server implementations, who would need different validators.

Also, it's unlikely that clients will all validate their input values - and clients will also need to handle misbehaving servers sending them invalid content; so I don't see the real world benefit to imposing this restriction given that it won't apply to all JMAP objects, or even all of jmap contacts' fields (given the need to remain compatible with RFC 6350 data).

I suggest saying something like this in the security considerations:

Servers SHOULD reject any attempt to set names using characters not in the Freeform Class as defined in PRECIS.

and

Clients SHOULD strip any characters not in the Freeform Class as defined in PRECIS before displaying strings.

Regards,

Bron.

--

  Bron Gondwana, CEO, Fastmail Pty Ltd

  brong@xxxxxxxxxxxxxxxx

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call