Re: [Extra] Publication has been requested for draft-ietf-extra-imap-uidonly-06
Ben Bucksch <ben.bucksch@beonex.com> Wed, 13 March 2024 14:52 UTC
Return-Path: <ben.bucksch@beonex.com>
X-Original-To: extra@ietfa.amsl.com
Delivered-To: extra@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 541FAC14F60C for <extra@ietfa.amsl.com>; Wed, 13 Mar 2024 07:52:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syIas5OjV5Df for <extra@ietfa.amsl.com>; Wed, 13 Mar 2024 07:52:49 -0700 (PDT)
Received: from mail.server.beonex.com (mail.server.beonex.com [144.76.227.234]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4E40C14F60A for <extra@ietf.org>; Wed, 13 Mar 2024 07:52:47 -0700 (PDT)
Content-Type: multipart/alternative; boundary="------------19cfkrduQEx5G88nN7ZFEhyz"
Message-ID: <6e02eab8-8534-4d01-ab04-d2203c204895@beonex.com>
Date: Wed, 13 Mar 2024 15:52:38 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: fr
To: extra@ietf.org
References: <170769454546.35179.3683352028983215625@ietfa.amsl.com> <CAL0qLwY5p3wT0sxFmb2w2vHU+KdnYY8uDiu6FjWXYY_rUvm2cw@mail.gmail.com> <77c972d5-4ad8-c44b-b7a3-65173f11d594@isode.com> <CAL0qLwZiAaUPQUZtzmOGYpb5xLjdJ-_WeLPyTeMss-FFJkZsVQ@mail.gmail.com> <a8080722-1eed-4a2f-acf1-5287b60dde14@isode.com>
From: Ben Bucksch <ben.bucksch@beonex.com>
Organization: Beonex
In-Reply-To: <a8080722-1eed-4a2f-acf1-5287b60dde14@isode.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/Qd79vJSmK26UkAXm7kAHWimgYY4>
Subject: Re: [Extra] Publication has been requested for draft-ietf-extra-imap-uidonly-06
X-BeenThere: extra@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Email mailstore and eXtensions To Revise or Amend <extra.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/extra>, <mailto:extra-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/extra/>
List-Post: <mailto:extra@ietf.org>
List-Help: <mailto:extra-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/extra>, <mailto:extra-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Mar 2024 14:52:50 -0000
Am 13.03.24 um 15:47 schrieb Alexey Melnikov: > > On 13/03/2024 05:28, Murray S. Kucherawy wrote: > >> On Tue, Mar 5, 2024 at 3:46 AM Alexey Melnikov >> <alexey.melnikov@isode.com> wrote: >> >> Hi Murray, >> >> On 01/03/2024 22:48, Murray S. Kucherawy wrote: >>> On Sun, Feb 11, 2024 at 3:36 PM Bron Gondwana via Datatracker >>> <noreply@ietf.org> wrote: >>> >>> Bron Gondwana has requested publication of >>> draft-ietf-extra-imap-uidonly-06 as Experimental on behalf >>> of the EXTRA working group. >>> >>> Please verify the document's state at >>> https://datatracker.ietf.org/doc/draft-ietf-extra-imap-uidonly/ >>> >>> >>> Why does the shepherd writeup identify RFC 3501 as a normative >>> downward reference? >> In most recent RFCs we want to signal that an extension is >> compatible with both IMAP4rev2 (RFC 9051) and IMAP4rev1 (RFC >> 3501). Is this Ok? >> >> >> So what's weird is that I asked the question, but then started the >> Last Call anyway, and the datatracker didn't automatically identify >> the downward reference in its auto-generated Last Call text. This >> may or may not be a problem, but I'll sort it out. > Great, thanks. I think there were several RFCs published referencing > both, so this shouldn't be a problem from the process point of view. Given that IMAPrev2 is relatively new (in email time scales...), and most current implementations implement IMAP4rev1, the statement that this new spec is compatible is comforting. Particularily given that the RFC talks about IDs, and sematics of IDs are a *major* main point in IMAP, it's re-assuring that this RFC is explicitly backwards compatible with IMAP4rev1.
- [Extra] Publication has been requested for draft-… Bron Gondwana via Datatracker
- Re: [Extra] Publication has been requested for dr… Murray S. Kucherawy
- Re: [Extra] Publication has been requested for dr… Ken Murchison
- Re: [Extra] Publication has been requested for dr… Alexey Melnikov
- Re: [Extra] Publication has been requested for dr… Murray S. Kucherawy
- Re: [Extra] Publication has been requested for dr… Alexey Melnikov
- Re: [Extra] Publication has been requested for dr… Ben Bucksch