Re: [Extra] Martin Duke's No Objection on draft-ietf-extra-imap4rev2-25: (with COMMENT)

Martin Duke <martin.h.duke@gmail.com> Sun, 24 January 2021 21:14 UTC

Return-Path: <martin.h.duke@gmail.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 85B933A0B16; Sun, 24 Jan 2021 13:14:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Level:
X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WM370OsuCiM8; Sun, 24 Jan 2021 13:14:29 -0800 (PST)
Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DFF93A0B12; Sun, 24 Jan 2021 13:14:29 -0800 (PST)
Received: by mail-io1-xd2a.google.com with SMTP id u8so9531635ior.13; Sun, 24 Jan 2021 13:14:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Qwy8DunQMS5hD6SKr3NyecHbqKcQeSeL0tJfNyoDkVo=; b=t7UW6P1VzMLpv9hDWeIoD1IzD4PQBVWgaOlotv8+XYUFGAyyAMk6Yv9NT7IBKhKsVs PdhHpz1UtZw1T0GQjZp7cLqj4mKb51dqWbNTojHxc+mygTLhNLNnksaXRNenDuiYwXms +vIYx3ueaT18kULW7WYlJhC6SHpRQM5q3FSORK2mLZ5UI9fNWO6IXs2vaPNWSI//fRpJ LszE9+V3frwup0nZSWBXOP9LN1P9bCixSYo9CpH0uUrhlm/siS9OKngV4Wn9F4fy7WPr sib7EfoiWBWjB/vHLVWvSwkmU8eykQ/G3bERRdx+ddoWh1B6/SbZ9DtlY179AcW8OqE4 NcMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Qwy8DunQMS5hD6SKr3NyecHbqKcQeSeL0tJfNyoDkVo=; b=HgLZtInuPUmiESWMFcEHXL8FvNwTBQ1OG6TK4w00eI6V2ykxiBj36SGK1e6ubxTTia 06KGuC5ZTaxeXiguGd8QEfJ9pOYT3P+7+2CmVcLO6MQhXXCeN9jf7nzOCLuMiHverKLW eiNJHRGjru44MMZurhxBd/NabvM5TX51JxfF2GBRjrAS/+9hP7xma9hUdPw4UjgTwVEw IkxUjAGR7LFGInL9DijFnrGVRoiNYV3GbmqOmUPuOKm/WMdEJhnS7Ve9gbLbcnU8PDJk ximz2Zs3hlvtR0In0zS1DK5lvQLitD01YJrFcZR2F14f4Ke4XT1QU1HlWHSJy+G3sKyM wtsA==
X-Gm-Message-State: AOAM530+IIHIkXtlhkqiPj7AA42hmLZ7GqGSrSva96g8MI/jle1m1PW0 ZQG0U7EEjwZzGx98dDYK2BNhlSjSOayjAV4ca5Kb4yMgddMVzQ==
X-Google-Smtp-Source: ABdhPJzjJJxY+ASi24METnySvvPtkpiea2mZCXm2ag+PAnU1Yeg/vH2kEojIJrsIFP8OVM5wAxjizEXF/c985g4zRbk=
X-Received: by 2002:a02:5889:: with SMTP id f131mr156386jab.121.1611522868491; Sun, 24 Jan 2021 13:14:28 -0800 (PST)
MIME-Version: 1.0
References: <161137784334.20615.12096399788075509949@ietfa.amsl.com> <f950de71-5e6a-4b19-ad2e-40b7394c27f7@dogfood.fastmail.com>
In-Reply-To: <f950de71-5e6a-4b19-ad2e-40b7394c27f7@dogfood.fastmail.com>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Sun, 24 Jan 2021 13:14:18 -0800
Message-ID: <CAM4esxS07JxMAQnfOOASxAZd3PvT=_GZpYE=P9i8d9nzpwmN=w@mail.gmail.com>
To: Bron Gondwana <brong@fastmailteam.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-extra-imap4rev2@ietf.org, extra-chairs@ietf.org, extra@ietf.org
Content-Type: multipart/alternative; boundary="0000000000001fbdcb05b9abe86b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/z8K9KRKbrvu5eCg7qxcL6v1Q8Ec>
Subject: Re: [Extra] Martin Duke's No Objection on draft-ietf-extra-imap4rev2-25: (with COMMENT)
X-BeenThere: extra@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 24 Jan 2021 21:14:32 -0000

Thanks Bron,

Your replies make sense, but one:

Regarding 4.1.1, I find this terminology confusing, overloading the word
"sequence", although at this stage maybe it can't be helped. Still, this
section still seems very unclear to me.

4.1.1 <https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap4rev2-26#section-4.1.1>.
Sequence set and UID set

   A set of messages can be referenced by a sequence set containing
   either message sequence numbers or unique identifiers.  See Section
9 <https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap4rev2-26#section-9>
   for details.  Sequence sets can contain ranges (e.g. "5:50"), an
   enumeration of specific message/UID numbers, a special symbol "*", or
   a combination of the above.

   A "UID set" is similar to the sequence set of unique identifiers;
   however, the "*" value for a sequence number is not permitted.

So if I got this right, there's a "sequence set" that contains either
sequence numbers or UIDs and can contain "*".
then there is also a "UID Set" which is UID only, and cannot contain "*".
But then I have two questions:
(1) Can a sequence set have a combination of sequence numbers and UIDs (" a
combination of the above")?
(2) If a UID set can't have sequence numbers, then why is it explaining the
lack of "*" in the context of UID sets with sequence numbers?

On Sat, Jan 23, 2021 at 7:14 PM Bron Gondwana <brong@fastmailteam.com>
wrote:

> On Sat, Jan 23, 2021, at 15:57, Martin Duke via Datatracker wrote:
>
> (I know the answers to these!)
>
> 2.3.1.1 what would happen if the UID approached 2^32 due to a lifetime of
> spam
> or something? The server can increment the validity value, but doesn’t that
> make earlier email unreferenceable except via sequence number?
>
>
> Sequence number is even less persistent - but when you increment the
> UIDVALIDITY you can renumber the UIDs for everything, so you'd just start
> at 1 and reid all the existing records.  So they'll be referenceable by
> their new UIDs next time the mailbox is selected.
>
> And (plug) if the server implements RFC8474 (object ids) then a client can
> even tell that it's the same email and not need to fetch the content again,
> even after a UIDVALIDITY change.
>
> 2.3.2 In the $Phishing definition, do you mean the user agent SHOULD (in
> caps)
> display an additional warning message?
>
>
> This definition is copied from the IANA registry for keywords:
>
>
> https://www.iana.org/assignments/imap-jmap-keywords/phishing/phishing-template
>
> I'm not sure there's any point in changing the text to be different from
> the IANA registration just to make it capital SHOULD.  It's unlikely to
> change anybody's behaviour on reading this document.
>
> 4.1.1 the last statement, “ the "*" value for a sequence number is not
> permitted.”, is oddly placed, enough that it almost reads like a typo
> where you
> meant UID. A clearer statement might be “The ‘*’ value is permitted for
> UIDs
> but not sequence numbers.”
>
>
> No, that would be an incorrect statement.  The phrase "UID set" is a
> definitional term which means:
>
> * a sequence set;
> * that references UIDs, not message numbers; and
> * that consists only of numbers, not the magic '*' character (which can
> change value as new messages arrive)
>
> You can have a "sequence set" which references UIDs and does contain '*',
> but then it's not a "UID set" any more by definition.
>
> Cheers,
>
> Bron.
>
> --
>   Bron Gondwana, CEO, Fastmail Pty Ltd
>   brong@fastmailteam.com
>
>
>