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

[Alexey Melnikov <[e-mail]>]

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:

> Cheers,
>
> Bron.
>
> On Mon, Jan 25, 2021, at 08:14, Martin Duke wrote:
>> 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.  SeeSection 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")?
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 <[e-mail] 
>> <mailto:[e-mail]>> 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
>>     <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
>>     [e-mail] <mailto:[e-mail]>
>>
>>
>> _______________________________________________
>> Extra mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/extra 
>> <https://www.ietf.org/mailman/listinfo/extra>
>>
>
> --
>   Bron Gondwana, CEO, Fastmail Pty Ltd
>   [e-mail]
>
>
>
> _______________________________________________
> Extra mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/extra