Return-Path: X-Original-To: jmap@mail2.ietf.org Delivered-To: jmap@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 5BFFA2A83ACD for ; Mon, 19 May 2025 21:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b="KCs/HmgY"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="hHN0lEEL" Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HapnM_EouLRs for ; Mon, 19 May 2025 21:10:24 -0700 (PDT) Received: from fout-b8-smtp.messagingengine.com (fout-b8-smtp.messagingengine.com [202.12.124.151]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 520C22A83AC6 for ; Mon, 19 May 2025 21:10:24 -0700 (PDT) Received: from phl-compute-02.internal (phl-compute-02.phl.internal [10.202.2.42]) by mailfout.stl.internal (Postfix) with ESMTP id B399B114017E for ; Tue, 20 May 2025 00:10:23 -0400 (EDT) Received: from phl-imap-15 ([10.202.2.104]) by phl-compute-02.internal (MEProxy); Tue, 20 May 2025 00:10:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-type:content-type:date:date:from :from:in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=fm1; t=1747714223; x= 1747800623; bh=5l+OYmgxss1D9lf+ITT8gSivkT/ZZPwbgKCyjyGjJYA=; b=K Cs/HmgYprSot9QxrdqRvAH6mavvKNhpNJCMIvykApSnd8SOBnXnubcI3QHz01Na9 oEl3DcwYUB9SY8QEctr4K275KN9iHIocWky/Uib9XVtlqO/sVUs2PdySc+kgwXx8 RroEOeWbhUdr/z5kvYTzuLeyiE9uDTRkNJ20OZxAn+teqaysGPF8vLEjc2AVveOD WiTplUTeWAziOa/om8PYGtoi75D9kD7qBy5aecD0XGxIW67+ayx/7Lw54apjsRB0 +RnhTMWHVh/ZKOvXosiYp9dDM7fqBo8DGLoyFJeJ0kc+Gov80c5XydgS0PmIYdWW KTBmm189K+ErydIh84lmg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1747714223; x=1747800623; bh=5l+OYmgxss1D9lf+ITT8gSivkT/ZZPwbgKC yjyGjJYA=; b=hHN0lEELdrhRsbI156l+vKHL5za3gaDmtW8YKIFSIOu3rN1bUcJ E79+LlnJUWrIU1lV1Yj2PwV+q5fmClfqVnlM6EluWvrO1bZy3BT3v6dcOi7KVF0w REI/tIwknq2Ii8pj2rVhlAGiq6f2xNUzeuS71F8ubmLDZQpRXcnX59Cyx/LfhP4o 1ek5a7myFmLFdXvMD4oBjCL52r3cPOXN8ZYMZBfREjLaeLvMtWtHtFDCVUGB4+1d IvDkdX9tQb01MxMcp7HqfcTJIPqqK6bZsWVpTj/UiIPck/4MhrXJbbkjN2vkisDe utJzOSoVsnzG8C1PrZGUtAFnSGIUDi9+MFw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdefvdefvdeiucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih gvnhhtshculddquddttddmnecujfgurhepofggfffhvffkjghfufgtsegrtderreertddt necuhfhrohhmpedfpfgvihhlucflvghnkhhinhhsfdcuoehnvghilhhjsehfrghsthhmrg hilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhepvdetiedvvefgieelveeggeeg geeugfdvuddvudehtddvkefhteefudetffdutedunecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomhepnhgvihhljhesfhgrshhtmhgrihhlthgvrghm rdgtohhmpdhnsggprhgtphhtthhopedupdhmohguvgepshhmthhpohhuthdprhgtphhtth hopehjmhgrphesihgvthhfrdhorhhg X-ME-Proxy: Feedback-ID: ibc614277:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 50F0678006C; Tue, 20 May 2025 00:10:23 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface MIME-Version: 1.0 X-ThreadId: T6e63edbaabfe256a Date: Tue, 20 May 2025 14:10:02 +1000 From: "Neil Jenkins" To: "IETF JMAP Mailing List" Message-Id: <24db4c6a-4f21-41d5-88f4-4112207d2b1a@localhost:3000> In-Reply-To: References: Content-Type: multipart/alternative; boundary=38e9b66b6d8b4a4899e03e00e6c97960 Message-ID-Hash: LHSFFBO6KWXT3GCZDHV62PFI6J5Z2PDH X-Message-ID-Hash: LHSFFBO6KWXT3GCZDHV62PFI6J5Z2PDH X-MailFrom: neilj@fastmailteam.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-jmap.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BJmap=5D_Re=3A_GroupedAddresses_suggests_grouping_consecutive_ad?= =?utf-8?q?dresses_into_own_group=2C_is_this_correct=3F?= List-Id: JSON Message Access Protocol Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --38e9b66b6d8b4a4899e03e00e6c97960 Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, 20 May 2025, at 06:19, Craven wrote: > RFC8621 holds the following statement: > "Consecutive "mailbox" values that are not part of a group are still collected under an EmailAddressGroup object to provide a uniform type." > > IIUC this means that after parsing both "To: , group: ;, " and "To: , , group: ;" this will result in two parse trees that are not simply a reordering of each other. That's right. Just to confirm we're on the same page: To: , group: ; would be parsed as: [ { "name": null, "addresses": [ { "name": null "email": "x@y.com" } ]}, { "name": "group", "addresses": [ { "name": null "email": "x@y.com" } ]}, { "name": null, "addresses": [ { "name": null "email": "x@y.com" } ]} ] while To: , , group: ; would be parsed as: [ { "name": null, "addresses": [ { "name": null "email": "x@y.com" }, { "name": null "email": "x@y.com" } ]}, { "name": "group", "addresses": [ { "name": null "email": "x@y.com" } ]} ] > This is surprising because the text makes reference to RFC5322 for which the parse trees as addr-list would be equivalent up to reordering. Again, just to make sure we're on the same page, the relevant bits of ABNF: address-list = (address *("," address)) / obs-addr-list address = mailbox / group So you would end up with `[mailbox, group, mailbox]` for the first example, and `[group, mailbox, mailbox]` for the second. > Interpreting the addr-list as suggested by RFC8621 goes from being equivalent up to ordering to non-equivalent under reordering. Is this intended? Yes. I mean, as stated in RFC8621, it deliberately wraps the `mailbox` entries in the same group structure so you have a uniform type, but you can see from the `null` group name that these were originally just bare `mailbox`es if you want to decompose again for some reason. Cheers, Neil. --38e9b66b6d8b4a4899e03e00e6c97960 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Tue, 20 M= ay 2025, at 06:19, Craven wrote:
RFC8621 holds the following statement:
"Cons= ecutive "mailbox" values that are not part of a group are still collecte= d under an EmailAddressGroup object to provide a uniform type."

IIUC this means that after parsing both "To: <x@y.com>, group: <x@y.com>;, <x@y.com>" an= d "To: <x@y.com>, <x@y.com>, group: <x@y= .com>;" this will result in two parse trees that are not simply a= reordering of each other.

That's = right. Just to confirm we're on the same page:
To: <x@y.com<=
/a>>, group: <x@y.com>; <x@y.com>
would be parsed as:
[=0A { "name": null, "add=
resses": [=0A   { "name": null "email": "x@y.com" }=0A ]},=0A { "name": =
"group", "addresses": [=0A   { "name": null "email": "x@y.com" }=0A ]},=0A=
 { "name": null, "addresses": [=0A   { "name": null "email": "x@y.com" }=
=0A ]}=0A]
while 
To: <x@y.com>, <<=
a href=3D"mailto:x@y.com">x@y.com>, group: <x@y.com>;
would be parsed as:
[=0A { "name": null, "addresses": [=0A  =
 { "name": null "email": "x@y.com" },=0A   { "name": null "email": "x@y.=
com" }=0A ]},=0A { "name": "group", "addresses": [=0A   { "name": null "=
email": "x@y.com" }=0A ]}=0A]

This is surprising because the text ma= kes reference to RFC5322 for which the parse trees as addr-list would be= equivalent up to reordering.

Aga= in, just to make sure we're on the same page, the relevant bits of ABNF:= 
address-list    =3D  =
 (address *("," address)) / obs-addr-list=0Aaddress         =3D   mailbo=
x / group

So you would end up with [mailbox, group, mailbox]  = for the first example, and [group, mailbox, mailbox]  for the second.

<= /div>
Interpreting th= e addr-list as suggested by RFC8621 goes from being equivalent up to ord= ering to non-equivalent under reordering. Is this intended?

Yes. I mean, as stated in RFC8621, it delibera= tely wraps the mailbox  entries in the same group structure so you have a uniform typ= e, but you can see from the null group name that these were originally just bare mailboxes if you want to de= compose again for some reason.

Cheers,
Neil.
--38e9b66b6d8b4a4899e03e00e6c97960--