Sieve Email Filtering: Delivery by MAILBOXID
draft-ietf-extra-sieve-mailboxid-09
Yes
Murray Kucherawy
(Barry Leiba)
No Objection
Erik Kline
Roman Danyliw
(Alvaro Retana)
(Deborah Brungard)
(Martin Vigoureux)
No Record
Note: This ballot was opened for revision 06 and is now closed.
Murray Kucherawy
(was No Objection)
Yes
Erik Kline
No Objection
Francesca Palombini
No Objection
Comment
(2021-03-12 for -07)
Sent
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
Roman Danyliw
No Objection
Éric Vyncke
No Objection
Comment
(2020-12-13 for -06)
Sent
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> ?
Barry Leiba Former IESG member
Yes
Yes
(for -06)
Unknown
Alvaro Retana Former IESG member
No Objection
No Objection
(for -06)
Not sent
Benjamin Kaduk Former IESG member
No Objection
No Objection
(2020-12-19 for -06)
Sent
[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.
Deborah Brungard Former IESG member
No Objection
No Objection
(for -06)
Not sent
Martin Duke Former IESG member
No Objection
No Objection
(2020-12-11 for -06)
Sent
* 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.
Martin Vigoureux Former IESG member
No Objection
No Objection
(for -06)
Not sent
Robert Wilton Former IESG member
No Objection
No Objection
(2020-12-16 for -06)
Sent
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
Magnus Westerlund Former IESG member
(was Discuss)
No Record
No Record
(2021-03-09 for -07)
Sent
Clearing my discuss as I step down. The text in section 4.1 was addressed, however I do question the removal of the formal syntax if that was the right thing to do? Have not received an answer and I think the responsible AD should have a discussion with the WG if this was the right step.