[Extra] Benjamin Kaduk's No Objection on draft-ietf-extra-sieve-mailboxid-06: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-extra-sieve-mailboxid-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-mailboxid/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 1

Thanks to the document shepherd for noting the lack of specific mention
in the Introduction that RFC 5228 is updated (and how).  Because the
Abstract and Introduction are supposed to be able to stand separately,
some text similar to what is in the Abstract should also be present in
the Introduction.

Section 3

   Scripts which use the following extensions MUST explicitly require
   the capability "mailboxid".

(editorial) since it may not be immediately clear "what follows", I'd
consider s/the following extensions/the extensions defined in this
document/.

Section 4.1

At risk of piling on, my suggested rewording for the initial paragraph
here would be:

% For servers that support the [RFC5490] mailbox extension, the
% ":mailboxid" modifier may be specified together with the ":create"
% modifier.  However, in this case the ":mailboxid" modifier has no
% effect, with the ":create" modifier causing the mailbox to be created
% and otherwise interacting as normal with all other extensions.

Section 5

   This document extends the definition of the ":fcc" argument defined
   in [RFC8580] so that it can optionally be used with the ":mailboxid"
   argument.

Is it normal to make this kind of behavior change without a formal
"Updates:" relationship?

Section 6

   a) the READ-WRITE response code is present for the mailbox (see
   Section 7.1 of [RFC3501]), if IMAP Access Control List (ACL)
   [RFC4314] is not supported by the server, or

Just to confirm, if the server does not provide response codes at all,
the client has to assume that delivery is not possible to that folder?

   b) the user has 'p' or 'i' rights for the mailbox (see Section 5.2 of
   [RFC4314]).

I'm not sure where the 'p' comes from; it is mentioned (as "p", with
double quotes) only once in §2.2, as part of the statement that
rights defined in RFC 2028 MUST NOT be present in the "RIGHTS="
capability.  In particular, following the reference suggests that it is
'e' and 'i' that correspond to READ-WRITE.

Section 9

There are quite a few extensions listed at
https://www.iana.org/assignments/sieve-extensions/sieve-extensions.xhtml
and this document only discusses the interaction of the "mailboxid"
extension with a handful of them.  I did not attempt to examine all
extensions that are currently registered to check for potential
interactions with "mailboxid" that might have security-relevant
considerations, but I encourage the authors and/or shepherd to ensure
that such a check has been made.

Section 14

I find it interesting that the changelog for the -04 reports that RFC
5490 has been moved to normative, but it shows up as informative now (in
the -06) with no other changelog mention.  (I don't currently have a
position on which classification of reference is more appropriate for
it.)

However, it seems like RFCs 3501 and 4314 need to be normative, since
they are used to determine the behavior of the "mailboxidexists" test.