Re: [Extra] Benjamin Kaduk's No Objection on draft-ietf-extra-imap4rev2-27: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

Hi Barry,

On Thu, Feb 04, 2021 at 09:33:13AM -0500, Barry Leiba wrote:
> Thanks, Ben, for the usual good comments.  Just responses on a couple here:
> 
> > Section 2.2.1
> >
> >       response, and reads another response from the server.  In all
> >       cases, the client MUST send a complete command (including
> >       receiving all command continuation request responses and command
> >       continuations for the command) before initiating a new command.
> >
> > To check my understanding: the "command continuations for the command"
> > are things that the client sends, right?  Adding a word or two might
> > help clarify.
> 
> Yes, it should say "and sending command continuations"; the word
> "sending" is missing.
> 
> > Section 2.3.1.1
> >
> >                                          A good UIDVALIDITY value to use
> >    is a 32-bit representation of the current date/time when the value is
> >    assigned: this ensures that the value is unique and always increases.
> >    Another possible alternative is a global counter that gets
> >    incremented every time a mailbox is created.
> >
> > In light of the discussion in draft-gont-numeric-ids-sec-considerations,
> > I wonder if these are truly the most recommended options, as either
> > option has potential to leak some information about rate or time of
> > mailbox creation.  Leaking the time of mailbox creation to the user who
> > created it is, of course, not an issue, but not all IMAP mailboxes are
> > single-user-access.  A 32-bit PRP (e.g., block cipher) applied to either
> > option would provide some level of obfuscation while preserving the
> > uniqueness properties.
> 
> It would obfuscate and preserve uniqueness, but it would not preserve
> the monotonicity: a new UIDVALIDITY must always be greater than the
> previous ones.  Do you have a good suggestion for that, which still
> takes care of the privacy leak?

Oops, I missed the one line about UIDVALIDITY also needing to be monotonic
(written out as "unique identifier validity" it is easy to skip over the
"validity" word and just think read it as a UID).  No immediate
suggestions, then, though as the follow-up from Timo notes, it's unclear
what value the monotonicity of UIDVALIDITY adds -- the semantics seem to
just be "exact match required" for everything I noticed.

> > Section 2.3.2
> >
> >    $Junk  The user (or a delivery agent on behalf of the user) may
> >       choose to mark a message as definitely containing junk ($Junk; see
> >       also the related keyword $NotJunk).  The $Junk keyword can be used
> >       to mark (and potentially move/delete messages later), group or
> >       hide undesirable messages.  See [IMAP-KEYWORDS-REG] for more
> >       information.
> >
> > I'm not entirely sure what additional information I'm supposed to get
> > from [IMAP-KEYWORDS-REG]; the registry page is fairly short on
> > commentary.  (Applies throughout.)
> 
> It's meant to send you to the reference doc, but, yes, the reader
> already has that anyway.  It might simply be better to say that the
> registration is recorded in IMAP-KEYWORDS-REG.

Okay.

> > Section 6.4.8
> >
> >    Because of the similarity of MOVE to COPY, extensions that affect
> >    COPY affect MOVE in the same way.  Response codes listed in
> >    Section 7.1, as well as those defined by extensions, are sent as
> >    appropriate.
> >
> > Who decides what is "appropriate"?  Will everyone come to the same
> > conclusion?
> 
> It means that the same responses are sent for MOVE as for COPY, under
> the corresponding conditions.  Yes, we'd expect that to be evident.
> We can try rephrasing it if you think that's unclear.  Is what I said
> two sentences ago clearer?  Do you have other suggestions?

Maybe "as indicated for COPY" (assuming I correctly remembered the context
about which way the analogy is going).

Thanks,

Ben