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

From: Martin Duke via Datatracker <[email-masked]>
Date: Fri, 22 Jan 2021 20:57:23 -0800

Martin Duke has entered the following ballot position for
draft-ietf-extra-imap4rev2-25: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-extra-imap4rev2/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Various non-blocking questions/comments:

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?

2.3.2 In the $Phishing definition, do you mean the user agent SHOULD (in caps)
display an additional warning message?

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.”

---

From: "Bron Gondwana" <[email-masked]>
Date: Sun, 24 Jan 2021 14:14:28 +1100

On Sat, Jan 23, 2021, at 15:57, Martin Duke via Datatracker wrote:

(I know the answers to these!)

> 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.

> 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.

> 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
  [email-masked]

---

From: Martin Duke <[email-masked]>
Date: Sun, 24 Jan 2021 13:14:18 -0800

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 <[email-masked]>
wrote:

> 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.
>
> 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.
>
> 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.
>
> --

---

From: "Bron Gondwana" <[email-masked]>
Date: Mon, 25 Jan 2021 10:01:01 +1100

Oh hey - I'll defer to Alexey / Barry on this one.  It looks like "UID Set" is fresh terminology in imap4rev2 - I can't see it in RFC3501 - so they can explain why it's needed.

Cheers,

Bron.

On Mon, Jan 25, 2021, at 08:14, Martin Duke wrote:
> 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

   either message sequence numbers or unique identifiers.  See Section 9 <https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap4rev2-26#section-9>

> 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 <[email-masked]> wrote:
>> __
> _______________________________________________
> Extra mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/extra
>

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 25 Jan 2021 11:12:15 +0000

On 24/01/2021 23:01, Bron Gondwana wrote:

> Oh hey - I'll defer to Alexey / Barry on this one.  It looks like "UID 
> Set" is fresh terminology in imap4rev2 - I can't see it in RFC3501 - 
> so they can explain why it's needed.

"UID Set" came from RFC 4315 (UIDPLUS), which was folded into this 
document. It is needed to describe COPYUID/APPENDUID response codes, 
which always contain definite set of UIDs, i.e. no special "*".

Replying to Martin's comments below:

>> 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
>>
>>     either message sequence numbers or unique identifiers.  SeeSection 9  <https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap4rev2-26#section-9>
No it is not possible to combine them. And it is always clear from 
context (syntax) whether it is a sequence set of message numbers or a 
sequence set of UIDs. For example, FETCH command always takes a sequence 
set of message numbersas a parameter, while UID FETCH a always takes a 
sequence set of UIDs as a parameter.
>> (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?

Hopefully my explanation below anwered that. Also, sequence set is the 
original concept from IMAP4, so explaining how UID set differs from it 
seem to make sense.

Basically "*" is suitable as input to a command, when its value can be 
evaluated by the server, while the client might not even know its exact 
value at the time the command is executed.

When the server is returning a UID set (which is typically a part of a 
map from old UID set to a new UID set), the client has to know all 
values. So "*" is not suitable for this case.

Best Regards,

Alexey

>>
>> On Sat, Jan 23, 2021 at 7:14 PM Bron Gondwana <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>
>>     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.
>>
>>     <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.
>>
>>     * 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.
>>
>>     --
>>     [email-masked] <mailto:[email-masked]>
>>
>>
>> [email-masked] <mailto:[email-masked]>
>> <https://www.ietf.org/mailman/listinfo/extra>
>>
>
> --