SORT and CONDSTORE

Quick question: Should

   A001 SORT (DATE) UTF-8 MODSEQ 500

cause a " (MODSEQ 4551)" to be appended to the SORT result?  The
SORT extension doesn't indicate it, but it seems as necessary as
adding it to the corresponding SEARCH.
_______________________________________________
lemonade mailing list
lemonade <at> ietf.org
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

Re: SORT and CONDSTORE

Dan Karp wrote:

>Quick question: Should
>
>   A001 SORT (DATE) UTF-8 MODSEQ 500
>
>cause a " (MODSEQ 4551)" to be appended to the SORT result?  The
>SORT extension doesn't indicate it, but it seems as necessary as
>adding it to the corresponding SEARCH.
>  
>
I agree. I can include this into QRESYNC RFC update.
(I wish we could use ESEARCH response in all cases.)

_______________________________________________
lemonade mailing list
lemonade <at> ietf.org
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

Re: SORT and CONDSTORE

> >Quick question: Should
> >
> >   A001 SORT (DATE) UTF-8 MODSEQ 500
> >
> >cause a " (MODSEQ 4551)" to be appended to the SORT result?  The
> >SORT extension doesn't indicate it, but it seems as necessary as
> >adding it to the corresponding SEARCH.
> 
> I agree. I can include this into QRESYNC RFC update.
> (I wish we could use ESEARCH response in all cases.)

Such a command should also be regarded as a CONDSTORE-enabling command.
_______________________________________________
lemonade mailing list
lemonade <at> ietf.org
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

Re: SORT and CONDSTORE

On Wed, 2008-06-04 at 14:35 +0100, Alexey Melnikov wrote:
> Dan Karp wrote:
> 
> >Quick question: Should
> >
> >   A001 SORT (DATE) UTF-8 MODSEQ 500
> >
> >cause a " (MODSEQ 4551)" to be appended to the SORT result?  The
> >SORT extension doesn't indicate it, but it seems as necessary as
> >adding it to the corresponding SEARCH.
> >  
> >
> I agree. I can include this into QRESYNC RFC update.
> (I wish we could use ESEARCH response in all cases.)

And what about THREAD?

_______________________________________________
lemonade mailing list
lemonade <at> ietf.org
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

Re: SORT and CONDSTORE

Timo Sirainen wrote:

>On Wed, 2008-06-04 at 14:35 +0100, Alexey Melnikov wrote:
>  
>
>>Dan Karp wrote:
>>    
>>
>>>Quick question: Should
>>>
>>>  A001 SORT (DATE) UTF-8 MODSEQ 500
>>>
>>>cause a " (MODSEQ 4551)" to be appended to the SORT result?  The
>>>SORT extension doesn't indicate it, but it seems as necessary as
>>>adding it to the corresponding SEARCH.
>>>      
>>>
>>I agree. I can include this into QRESYNC RFC update.
>>(I wish we could use ESEARCH response in all cases.)
>>    
>>
>And what about THREAD?
>  
>
Ok, I can update THREAD response as well. Do we want to extend it, or 
make the server send another response?

_______________________________________________
lemonade mailing list
lemonade <at> ietf.org

RFC 5256 on Internet Message Access Protocol - SORT and THREAD Extensions

A new Request for Comments is now available in online RFC libraries.

        
        RFC 5256

        Title:      Internet Message Access Protocol - 
                    SORT and THREAD Extensions 
        Author:     M. Crispin, K. Murchison
        Status:     Standards Track
        Date:       June 2008
        Mailbox:    IMAP+SORT+THREAD <at> Lingling.Panda.COM, 
                    murch <at> andrew.cmu.edu
        Pages:      19
        Characters: 40779
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-imapext-sort-20.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5256.txt

This document describes the base-level server-based sorting and
threading extensions to the IMAP protocol.  These extensions
provide substantial performance improvements for IMAP clients that
offer sorted and threaded views.  [STANDARDS TRACK]

This document is a product of the Internet Message Access Protocol Extension Working Group of the IETF.

This is now a Proposed Standard Protocol.

RFC 5255 on Internet Message Access Protocol Internationalization

A new Request for Comments is now available in online RFC libraries.

        
        RFC 5255

        Title:      Internet Message Access Protocol Internationalization 
        Author:     C. Newman, A. Gulbrandsen, A. Melnikov
        Status:     Standards Track
        Date:       June 2008
        Mailbox:    chris.newman <at> sun.com, 
                    arnt <at> oryx.com, 
                    Alexey.Melnikov <at> isode.com
        Pages:      20
        Characters: 41403
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-imapext-i18n-15.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5255.txt

Internet Message Access Protocol (IMAP) version 4rev1 has basic
support for non-ASCII characters in mailbox names and search
substrings.  It also supports non-ASCII message headers and content
encoded as specified by Multipurpose Internet Mail Extensions
(MIME).  This specification defines a collection of IMAP extensions
that improve international support including language negotiation for 
international error text, translations for namespace prefixes, and 
comparator negotiation for search, sort, and thread.  [STANDARDS TRACK]

RFC 5258 on Internet Message Access Protocol version 4 - LIST Command Extensions

A new Request for Comments is now available in online RFC libraries.

        
        RFC 5258

        Title:      Internet Message Access Protocol version 
                    4 - LIST Command Extensions 
        Author:     B. Leiba, A. Melnikov
        Status:     Standards Track
        Date:       June 2008
        Mailbox:    leiba <at> watson.ibm.com, 
                    Alexey.Melnikov <at> isode.com
        Pages:      31
        Characters: 65074
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-imapext-list-extensions-18.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5258.txt

IMAP4 has two commands for listing mailboxes: LIST and LSUB.  As we
have added extensions, such as Mailbox Referrals, that have required
specialized lists we have had to expand the number of list commands,
since each extension must add its function to both LIST and LSUB, and
these commands are not, as they are defined, extensible.  If we've
needed the extensions to work together, we've had to add a set of
commands to mix the different options, the set increasing in size
with each new extension.  This document describes an extension to the
base LIST command that will allow these additions to be done with

all done?

ACL2 apparently was/will be dropped?

What about ANNOTATE? Its draft expired over a year ago. I doubt I'll try
implementing it anytime soon, but it (or something like it) would be
nice at some point.

Re: all done?

> What about ANNOTATE? Its draft expired over a year ago. I doubt I'll
> try implementing it anytime soon, but it (or something like it) would 
> be nice at some point.

ANNOTATE got published as Experimental, not as a Proposed Standard.
I believe its capability string was changed to ANNOTATE_EXPERIMENTAL-1.