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

[Ballot comment]
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

[Ballot comment]
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.

[Ballot comment]
[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.

[Ballot comment]
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

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

[Ballot discuss]
First part is a formality discuss that likely is fairly easy to resolve

So this document uses formal syntax, however it does not explicitly reference which. So I noticed RFC 5228 that do reference RFC 4234 which is now obsolete, and the current in force version of ABNF is RFC 5234. Also as no WSP are included in the rules, this document appears to use ABNF to express RFC 5228 grammar and not parsing syntax. So please clarify prior to the usages what the formal language is and what it represents.

So this needs to be done prior to Section 5. But, can you please check that you actually have the same level of  formal syntax in Section 5 that goes through RFC 8580 as what is in Section 8. Otherwise please clarify both.

Secondly, I do consider the defining text first paragraph of in Section 4.1 so hard to interpret that it must be fixed prior to publication. So although you already are going to address it based on discussion of Martin Duke's comment, I want to hold a discuss on this.

[Ballot comment]
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 ?

[Ballot comment]
* 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.

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-sieve-mailboxid-05. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the Sieve Extensions registry located at:

https://www.iana.org/assignments/sieve-extensions/

A single, new extension is to be registered as follows:

Capability name: mailboxid
Description: adds a test for checking mailbox existence by objectid, and new optional arguments to fileinto and :fcc which allow selecting the destination mailbox by objectid.
RFC Number: [ RFC-to-be ]
Contact address: extra@ietf.org

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Michelle Cotton
Protocol Parameters Engagement Sr. Manager
IANA Services

The following Last Call announcement was sent out (ends 2020-12-02):

From: The IESG
To: IETF-Announce
CC: barryleiba@gmail.com, yaojk@cnnic.cn, Jiankang Yao , extra@ietf.org, draft-ietf-extra-sieve-mailboxid@ietf.org, extra-chairs@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Sieve Email Filtering: delivery by mailboxid) to Proposed Standard


The IESG has received a request from the Email mailstore and eXtensions To
Revise or Amend WG (extra) to consider the following document: - 'Sieve Email
Filtering: delivery by mailboxid'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-12-02. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The OBJECTID capability of the IMAP protocol (RFC8474) allows clients
  to identify mailboxes by a unique identifier which survives rename.

  This document extends the Sieve mail filtering language (RFC5228) to
  allow using that same unique identifier as a target for fileinto
  rules, and for testing the existance of mailboxes.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-mailboxid/



No IPR declarations have been submitted directly on this I-D.

Document Shepherd Write-Up for draft-ietf-extra-sieve-mailboxid-03

1. This document is being requested as a Proposed Standard because it
adds new capabilities to existing Standards Track document(RFC 5228).
The request type is indicated in the title page header.

2.
Technical Summary

  The OBJECTID capability of the IMAP protocol (RFC8474) allows clients
  to identify mailboxes by a unique identifier which survives rename.
  This document extends the Sieve mail filtering language (RFC5228) to
  allow using that same unique identifier as a target for fileinto
  rules, and for testing the existance of mailboxes.

Working Group Summary
 
  Before being a WG draft, the WG members gave some significant comments.
  All identified issues were reflected in the new version of the draft.
  The EXTRA WG meeting in IETF 108 had detailed discussion about this draft
  and decided to move this document to WGLC.
  Some significant experts have looked throught this document in detail. It passed WGLC.
  Some small issues found in WGLC has been reflected in the new version of the draft.

Document Quality

  The document is in good shape and is ready to be published.
  Fastmail has implemented it, and have been using it in production for about a year.
  It's in the open source Cyrus IMAP server.
  All important comments and suggestions based on WG's discussion have been updated
  into the new version of this document.
  A few important experts in the WG think that this document is ready to be published.
 

Personnel

  Document Shepherd - Jiankang Yao (EXTRA co-chair)
  Responsible Area Director -  Barry Leiba


3. The Document Shepherd has read the document through in detail and
think that it is ready to go.

4. There has no concerns.

5. There is no review required for the document by other areas, it's
very self-contained.

6. There are no concerns with this document that IESG should be aware of.

7. There have been no IPR disclosures for this spec.

8. There have been no IPR disclosures for this spec.

9. The WG consensus is solid, while not everybody spoke, it was
clear that the entire group understood and agreed with the idea and
the method chosen.

10. There has been no discontent.

11. The ID nits tool shows the following:

"
if you have code sections in the document, please surround them with ''  and  ''

