Message Disposition Notification
draft-ietf-appsawg-mdn-3798bis-16
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2017-02-24
|
16 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2017-02-06
|
16 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2017-01-23
|
16 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2016-12-09
|
16 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2016-12-07
|
16 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2016-12-07
|
16 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2016-12-05
|
16 | Jean Mahoney | Closed request for Last Call review by GENART with state 'No Response' |
2016-12-05
|
16 | (System) | RFC Editor state changed to EDIT |
2016-12-05
|
16 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2016-12-05
|
16 | (System) | Announcement was received by RFC Editor |
2016-12-05
|
16 | (System) | IANA Action state changed to In Progress |
2016-12-05
|
16 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2016-12-05
|
16 | Cindy Morgan | IESG has approved the document |
2016-12-05
|
16 | Cindy Morgan | Closed "Approve" ballot |
2016-12-05
|
16 | Cindy Morgan | Ballot writeup was changed |
2016-12-05
|
16 | Cindy Morgan | Ballot approval text was generated |
2016-12-01
|
16 | Ben Campbell | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::Revised I-D Needed |
2016-12-01
|
16 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation |
2016-12-01
|
16 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2016-12-01
|
16 | Alexey Melnikov | New version available: draft-ietf-appsawg-mdn-3798bis-16.txt |
2016-12-01
|
16 | (System) | New version approved |
2016-12-01
|
16 | (System) | Request for posting confirmation emailed to previous authors: appsawg-chairs@ietf.org, "Tony Hansen" , "Alexey Melnikov" |
2016-12-01
|
16 | Alexey Melnikov | Uploaded new revision |
2016-12-01
|
15 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Donald Eastlake. |
2016-12-01
|
15 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2016-11-30
|
15 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2016-11-30
|
15 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2016-11-30
|
15 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2016-11-30
|
15 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
2016-11-30
|
15 | Alissa Cooper | [Ballot comment] Thanks for the good work to improve the privacy properties here. = Section 6.2 = "Disposition mode (Section 3.2.6.1) can leak information about … [Ballot comment] Thanks for the good work to improve the privacy properties here. = Section 6.2 = "Disposition mode (Section 3.2.6.1) can leak information about recipient's MUA configuration, in particular whether MDNs are acknowledged manually or automatically. If this is a concern, MUAs can return "manual-action/MDN-sent-manually" disposition mode in generated MDNs." I see why this is here, but doesn't recommending falsifying these fields put their integrity in question whenever they are set to manual? I mean, why would recipients trust this information if the RFC actually suggests sending a field that lies about an MDN being automatically acknowledged? = Section 6.2.2 = "The "Reporting-UA" field (Section 3.2.1) might contain enough information to uniquely identify a specific device, usually when combined with other characteristics, particularly if the user agent sends excessive details about the user's system or extensions. However, the source of unique information that is least expected by users is proactive negotiation, including the Accept-Language header fields." I think the use of "However" is tripping me up here. Earlier in the document you have good recommendations about how to mitigate the risk of fingerprinting based on the Reporting-UA field. That guidance is valid regardless of whether other header fields might also contribute to fingerprinting or whether users would expect that (frankly, I don't see how user expectations are relevant here, since most users don't understand fingerprinting anyway). I think something along the following lines to replace the last sentence above would be more accurate: "Even when the guidance in Section 3.2.1 is followed to avoid fingerprinting, other sources of unique information may still be present, including the Accept-Language header fields." |
2016-11-30
|
15 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2016-11-29
|
15 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2016-11-29
|
15 | Alia Atlas | [Ballot comment] Should the Media-Type registration go to the authors of the draft, as specified, or instead to the appsawg & eventually defaulting to the … [Ballot comment] Should the Media-Type registration go to the authors of the draft, as specified, or instead to the appsawg & eventually defaulting to the IESG? |
2016-11-29
|
15 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2016-11-29
|
15 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2016-11-29
|
15 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2016-11-29
|
15 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2016-11-24
|
15 | Alexey Melnikov | [Ballot comment] I am the editor. |
2016-11-24
|
15 | Alexey Melnikov | [Ballot Position Update] New position, Recuse, has been recorded for Alexey Melnikov |
2016-11-23
|
15 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2016-11-08
|
15 | Ben Campbell | Placed on agenda for telechat - 2016-12-01 |
2016-11-08
|
15 | Ben Campbell | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2016-11-08
|
15 | Ben Campbell | Ballot has been issued |
2016-11-08
|
15 | Ben Campbell | [Ballot Position Update] New position, Yes, has been recorded for Ben Campbell |
2016-11-08
|
15 | Ben Campbell | Created "Approve" ballot |
2016-11-03
|
15 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2016-11-02
|
15 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2016-11-02
|
15 | Sabrina Tanamal | (Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-appsawg-mdn-3798bis-15.txt. If any part of this review is inaccurate, please let … (Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-appsawg-mdn-3798bis-15.txt. If any part of this review is inaccurate, please let us know. Upon approval of this document, we understand that there are three registry actions to complete. First, in the message subregistry of the Media Type registry located at: https://www.iana.org/assignments/media-types/ the registration template for the message/disposition-notification media type will be changed to the text in Section 3.1 of the current document. In addition, the reference will be changed to [ RFC-to-be ]. Second, the following registries in the Message Disposition Notification (MDN) Parameters located at: https://www.iana.org/assignments/mdn/ will each have their references changed from RFC3798 to [ RFC-to-be ]: MDN-Disposition-modifier-names MDN-Disposition-notification-option-names MDN-Extension-field-names We understand 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 only to confirm what actions will be performed. Thank you, Sabrina Tanamal IANA Services Specialist PTI |
2016-10-27
|
15 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Donald Eastlake |
2016-10-27
|
15 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Donald Eastlake |
2016-10-22
|
15 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Suzanne Woolf |
2016-10-22
|
15 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Suzanne Woolf |
2016-10-20
|
15 | Jean Mahoney | Request for Last Call review by GENART is assigned to Wassim Haddad |
2016-10-20
|
15 | Jean Mahoney | Request for Last Call review by GENART is assigned to Wassim Haddad |
2016-10-20
|
15 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2016-10-20
|
15 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: "IETF-Announce" CC: ben@nostrum.com, "Barry Leiba" , appsawg-chairs@ietf.org, art@ietf.org, superuser@gmail.com, … The following Last Call announcement was sent out: From: The IESG To: "IETF-Announce" CC: ben@nostrum.com, "Barry Leiba" , appsawg-chairs@ietf.org, art@ietf.org, superuser@gmail.com, draft-ietf-appsawg-mdn-3798bis@ietf.org Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Message Disposition Notification) to Internet Standard The IESG has received a request from the ART Area General Applications Working Group WG (appsawg) to consider the following document: - 'Message Disposition Notification' as Internet 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 2016-11-03. 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 memo defines a MIME content-type that may be used by a mail user agent (MUA) or electronic mail gateway to report the disposition of a message after it has been successfully delivered to a recipient. This content-type is intended to be machine-processable. Additional message header fields are also defined to permit Message Disposition Notifications (MDNs) to be requested by the sender of a message. The purpose is to extend Internet Mail to support functionality often found in other messaging systems, such as X.400 and the proprietary "LAN-based" systems, and often referred to as "read receipts," "acknowledgements", or "receipt notifications." The intention is to do this while respecting privacy concerns, which have often been expressed when such functions have been discussed in the past. Because many messages are sent between the Internet and other messaging systems (such as X.400 or the proprietary "LAN-based" systems), the MDN protocol is designed to be useful in a multi- protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses, in addition to those normally used in Internet Mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet Mail. This document obsoletes RFC 3798, moving it to Internet Standard. It also updates RFC 2046 (message/partial Media Type handling) and RFC 3461 (Original-Recipient header field generation requirement). The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-appsawg-mdn-3798bis/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-appsawg-mdn-3798bis/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward reference to a Proposed Standard: rfc3503: Message Disposition Notification (MDN) profile for Internet Message Access Protocol (IMAP) (Proposed Standard - Legacy stream) Additionally, the document contains these normative downward references to Draft Standards: rfc5321: Simple Mail Transfer Protocol (Draft Standard - IETF stream) rfc3461: Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs) (Draft Standard - IETF stream) rfc3464: An Extensible Message Format for Delivery Status Notifications (Draft Standard - IETF stream) rfc2047: MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text (Draft Standard - IETF stream) rfc2046: Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types (Draft Standard - IETF stream) See RFC 3967 for additional information. Note that some of these references may already be listed in the acceptable Downref Registry. |
2016-10-20
|
15 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2016-10-20
|
15 | Ben Campbell | Last call was requested |
2016-10-20
|
15 | Ben Campbell | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2016-10-20
|
15 | Ben Campbell | Last call announcement was changed |
2016-10-20
|
15 | Ben Campbell | Last call announcement was generated |
2016-10-20
|
15 | Ben Campbell | Last call announcement was changed |
2016-10-20
|
15 | Ben Campbell | Last call announcement was generated |
2016-10-20
|
15 | Ben Campbell | Ballot writeup was changed |
2016-10-20
|
15 | Ben Campbell | Ballot approval text was generated |
2016-10-20
|
15 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2016-10-20
|
15 | Alexey Melnikov | New version available: draft-ietf-appsawg-mdn-3798bis-15.txt |
2016-10-20
|
15 | (System) | New version approved |
2016-10-20
|
14 | (System) | Request for posting confirmation emailed to previous authors: appsawg-chairs@ietf.org, "Tony Hansen" , "Alexey Melnikov" |
2016-10-20
|
14 | Alexey Melnikov | Uploaded new revision |
2016-10-20
|
14 | Ben Campbell | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup |
2016-10-16
|
14 | Alexey Melnikov | New version available: draft-ietf-appsawg-mdn-3798bis-14.txt |
2016-10-16
|
14 | (System) | New version approved |
2016-10-16
|
13 | (System) | Request for posting confirmation emailed to previous authors: appsawg-chairs@ietf.org, "Tony Hansen" , "Alexey Melnikov" |
2016-10-16
|
13 | Alexey Melnikov | Uploaded new revision |
2016-10-16
|
13 | Alexey Melnikov | New version available: draft-ietf-appsawg-mdn-3798bis-13.txt |
2016-10-16
|
13 | (System) | New version approved |
2016-10-16
|
12 | (System) | Request for posting confirmation emailed to previous authors: appsawg-chairs@ietf.org, "Tony Hansen" , "Alexey Melnikov" |
2016-10-16
|
12 | Alexey Melnikov | Uploaded new revision |
2016-08-12
|
12 | Alexey Melnikov | New version available: draft-ietf-appsawg-mdn-3798bis-12.txt |
2016-08-09
|
11 | Ben Campbell | Hi, Here is my AD evaluation of draft-ietf-appsawg-mdn-3798bis-11. I think we need to discuss at least some of this prior to this going to IETF … Hi, Here is my AD evaluation of draft-ietf-appsawg-mdn-3798bis-11. I think we need to discuss at least some of this prior to this going to IETF last call. Process: - The shepherd report describes lackluster working group participation. Is the shepherd comfortable that this has had sufficient review? -1, paragraph 4: This says the memo has pre5378Trust200902 boilerplate. It doesn't seem to actually have it. Have the 3798 authors agreed to release? - The shepherd report recommends listing errata that was addressed in Appendix A. I agree that would be helpful. Can that happen before we go to last call? Substantive: - 2.1, paragraph 8: Does this assume that it's reasonable for such consent to be global? That is, do we assume recipient will want the same MDN policy for every sender? Why does the default to not send MDNs depend on whether the consent comes via a preference setting? If you ask the user to decide for each MDN, should the default choice be "No"? -2.1, last paragraph: Seems like this deserves a MUST -2.2: Would it make sense to offer some more guidance about registering "X-..." attributes? I suspect we would rather people not name substantially new attributes that way, and that such registrations should really be used for existing "X-..." attributes that have fallen into common use? (And also that any such registration needs to use care not to conflict with commonly used existing X- attributes? (If any exist?) -6.2, paragraph 5: Seems like we could use a stronger statement not to send information that had been encrypted in the original message as clear-text in an MDN. Would a MUST NOT be reasonable here? Editorial and nits: - idnits returns some warnings, please check. I think most are spurious, but some may not be. -2.1, paragraph 7: s/laverage/leverage -2.1, paragraph 11: Since RFC 5322 has the authoritative text about case sensitigy, consider making the related MUST and SHOULD descriptive rather than normative. (e.g. "The comparison is case-sensitive...." and "The local-part comparison is done after..." -2.1, last paragraph: This paragraph switches to 2nd person imperative from the previous 3rd person. Is there a reason? The change for just this one paragraph is a bit jarring. - 3.2.6.3, disposition-modifier-extension: s/"MUST not"/"MUST NOT" -4, step starting with "(Recipient's ) MUA discovers: s/MDN has been generated/MDN has already been generated - Appendix A: Is this expected to stay in the final RFC? |
2016-08-09
|
11 | Ben Campbell | Note added 'Please note that this draft intends to move MDN to Internet Standard.' |
2016-08-09
|
11 | Ben Campbell | Intended Status changed to Internet Standard from Proposed Standard |
2016-08-09
|
11 | Ben Campbell | Changed consensus to Yes from Unknown |
2016-08-04
|
11 | Alexey Melnikov | New version available: draft-ietf-appsawg-mdn-3798bis-11.txt |
2016-07-31
|
10 | Alexey Melnikov | New version available: draft-ietf-appsawg-mdn-3798bis-10.txt |
2016-07-31
|
09 | Alexey Melnikov | New version available: draft-ietf-appsawg-mdn-3798bis-09.txt |
2016-06-25
|
08 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2016-06-25
|
08 | Alexey Melnikov | New version available: draft-ietf-appsawg-mdn-3798bis-08.txt |
2016-06-07
|
07 | Ben Campbell | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup |
2016-05-01
|
07 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2016-05-01
|
07 | Alexey Melnikov | New version available: draft-ietf-appsawg-mdn-3798bis-07.txt |
2016-04-07
|
06 | Alexey Melnikov | Notification list changed to Barry Leiba <barryleiba@computer.org> |
2016-04-07
|
06 | Alexey Melnikov | Shepherding AD changed to Ben Campbell |
2016-04-06
|
06 | Amy Vezza | Shepherding AD changed to Alexey Melnikov |
2016-04-06
|
06 | Barry Leiba | Shepherding AD changed to Ben Campbell |
2016-04-05
|
06 | Barry Leiba | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2016-04-02
|
06 | Murray Kucherawy | 1. Summary Murray Kucherawy is the document shepherd. Barry Leiba is the (outgoing) responsible Area Director. This is an update to an existing Standards Track … 1. Summary Murray Kucherawy is the document shepherd. Barry Leiba is the (outgoing) responsible Area Director. This is an update to an existing Standards Track document. The Abstract: This memo defines a MIME content-type that may be used by a mail user agent (MUA) or electronic mail gateway to report the disposition of a message after it has been successfully delivered to a recipient. This content-type is intended to be machine-processable. Additional message header fields are also defined to permit Message Disposition Notifications (MDNs) to be requested by the sender of a message. The purpose is to extend Internet Mail to support functionality often found in other messaging systems, such as X.400 and the proprietary "LAN-based" systems, and often referred to as "read receipts," "acknowledgements", or "receipt notifications." The intention is to do this while respecting privacy concerns, which have often been expressed when such functions have been discussed in the past. Because many messages are sent between the Internet and other messaging systems (such as X.400 or the proprietary "LAN-based" systems), the MDN protocol is designed to be useful in a multi- protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses, in addition to those normally used in Internet Mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet Mail. 2. Review and Consensus The document received general "Yes, this should happen" support at WG meetings, but unfortunately very little came in the way of active review. The working group appears to have trusted that the authors were doing good work and knew what they were doing and, if there were any problems found, they were not reported. MAAWG was also solicited for comments, but none were received (that I know of). In any case, there was no objection to its adoption by and publication through APPSAWG. There were no significant points of controversy or other difficulty. No directorate reviews were solicited, and none seem to be appropriate. 3. Intellectual Property Of particular note is the following in Section 1: This memo is currently marked with the 'pre5378Trust200902' IPR statements until a release has been obtained from all previous authors and editors of this text. The IESG may want to wait for this to be resolved before Last Call. This writeup is done with it still in the document; I can edit it later if that condition changes. 4. Other Points There are no downward references needing special attention during Last Call. The IANA Considerations were reviewed and look good. The only point of note here is MUSTard in the section; there seem to be varying opinions among IESG members over the years as to whether this is appropriate. The first word of Appendix A is spelled incorrectly. The IESG might want to suggest that existing errata against RFC3798 be highlighted in Appendix A explicitly, by number, assuming they were addressed. Previous IESGs have found this useful with my own documents. |
2016-04-01
|
06 | Barry Leiba | IESG state changed to AD Evaluation from Publication Requested |
2016-04-01
|
06 | Murray Kucherawy | 1. Summary Murray Kucherawy is the document shepherd. Barry Leiba is the (outgoing) responsible Area Director. This is an update to an existing Standards Track … 1. Summary Murray Kucherawy is the document shepherd. Barry Leiba is the (outgoing) responsible Area Director. This is an update to an existing Standards Track document. The Abstract: This memo defines a MIME content-type that may be used by a mail user agent (MUA) or electronic mail gateway to report the disposition of a message after it has been successfully delivered to a recipient. This content-type is intended to be machine-processable. Additional message header fields are also defined to permit Message Disposition Notifications (MDNs) to be requested by the sender of a message. The purpose is to extend Internet Mail to support functionality often found in other messaging systems, such as X.400 and the proprietary "LAN-based" systems, and often referred to as "read receipts," "acknowledgements", or "receipt notifications." The intention is to do this while respecting privacy concerns, which have often been expressed when such functions have been discussed in the past. Because many messages are sent between the Internet and other messaging systems (such as X.400 or the proprietary "LAN-based" systems), the MDN protocol is designed to be useful in a multi- protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses, in addition to those normally used in Internet Mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet Mail. 2. Review and Consensus The document received general "Yes, this should happen" support at WG meetings, but unfortunately very little came in the way of active review. The working group appears to have trusted that the authors were doing good work and knew what they were doing and, if there were any problems found, they were not reported. MAAWG was also solicited for comments, but none were received (that I know of). In any case, there was no objection to its adoption by and publication through APPSAWG. There were no significant points of controversy or other difficulty. No directorate reviews were solicited, and none seem to be appropriate. 3. Intellectual Property Of particular note is the following in Section 1: This memo is currently marked with the 'pre5378Trust200902' IPR statements until a release has been obtained from all previous authors and editors of this text. The IESG may want to wait for this to be resolved before Last Call. This writeup is done with it still in the document; I can edit it later if that condition changes. The authors of this version have not yet affirmed compliance with BCPs 78 and 79. 4. Other Points There are no downward references needing special attention during Last Call. The IANA Considerations were reviewed and look good. The only point of note here is MUSTard in the section; there seem to be varying opinions among IESG members over the years as to whether this is appropriate. The first word of Appendix A is spelled incorrectly. The IESG might want to suggest that existing errata against RFC3798 be highlighted in Appendix A explicitly, by number, assuming they were addressed. Previous IESGs have found this useful with my own documents. |
2016-04-01
|
06 | Murray Kucherawy | Responsible AD changed to Barry Leiba |
2016-04-01
|
06 | Murray Kucherawy | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2016-04-01
|
06 | Murray Kucherawy | IESG state changed to Publication Requested |
2016-04-01
|
06 | Murray Kucherawy | IESG process started in state Publication Requested |
2016-04-01
|
06 | Murray Kucherawy | Tag Doc Shepherd Follow-up Underway cleared. |
2016-03-31
|
06 | Murray Kucherawy | Changed document writeup |
2016-03-29
|
06 | Murray Kucherawy | Tag Doc Shepherd Follow-up Underway set. |
2016-03-29
|
06 | Murray Kucherawy | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2016-03-09
|
06 | Murray Kucherawy | WGLC ends March 25, 2016. |
2016-03-09
|
06 | Murray Kucherawy | IETF WG state changed to In WG Last Call from WG Document |
2016-01-24
|
06 | Alexey Melnikov | New version available: draft-ietf-appsawg-mdn-3798bis-06.txt |
2015-12-02
|
05 | Alexey Melnikov | New version available: draft-ietf-appsawg-mdn-3798bis-05.txt |
2015-11-28
|
04 | Alexey Melnikov | New version available: draft-ietf-appsawg-mdn-3798bis-04.txt |
2015-07-04
|
03 | Alexey Melnikov | New version available: draft-ietf-appsawg-mdn-3798bis-03.txt |
2015-03-09
|
02 | Alexey Melnikov | New version available: draft-ietf-appsawg-mdn-3798bis-02.txt |
2015-01-19
|
01 | Alexey Melnikov | New version available: draft-ietf-appsawg-mdn-3798bis-01.txt |
2014-09-11
|
00 | Murray Kucherawy | Document shepherd changed to Murray Kucherawy |
2014-09-11
|
00 | Murray Kucherawy | Intended Status changed to Proposed Standard from None |
2014-09-11
|
00 | Murray Kucherawy | This document now replaces draft-hansen-mdn-3798bis instead of None |
2014-09-11
|
00 | Alexey Melnikov | New version available: draft-ietf-appsawg-mdn-3798bis-00.txt |