MIME-Version: 1.0
References: <171605695839.29495.8129547067232508808@ietfa.amsl.com>
In-Reply-To: <171605695839.29495.8129547067232508808@ietfa.amsl.com>
From: Rob Sayre <sayrer@gmail.com>
Date: Sat, 18 May 2024 12:47:48 -0700
Message-ID: 
 <CAChr6SyGwH5B5mFKrByeS2ymrU_NG-TmHKDRxN=jZ1o4=KKNhQ@mail.gmail.com>
To: Tim Bray <tbray@textuality.com>
Content-Type: multipart/alternative; boundary="000000000000de67b70618bfbe89"
Message-ID-Hash: HS36S2HB2CKFS6J2ABCA5VKM5WOFT767
CC: art@ietf.org, draft-ietf-jmap-contacts.all@ietf.org, jmap@ietf.org,
 last-call@ietf.org
Precedence: list
Subject: =?utf-8?q?=5BJmap=5D_Re=3A_=5Bart=5D_Artart_telechat_review_of_draft-ietf-jm?=
	=?utf-8?q?ap-contacts-09?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/jmap/ZCYP-58LtkND4n3V3A0Y_ijgzbQ>

--000000000000de67b70618bfbe89
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, May 18, 2024 at 11:29=E2=80=AFAM Tim Bray via Datatracker <noreply@=
ietf.org>
wrote:

> Reviewer: Tim Bray
> Review result: Ready with Issues
>
> Thanks for adding the Internationalization Considerations section, which
> addresses the concern in my previous review that this issue needed more
> work.
> I have small issues:
>
> 1. There is a reference to "control characters" without any citation, and
> the
> definition is not as obvious as one might think. A good reference is
> [UNICODE]
> section 23.1, which may be summarized as "65 code points in the ranges
> U+0000-U+001F ("C0 Controls") and U+0080-U+009F (=E2=80=9CC1 Controls=E2=
=80=9D), plus
> U+007F,

"DEL" 2.


RFC 20, section 4.1 (or some update) would do. But, I wonder if that
part is right, because of the way JSContact is defined.

https://www.rfc-editor.org/rfc/rfc9553.html#name-free-form-text

That can certainly contain CR, LF, TAB, in common cases. But if you get BEL
or SUB, that may be a problem.


> This section might benefit from a reference to RFC9413, which has a
> thorough discussion of dealing with input data that is invalid for some
> reason.
> 3. There are 3 options when receiving a message with invalid characters:
> delete
> them, replace them (Unicode provides U+FFFD for this purpose), or reject
> the
> message.

The draft mentions two of these but not the replacement option. Is it
> never appropriate in the JMAP context?
>

I think most people do this, because they add new emoji every year, but I
think the operating system takes care of it most of the time.

For example, I am listed as "Rob =F0=9F=8E=A7" for one person, because they=
 call me
with audio problems (it showed up in an email, so I found this out when the
iPhone contact list name drifted into email). But you can see this pattern
drifting to whatever new ones they add.

thanks,
Rob

--000000000000de67b70618bfbe89
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Sat, May 18, 2024 at 11:29=E2=80=
=AFAM Tim Bray via Datatracker &lt;<a href=3D"mailto:noreply@ietf.org">nore=
ply@ietf.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex">Reviewer: Tim Bray<br>
Review result: Ready with Issues<br>
<br>
Thanks for adding the Internationalization Considerations section, which<br=
>
addresses the concern in my previous review that this issue needed more wor=
k. <br>
I have small issues:<br>
<br>
1. There is a reference to &quot;control characters&quot; without any citat=
ion, and the<br>
definition is not as obvious as one might think. A good reference is [UNICO=
DE]<br>
section 23.1, which may be summarized as &quot;65 code points in the ranges=
<br>
U+0000-U+001F (&quot;C0 Controls&quot;) and U+0080-U+009F (=E2=80=9CC1 Cont=
rols=E2=80=9D), plus U+007F,=C2=A0</blockquote><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex">
&quot;DEL&quot; 2. </blockquote><div><br></div><div>RFC 20, section 4.1 (or=
 some update) would do. But, I wonder if that part=C2=A0is right, because o=
f the way JSContact is defined.</div><div><br></div><div><a href=3D"https:/=
/www.rfc-editor.org/rfc/rfc9553.html#name-free-form-text">https://www.rfc-e=
ditor.org/rfc/rfc9553.html#name-free-form-text</a><br></div><div><br></div>=
<div>That can certainly contain CR, LF, TAB, in common cases. But if you ge=
t BEL or SUB, that may be a problem.</div><div>=C2=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex">This section might benefit from a referen=
ce to RFC9413, which has a<br>
thorough discussion of dealing with input data that is invalid for some rea=
son.<br>
3. There are 3 options when receiving a message with invalid characters: de=
lete<br>
them, replace them (Unicode provides U+FFFD for this purpose), or reject th=
e<br>
message.</blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The =
draft mentions two of these but not the replacement option. Is it<br>
never appropriate in the JMAP context?<br></blockquote><div><br></div><div>=
I think most people do this, because they add new emoji every year, but I t=
hink the operating system takes care of it most of the time.</div><div><br>=
</div><div>For example, I am listed as &quot;Rob=C2=A0=F0=9F=8E=A7&quot; fo=
r one person, because they call me with audio problems (it showed up in an =
email, so I found this out when the iPhone contact list name drifted into e=
mail). But you can see this pattern drifting to whatever new ones they add.=
</div><div><br></div><div>thanks,</div><div>Rob</div><div><br></div><div>=
=C2=A0</div></div></div>

--000000000000de67b70618bfbe89--