lines.
"

    Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--).


12. This document doesn't define anything which needs formal review
outside the working group.

13. All references have been identified as either normative or
informative.

14. All normative references are published standards.

15. There are no downward normative references references.

16. This RFC updates RFC5228. RFC5228 has been listed on the title page header, indicated in the abstract.

In the introduction, there has only one sentence which mentions
" [RFC5228] Sieve rules are sometimes created using graphical
  interfaces which allow users to select the mailbox to be used as a
  target for a rule."
The introduction does not directly say " this document updates RFC5228".


17. IANA are requested to add a capability to the sieve-extensions registry:

  To: iana@iana.org
  Subject: Registration of new Sieve extension

  Capability name: mailboxid
  Description: adds a test for checking mailbox existence by objectid,
                and new optional arguments to fileinto and :fcc which
                allow selecting the destination mailbox by objectid.
  RFC number: this RFC
  Contact address: The EXTRA discussion list 

18. None of the IANA registries mentioned require Expert Review.

19. Have checked the formal language. Find some issues in section "Formal Syntax" of version 2 of this draft and ask the author to update it to version 3.

20. Find no issues here.

Document Shepherd Write-Up for draft-ietf-extra-sieve-mailboxid-03

1. This document is being requested as a Proposed Standard because it
adds new capabilities to existing Standards Track document(RFC 5228).
The request type is indicated in the title page header.

2.
Technical Summary

  The OBJECTID capability of the IMAP protocol (RFC8474) allows clients
  to identify mailboxes by a unique identifier which survives rename.
  This document extends the Sieve mail filtering language (RFC5228) to
  allow using that same unique identifier as a target for fileinto
  rules, and for testing the existance of mailboxes.

Working Group Summary
 
  Before being a WG draft, the WG members gave some significant comments.
  All identified issues were reflected in the new version of the draft.
  The EXTRA WG meeting in IETF 108 had detailed discussion about this draft
  and decided to move this document to WGLC.
  Some significant experts have looked throught this document in detail. It passed WGLC.
  Some small issues found in WGLC has been reflected in the new version of the draft.

Document Quality

  The document is in good shape and is ready to be published.
  Fastmail has implemented it, and have been using it in production for about a year.
  It's in the open source Cyrus IMAP server.
  All important comments and suggestions based on WG's discussion have been updated
  into the new version of this document.
  A few important experts in the WG think that this document is ready to be published.
 

Personnel

  Document Shepherd - Jiankang Yao (EXTRA co-chair)
  Responsible Area Director -  Barry Leiba


3. The Document Shepherd has read the document through in detail and
think that it is ready to go.

4. There has no concerns.

5. There is no review required for the document by other areas, it's
very self-contained.

6. There are no concerns with this document that IESG should be aware of.

7. There have been no IPR disclosures for this spec.

8. There have been no IPR disclosures for this spec.

9. The WG consensus is solid, while not everybody spoke, it was
clear that the entire group understood and agreed with the idea and
the method chosen.

10. There has been no discontent.

11. The ID nits tool shows the following:

"
if you have code sections in the document, please surround them with ''  and  ''

lines.
"

    Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--).


12. This document doesn't define anything which needs formal review
outside the working group.

13. All references have been identified as either normative or
informative.

14. All normative references are published standards.

15. There are no downward normative references references.

16. This RFC updates RFC5228. RFC5228 has been listed on the title page header, indicated in the abstract.

In the introduction, there has only one sentence which mentions
" [RFC5228] Sieve rules are sometimes created using graphical
  interfaces which allow users to select the mailbox to be used as a
  target for a rule."
The introduction does not directly say " this document updates RFC5228".


17. IANA are requested to add a capability to the sieve-extensions registry:

  To: iana@iana.org
  Subject: Registration of new Sieve extension

  Capability name: mailboxid
  Description: adds a test for checking mailbox existence by objectid,
                and new optional arguments to fileinto and :fcc which
                allow selecting the destination mailbox by objectid.
  RFC number: this RFC
  Contact address: The EXTRA discussion list 

18. None of the IANA registries mentioned require Expert Review.

19. Have checked the formal language. Find some issues in section "Formal Syntax" of version 2 of this draft and ask the author to update it to version 3.

20. Find no issues here.

Based on the IETF 108 EXTRA WG discussion, this document is in good state.
If you have any further comments on draft-ietf-extra-sieve-mailboxid-01. Please reply with any comments by Thursday, Aug.26 2020.