Sieve Extension: File Carbon Copy (FCC)
RFC 8580
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2019-05-10
|
09 | (System) | Received changes through RFC Editor sync (created alias RFC 8580, changed title to 'Sieve Extension: File Carbon Copy (FCC)', changed abstract to 'The Sieve … Received changes through RFC Editor sync (created alias RFC 8580, changed title to 'Sieve Extension: File Carbon Copy (FCC)', changed abstract to 'The Sieve email filtering language provides a number of action commands, some of which can generate additional messages on behalf of the user. This document defines an extension to such commands to allow a copy of any generated message to be filed into a target mailbox. This document updates RFCs 5230 and 5435 by adding a new tagged argument to the Vacation and Notify actions, respectively.', changed pages to 12, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2019-05-10, changed IESG state to RFC Published, created updates relation between draft-ietf-extra-sieve-fcc and RFC 5230, created updates relation between draft-ietf-extra-sieve-fcc and RFC 5435) |
2019-05-10
|
09 | (System) | RFC published |
2019-04-25
|
09 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2019-04-16
|
09 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2019-04-01
|
09 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2019-01-31
|
09 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2019-01-31
|
09 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'No Response' |
2019-01-30
|
09 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2019-01-30
|
09 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2019-01-29
|
09 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2019-01-29
|
09 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2019-01-29
|
09 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2019-01-25
|
09 | (System) | RFC Editor state changed to EDIT |
2019-01-25
|
09 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2019-01-25
|
09 | (System) | Announcement was received by RFC Editor |
2019-01-25
|
09 | (System) | IANA Action state changed to In Progress |
2019-01-25
|
09 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2019-01-25
|
09 | Amy Vezza | IESG has approved the document |
2019-01-25
|
09 | Amy Vezza | Closed "Approve" ballot |
2019-01-25
|
09 | Amy Vezza | Ballot approval text was generated |
2019-01-25
|
09 | Alexey Melnikov | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2019-01-13
|
09 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-01-13
|
09 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2019-01-13
|
09 | Kenneth Murchison | New version available: draft-ietf-extra-sieve-fcc-09.txt |
2019-01-13
|
09 | (System) | New version approved |
2019-01-13
|
09 | (System) | Request for posting confirmation emailed to previous authors: Ken Murchison , Bron Gondwana |
2019-01-13
|
09 | Kenneth Murchison | Uploaded new revision |
2019-01-11
|
08 | Ben Campbell | [Ballot comment] I am clearing my DISCUSS, since conversation seems to be going in the right direction. I've included the DISCUSS text below for documentation … [Ballot comment] I am clearing my DISCUSS, since conversation seems to be going in the right direction. I've included the DISCUSS text below for documentation purposes. The security considerations say that this extension adds no new considerations not already present in [RFC5228], [RFC5230], [RFC5435], and [RFC6131]. I'm not sure that that is true. It seems like the ability to insert a copy of message into a mailbox might have security and/or privacy considerations. This seems analogous to the "fileinto" action. I looked for security considerations for that in RFC 5228. All I found was a statement that "fileinfo" can be dangerous, but no elaboration on the nature of the danger or how it might be mitigated. So while I agree that fcc would have similar considerations as "fileinfo", I'm not sure those considerations have been adequately documented. (I expect people will point me to something I missed, or where some other analogous feature is documented, in which case I will clear.) §1, last paragraph (nit): Should "each action" be "each new action"? §3.2, construction for FCC-OPTS: There is no extension point among the options, which would seem to require any new options update this RFC. Would it be reasonable to add one? |
2019-01-11
|
08 | Ben Campbell | [Ballot Position Update] Position for Ben Campbell has been changed to Yes from Discuss |
2019-01-10
|
08 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2019-01-10
|
08 | Ignas Bagdonas | [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas |
2019-01-09
|
08 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2019-01-09
|
08 | Benjamin Kaduk | [Ballot comment] I support Ben's Discuss. I also have some other comments. Section 1 Each action that generates additional messages will need to specify … [Ballot comment] I support Ben's Discuss. I also have some other comments. Section 1 Each action that generates additional messages will need to specify how it interfacts with :fcc. [...] Do we need to Update: 5228 so that authors of such future actions are aware of this requirement? The syntax and semantics of the mailbox argument MUST match those of the mailbox argument to the "fileinto" action specified in Section 4.1 of [RFC5228]. If the specified mailbox doesn't exist, the implementation MUST file the message into the user's main mailbox (e.g. IMAP "INBOX"). It's unclear that the "syntax and semantics MUST match" needs the 2119 MUST; it could just be "are defined to match". (Except they don't, since we add on the extra condition that a nonexistant mailbox name be delivered to the no-longer-implementation-defined INBOX folder instead of the other MAY options for fileinto.) Section 3.1 Tagged arguments in future extensions to the "fileinto" action should describe their interaction with ":fcc", if any. This is not a very strong statement. What would an implementor be expected to do upon encountering such future extensions that do not describe interaction with :fcc? (This requirement may also be a candidate for an Updates: relationship with 5228.) Section 3.1.2 Perhaps note that implementations are permitted but not required to create the mailbox (if needed) without this extension. Section 3.1.3 It's a bit odd to update the behavior of another document that's still an I-D (vs. specifying the behavior in question in that document). Section 5 Usage: vacation [FCC] [":days" number | ":seconds" number] [":subject" string] [":from" string] [":addresses" string-list] [":mime"] [":handle" string] This is presumably just my having skimmed RFC 5228 too quickly, but why is this [FCC] instead of [":fcc" string]" or similar? (Same for the notify action in Section 6.) Section 7 Do we want to have a list of currently defined actions that are not compatible with the "fcc" extension, to avoid any confusion by future readers as to what was defined at the time of this writing? |
2019-01-09
|
08 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
2019-01-09
|
08 | Adam Roach | [Ballot comment] Thanks for the work everyone did on this document. The mechanism seems quite useful. I have some minor suggestions that you may want … [Ballot comment] Thanks for the work everyone did on this document. The mechanism seems quite useful. I have some minor suggestions that you may want to consider incorporating. I support Ben's discuss. --------------------------------------------------------------------------- §1: > This extension defines a new optional tagged argument ":fcc" to > action commands which generate additional messages to allow a copy of Nit: "...commands that generate..." --------------------------------------------------------------------------- §3: > alters the behavior of action commands which generate additional Nit: "...commands that generate..." --------------------------------------------------------------------------- §3.2: > FCC = ":fcc" string *FCC-OPTS > ; per Section 2.6.2 of RFC5228, > ; the tagged arguments in FCC may appear in any order This threw me for a bit of a loop when I got to the example in section 5, and I had to go carefully read RFC 5228 to figure out what was going on. I think this would be much clearer and more accurate if the rule were described as: > FCC = *FCC-OPTS ":fcc" string *FCC-OPTS --------------------------------------------------------------------------- General: I'm a little concerned about the fact that this extension is generating a new message and attempting to store it into a potentially quota-controlled user folder. This would seem to be a run-time error, about which RFC 5228 says: > When an error happens, implementations MUST notify the user that an > error occurred and which actions (if any) were taken, and do an > implicit keep. This probably isn't the right behavior for FCC. I think a sentence or two of guidance about what happens when an FCC action would put the destination mailbox over quota are in order, particularly since they'll be different than the guidance in the base SIEVE spec. I might just be confused here -- corrections to any incorrect notions I've expressed would be appreciated. |
2019-01-09
|
08 | Adam Roach | [Ballot Position Update] New position, Yes, has been recorded for Adam Roach |
2019-01-09
|
08 | Ben Campbell | [Ballot discuss] Thanks for the work on this. I plan to ballot "yes", but have one item I think needs to be discussed first: The … [Ballot discuss] Thanks for the work on this. I plan to ballot "yes", but have one item I think needs to be discussed first: The security considerations say that this extension adds no new considerations not already present in [RFC5228], [RFC5230], [RFC5435], and [RFC6131]. I'm not sure that that is true. It seems like the ability to insert a copy of message into a mailbox might have security and/or privacy considerations. This seems analogous to the "fileinto" action. I looked for security considerations for that in RFC 5228. All I found was a statement that "fileinfo" can be dangerous, but no elaboration on the nature of the danger or how it might be mitigated. So while I agree that fcc would have similar considerations as "fileinfo", I'm not sure those considerations have been adequately documented. (I expect people will point me to something I missed, or where some other analogous feature is documented, in which case I will clear.) |
2019-01-09
|
08 | Ben Campbell | [Ballot comment] §1, last paragraph (nit): Should "each action" be "each new action"? §3.2, construction for FCC-OPTS: There is no extension point among the options, … [Ballot comment] §1, last paragraph (nit): Should "each action" be "each new action"? §3.2, construction for FCC-OPTS: There is no extension point among the options, which would seem to require any new options update this RFC. Would it be reasonable to add one? |
2019-01-09
|
08 | Ben Campbell | [Ballot Position Update] New position, Discuss, has been recorded for Ben Campbell |
2019-01-09
|
08 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2019-01-09
|
08 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2019-01-09
|
08 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2019-01-09
|
08 | Dan Romascanu | Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Dan Romascanu. Sent review to list. |
2019-01-08
|
08 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2019-01-08
|
08 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2019-01-08
|
08 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2019-01-07
|
08 | Mirja Kühlewind | [Ballot comment] I also have a minor comment on this sentence: "If the specified mailbox doesn't exist, the implementation MUST file the message into … [Ballot comment] I also have a minor comment on this sentence: "If the specified mailbox doesn't exist, the implementation MUST file the message into the user's main mailbox (e.g. IMAP "INBOX")." Beside the conflict Ekr mentioned, I'm wondering why this is a MUST. I guess the other option would be to not copy it anywhere (and file an error message to the user). I'm not an expert on mail at all but as a user I would find it confusing to find such messages in my INBOX. However, if there is a good reason that it must be ensured that such a message is stored, I guess that's the only viable default option. |
2019-01-07
|
08 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2019-01-06
|
08 | Eric Rescorla | [Ballot comment] Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3898 IMPORTANT S 3. > copy of the generated message into the mailbox provided in … [Ballot comment] Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3898 IMPORTANT S 3. > copy of the generated message into the mailbox provided in the > subsequent argument. The syntax and semantics of the mailbox > argument MUST match those of the mailbox argument to the "fileinto" > action specified in Section 4.1 of [RFC5228]. If the specified > mailbox doesn't exist, the implementation MUST file the message into > the user's main mailbox (e.g. IMAP "INBOX"). This seems to sort of conflict with S 3.1.1. I assume that the logic is: if (!exists && :create) { try_to_create() }; if (!exists) { file_in_inbox()} else { file_in_fcc_mailbox()}, but this text isn't celar. COMMENTS S 1. > > The capability string associated with this extension is "fcc". > > Each action that generates additional messages will need to specify > how it interfacts with :fcc. This document specifies the interaction > of :fcc with the Vacation [RFC5230] and Notify [RFC5435] extensions. Are these the only such actions? |
2019-01-06
|
08 | Eric Rescorla | [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla |
2019-01-03
|
08 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2018-12-26
|
08 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Dan Romascanu |
2018-12-26
|
08 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Dan Romascanu |
2018-12-20
|
08 | Cindy Morgan | Placed on agenda for telechat - 2019-01-10 |
2018-12-20
|
08 | Alexey Melnikov | Ballot has been issued |
2018-12-20
|
08 | Alexey Melnikov | [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov |
2018-12-20
|
08 | Alexey Melnikov | Created "Approve" ballot |
2018-12-20
|
08 | Alexey Melnikov | Ballot writeup was changed |
2018-12-20
|
08 | Alexey Melnikov | IESG state changed to IESG Evaluation from Waiting for Writeup |
2018-12-18
|
08 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2018-12-18
|
08 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-extra-sieve-fcc-08. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-extra-sieve-fcc-08. If any part of this review is inaccurate, please let us know. The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete. First, in the Sieve Extensions registry located at: https://www.iana.org/assignments/sieve-extensions/ a single, new registration will be made as follows: Capability name: fcc Description: Adds the ":fcc" parameter to Sieve action commands that generate additional messages. RFC Number: [ RFC-to-be ] Contact address: sieve@ietf.org Registration date: [ TBD-at-Registration ] Second, in the Notification-Capability Parameters registry located at: https://www.iana.org/assignments/notification-capability-parameters/ a single, new parameter will be registered as follows: Capability name: fcc Description: Returns whether a copy of the notification message sent using the method identified by the notification-uri parameter to the notify_method_capability test can be filed into a target mailbox. Syntax: Can contain one of two values: "yes" or "no". Values MUST be in lowercase. Contact: ietf-mta-filters@imc.org Reference: [ RFC-to-be ] As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC. The IANA Functions Operator understands that these are the only actions 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, Sabrina Tanamal Senior IANA Services Specialist |
2018-12-18
|
08 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2018-12-17
|
08 | Ines Robles | Request for Last Call review by GENART Completed: Ready. Reviewer: Ines Robles. Sent review to list. |
2018-12-11
|
08 | Joe Clarke | Assignment of request for Last Call review by OPSDIR to Joe Clarke was rejected |
2018-12-11
|
08 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Joe Clarke |
2018-12-11
|
08 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Joe Clarke |
2018-12-07
|
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Steve Hanna |
2018-12-07
|
08 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Steve Hanna |
2018-12-06
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Ines Robles |
2018-12-06
|
08 | Jean Mahoney | Request for Last Call review by GENART is assigned to Ines Robles |
2018-12-04
|
08 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2018-12-04
|
08 | Amy Vezza | The following Last Call announcement was sent out (ends 2018-12-18): From: The IESG To: IETF-Announce CC: draft-ietf-extra-sieve-fcc@ietf.org, Jiankang Yao , extra@ietf.org, yaojk@cnnic.cn, … The following Last Call announcement was sent out (ends 2018-12-18): From: The IESG To: IETF-Announce CC: draft-ietf-extra-sieve-fcc@ietf.org, Jiankang Yao , extra@ietf.org, yaojk@cnnic.cn, extra-chairs@ietf.org, alexey.melnikov@isode.com Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Sieve Extension: File Carbon Copy (Fcc)) 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 Extension: File Carbon Copy (Fcc)' 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 ietf@ietf.org mailing lists by 2018-12-18. 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 Sieve Email Filtering Language provides a number of action commands, some of which can generate additional messages on behalf of the user. This document defines an extension to such commands to allow a copy of any generated message to be filed into a target mailbox. This document updates RFC5230 and RFC5435 by adding a new tagged argument to the "vacation" and "enotify" actions respectively. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-fcc/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-fcc/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: draft-ietf-extra-sieve-special-use: Sieve Email Filtering: Delivering to Special-Use Mailboxes (None - IETF stream) |
2018-12-04
|
08 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2018-12-04
|
08 | Alexey Melnikov | Last call was requested |
2018-12-04
|
08 | Alexey Melnikov | Last call announcement was generated |
2018-12-04
|
08 | Alexey Melnikov | Ballot approval text was generated |
2018-12-04
|
08 | Alexey Melnikov | Ballot writeup was generated |
2018-12-04
|
08 | Alexey Melnikov | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2018-12-04
|
08 | Kenneth Murchison | New version available: draft-ietf-extra-sieve-fcc-08.txt |
2018-12-04
|
08 | (System) | New version approved |
2018-12-04
|
08 | (System) | Request for posting confirmation emailed to previous authors: Ken Murchison , Bron Gondwana |
2018-12-04
|
08 | Kenneth Murchison | Uploaded new revision |
2018-11-29
|
07 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-11-29
|
07 | Kenneth Murchison | New version available: draft-ietf-extra-sieve-fcc-07.txt |
2018-11-29
|
07 | (System) | New version approved |
2018-11-29
|
07 | (System) | Request for posting confirmation emailed to previous authors: Ken Murchison , Bron Gondwana |
2018-11-29
|
07 | Kenneth Murchison | Uploaded new revision |
2018-10-16
|
06 | Alexey Melnikov | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2018-10-16
|
06 | Alexey Melnikov | IESG state changed to AD Evaluation from Publication Requested |
2018-10-03
|
06 | Jiankang Yao | Document Shepherd Write-Up for draft-ietf-extra-sieve-fcc 1. This document is being requested as a Proposed Standard because it updates existing Standards Track documents(RFC 5230, … Document Shepherd Write-Up for draft-ietf-extra-sieve-fcc 1. This document is being requested as a Proposed Standard because it updates existing Standards Track documents(RFC 5230, RFC 5435). The request type is indicated in the title page header. 2. Technical Summary The Sieve Email Filtering Language provides a number of action commands, some of which can generate additional messages on behalf of the user. This document defines an extension to such commands to allow a copy of any generated message to be filed into a target mailbox. Working Group Summary The EXTRA WG meeting in IETF 101 had detailed discussion about this draft. The authors had updated it accordingly. Before WGLC, several experts reviewed the draft in detail. All identified issues were reflected in the new version of the draft. The EXTRA WG meeting in IETF 102 decided to poll list for WGLC after the new vesion. During WGLC, some minor issues were identified and fixed in the new version. The WG has looked throught this document in detail. Document Quality The document is in good shape and is ready to be published. One expert has indicated that he has implemented it. He noted that this was far more difficult to implement than he expected. Specially, section 4 of the document records the status of some known implementations. Personnel Document Shepherd - Jiankang Yao (EXTRA co-chair) Responsible Area Director - Alexey Melnikov 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 very 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: No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 5 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 RFC5230 and RFC5435. RFC5230 and RFC5435 have been listed on the title page header, listed in the abstract. In the introduction, there has only one sentence which mentions " This document also specifies the interaction of :fcc with the Vacation [RFC5230] and Notify [RFC5435] extensions. " but it does not clearly indicates which part of RFC5230 and RFC5435 is updated by this document. I think that the author might need to clarify it in the introduction of the future new version. 17. The IANA considerations ask for the following two items to be added to the registry: IANA is requested to add the new entry spcified in section 6.1 to the "Sieve Extensions". IANA is requested to add the new entry spcified in section 6.2 to the "Notification-Capability Parameters" 18. None of the IANA registries mentioned require Expert Review. 19. Have run Bill's ABNF Parser for checking of ABNF, and no issue was found. |
2018-10-03
|
06 | Jiankang Yao | Responsible AD changed to Alexey Melnikov |
2018-10-03
|
06 | Jiankang Yao | IETF WG state changed to Submitted to IESG for Publication from In WG Last Call |
2018-10-03
|
06 | Jiankang Yao | IESG state changed to Publication Requested |
2018-10-03
|
06 | Jiankang Yao | IESG process started in state Publication Requested |
2018-10-03
|
06 | Jiankang Yao | Changed document writeup |
2018-10-03
|
06 | Jiankang Yao | Changed document writeup |
2018-10-03
|
06 | Jiankang Yao | Changed document writeup |
2018-10-01
|
06 | Kenneth Murchison | New version available: draft-ietf-extra-sieve-fcc-06.txt |
2018-10-01
|
06 | (System) | New version approved |
2018-10-01
|
06 | (System) | Request for posting confirmation emailed to previous authors: Ken Murchison , Bron Gondwana |
2018-10-01
|
06 | Kenneth Murchison | Uploaded new revision |
2018-09-16
|
05 | Bron Gondwana | Notification list changed to Jiankang Yao <yaojk@cnnic.cn> |
2018-09-16
|
05 | Bron Gondwana | Document shepherd changed to Jiankang Yao |
2018-09-16
|
05 | Bron Gondwana | Changed consensus to Yes from Unknown |
2018-09-16
|
05 | Bron Gondwana | Intended Status changed to Proposed Standard from None |
2018-09-10
|
05 | Kenneth Murchison | New version available: draft-ietf-extra-sieve-fcc-05.txt |
2018-09-10
|
05 | (System) | New version approved |
2018-09-10
|
05 | (System) | Request for posting confirmation emailed to previous authors: Ken Murchison , Bron Gondwana |
2018-09-10
|
05 | Kenneth Murchison | Uploaded new revision |
2018-09-05
|
04 | Jiankang Yao | This document has been updated for several versions based comments received and do not receive any more comments since new version published in 12 Aug. … This document has been updated for several versions based comments received and do not receive any more comments since new version published in 12 Aug. This document is ready for WGLC. |
2018-09-05
|
04 | Jiankang Yao | IETF WG state changed to In WG Last Call from Adopted by a WG |
2018-08-12
|
04 | Kenneth Murchison | New version available: draft-ietf-extra-sieve-fcc-04.txt |
2018-08-12
|
04 | (System) | New version approved |
2018-08-12
|
04 | (System) | Request for posting confirmation emailed to previous authors: Ken Murchison , Bron Gondwana |
2018-08-12
|
04 | Kenneth Murchison | Uploaded new revision |
2018-08-03
|
03 | Kenneth Murchison | New version available: draft-ietf-extra-sieve-fcc-03.txt |
2018-08-03
|
03 | (System) | New version approved |
2018-08-03
|
03 | (System) | Request for posting confirmation emailed to previous authors: Ken Murchison , Bron Gondwana |
2018-08-03
|
03 | Kenneth Murchison | Uploaded new revision |
2018-04-30
|
02 | Kenneth Murchison | New version available: draft-ietf-extra-sieve-fcc-02.txt |
2018-04-30
|
02 | (System) | New version approved |
2018-04-30
|
02 | (System) | Request for posting confirmation emailed to previous authors: Ken Murchison , Bron Gondwana |
2018-04-30
|
02 | Kenneth Murchison | Uploaded new revision |
2018-03-05
|
01 | Bron Gondwana | IETF WG state changed to Adopted by a WG from WG Document |
2018-01-11
|
01 | Kenneth Murchison | New version available: draft-ietf-extra-sieve-fcc-01.txt |
2018-01-11
|
01 | (System) | New version approved |
2018-01-11
|
01 | (System) | Request for posting confirmation emailed to previous authors: Ken Murchison , Bron Gondwana |
2018-01-11
|
01 | Kenneth Murchison | Uploaded new revision |
2017-09-21
|
00 | Kenneth Murchison | New version available: draft-ietf-extra-sieve-fcc-00.txt |
2017-09-21
|
00 | (System) | WG -00 approved |
2017-09-21
|
00 | Kenneth Murchison | Set submitter to "Kenneth Murchison ", replaces to (none) and sent approval email to group chairs: extra-chairs@ietf.org |
2017-09-21
|
00 | Kenneth Murchison | Uploaded new revision |