Skip to main content

Sieve Email Filtering: Delivery by MAILBOXID
RFC 9042

Revision differences

Document history

Date Rev. By Action
2021-06-30
09 (System)
Received changes through RFC Editor sync (created alias RFC 9042, changed title to 'Sieve Email Filtering: Delivery by MAILBOXID', changed abstract to 'The OBJECTID …
Received changes through RFC Editor sync (created alias RFC 9042, changed title to 'Sieve Email Filtering: Delivery by MAILBOXID', changed abstract to 'The OBJECTID capability of IMAP (RFC 8474) allows clients to identify mailboxes by a unique identifier that survives renaming.

This document extends the Sieve email filtering language (RFC 5228) to allow using that same unique identifier as a target for fileinto rules and for testing the existence of mailboxes.', changed pages to 8, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2021-06-30, changed IESG state to RFC Published, created updates relation between draft-ietf-extra-sieve-mailboxid and RFC 5228)
2021-06-30
09 (System) RFC published
2021-06-30
09 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2021-05-26
09 (System) RFC Editor state changed to AUTH48
2021-04-05
09 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2021-03-31
09 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2021-03-30
09 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2021-03-30
09 (System) IANA Action state changed to In Progress from Waiting on Authors
2021-03-30
09 (System) IANA Action state changed to Waiting on Authors from In Progress
2021-03-30
09 (System) RFC Editor state changed to EDIT
2021-03-30
09 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2021-03-30
09 (System) Announcement was received by RFC Editor
2021-03-30
09 (System) IANA Action state changed to In Progress
2021-03-30
09 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2021-03-30
09 Amy Vezza IESG has approved the document
2021-03-30
09 Amy Vezza Closed "Approve" ballot
2021-03-30
09 Amy Vezza Ballot approval text was generated
2021-03-30
09 Murray Kucherawy IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2021-03-16
09 Bron Gondwana New version available: draft-ietf-extra-sieve-mailboxid-09.txt
2021-03-16
09 (System) New version accepted (logged-in submitter: Bron Gondwana)
2021-03-16
09 Bron Gondwana Uploaded new revision
2021-03-15
08 Bron Gondwana New version available: draft-ietf-extra-sieve-mailboxid-08.txt
2021-03-15
08 (System) New version accepted (logged-in submitter: Bron Gondwana)
2021-03-15
08 Bron Gondwana Uploaded new revision
2021-03-12
07 Francesca Palombini
[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 …
[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
2021-03-12
07 Francesca Palombini [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini
2021-03-11
07 Murray Kucherawy [Ballot Position Update] Position for Murray Kucherawy has been changed to Yes from No Objection
2021-03-10
07 Cindy Morgan Shepherding AD changed to Murray Kucherawy
2021-03-09
07 Magnus Westerlund
[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 …
[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.
2021-03-09
07 Magnus Westerlund [Ballot Position Update] Position for Magnus Westerlund has been changed to No Record from Discuss
2021-03-01
07 Bron Gondwana Added to session: IETF-110: extra  Fri-1530
2021-02-07
07 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-02-07
07 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2021-02-07
07 Bron Gondwana New version available: draft-ietf-extra-sieve-mailboxid-07.txt
2021-02-07
07 (System) New version accepted (logged-in submitter: Bron Gondwana)
2021-02-07
07 Bron Gondwana Uploaded new revision
2020-12-19
06 Benjamin Kaduk
[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 …
[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.
2020-12-19
06 Benjamin Kaduk Ballot comment text updated for Benjamin Kaduk
2020-12-17
06 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2020-12-17
06 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2020-12-17
06 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2020-12-16
06 Samuel Weiler Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Samuel Weiler. Sent review to list.
2020-12-16
06 Robert Wilton
[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 …
[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
2020-12-16
06 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2020-12-15
06 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2020-12-15
06 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2020-12-15
06 Benjamin Kaduk
[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 …
[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.
2020-12-15
06 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2020-12-15
06 Magnus Westerlund
[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 …
[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.
2020-12-15
06 Magnus Westerlund [Ballot Position Update] New position, Discuss, has been recorded for Magnus Westerlund
2020-12-14
06 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2020-12-13
06 Éric Vyncke
[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 …
[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 ?
2020-12-13
06 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2020-12-13
06 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2020-12-11
06 Martin Duke
[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. …
[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.
2020-12-11
06 Martin Duke [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke
2020-12-07
06 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2020-12-03
06 Cindy Morgan Placed on agenda for telechat - 2020-12-17
2020-12-03
06 Barry Leiba IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2020-12-03
06 Barry Leiba Ballot has been issued
2020-12-03
06 Barry Leiba [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba
2020-12-03
06 Barry Leiba Created "Approve" ballot
2020-12-03
06 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2020-12-03
06 Bron Gondwana New version available: draft-ietf-extra-sieve-mailboxid-06.txt
2020-12-03
06 (System) New version accepted (logged-in submitter: Bron Gondwana)
2020-12-03
06 Bron Gondwana Uploaded new revision
2020-12-02
05 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2020-11-30
05 Pete Resnick Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Pete Resnick. Sent review to list.
2020-11-30
05 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2020-11-30
05 Michelle Cotton
(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 …
(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
2020-11-25
05 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Nagendra Nainar
2020-11-25
05 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Nagendra Nainar
2020-11-21
05 Jean Mahoney Request for Last Call review by GENART is assigned to Pete Resnick
2020-11-21
05 Jean Mahoney Request for Last Call review by GENART is assigned to Pete Resnick
2020-11-19
05 Tero Kivinen Request for Last Call review by SECDIR is assigned to Samuel Weiler
2020-11-19
05 Tero Kivinen Request for Last Call review by SECDIR is assigned to Samuel Weiler
2020-11-18
05 Amy Vezza IANA Review state changed to IANA - Review Needed
2020-11-18
05 Amy Vezza
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, …
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.




2020-11-18
05 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2020-11-18
05 Barry Leiba Last call was requested
2020-11-18
05 Barry Leiba Last call announcement was generated
2020-11-18
05 Barry Leiba Ballot approval text was generated
2020-11-18
05 Barry Leiba IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2020-11-18
05 Bron Gondwana New version available: draft-ietf-extra-sieve-mailboxid-05.txt
2020-11-18
05 (System) New version accepted (logged-in submitter: Bron Gondwana)
2020-11-18
05 Bron Gondwana Uploaded new revision
2020-11-01
04 Bron Gondwana New version available: draft-ietf-extra-sieve-mailboxid-04.txt
2020-11-01
04 (System) New version accepted (logged-in submitter: Bron Gondwana)
2020-11-01
04 Bron Gondwana Uploaded new revision
2020-09-04
03 Barry Leiba IESG state changed to AD Evaluation::AD Followup from AD Evaluation
2020-09-04
03 Barry Leiba Ballot writeup was changed
2020-09-04
03 Barry Leiba IESG state changed to AD Evaluation from Publication Requested
2020-09-04
03 Jiankang Yao

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( …

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.
2020-09-04
03 Jiankang Yao Responsible AD changed to Barry Leiba
2020-09-04
03 Jiankang Yao IETF WG state changed to Submitted to IESG for Publication from In WG Last Call
2020-09-04
03 Jiankang Yao IESG state changed to Publication Requested from I-D Exists
2020-09-04
03 Jiankang Yao IESG process started in state Publication Requested
2020-09-04
03 Jiankang Yao

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( …

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.
2020-09-04
03 Bron Gondwana New version available: draft-ietf-extra-sieve-mailboxid-03.txt
2020-09-04
03 (System) New version accepted (logged-in submitter: Bron Gondwana)
2020-09-04
03 Bron Gondwana Uploaded new revision
2020-09-03
02 Bron Gondwana New version available: draft-ietf-extra-sieve-mailboxid-02.txt
2020-09-03
02 (System) New version accepted (logged-in submitter: Bron Gondwana)
2020-09-03
02 Bron Gondwana Uploaded new revision
2020-09-02
01 Jiankang Yao Notification list changed to Jiankang Yao <yaojk@cnnic.cn>
2020-09-02
01 Jiankang Yao Document shepherd changed to Jiankang Yao
2020-08-05
01 Jiankang Yao
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 …
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.
2020-08-05
01 Jiankang Yao IETF WG state changed to In WG Last Call from WG Document
2020-07-29
01 Bron Gondwana Changed consensus to Yes from Unknown
2020-07-29
01 Bron Gondwana Intended Status changed to Proposed Standard from None
2020-07-29
01 Bron Gondwana New version available: draft-ietf-extra-sieve-mailboxid-01.txt
2020-07-29
01 (System) New version accepted (logged-in submitter: Bron Gondwana)
2020-07-29
01 Bron Gondwana Uploaded new revision
2020-07-29
00 Bron Gondwana This document now replaces draft-gondwana-sieve-mailboxid instead of None
2020-07-29
00 Bron Gondwana New version available: draft-ietf-extra-sieve-mailboxid-00.txt
2020-07-29
00 (System) New version accepted (logged-in submitter: Bron Gondwana)
2020-07-29
00 Bron Gondwana Uploaded new revision