From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from mx1.math.uh.edu (mx1.math.uh.edu [129.7.128.32]) by inbox.vuxu.org (Postfix) with ESMTP id 288BC2B3D5 for ; Mon, 19 Feb 2024 22:40:59 +0100 (CET) Received: from lists1.math.uh.edu ([129.7.128.208]) by mx1.math.uh.edu with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.97.1) (envelope-from ) id 1rcBNi-0000000GBna-1QpB for ml@inbox.vuxu.org; Mon, 19 Feb 2024 15:40:58 -0600 Received: from lists1.math.uh.edu ([127.0.0.1] helo=lists.math.uh.edu) by lists1.math.uh.edu with smtp (Exim 4.97.1) (envelope-from ) id 1rcBNi-00000000ho3-0RR2 for ml@inbox.vuxu.org; Mon, 19 Feb 2024 15:40:58 -0600 Received: from mx1.math.uh.edu ([129.7.128.32]) by lists1.math.uh.edu with esmtp (Exim 4.97.1) (envelope-from ) id 1rcBNa-00000000hnu-0ZD9 for ding@lists.math.uh.edu; Mon, 19 Feb 2024 15:40:55 -0600 Received: from quimby.gnus.org ([95.216.78.240]) by mx1.math.uh.edu with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.97.1) (envelope-from ) id 1rcBNY-0000000GBmw-0xrz for ding@lists.math.uh.edu; Mon, 19 Feb 2024 15:40:49 -0600 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :Date:References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=0UfIgWcsc5QZYjg6KjeEZ/g/prPut71h3u8qjPdUwkI=; b=bDvoR7IzdqB1WKPAqymEjLSoFd JvZju33aAQU3Nt68eQx20KvbLi0Fjy9/UmCD9L+SYqGseveHQNLv8fraFqoCRFY2aKcrJBrRZLUyd IyWn3knQ4J/kV3cNcvkeQKQ+3ksOUbqQMvvk3IaV3nUwK++eCE8Rvt7GKmpL1VuUUwZQ=; Received: from mail.ericabrahamsen.net ([52.70.2.18]) by quimby.gnus.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rcBNQ-0004Lr-Ta for ding@gnus.org; Mon, 19 Feb 2024 22:40:43 +0100 Received: from localhost (71-212-21-65.tukw.qwest.net [71.212.21.65]) (Authenticated sender: eric@ericabrahamsen.net) by mail.ericabrahamsen.net (Postfix) with ESMTPSA id DF44DFA02C; Mon, 19 Feb 2024 21:40:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericabrahamsen.net; s=mail; t=1708378838; bh=0UfIgWcsc5QZYjg6KjeEZ/g/prPut71h3u8qjPdUwkI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=d7+zbM/TwUiSumvbSZR9vR4+Py/L5ICc9eAk2gqfjvipt0fDudNg4SDCmpoz1hal4 IMMMIa8P3toYB5e/cWruSm9+U1n21clRJO3LPlMj2e+t6fvwkqviDMb07sXqMT2zH6 8IXkprdsLOw+LBWT4Gy6HPzo26a7yKzIeCP/PN4o= From: Eric Abrahamsen To: =?utf-8?Q?Bj=C3=B8rn?= Mork Cc: Jakub =?utf-8?B?SmXEjW3DrW5law==?= , ding@gnus.org Subject: Re: ProtonMail Bridge Patch In-Reply-To: <87sf1o71pd.fsf@miraculix.mork.no> (=?utf-8?Q?=22Bj=C3=B8rn?= Mork"'s message of "Mon, 19 Feb 2024 19:23:26 +0100") References: <86msrzknim.fsf@kubajecminek.cz> <87frxrq84g.fsf@ericabrahamsen.net> <86cysvexqv.fsf@kubajecminek.cz> <87y1bhpt1o.fsf@ericabrahamsen.net> <87r0h94pvh.fsf@kubajecminek.cz> <87sf1o71pd.fsf@miraculix.mork.no> Date: Mon, 19 Feb 2024 13:40:36 -0800 Message-ID: <871q98m8tn.fsf@ericabrahamsen.net> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-ID: Precedence: bulk Bj=C3=B8rn Mork writes: > Jakub Je=C4=8Dm=C3=ADnek writes: >> "Eric Abrahamsen" writes: >> >>> I also wasn't able to find anything explicit in RFC 3501 or 9051 about >>> the order of FETCH responses -- for my information, can you point me in >>> the right direction? >> >> That's the thing. There's nothing explicit in RFC 3501 about the message >> order so AFAIK the consensus is that UIDs don't have to be sorted. > > I was curiuos about this too and went looking. I believe the definition > of "sequence-set" (which is what the ID range in the FETCH request is) > on https://datatracker.ietf.org/doc/html/rfc3501#page-90 suggests that > clients should expect replies in any order: > > Servers MAY coalesce overlaps and/or execute the sequence in any > order. Thanks! I hadn't looked as far as the formal syntax section, that's helpful.