Sieve Email Filtering: Delivery by MAILBOXID
draft-ietf-extra-sieve-mailboxid-09

Thank you for this document, which I found clear and easy to read.

I would only like to bring up again Magnus unanswered comment about formal syntax, and hope that the working group can address that before the document moves forward. Thread starting here: https://mailarchive.ietf.org/arch/msg/extra/zuH2VTx-NoXQXFzQ1PeJJkts0Bo/

Francesca

Thank you for the work put into this document. This extension seems obvious and quite useful.

Please find below one some nits.

I hope that this helps to improve the document,

Regards,

-éric

As a side note about the document shepherd's write-up, so much I liked the WG summary, so much I am surprized by the similar section 7 and 8 ;-)

Should the example be delimited by <CODE BEGINS> <CODE ENDS> ?

[edited to add: please respond to the secdir review.  Adding the :mailboxid
that takes precedence over the human-readable name does seem to be a case
where retrofitting functionality in can leave some rough edges.]

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.

* Do I understand the example correctly in Section 4.1?

- If "Fnosuch" and "INBOX.no-such-folder" exist, it gets filed to Fnosuch.
- If "Fnosuch" exists but "INBOX.no-such-folder" does not, it's filed to Fnosuch but INBOX.no-such-folder is created as well.
- If "Fnosuch" does not exist, it goes to "INBOX.no-such-folder", which is created if necessary.

If not, some additional clarification here would be useful.

* Similarly, am I correct that Section 6's example is functionally equivalent to Section 4's example (although not demonstrating use of the test)? If so, the "Note to implementers" might as well make that clear as well.

Hi,

Thanks for this document.  It was easy to read/understand.

One minor suggestion.  It would perhaps be better to use "SHOULD" rather than "It is advisable" in section 4.2.

One nit: "end run" rather than "endrun"?

Regards,
Rob