IMAP4 Multimailbox SEARCH Extension
draft-ietf-appsawg-multimailbox-search-04
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2014-10-03
|
04 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2014-09-11
|
04 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2014-09-08
|
04 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2014-08-18
|
04 | Francis Dupont | Request for Telechat review by GENART Completed: Ready. Reviewer: Francis Dupont. |
2014-08-13
|
04 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2014-08-12
|
04 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2014-08-12
|
04 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2014-08-12
|
04 | Cindy Morgan | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2014-08-12
|
04 | (System) | RFC Editor state changed to EDIT |
2014-08-12
|
04 | (System) | Announcement was received by RFC Editor |
2014-08-11
|
04 | Barry Leiba | Notification list changed to : appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-multimailbox-search@tools.ietf.org |
2014-08-11
|
04 | (System) | IANA Action state changed to In Progress |
2014-08-11
|
04 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2014-08-11
|
04 | Amy Vezza | IESG has approved the document |
2014-08-11
|
04 | Amy Vezza | Closed "Approve" ballot |
2014-08-11
|
04 | Amy Vezza | Ballot approval text was generated |
2014-08-07
|
04 | Cindy Morgan | IESG state changed to Approved-announcement to be sent from IESG Evaluation |
2014-08-07
|
04 | Barry Leiba | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2014-08-07
|
04 | Barry Leiba | New version available: draft-ietf-appsawg-multimailbox-search-04.txt |
2014-08-07
|
03 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2014-08-07
|
03 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2014-08-07
|
03 | Ted Lemon | [Ballot Position Update] Position for Ted Lemon has been changed to No Objection from No Record |
2014-08-07
|
03 | Ted Lemon | [Ballot comment] This extension was previously published as experimental. There is now implementation experience, giving confidence in the protocol, so this document … [Ballot comment] This extension was previously published as experimental. There is now implementation experience, giving confidence in the protocol, so this document puts the extension on the Standards Track, with some minor updates that were informed by the implementation experience. [[RFC Editor: Please remove this paragraph at publication.]] The list of implementations is apparently one, which is not in widespread use. I mention this not to argue against reclassification. But: The client SHOULD NOT provide source options that resolve to including the same mailbox more than once. A server can, of course, remove the duplicates before processing, but the server MAY return "BAD" to an ESEARCH command with duplicate source mailboxes. This sounds a little tenuous to me, and I wonder if it's not the result of some implementors making an engineering decision and then deciding to mention it in the RFC as advice. ISTM that it's actually not unreasonable to expect two mail box terms to identify an overlapping set of mailboxes, and in such a case it would be very desirable for the server to eliminate the duplicate rather than rejecting the command: that is, it is easier for the server to know that such a duplication exists than for the client to know, and therefore requiring the client to prevent this error is more onerous than requiring the server to prevent the error. ISTM that the right advice here is "the server should notice and eliminate duplicates when searching, and MUST NOT return BAD." However I assume there was vigorous discussion on the working group mailing list that reached the conclusion presented in the current text, and eagerly await explanation as to why I am wrong about this. :) |
2014-08-07
|
03 | Ted Lemon | Ballot comment text updated for Ted Lemon |
2014-08-06
|
03 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2014-08-06
|
03 | Spencer Dawkins | [Ballot comment] One question, at most a nit. In the Abstract This extension also uses MAILBOX and TAG fields in ESEARCH responses, … [Ballot comment] One question, at most a nit. In the Abstract This extension also uses MAILBOX and TAG fields in ESEARCH responses, ^^^^^^^ ^^^ allowing a client to pipeline the searches if it chooses. This document updates RFC 4466 and obsoletes RFC 6237. but in 1. Introduction o The MAILBOX, UIDVALIDITY, and TAG fields in the responses allow a ^^^^^^^ ^^^^^^^^^^^ ^^^ client to distinguish which responses go with which search (and which mailbox). A client can safely pipeline these search commands without danger of confusion. The addition of the MAILBOX and UIDVALIDITY fields updates the search-correlator item defined in [RFC4466]. I'm only pattern matching, but should these lists of fields match? Or am I not understanding (which is likely)? |
2014-08-06
|
03 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2014-08-06
|
03 | Kathleen Moriarty | [Ballot comment] Thanks for discussing my concerns around logging. I'm okay with that being left as an implementation choice (not mentioned in the draft), but … [Ballot comment] Thanks for discussing my concerns around logging. I'm okay with that being left as an implementation choice (not mentioned in the draft), but do think it would be helpful to have it for testing access controls as well as detection of unapproved access attempts. |
2014-08-06
|
03 | Kathleen Moriarty | [Ballot Position Update] Position for Kathleen Moriarty has been changed to No Objection from Discuss |
2014-08-06
|
03 | Richard Barnes | [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes |
2014-08-05
|
03 | Kathleen Moriarty | [Ballot discuss] The draft is well written and this should be easy to clear, but I thought it was important to discuss to see if … [Ballot discuss] The draft is well written and this should be easy to clear, but I thought it was important to discuss to see if a change might be needed. In the security considerations section, the following sentence says, "Mailboxes matching the source options for which the logged-in user lacks sufficient rights MUST be ignored by the ESEARCH command processing (see the paragraph about this in Section 2.2). " It is good that access is not permitted, but shouldn't this be logged as a possible access attempt violation? |
2014-08-05
|
03 | Kathleen Moriarty | [Ballot Position Update] New position, Discuss, has been recorded for Kathleen Moriarty |
2014-08-05
|
03 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2014-08-04
|
03 | Alissa Cooper | [Ballot comment] Section 2: "A server that supports this extension includes "MULTISEARCH" in its IMAP capability string." This jumped out at me as I would … [Ballot comment] Section 2: "A server that supports this extension includes "MULTISEARCH" in its IMAP capability string." This jumped out at me as I would have expected a statement like this to be a normative requirement, rather than a statement of fact. |
2014-08-04
|
03 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2014-08-04
|
03 | Adrian Farrel | [Ballot comment] I have no objection to the publication of this document, but please consider my one suggestion below. (Also a homily for the delectation … [Ballot comment] I have no objection to the publication of this document, but please consider my one suggestion below. (Also a homily for the delectation of future generations.) --- In section 1 This extension was previously published as experimental. There is now implementation experience, giving confidence in the protocol, so this document puts the extension on the Standards Track, with some minor updates that were informed by the implementation experience. [[RFC Editor: Please remove this paragraph at publication.]] To the contrary, I think you should retain this paragraph and use it to record how/why this document obsoletes 6327 with the inclusion of a forward-pointer to section 8. --- I appreciate your use of RFC 6982 (because I get commission), but the information you included is not overwhelming or very detailed. Nothing to be done at this stage, but next time... |
2014-08-04
|
03 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel |
2014-08-04
|
03 | Brian Haberman | [Ballot comment] Thanks for including the RFC 6982 section! |
2014-08-04
|
03 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2014-07-31
|
03 | Jean Mahoney | Request for Telechat review by GENART is assigned to Francis Dupont |
2014-07-31
|
03 | Jean Mahoney | Request for Telechat review by GENART is assigned to Francis Dupont |
2014-07-31
|
03 | Pete Resnick | Changed consensus to Yes from Unknown |
2014-07-31
|
03 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2014-07-30
|
03 | Barry Leiba | [Ballot Position Update] New position, Recuse, has been recorded for Barry Leiba |
2014-07-30
|
03 | Barry Leiba | New version available: draft-ietf-appsawg-multimailbox-search-03.txt |
2014-07-30
|
02 | Pete Resnick | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2014-07-30
|
02 | Pete Resnick | Placed on agenda for telechat - 2014-08-07 |
2014-07-30
|
02 | Pete Resnick | Ballot has been issued |
2014-07-30
|
02 | Pete Resnick | [Ballot Position Update] New position, Yes, has been recorded for Pete Resnick |
2014-07-30
|
02 | Pete Resnick | Created "Approve" ballot |
2014-07-30
|
02 | Pete Resnick | Notification list changed to : appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-multimailbox-search@tools.ietf.org, apps-discuss@ietf.org |
2014-07-30
|
02 | Pete Resnick | Ballot writeup was changed |
2014-07-26
|
02 | Francis Dupont | Request for Last Call review by GENART Completed: Ready. Reviewer: Francis Dupont. |
2014-07-24
|
02 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Tina Tsou. |
2014-07-21
|
02 | Gunter Van de Velde | Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Stefan Winter. |
2014-07-21
|
02 | Barry Leiba | Ballot writeup was changed |
2014-07-21
|
02 | Barry Leiba | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2014-07-21
|
02 | Barry Leiba | New version available: draft-ietf-appsawg-multimailbox-search-02.txt |
2014-07-21
|
01 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2014-07-17
|
01 | Barry Leiba | Ballot writeup was changed |
2014-07-17
|
01 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2014-07-17
|
01 | Pearl Liang | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-appsawg-multimailbox-search-01. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-appsawg-multimailbox-search-01. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. IANA's reviewer has the following comments/questions: 1) IANA understands that, upon approval of this document, there is a single action which IANA must complete. In the Internet Message Access Protocol (IMAP) Capabilities Registry located at: http://www.iana.org/assignments/imap-capabilities/ the reference for the capability MULTISEARCH will be changed from: [RFC6237] to: [ RFC-to-be ] 2) Please change the URL in the IANA Considerations section: FROM: . TO: This will ensure the URL will always work and point to the most current version/extension. IANA 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 only to confirm what actions will be performed. |
2014-07-14
|
01 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Stefan Winter |
2014-07-14
|
01 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Stefan Winter |
2014-07-10
|
01 | Jean Mahoney | Request for Last Call review by GENART is assigned to Francis Dupont |
2014-07-10
|
01 | Jean Mahoney | Request for Last Call review by GENART is assigned to Francis Dupont |
2014-07-10
|
01 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Tina Tsou |
2014-07-10
|
01 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Tina Tsou |
2014-07-07
|
01 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2014-07-07
|
01 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (IMAP4 Multimailbox SEARCH Extension) to … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (IMAP4 Multimailbox SEARCH Extension) to Proposed Standard The IESG has received a request from the Applications Area Working Group WG (appsawg) to consider the following document: - 'IMAP4 Multimailbox SEARCH Extension' 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 2014-07-21. 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 IMAP4 specification allows the searching of only the selected mailbox. A user often wants to search multiple mailboxes, and a client that wishes to support this must issue a series of SELECT and SEARCH commands, waiting for each to complete before moving on to the next. This extension allows a client to search multiple mailboxes with one command, limiting round trips delay, and not requiring disruption of the currently selected mailbox. This extension also uses MAILBOX and TAG fields in ESEARCH responses, allowing a client to pipeline the searches if it chooses. This document updates RFC 4466 and obsoletes RFC 6237. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-appsawg-multimailbox-search/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-appsawg-multimailbox-search/ballot/ No IPR declarations have been submitted directly on this I-D. |
2014-07-07
|
01 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2014-07-07
|
01 | Amy Vezza | Last call announcement was generated |
2014-07-06
|
01 | Pete Resnick | Last call was requested |
2014-07-06
|
01 | Pete Resnick | IESG state changed to Last Call Requested from AD Evaluation |
2014-06-29
|
01 | Pete Resnick | Last call announcement was generated |
2014-06-29
|
01 | Pete Resnick | Last call announcement was generated |
2014-06-29
|
01 | Pete Resnick | Ballot writeup was changed |
2014-06-29
|
01 | Pete Resnick | Ballot approval text was generated |
2014-06-29
|
01 | Pete Resnick | Ballot writeup was generated |
2014-06-29
|
01 | Pete Resnick | IESG state changed to AD Evaluation from Publication Requested |
2014-06-20
|
01 | Barry Leiba | Shepherding AD changed to Pete Resnick |
2014-06-20
|
01 | Murray Kucherawy | 1. Summary Murray Kucherawy is the document shepherd. Pete Resnick is the responsible Area Director. From the Abstract: The IMAP4 specification allows the searching … 1. Summary Murray Kucherawy is the document shepherd. Pete Resnick is the responsible Area Director. From the Abstract: The IMAP4 specification allows the searching of only the selected mailbox. A user often wants to search multiple mailboxes, and a client that wishes to support this must issue a series of SELECT and SEARCH commands, waiting for each to complete before moving on to the next. This extension allows a client to search multiple mailboxes with one command, limiting round trips delay, and not requiring disruption of the currently selected mailbox. This extension also uses MAILBOX and TAG fields in ESEARCH responses, allowing a client to pipeline the searches if it chooses. This document updates RFC 4466 and obsoletes RFC 6237. This document moves the contained extension from Experimental status (originally RFC 6237) to the standards track after some implementation experience has shown it to be useful and stable. 2. Review and Consensus The document was reviewed on the imapext mailing list by several participants. This is also where the original work on RFC 6237 was done. There was some discussion within the interested community on that list (around a half dozen regular contributors) about whether there was ample implementation experience to justify moving it to the Standards Track, and after some concerns were addressed in that regard, consensus was reached to proceed. There is another mechanism referred to as “\all” (I am not an IMAP expert by any stretch so I can’t comment on this myself) that a few believe to be the more widely deployed solution, but it has not been documented and there don’t appear to be any plans to do so. There is an imapext thread where this discussion took place, including anecdotes of implementation as well as some from people who chose not to implement and their reasons. The thread begins here: http://www.ietf.org/mail-archive/web/imapext/current/msg05151.html 3. Intellectual Property The authors have affirmed that they know of no cause to make any IPR filings under BCPs 78 and 79. This issue was also specifically called out in the WGLC, and there were no such statements made by the working group or on the imapext list (to which the WGLC was forwarded). 4. Other Points Nothing of note. |
2014-06-20
|
01 | Murray Kucherawy | State Change Notice email list changed to appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-multimailbox-search@tools.ietf.org |
2014-06-20
|
01 | Murray Kucherawy | Responsible AD changed to Barry Leiba |
2014-06-20
|
01 | Murray Kucherawy | IETF WG state changed to Submitted to IESG for Publication from Waiting for WG Chair Go-Ahead |
2014-06-20
|
01 | Murray Kucherawy | IESG state changed to Publication Requested |
2014-06-20
|
01 | Murray Kucherawy | IESG process started in state Publication Requested |
2014-06-20
|
01 | Murray Kucherawy | IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call |
2014-06-03
|
01 | Murray Kucherawy | WGLC ends June 20, 2014. |
2014-06-03
|
01 | Murray Kucherawy | IETF WG state changed to In WG Last Call from WG Document |
2014-06-03
|
01 | Barry Leiba | New version available: draft-ietf-appsawg-multimailbox-search-01.txt |
2014-06-03
|
00 | Murray Kucherawy | Changed document writeup |
2014-03-03
|
00 | Murray Kucherawy | Document shepherd changed to Murray Kucherawy |
2014-03-03
|
00 | Murray Kucherawy | Intended Status changed to Proposed Standard from None |
2014-03-03
|
00 | Barry Leiba | New version available: draft-ietf-appsawg-multimailbox-search-00.txt |