Add support for RFC7162 (QRESYNC) VANISHED response. #101
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
RFC7162 defines a
VANISHEDresponse to theEXPUNGEcommand which must be used whenever a client has enabledQRESYNC.VANISHEDmay also appear in response toSELECT/EXAMINEorUID FETCH.https://tools.ietf.org/html/rfc7162#section-3.2.10
The
VANISHEDresponse sends a sequence set ofUIDs indicatingUIDs which have been deleted from the mailbox.I had to add parsers for
sequence-range(eg15:30) andsequence-set(eg.1,10:20,25,28:31), and I put them in core.rs since they are actually defined in RFC 3501 and show up in a couple of other places, so may be generically useful.I am not sure if the choice to return a
Vec<RangeInclusive>is to your liking. Alternatives could be just a tuple of(start, end), or expand the range out into a big list ofVec<u32>. I experimented with both options and settled on theVec<RangeInclusive>because:(start, end)is inclusiveThe downside is it can be a bit awkward to use, since you end up iterating a list of iterators. Of course, the nicest way to represent this for the user is to expand the sequence set out into a
Vec<u32>, but this could be wasteful / dangerous in some circumstances.