Updated Use of the Expires Message Header Field
draft-billon-expires-09
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2024-03-01
|
09 | (System) | Document has expired |
2024-02-29
|
09 | Murray Kucherawy | IESG state changed to Dead::AD Followup from Waiting for AD Go-Ahead::AD Followup |
2023-05-11
|
09 | (System) | Removed all action holders (IESG state changed) |
2023-05-11
|
09 | (System) | Sub state has been changed to AD Followup from Revised I-D Needed |
2023-05-11
|
09 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2023-05-11
|
09 | John Levine | New version available: draft-billon-expires-09.txt |
2023-05-11
|
09 | John Levine | New version accepted (logged-in submitter: John Levine) |
2023-05-11
|
09 | John Levine | Uploaded new revision |
2023-05-10
|
08 | Murray Kucherawy | Changed action holders to John Levine, Benjamin BILLON |
2023-05-10
|
08 | (System) | Changed action holders to Murray Kucherawy (IESG state changed) |
2023-05-10
|
08 | Murray Kucherawy | IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for Writeup::Revised I-D Needed |
2023-05-10
|
08 | Murray Kucherawy | ## Document History 1. Was the document considered in any WG, and if so, why was it not adopted as a work item there? … ## Document History 1. Was the document considered in any WG, and if so, why was it not adopted as a work item there? The document was discussed on the ietf-822 list, which is the venue for discussions related to email message formatting. It does not fit the charter for any current working group. 2. Was there controversy about particular points that caused the WG to not adopt the document? N/A 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) There was strong feedback from two participants in particular during Last Call. Their feedback has been addressed in the -09 revision. 4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as [RFC 7942][3] recommends) or elsewhere (where)? Implementations have existed since RFC 2156 in 1998. RFC 4021 indicates this field is "not for general use", considering it only a header field used in X.400 message gatewaying; however, several implementations do pay attention to it, so it needs its own standards track document and registration. ## Additional Reviews 5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place. It was circulated in DISPATCH and the "ietf-822" lists, which is where most of the email people live these days. A lot of feedback was also present on the last-call list. 6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. It will need to pass through the Designated Expert for header fields, but no friction is expected. 7. If the document contains a YANG module, has the final version of the module been checked with any of the [recommended validation tools][4] for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342][5]? N/A 8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc. There's one line of ABNF, and it looks good. ## Document Shepherd Checks 9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director? The document is satisfactory in terms of its simplicity and clarity. 10. Several IETF Areas have assembled [lists of common issues that their reviewers encounter][6]. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews? No area-specific review items are relevant to this work. 11. What type of RFC publication is being requested on the IETF stream ([Best Current Practice][12], [Proposed Standard, Internet Standard][13], [Informational, Experimental or Historic][14])? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent? Standards Track; this involves interoperability between components, so Standards Track is warranted. The datatracker shows this correctly. 12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in [BCP 79][7]? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable. Yes, the authors have been reminded. 13. Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification. Yes. 14. Document any remaining I-D nits in this document. Simply running the [idnits tool][8] is not enough; please review the ["Content Guidelines" on authors.ietf.org][15]. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.) There are none remaining as of the crafting of this shepherd writeup. 15. Should any informative references be normative or vice-versa? See the [IESG Statement on Normative and Informative References][16]. The references are correct. 16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? N/A 17. Are there any normative downward references (see [RFC 3967][9] and [BCP 97][10]) that are not already listed in the [DOWNREF registry][17]? If so, list them. No. 18. Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion? No. 19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed. No. 20. Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see [RFC 8126][11]). The sole IANA action is complete. 21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate. No new registries are being created. [1]: https://www.ietf.org/about/groups/iesg/ [2]: https://www.rfc-editor.org/rfc/rfc4858.html [3]: https://www.rfc-editor.org/rfc/rfc7942.html [4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools [5]: https://www.rfc-editor.org/rfc/rfc8342.html [6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics [7]: https://www.rfc-editor.org/info/bcp79 [8]: https://www.ietf.org/tools/idnits/ [9]: https://www.rfc-editor.org/rfc/rfc3967.html [10]: https://www.rfc-editor.org/info/bcp97 [11]: https://www.rfc-editor.org/rfc/rfc8126.html [12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5 [13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1 [14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2 [15]: https://authors.ietf.org/en/content-guidelines-overview [16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ [17]: https://datatracker.ietf.org/doc/downref/ |
2023-05-10
|
08 | (System) | Changed action holders to Benjamin BILLON, John Levine, Murray Kucherawy (IESG state changed) |
2023-05-10
|
08 | Murray Kucherawy | IESG state changed to Waiting for Writeup::Revised I-D Needed from Waiting for Writeup::AD Followup |
2023-05-09
|
08 | Murray Kucherawy | Changed document external resources from: None to: mailing_list https://www.ietf.org/mailman/listinfo/ietf-822 |
2023-01-05
|
08 | Tim Chown | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Tim Chown. Sent review to list. |
2022-12-28
|
08 | Murray Kucherawy | IESG state changed to Waiting for Writeup::AD Followup from Waiting for Writeup |
2022-12-27
|
08 | (System) | Changed action holders to Murray Kucherawy (IESG state changed) |
2022-12-27
|
08 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2022-12-24
|
08 | Chris Lonvick | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Chris Lonvick. Sent review to list. |
2022-12-16
|
08 | Robert Sparks | Request for Last Call review by GENART Completed: Ready. Reviewer: Robert Sparks. Sent review to list. |
2022-12-14
|
08 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2022-12-14
|
08 | David Dong | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-billon-expires-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-billon-expires-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 is a single action which we must complete. In the Permanent Message Header Field Names registry on the Message Headers registry page located at: https://www.iana.org/assignments/message-headers/ the existing registration for Header Field Name: expires Protocol: mail Status: standard will have its Reference changed from [RFC4021] to [ RFC-to-be ]. 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. For definitions of IANA review states, please see: https://datatracker.ietf.org/help/state/draft/iana-review Thank you, David Dong IANA Services Specialist |
2022-12-14
|
08 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tim Chown |
2022-12-14
|
08 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tim Chown |
2022-12-11
|
08 | John Levine | New version available: draft-billon-expires-08.txt |
2022-12-11
|
08 | John Levine | New version accepted (logged-in submitter: John Levine) |
2022-12-11
|
08 | John Levine | Uploaded new revision |
2022-12-11
|
07 | Barry Leiba | Request for Last Call review by ARTART Completed: Ready. Reviewer: Barry Leiba. Sent review to list. |
2022-12-11
|
07 | Barry Leiba | Request for Last Call review by ARTART is assigned to Barry Leiba |
2022-12-11
|
07 | Barry Leiba | Request for Last Call review by ARTART is assigned to Barry Leiba |
2022-12-10
|
07 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Chris Lonvick |
2022-12-10
|
07 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Chris Lonvick |
2022-12-08
|
07 | John Levine | New version available: draft-billon-expires-07.txt |
2022-12-08
|
07 | John Levine | New version accepted (logged-in submitter: John Levine) |
2022-12-08
|
07 | John Levine | Uploaded new revision |
2022-12-05
|
06 | Chris Lonvick | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Chris Lonvick. |
2022-12-05
|
06 | Chris Lonvick | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Chris Lonvick. Sent review to list. Submission of review completed at an earlier date. |
2022-12-04
|
06 | Murray Kucherawy | Removed all action holders |
2022-12-04
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Chris Lonvick |
2022-12-04
|
06 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Chris Lonvick |
2022-12-01
|
06 | Carlos Pignataro | Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Carlos Pignataro. Sent review to list. |
2022-12-01
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Robert Sparks |
2022-12-01
|
06 | Jean Mahoney | Request for Last Call review by GENART is assigned to Robert Sparks |
2022-11-29
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Carlos Pignataro |
2022-11-29
|
06 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Carlos Pignataro |
2022-11-29
|
06 | Barry Leiba | Request for Last Call review by ARTART Completed: Ready with Nits. Reviewer: Barry Leiba. Sent review to list. |
2022-11-29
|
06 | Barry Leiba | Request for Last Call review by ARTART is assigned to Barry Leiba |
2022-11-29
|
06 | Barry Leiba | Request for Last Call review by ARTART is assigned to Barry Leiba |
2022-11-29
|
06 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2022-11-29
|
06 | Amy Vezza | The following Last Call announcement was sent out (ends 2022-12-27): From: The IESG To: IETF-Announce CC: draft-billon-expires@ietf.org, superuser@gmail.com Reply-To: last-call@ietf.org Sender: Subject: Last Call: … The following Last Call announcement was sent out (ends 2022-12-27): From: The IESG To: IETF-Announce CC: draft-billon-expires@ietf.org, superuser@gmail.com Reply-To: last-call@ietf.org Sender: Subject: Last Call: (Updated Use of the Expires Message Header Field) to Proposed Standard The IESG has received a request from an individual submitter to consider the following document: - 'Updated Use of the Expires Message Header Field' 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 2022-12-27. 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 This document allows broader use of the Expires message header field for mail messages. Message creators can then indicate when a message sent becomes valueless and can safely be deleted, while recipients would use the information to delete or ignore these valueless messages. The file can be obtained via https://datatracker.ietf.org/doc/draft-billon-expires/ No IPR declarations have been submitted directly on this I-D. |
2022-11-29
|
06 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2022-11-29
|
06 | Amy Vezza | Last call announcement was changed |
2022-11-27
|
06 | Murray Kucherawy | Last call was requested |
2022-11-27
|
06 | Murray Kucherawy | Ballot approval text was generated |
2022-11-27
|
06 | Murray Kucherawy | Ballot writeup was generated |
2022-11-27
|
06 | Murray Kucherawy | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2022-11-27
|
06 | Murray Kucherawy | Last call announcement was generated |
2022-11-27
|
06 | Murray Kucherawy | ## Document History 1. Was the document considered in any WG, and if so, why was it not adopted as a work item there? … ## Document History 1. Was the document considered in any WG, and if so, why was it not adopted as a work item there? The document was discussed on the ietf-822 list, which is the venue for discussions related to email message formatting. It does not fit the charter for any current working group. 2. Was there controversy about particular points that caused the WG to not adopt the document? N/A 3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. 4. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as [RFC 7942][3] recommends) or elsewhere (where)? Implementations have existed since RFC 2156 in 1998. RFC 4021 indicates this field is "not for general use", considering it only a header field used in X.509 message gatewaying; however, several implementations do pay attention to it, so it needs its own standards track document and registration. ## Additional Reviews 5. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place. It was circulated in DISPATCH and the "ietf-822" lists, which is where most of the email people live these days. 6. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. It will need to pass through the Designated Expert for header fields, but no friction is expected. 7. If the document contains a YANG module, has the final version of the module been checked with any of the [recommended validation tools][4] for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342][5]? N/A 8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc. There's one line of ABNF, and it looks good. ## Document Shepherd Checks 9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director? The document is satisfactory in terms of its simplicity and clarity. 10. Several IETF Areas have assembled [lists of common issues that their reviewers encounter][6]. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews? No area-specific review items are relevant to this work. 11. What type of RFC publication is being requested on the IETF stream ([Best Current Practice][12], [Proposed Standard, Internet Standard][13], [Informational, Experimental or Historic][14])? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent? Standards Track; this involves interoperability between components, so Standards Track is warranted. The datatracker shows this correctly. 12. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in [BCP 79][7]? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable. Yes, the authors have been reminded. 13. Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification. Yes. 14. Document any remaining I-D nits in this document. Simply running the [idnits tool][8] is not enough; please review the ["Content Guidelines" on authors.ietf.org][15]. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.) There are none remaining as of the crafting of this shepherd writeup. 15. Should any informative references be normative or vice-versa? See the [IESG Statement on Normative and Informative References][16]. The references are correct. 16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? N/A 17. Are there any normative downward references (see [RFC 3967][9] and [BCP 97][10]) that are not already listed in the [DOWNREF registry][17]? If so, list them. No. 18. Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion? No. 19. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed. No. 20. Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see [RFC 8126][11]). The sole IANA action is complete. 21. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate. No new registries are being created. [1]: https://www.ietf.org/about/groups/iesg/ [2]: https://www.rfc-editor.org/rfc/rfc4858.html [3]: https://www.rfc-editor.org/rfc/rfc7942.html [4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools [5]: https://www.rfc-editor.org/rfc/rfc8342.html [6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics [7]: https://www.rfc-editor.org/info/bcp79 [8]: https://www.ietf.org/tools/idnits/ [9]: https://www.rfc-editor.org/rfc/rfc3967.html [10]: https://www.rfc-editor.org/info/bcp97 [11]: https://www.rfc-editor.org/rfc/rfc8126.html [12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5 [13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1 [14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2 [15]: https://authors.ietf.org/en/content-guidelines-overview [16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ [17]: https://datatracker.ietf.org/doc/downref/ |
2022-11-22
|
06 | John Levine | New version available: draft-billon-expires-06.txt |
2022-11-22
|
06 | John Levine | New version accepted (logged-in submitter: John Levine) |
2022-11-22
|
06 | John Levine | Uploaded new revision |
2022-11-08
|
05 | Murray Kucherawy | Referred to the ietf-822 list for feedback before proceeding. |
2022-11-08
|
05 | Murray Kucherawy | IESG state changed to AD Evaluation::AD Followup from AD Evaluation |
2022-11-07
|
05 | Murray Kucherawy | IESG state changed to AD Evaluation from Publication Requested::AD Followup |
2022-11-07
|
05 | Murray Kucherawy | Changed consensus to Yes from Unknown |
2022-11-07
|
05 | Murray Kucherawy | IETF WG state changed to Submitted to IESG for Publication |
2022-11-07
|
05 | Murray Kucherawy | IESG state changed to Publication Requested from AD is watching |
2022-11-07
|
05 | (System) | Changed action holders to Murray Kucherawy (IESG state changed) |
2022-11-07
|
05 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2022-11-07
|
05 | John Levine | New version available: draft-billon-expires-05.txt |
2022-11-07
|
05 | John Levine | New version accepted (logged-in submitter: John Levine) |
2022-11-07
|
05 | John Levine | Uploaded new revision |
2022-11-07
|
04 | (System) | Changed action holders to John Levine, Murray Kucherawy, Benjamin BILLON (IESG state changed) |
2022-11-07
|
04 | Murray Kucherawy | IESG state changed to AD is watching::Revised I-D Needed from AD is watching |
2022-11-07
|
04 | (System) | Changed action holders to Murray Kucherawy (IESG state changed) |
2022-11-07
|
04 | Murray Kucherawy | Assigned to Applications and Real-Time Area |
2022-11-07
|
04 | Murray Kucherawy | Responsible AD changed to Murray Kucherawy |
2022-11-07
|
04 | Murray Kucherawy | Intended Status changed to Proposed Standard |
2022-11-07
|
04 | Murray Kucherawy | Document is now in IESG state AD is watching |
2022-11-07
|
04 | Murray Kucherawy | Stream changed to IETF from None |
2022-11-07
|
04 | John Levine | New version available: draft-billon-expires-04.txt |
2022-11-07
|
04 | John Levine | New version accepted (logged-in submitter: John Levine) |
2022-11-07
|
04 | John Levine | Uploaded new revision |
2022-10-16
|
03 | (System) | Document has expired |
2022-04-14
|
03 | Benjamin BILLON | New version available: draft-billon-expires-03.txt |
2022-04-14
|
03 | (System) | New version accepted (logged-in submitter: Benjamin BILLON) |
2022-04-14
|
03 | Benjamin BILLON | Uploaded new revision |
2022-03-20
|
02 | Benjamin BILLON | New version available: draft-billon-expires-02.txt |
2022-03-20
|
02 | (System) | New version accepted (logged-in submitter: Benjamin BILLON) |
2022-03-20
|
02 | Benjamin BILLON | Uploaded new revision |
2022-03-11
|
01 | Kirsty Paine | Added to session: IETF-113: dispatch Mon-1000 |
2022-02-28
|
01 | Benjamin BILLON | New version available: draft-billon-expires-01.txt |
2022-02-28
|
01 | (System) | New version accepted (logged-in submitter: Benjamin BILLON) |
2022-02-28
|
01 | Benjamin BILLON | Uploaded new revision |
2021-12-14
|
00 | Benjamin BILLON | New version available: draft-billon-expires-00.txt |
2021-12-14
|
00 | (System) | New version accepted (logged-in submitter: Benjamin BILLON) |
2021-12-14
|
00 | Benjamin BILLON | Uploaded new revision |