S Moonesamy | 27 Jun 00:20 2015

imapapdb milestones

Hello,

The Working Group Charter for IMAP APPEND Extensions (imapapnd) is at 
https://datatracker.ietf.org/wg/imapapnd/charter/  The working group 
has to deliver two Standards Track specifications to the IESG.  The 
first step is set the milestones for the 
draft-jayantheesh-imap-appendlimit-extension and 
draft-melnikov-rfc2088bis.  Could the working group participants 
please suggest a date for each of the two drafts?  I would like to 
have the milestones settled by 30 June so that the working group can 
proceed with the technical discussions about the two drafts.

If you have any questions about the work of the working group please 
feel free to raise them on the mailing list [1].  You can also email 
me if you find that easier.

Regards,
S. Moonesamy (as imapapdb WG Chair)

1. https://www.ietf.org/mailman/listinfo/imapext

_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext

The IESG | 26 Jun 22:42 2015
Picon

WG Action: Formed IMAP APPEND Extensions (imapapnd)

A new IETF working group has been formed in the Applications and
Real-Time Area. For additional information please contact the Area
Directors or the WG Chair.

IMAP APPEND Extensions (imapapnd)
------------------------------------------------
Current Status: Proposed WG

Chairs:
  S Moonesamy <sm+ietf <at> elandsys.com>

Assigned Area Director:
  Barry Leiba <barryleiba <at> computer.org>

Mailing list
  Address: imapext <at> ietf.org
  To Subscribe: https://www.ietf.org/mailman/listinfo/imapext
  Archive: https://mailarchive.ietf.org/arch/browse/imapext/

Charter:

The Internet Message Access Protocol (IMAP), defined in RFC 3501,
specifies a protocol for transferring email messages between a server
that implements a message store, and a client. It also includes commands
for manipulating the message store -- creating, deleting, and renaming
mailboxes, adding a message to a mailbox, and copying messages from one
mailbox to another.

IMAP (RFC 3501) contains the "literal" syntactic construct for
transferring blocks of data. Sending an IMAP literal string entails
(Continue reading)

Ben Campbell | 24 Jun 02:23 2015

Ben Campbell's Yes on charter-ietf-imapapnd-00-00: (with COMMENT)

Ben Campbell has entered the following ballot position for
charter-ietf-imapapnd-00-00: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-imapapnd/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Some milestones would be good.

_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext

IETF Secretariat | 21 Jun 17:27 2015
Picon

State changed: charter-ietf-imapapnd-00-00

State changed to IESG review.

URL: https://datatracker.ietf.org/doc/charter-ietf-imapapnd/

_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext

IETF Secretariat | 12 Jun 18:07 2015
Picon

Telechat update notice: <charter-ietf-imapapnd-00-00.txt>

Telechat date has been changed to 2015-06-25 from 2015-06-11
ID Tracker URL: https://datatracker.ietf.org/doc/charter-ietf-imapapnd/

_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext

IETF Secretariat | 12 Jun 18:07 2015
Picon

State changed: charter-ietf-imapapnd-00-00

State changed to External review.

URL: https://datatracker.ietf.org/doc/charter-ietf-imapapnd/

_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext

IETF Secretariat | 2 Jun 20:22 2015
Picon

Telechat update notice: <charter-ietf-imapapnd-00-00.txt>

Placed on agenda for telechat - 2015-06-11
ID Tracker URL: https://datatracker.ietf.org/doc/charter-ietf-imapapnd/

_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext

IETF Secretariat | 2 Jun 20:22 2015
Picon

State changed: charter-ietf-imapapnd-00-00

State changed to Internal review.

URL: https://datatracker.ietf.org/doc/charter-ietf-imapapnd/

_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext

Stu Brandt | 6 May 00:18 2015

Re: IMAP REPLACE extension

Pete -

Thanks for your response. My comments are inline.

On 5/5/15 2:35 PM, Pete Maclean wrote:
> Stu,
>
> This is a good start indeed but I find a few things to mention.
>
> Is UID REPLACE valid in the authenticated state?  My assumption would be
> that it is but it might be good for the text to make that explicit.

I was hoping that section 3.5 would have covered that. Specifically my 
statement of...

  "Unlike the APPEND command which is valid in the authenticated state,
    the REPLACE command MUST only be valid in the selected state. "

...was intended to answer your question. In my proposal, I'm intending 
to say it's valid ONLY in SELECTED state.  Does that wording cover it 
for you or can you help detail the ambiguity in the wording?

>
> Can REPLACE be used to replace a message in a mailbox other than the one
> the client has selected?  Surely it should not be.  Which perhaps
> suggests that REPLACE should not have a mailbox-name argument.

Yeah, I spent a lot of time going back and forth on this question.
Ultimately where I ended up is that since the problems that REPLACE 
solves (specified in section 2) exist regardless of whether the new 
(Continue reading)

Michael M Slusarz | 4 May 07:56 2015

IMAP SNIPPET extension (initial draft)

A little late, but here's my efforts on an initial draft regarding  
SNIPPET so that it can be added to the WG.

Based on the conversation that occurred on this list a few months  
back, I made these editorial decisions:

   - Extend FETCH: several people said this would not be implemented  
if it used ANNOTATE/CONVERT
   - Allow multiple different algorithms

I think the main point of discussion going forward is whether to  
explicitly define an algorithm for snippet generation (i.e. threading)  
or to allow the default algorithm to be entirely server-defined (i.e.  
FUZZY searching).  For now, I went with the latter, and even named it  
FUZZY.

Another issue regards the size of snippet return.  In this draft, this  
is not client configurable.  For the FUZZY algorithm, I used 150  
octets as SHOULD and MUST NOT ever exceed 300 octets.  (Snippet data  
must be returned as UTF-8).

But hopefully this is a decent enough starting point where it can be  
used to continue the discussion going forward.

michael

----------------

Internet Engineering Task Force                          M. Slusarz, Ed.
Internet-Draft                                                   Dovecot
(Continue reading)

Stu Brandt | 29 Apr 15:45 2015

IMAP REPLACE extension

As promised, here's a draft of a REPLACE extension.

Since the most obvious question is going to be "Why REPLACE and not an 
option on APPEND?",  I'll answer it straight away...

First, APPEND is valid in the authenticated state. REPLACE requires the 
selected state. I chose not to generate a mixed state scenario for 
APPEND. Secondly, REPLACE is similar to MOVE in that it avoids a number 
of issues that come with a serialized non-atomic sequence attempting to 
perform a single operation. MOVE is not an option on COPY, so I chose to 
follow the same precedent.

Here's the writeup.

------------------------------------------------------------------------

Network Working Group                                          S. Brandt
Internet-Draft                                                       AOL
Intended status: Standards Track                          April 29, 2015
Expires: October 31, 2015

                          IMAP REPLACE Extension
                       draft-brandt-imap-replace-00

Abstract

    This document defines an IMAP extension which can be used to replace
    an existing message in a message store with a new message.  Message
    replacment is a common operation for clients that automatically save
    drafts or notes as a user composes them.
(Continue reading)


Gmane