Re: [Extra] Review: draft-ietf-extra-imap-uidonly

[Bron Gondwana <[e-mail]>]

On Fri, Mar 3, 2023, at 10:10, Alexey Melnikov wrote:
> Hi Bron,
> 
> On 31/01/2023 01:21, Bron Gondwana wrote:
>> I figured I should do an initial review of this document now it's adopted.  It looks good, though there's definitely outstanding questions to respond to.  Here's my responses.
>> 
>> *Abstract**
*
>> 
>> The wording could do with some tightening up.  My idea for a rewrite looks something like:
>> 
>>    The UIDONLY extension to the Internet Message Access Protocol (RFC
>>    3501/RFC 9051) allows clients to enable a mode in which information
>>    about mailbox changes is returned using only UIDs.  Message numbers are
>>    not returned in responses, and can not be used in requests once this
>>    extension is enabled.  This allows both clients and servers to avoid
>>    requiring resources to maintain a map between message numbers and UIDs.
>> 
> I used some of your text, thank you!
>> 
>> *3.2 Changes to FETCH/STORE/SEARCH*
>> 
>> No, this is not too restrictive.  Yes, COPY/MOVE should be restricted in the same way.  They allow MSGNOs, they need to be restricted.  ALSO SEARCH/SORT/THREAD/etc *MUST NOT* have a `<sequence set>` without the UID specifier.
> Ok. I now also mention SORT/THREAD.
>> 
>> *3.3 Changes to UID FETCH/UID STORE*
>> 
>> I would not make this change to not give the UID if requested.  I see the point of UIDFETCH vs FETCH but I'd still allow the UID item to be in the result if explicitly requested rather than ignoring it.
>> 
>> Either make it an error to specify it, or return it so parsers don't need to be quite so smart.
> I am not sure what is the big deal either way?

It's not a huge deal - I guess you're writing new code anyway.

>> **
>> *3.5. Changes to how other mailbox changes are announced***
>> 
>> Regarding interaction with CONDSTORE/QRESYNC - I don't think it's that complex, basically:
>> **
>> *RFC7162 section 3.2.5, the client MUST NOT include a sequence range to UID mapping in the SELECT parameters.*
>> 
>> We should just specify that.  There's nothing else in that document which isn't already covered by removing the msgno versions of FETCH/STORE etc.
> Ok.
>> And with that, I really think this is basically ready to go - unless we want to re-open the debate about having a FETCH response with a zero or random msgno rather than a UIDFETCH response.
> I would rather not :-). I think reusing FETCH is a mistake (in particular 0 FETCH) and will confuse existing client implementations.
> 

I'm good with this.

> UIDFETCH is also a safety net if servers start sending this [by mistake] to clients without UIDONLY being enabled.
> 

Yes, that's a really good point.  Safety net is sensible.

Cheers,

Bron.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  [e-mail]