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

[Barry Leiba <[e-mail]>]

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?

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

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

Barry