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

[Alexey Melnikov <[e-mail]>]

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

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


Best Regards,

Alexey