Subject: Re: Revised IMAPEXT milestones...
From: Alexey Melnikov <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Date: Thu, 25 Aug 2005 15:46:10 +0400
List-Id: <ietf-imapext.imc.org>

Lisa Dusseault wrote:

>
> To update the charter, looks like I have to add a year to every 
> milestone we haven't yet hit, plus add milestones for comparator:
>
> Done          Submit revised Sorting/Threading/Viewing spec(s) to IESG
> Done          Submit draft on conditional storage to help multiple 
> clients use a single mailbox to IESG
> Done          Standardize proposal to *update* existing ACL RFC, 
> explaining rights & listing rights in CAPABILITY response
> Aug 05        WG last call for comparator draft
> Aug 05          WG last call for annotate draft
> Aug 05          WG last call for LIST extensions draft, defining 
> syntax allowing much better extensibility in the frequently-extended 
> LIST command, and supporting other drafts in this WG

I think all three should be moved to September (August is almost over 
anyway).
Maybe even move comparator to October. I think 3 documents in WGLC is 
too much.

> Sep 05        Submit to IESG: comparator
> Sep 05          Submit to IESG: annotate
> Sep 05          WG last call for i18n draft
> Oct 05          Submit to IESG: List Extensions
> Oct 05          Submit to IESG: i18n
> Oct 05          New draft of ACL2 proposal which would *obsolete* 
> existing ACL RFC
> Feb 06          ACL2 to WG Last Call -- note that if this milestone is 
> not met we agreed to close the WG and defer ACL2 to another WG
>
> (compare to: http://www.ietf.org/html.charters/imapext-charter.html)
>
> If there are any problems with this, let me know.  Otherwise I'll 
> submit the revised milestones as a charter change, and let the public 
> shamings (for unfinished August tasks) begin in September...

Date: Wed, 24 Aug 2005 19:27:18 -0400
From: Cyrus Daboo <[email-masked]>
To: Lisa Dusseault <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Revised IMAPEXT milestones...
Sender: [email-masked]

Hi Lisa,

--On August 24, 2005 3:30:04 PM -0700 Lisa Dusseault 
<[email-masked]> wrote:

> If there are any problems with this, let me know.  Otherwise I'll submit
> the revised milestones as a charter change, and let the public shamings
> (for unfinished August tasks) begin in September...

Given the current date, I suggest you push back the annotate items by one 
month. I will have a new draft out with changes (as discussed on the list) 
next week.

-- 
Cyrus Daboo

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Revised IMAPEXT milestones...
Date: Wed, 24 Aug 2005 15:30:04 -0700
Sender: [email-masked]

To update the charter, looks like I have to add a year to every 
milestone we haven't yet hit, plus add milestones for comparator:

Done	  	Submit revised Sorting/Threading/Viewing spec(s) to IESG
Done	  	Submit draft on conditional storage to help multiple clients 
use a single mailbox to IESG
Done	  	Standardize proposal to *update* existing ACL RFC, explaining 
rights & listing rights in CAPABILITY response
Aug 05		WG last call for comparator draft
Aug 05	  	WG last call for annotate draft
Aug 05	  	WG last call for LIST extensions draft, defining syntax 
allowing much better extensibility in the frequently-extended LIST 
command, and supporting other drafts in this WG
Sep 05		Submit to IESG: comparator
Sep 05	  	Submit to IESG: annotate
Sep 05	  	WG last call for i18n draft
Oct 05	  	Submit to IESG: List Extensions
Oct 05	  	Submit to IESG: i18n
Oct 05	  	New draft of ACL2 proposal which would *obsolete* existing 
ACL RFC
Feb 06	  	ACL2 to WG Last Call -- note that if this milestone is not 
met we agreed to close the WG and defer ACL2 to another WG

(compare to: http://www.ietf.org/html.charters/imapext-charter.html)

If there are any problems with this, let me know.  Otherwise I'll 
submit the revised milestones as a charter change, and let the public 
shamings (for unfinished August tasks) begin in September...

Lisa

To: Dave Cridland <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, IMAP WG <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: Re: Confirm consensus on Annotate revision 
Date: Thu, 11 Aug 2005 00:12:52 -0700
Sender: [email-masked]

Dave Cridland <[email-masked]> writes:
...
>Secondly, I'm assuming these response codes incidate that annotations 
>are readonly except those mentioned in ANNOTATELEVEL, rather than 
>completely unavailable?

As Cyrus wants to use those indications when all the annotations on the
mailbox are read-only, I'm fairly sure he's thinking that they indicate
complete absence of one type of annotation.

Personally, I have a hard time seeing how that info would be useful when
the client isn't (or can't) do writes.  Defining them as meaning that
one type of annotation is read-only seems more useful to me, but then
the only IMAP client I hack on is a test suite, so I may easily be
missing a use case for the other interpretation.

Philip Guenther

Date: Wed, 10 Aug 2005 09:51:56 +0100
Subject: Re: Confirm consensus on Annotate revision
From: Dave Cridland <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, IMAP WG <[email-masked]>
Sender: [email-masked]

On Tue Aug  9 07:06:10 2005, Lisa Dusseault wrote:
> Looks good to me but I would go slightly farther and make a 
> recommendation
> to servers that if they're only going to support one of 
> PRIVATE/SHARED, to
> consider supporting SHARED.

I think the recommendation should be that they are PRIVATE for 
private mailboxes, and SHARED for shared mailboxes. This has 
implications for COPY, in particular, since copying a message between 
mailboxes copies shared annotations as shared. Copying a message on a 
dumbed-down ANNOTATE capable server only doing [ANNOTATELEVEL SHARED] 
would therefore expose previously private annotations.

Secondly, I'm assuming these response codes incidate that annotations 
are readonly except those mentioned in ANNOTATELEVEL, rather than 
completely unavailable?

Dave.

Date: Wed, 10 Aug 2005 10:49:03 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Confirm consensus on Annotate revision
Cc: Cyrus Daboo <[email-masked]>, Philip Guenther <[email-masked]>
Sender: [email-masked]

Philip Guenther writes:
> Cyrus Daboo <[email-masked]> writes:
>> My proposal for this would be the following:
>>
>> Add a new [ANNOTATELEVEL xxx] response code to the SELECT/EXAMINE 
>> commands, where xxx can be one of:
>>
>>     NONE    - annotations are not supported on this mailbox
>>     PRIVATE - only private annotations are supported on this mailbox
>>     SHARED  - only shared annotations are supported on this mailbox
>>     BOTH    - both private and shared annotations are supported
>
> To paraphrase a comment that Arnt made to me after the WG session, we 
> should design things so that there's no increase in traffic if the 
> server is fully functional, supporting both private and shared 
> annotations.

My major reason is that it's an optimization. The server is saying "I'm 
just telling you in advance that if you send so-and-so, that command 
will fail" which is more natural to me than "I'm just telling you in 
advance that so-and-so commands will work".

But I don't care very much.

Arnt

To: Cyrus Daboo <[email-masked]>
Cc: IMAP WG <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: Re: Confirm consensus on Annotate revision 
Date: Tue, 09 Aug 2005 22:55:11 -0700
Sender: [email-masked]

Cyrus Daboo <[email-masked]> writes:
...
>I think that would need to be:
>
>      resp-text-code    =/ "ANNOTATE" SP "TOOBIG" /
>                           "ANNOTATE" SP "TOOMANY" /
>                           "ANNOTATE" SP "NOPRIVATE" /
>                           "ANNOTATE" SP "NOSHARED" /
>                           "ANNOTATIONS" SP ann-size
>                          ; new response codes
>
>      ann-size		= "NONE" /
>                     ("READ-ONLY" / nz-number)
>                        [SP ("NOPRIVATE" / "NOSHARED")])
>
>That would allow for a NOPRIVATE or NOSHARED with the READ-ONLY indicator 
>as well.

I'm not sure I see how a client would find those useful in the
READ-ONLY case, but there's an obvious meaning, so I don't object.

>Note I also added new response codes to use in a tagged NO if the 
>client attempts to use unsupported .priv or .shared.

Those only apply to STORE and not FETCH, right?  IMHO, it shouldn't
be an error to attempt to fetch, for example, a .priv annotation
on a message in a mailbox that is NOPRIVATE, it'll simply never be
there.

>Also I changed the name of the ANNOTATIONSIZE response code.

Yeah, ANNOTATIONS is a better choice.  Should there be an example
of a SELECT and the resulting responses?

Two other comments on the draft:
1) section 3.3, last paragraph say
	A search, fetch, or sort which specifies neither uses both.
   What does it mean to "use both" in sort?

2) section 3.4, paragraph 6, says
	The "n" right MUST NOT be present if the "r" is not present.
   I think that should be dropped, as there's no similar requirement
   for the 's', 'w', or 'd' rights.  If you have the 'i' and 'n'
   rights on a mailbox, you should be able to APPEND a message with
   a shared annotation, regardless of whether you can select the
   mailbox (i.e., there's no silly state).

   If the requirement is kept, it has to be reworded to be specific
   requirements on the server, client, or both.  Is it an error to
   remove just the 'r' right when the 'n' right is present or is
   the server supposed to remove the 'n' right too?  Or simply
   suppress it in GETACL output?

Philip Guenther

Date: Wed, 10 Aug 2005 00:44:54 -0400
From: Cyrus Daboo <[email-masked]>
To: Philip Guenther <[email-masked]>
cc: IMAP WG <[email-masked]>
Subject: Re: Confirm consensus on Annotate revision 
Sender: [email-masked]

Hi Philip,

--On August 9, 2005 4:34:49 PM -0700 Philip Guenther 
<[email-masked]> wrote:

> or maybe
>       resp-text-code    =/ "ANNOTATE" SP "TOOBIG" /
>                            "ANNOTATE" SP "TOOMANY" /
> 			   "ANNOTATIONSIZE" SP att-size
>                           ; new response codes
>
>       att-size		= "NONE" / "READ-ONLY" /
> 			  (nz-number [SP ("NOPRIVATE" / "NOSHARED")])
>
> (In the context of the ANNOTATIONSIZE response, I find the negative
> version, NOPRIVATE/NOSHARED, clearer than the positive PRIVATE/SHARED or
> even PRIVATE-ONLY/SHARED-ONLY.)

I think that would need to be:

      resp-text-code    =/ "ANNOTATE" SP "TOOBIG" /
                           "ANNOTATE" SP "TOOMANY" /
                           "ANNOTATE" SP "NOPRIVATE" /
                           "ANNOTATE" SP "NOSHARED" /
                	        "ANNOTATIONS" SP ann-size
                          ; new response codes

      ann-size		= "NONE" /
                     ("READ-ONLY" / nz-number)
                        [SP ("NOPRIVATE" / "NOSHARED")])

That would allow for a NOPRIVATE or NOSHARED with the READ-ONLY indicator 
as well. Note I also added new response codes to use in a tagged NO if the 
client attempts to use unsupported .priv or .shared. Also I changed the 
name of the ANNOTATIONSIZE response code.

-- 
Cyrus Daboo

To: Timo Sirainen <[email-masked]>
Cc: IMAP WG <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: Re: Confirm consensus on Annotate revision 
Date: Tue, 09 Aug 2005 18:15:39 -0700
Sender: [email-masked]

Timo Sirainen <[email-masked]> writes:
...
>I'm not sure if these are a good idea to use in non-shared mailboxes, 
>which really are a majority. If my server supports only shared 
>annotations (because they're easier to implement), but only one user 
>has access to the mailbox, is it still right to call those annotations 
>shared?

Is it possible for a given mailbox to made a shared mailbox in the
future, whether via SETACL, RENAME (name based restriction?), or some
means outside IMAP?  If so, your naming should be guided by how the
annotations would behave after the change were it to happen.

Even if that's not possible, the difference is detectable if the user
can copy messages from the given non-shared mailbox to a shared mailbox
that supports annotations: will the annotations be visible to other
users after the COPY?  If so, they were shared to start with.

If your server doesn't support annotations on shared mailboxes, period,
then the difference is not detectable and you can call them whatever you
want, though I would tend to call them private annotations so that
clients don't hold back from using them for truly private info.

Philip Guenther

Cc: Lisa Dusseault <[email-masked]>, IMAP WG <[email-masked]>
From: Timo Sirainen <[email-masked]>
Subject: Re: Confirm consensus on Annotate revision
Date: Wed, 10 Aug 2005 03:22:19 +0300
To: Cyrus Daboo <[email-masked]>
Sender: [email-masked]

--Apple-Mail-3--702748900
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed

On 9.8.2005, at 22:10, Cyrus Daboo wrote:

> Add a new [ANNOTATELEVEL xxx] response code to the SELECT/EXAMINE 
> commands, where xxx can be one of:
>
>    NONE    - annotations are not supported on this mailbox
>    PRIVATE - only private annotations are supported on this mailbox
>    SHARED  - only shared annotations are supported on this mailbox
>    BOTH    - both private and shared annotations are supported

I'm not sure if these are a good idea to use in non-shared mailboxes, 
which really are a majority. If my server supports only shared 
annotations (because they're easier to implement), but only one user 
has access to the mailbox, is it still right to call those annotations 
shared?

--Apple-Mail-3--702748900
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

--Apple-Mail-3--702748900--

To: Cyrus Daboo <[email-masked]>
Cc: IMAP WG <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: Re: Confirm consensus on Annotate revision 
Date: Tue, 09 Aug 2005 16:34:49 -0700
Sender: [email-masked]

Cyrus Daboo <[email-masked]> writes:
>My proposal for this would be the following:
>
>Add a new [ANNOTATELEVEL xxx] response code to the SELECT/EXAMINE commands, 
>where xxx can be one of:
>
>    NONE    - annotations are not supported on this mailbox
>    PRIVATE - only private annotations are supported on this mailbox
>    SHARED  - only shared annotations are supported on this mailbox
>    BOTH    - both private and shared annotations are supported

To paraphrase a comment that Arnt made to me after the WG session, we
should design things so that there's no increase in traffic if the
server is fully functional, supporting both private and shared
annotations.  That can be achieved in at least a couple ways: 'BOTH'
could be made the default and the ANNOTATELEVEL response code could be
made optional or the indication of private-only/shared-only could rolled
into the existing ANNOTATIONSIZE response code (perhaps renaming it).

Offhand, I find the latter appealing.  The syntax could run something
like:
      resp-text-code    =/ "ANNOTATE" SP "TOOBIG" /
                           "ANNOTATE" SP "TOOMANY" /
			   "ANNOTATIONSIZE" SP (nil / att-size)
                          ; new response codes

      att-size		= number [SP ("NOPRIVATE" / "NOSHARED")]

or maybe
      resp-text-code    =/ "ANNOTATE" SP "TOOBIG" /
                           "ANNOTATE" SP "TOOMANY" /
			   "ANNOTATIONSIZE" SP att-size
                          ; new response codes

      att-size		= "NONE" / "READ-ONLY" /
			  (nz-number [SP ("NOPRIVATE" / "NOSHARED")])

(In the context of the ANNOTATIONSIZE response, I find the negative
version, NOPRIVATE/NOSHARED, clearer than the positive PRIVATE/SHARED or
even PRIVATE-ONLY/SHARED-ONLY.)

Philip Guenther

To: "Cyrus Daboo" <[email-masked]>, "IMAP WG" <[email-masked]>
Subject: Re: Confirm consensus on Annotate revision
Date: Tue, 09 Aug 2005 13:06:10 -0700
From: "Lisa Dusseault" <[email-masked]>
Organization: OSAF
Sender: [email-masked]

Looks good to me but I would go slightly farther and make a recommendation
to servers that if they're only going to support one of PRIVATE/SHARED, to
consider supporting SHARED.

(I'd almost equally go for a recommendation of "if you're only going to  
support
one, try supporting private" but I think that has a significantly bigger
implementation burden, and speaking as a client implementor, I think we can
do just fine with shared annotations only)

Lisa

On Tue, 09 Aug 2005 12:10:46 -0700, Cyrus Daboo <[email-masked]> wrote:

>
> Hi Lisa,
>
> --On August 8, 2005 6:25:07 PM -0700 Lisa Dusseault  
> <[email-masked]> wrote:
>
>> We discussed a number of options (check the meeting notes) such as
>> whether  to do something more drastic to the draft (definitely not a lot
>> of support  for drastic changes at this point) or whether to do nothing.
>> Please add  your 2 cents to this discussion (a clear vote, for example,
>> or some  considerations we missed) but please do read the meeting notes
>> first.  If  that's unclear please ask questions while the meeting is
>> still fresh in  the memories of the attendees, or check also the jabber
>> log
>
> My proposal for this would be the following:
>
> Add a new [ANNOTATELEVEL xxx] response code to the SELECT/EXAMINE  
> commands, where xxx can be one of:
>
>     NONE    - annotations are not supported on this mailbox
>     PRIVATE - only private annotations are supported on this mailbox
>     SHARED  - only shared annotations are supported on this mailbox
>     BOTH    - both private and shared annotations are supported
>
> Note that the NONE option will replace the current [ANNOTATIONSIZE NIL]  
> which is used to indicate lack of support for annotations.
>
> I believe this is a better solution than using separate CAPABILITY's. As  
> we have already recognized, there is a need to have a per-mailbox  
> indicator for annotation support because some mailbox formats may be  
> able to support them and others not. I see the issue of only supporting  
> one or other of private and shared as being along the same lines.
>

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Date: Tue, 9 Aug 2005 12:23:30 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Lisa Dusseault <[email-masked]>, IMAP WG <[email-masked]>
Subject: Re: Confirm consensus on Annotate revision
Organization: Networks & Distributed Computing
Sender: [email-masked]

Cyrus' proposal seems like a good idea to me.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Tue, 09 Aug 2005 15:10:46 -0400
From: Cyrus Daboo <[email-masked]>
To: Lisa Dusseault <[email-masked]>, IMAP WG <[email-masked]>
Subject: Re: Confirm consensus on Annotate revision
Sender: [email-masked]

Hi Lisa,

--On August 8, 2005 6:25:07 PM -0700 Lisa Dusseault 
<[email-masked]> wrote:

> We discussed a number of options (check the meeting notes) such as
> whether  to do something more drastic to the draft (definitely not a lot
> of support  for drastic changes at this point) or whether to do nothing.
> Please add  your 2 cents to this discussion (a clear vote, for example,
> or some  considerations we missed) but please do read the meeting notes
> first.  If  that's unclear please ask questions while the meeting is
> still fresh in  the memories of the attendees, or check also the jabber
> log

My proposal for this would be the following:

Add a new [ANNOTATELEVEL xxx] response code to the SELECT/EXAMINE commands, 
where xxx can be one of:

    NONE    - annotations are not supported on this mailbox
    PRIVATE - only private annotations are supported on this mailbox
    SHARED  - only shared annotations are supported on this mailbox
    BOTH    - both private and shared annotations are supported

Note that the NONE option will replace the current [ANNOTATIONSIZE NIL] 
which is used to indicate lack of support for annotations.

I believe this is a better solution than using separate CAPABILITY's. As we 
have already recognized, there is a need to have a per-mailbox indicator 
for annotation support because some mailbox formats may be able to support 
them and others not. I see the issue of only supporting one or other of 
private and shared as being along the same lines.

-- 
Cyrus Daboo

Date: Tue, 09 Aug 2005 12:00:16 +0100
From: Alexey Melnikov <[email-masked]>
To: Lisa Dusseault <[email-masked]>
CC: IMAP WG <[email-masked]>
Subject: Re: Proceedings for IMAPEXT meeting at IETF 63
Sender: [email-masked]

Lisa Dusseault wrote:

> Here are the notes and the slides from the IMAPEXT meeting last week.
>
> Notes:
> http://ietf.webdav.org/imapext/notes/IETF63-imapext-notes.txt

Some editorial/clarifying comments for the notes below:

> There's a suggestion to extend the grammar such that we can later include
> "max 100" blah, but the change makes the grammar much more complex.

I was talking about LIST paged results, i.e. the client ask "return me 
the first 100 mailboxes", later on it can ask "return the next 100", etc.

> Dave as
> client developer was in favour, Arnt was against until there are two good
> reasons. Alexey mentioned IMAPABNF, I didn't really get the point.

I think I've mentioned that it might be better if extended LIST ABNF is 
moved to IMAPABNF draft. For example, ACL2 might use extended LIST 
responses, without the need to require the servers to implement 
LIST-EXTENDED. But this is a separate issue to allowing option 
parameters in LIST.

I've also said that I would hate to do an extension to LIST extension.

> Food for
> thought, he said. Tony Hansen cautioned against painting ourselves into
> a corner.
>  
> Barry doesn't feel that he has guidance yet, just incidental opinions. 
> Arnt
> emphasizes that give two good reasons, etc. Chris proposes erring on the
> side of complexity, since we've had to many too-limited list 
> extensions in
> the past.

I think we had a weak consensus that extended LIST should allow for 
options. Chris' argument was very convincing, at least for me.

> Interaction of REMOTE and RECURSIVEMATCH. Alexey: Would it be reasonable
> to return all mailboxes that might have remote children? Tricky 
> discussion
> ensues - is it a no-op or not?

The question is what should the server that doesn't support any remote 
mailboxes do.
REMOTE is not "return only remote mailboxes", it is "return all local + 
remote mailboxes". So REMOTE RECURSIVE might be a bit counter intuitive, 
because it doesn't answer the question "all mailboxes with remote children".

> Scribe is not alone being puzzled. Document
> needs clarification. Dave will provide some text.
>  
> Currently, the CHILDINFO works like this: If the parent matches the
> pattern and the child the other requirement,

"the child doesn't match the pattern, but matches the selection criteria."

> the parent with CHILDINFO
> is returned. Is that what clients need? Phillip explains RECURSIVEMATCH:
> Clients want to find something, and doesn't want to use LIST *.
>  
> Barry shows parent-child relationships on a way he eventually explains.
> Revision will ensue, and will be reviewed by people who don't get it. New
> revision Aug 19, then probably WGLC.
>  
> ANNOTATE: Brief agreement that we don't need another WGLC. We'll push 
> it on.
>  
> IMAP ABNF:
>  
>  - purpose: use of common syntax for all extension elements
>    (refactoring)
>  - which extended commands should be listed (suggestion to add CREATE
>    and maybe ESEARCH response)
>  - discussion about wording requirements on future documents
>  
> Alexey has noted similar but different ABNF in several extensions, and
> wants that to be the same. Much silence in room. Arnt spoke in favour,
> saying we now have the experience to write such a document. Lisa
> suggests it's suitable individual submission and can be discussed on
> the list.

I've also clarified that consistent syntax doesn't change any existing 
extension, it just make grammar more permissive in certain cases. This 
should only affect future extensions.

>
> Alexey suggests adding ESEARCH to IMAP ABNF. Noone seems to understand
> the implications.

There are several extensions to SEARCH that need to be compatible with 
each others:
1). "IMAP extension for referencing the last SEARCH result" 
(draft-melnikov-imap-search-res-02.txt)
2). "IMAP4 extension to SEARCH command for controlling what kind of 
information is returned" (draft-melnikov-imap-search-ret-01.txt)

Also, CONDSTORE extends SEARCH response, in the future it probably 
should also use ESEARCH response as well.

>  
> Hairsplitting over draft names. It's good to name things clearly enough
> that grep can find it. It's also good to mention thing on lemonade, since
> a small group of people are paying attention there.
>  
> COMPARATOR and stuff: comparator is lost, can WG adopt? (Script edits
> that now.) Adoption carries. Phillip, Barry will review. Tony too. No
> rename is required. Arnt will submit with the right bullet, including
> Dave's comments.
>  
> Tony likes comparator, thinks it's close.
>  
> Lisa asks about who implements Annotate. Arnt, Dave, who else?
>  
> Annotatemore and annotate: Depend on each other? Dave says amore has

typo: annotatemore

> been deployed, annotate not. 

[...]

Date: Mon, 8 Aug 2005 18:39:40 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Lisa Dusseault <[email-masked]>
cc: IMAP WG <[email-masked]>
Subject: Re: Confirm consensus on Annotate revision
Organization: Networks & Distributed Computing
Sender: [email-masked]

I agree with the expressed sentiment that the implementation cost of the 
current ANNOTATE specification is too steep.  I do not wish to belabor the 
point, but I have expressed reservations in the past on the question of 
driving the design of IMAP extensions without adequate concern for server 
implementation considerations.

I support the idea of reducing/simplifying the ANNOTATE specification, 
with the goal of making server implementors feel less uncomfortable about 
the implementation cost.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Mon, 08 Aug 2005 18:25:07 -0700
To: "IMAP WG" <[email-masked]>
Subject: Confirm consensus on Annotate revision
From: "Lisa Dusseault" <[email-masked]>
Organization: OSAF
Sender: [email-masked]

I just sent the meeting notes to the list and to proceedings -- thanks  
Arnt for taking notes (and thanks Chris for being the jabber scribe).

The notes reminded me that we need to confirm the consensus we detected in  
the meeting to do a new version of the annotate draft, adding:
  - how a IMAP server may support shared annotations only (a per-folder  
response code, wasn't it?)
  - how an IMAP client may detect that
  - possibly some advice on whether it's appropriate for a client that  
would prefer to use private annotations to fall back to public annotations  
if that's all that the server supports

The impetus for this idea was that we noticed that hardly any IMAP servers  
planned to add support for annotations.  Most of the planned implementors  
were clients yet all the clients admitted that they were hoping for server  
implementations to come out first.  We polled server implementors a bit  
and the general impression was that the implementation cost, particularly  
for private annotations, was just too steep.  The client implementors in  
the room seemed to feel that a less ideal feature (shared annotations  
only) would still be useful.

We discussed a number of options (check the meeting notes) such as whether  
to do something more drastic to the draft (definitely not a lot of support  
for drastic changes at this point) or whether to do nothing.  Please add  
your 2 cents to this discussion (a clear vote, for example, or some  
considerations we missed) but please do read the meeting notes first.  If  
that's unclear please ask questions while the meeting is still fresh in  
the memories of the attendees, or check also the jabber log

http://www.xmpp.org/ietf-logs/[email-masked]/2005-08-03.html

thx,

Lisa

Date: Mon, 08 Aug 2005 18:16:11 -0700
To: "IMAP WG" <[email-masked]>, [email-masked]
Subject: Proceedings for IMAPEXT meeting at IETF 63 
From: "Lisa Dusseault" <[email-masked]>
Organization: OSAF
Sender: [email-masked]

Here are the notes and the slides from the IMAPEXT meeting last week.

Notes:
http://ietf.webdav.org/imapext/notes/IETF63-imapext-notes.txt

Slides
http://ietf.webdav.org/imapext/presentations/imapext-ietf63.ppt

Lisa

Date: Fri, 5 Aug 2005 01:28:12 +0200 (CEST)
From: "RL 'Bob' Morgan" <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Les amis du IMAPext
Sender: [email-masked]

Before:

   http://bobmorgan.org/pix/displayimage.php?album=5&pos=15

and during:

   http://bobmorgan.org/pix/displayimage.php?album=5&pos=16

a hardworking IETF dinner at which great progress was made settling many 
important issues, concerning which a full report will be issued at some 
later date (assuming someone was taking notes).

  - RL "Bob"

Date: Thu, 4 Aug 2005 13:29:52 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: ANNOTATEMORE
Sender: [email-masked]

On Thu, 4 Aug 2005, Cyrus Daboo wrote:
> The original thread on this was from June this year, and I have not updated 
> ANNOTATEMORE since then as I wanted to finish of ANNOTATE WGLC issues first. 
> However, your comment of string vs astring is also pertinent to ANNOTATE. 
> Only yourself and Phillip made any comment about this. Does anyone else have 
> an opinion? I am ambivalent myself. I think doing this change in ANNOTATE 
> post-WGLC is OK, but it will mean changing all the examples to remove 
> unnecessary quoting.

It isn't particularly necessary to change all the examples.  However, I 
feel that this change should be done as soon as possible.

It may also be necessary to change the capability name, if there are 
deployed servers that enforce string instead of astring.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Thu, 04 Aug 2005 16:27:45 -0400
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: ANNOTATEMORE
Sender: [email-masked]

Hi Mark,

--On Thursday, August 04, 2005 13:06 -0700 Mark Crispin 
<[email-masked]> wrote:

> I see that the ANNOTATEMORE draft still uses string instead of astring.
>
> I thought that we agreed to fix this.

The original thread on this was from June this year, and I have not updated 
ANNOTATEMORE since then as I wanted to finish of ANNOTATE WGLC issues 
first. However, your comment of string vs astring is also pertinent to 
ANNOTATE. Only yourself and Phillip made any comment about this. Does 
anyone else have an opinion? I am ambivalent myself. I think doing this 
change in ANNOTATE post-WGLC is OK, but it will mean changing all the 
examples to remove unnecessary quoting.

-- 
Cyrus Daboo

Date: Thu, 4 Aug 2005 13:06:14 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: ANNOTATEMORE
Sender: [email-masked]

I see that the ANNOTATEMORE draft still uses string instead of astring.

I thought that we agreed to fix this.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Thu, 04 Aug 2005 13:23:11 +0100
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: what I forgot while taking notes
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Alexey Melnikov writes:
>
>> I think you have missed the point. The drafts suggest transient 
>> capabilities that can be use by implementations to *play* with a 
>> particular extension while it still being developed. The transient 
>> capabilities must not be used once a draft becomes an RFC.
>
>
> I understand the purpose of the document. I don't understand why the 
> document needs to standardize anything to do with X-, and when in 
> doubt, I think an RFC should not standardize _anything_ to do with X-.
>
> What would make "X-DRAFT-number-name" better for the purpose than, 
> say, "INTERNET-DRAFT-number-name"?

Ah, I think I might be getting your point now.
My reading of RFC 3501 is that "X" prefix is reserved for private use. 
I've decided to use a part of this namespace for experimentation purposes.
It might be too late to use a different prefix for that, as I think this 
will require an update to RFC 3501.

Date: Thu, 4 Aug 2005 12:39:16 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Dinner tonight
Sender: [email-masked]

Hi,

dinner is at the Îlot Vache. We gather in the Concord (Concorde? don't 
know. don't stay there) lobby at eight, then go by Metro to l'Îlot 
Vache.

www.ilotvache.com is a fabulously bad web site. There is no reason at 
all to look at it.

(Should anyone wish to go there by themselves, the closest Metro station 
is Pont-Marie. Cross the bridge from the Pont Marie exit, go one block 
onwards, and you'll find yourself on the only street intersection worth 
speaking of. The "resto" is there.)

Arnt

To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked], Philip Guenther <[email-masked]>, Mark Crispin <[email-masked]>
Subject: Re: what I forgot while taking notes 
Date: Thu, 04 Aug 2005 03:33:27 -0700
From: Philip Guenther <[email-masked]>
Sender: [email-masked]

Arnt Gulbrandsen <[email-masked]> writes:
>Even at one remove, X- in an RFC makes me feel bad. There have been too 
>many threads on too many mailing lists in the past decade where too 
>many people have invoked too many bad arguments to standardize 
>X-something-or-other. I just want to stay away from that whole area.

RFC 3501 makes a requirement about using 'X' in capability name.  I see
the draft as making it more obvious that that requirement _often_
applies to early and intermediate I-Ds and then provides a specific
recommendation for how drafts can meet that requirement.  I believe the
experience with LISTEXT supports that this is a problem worth
documenting and giving direction on.

Philip Guenther

Date: Thu, 4 Aug 2005 12:19:59 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: what I forgot while taking notes
Cc: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

Alexey Melnikov writes:
> I think you have missed the point. The drafts suggest transient 
> capabilities that can be use by implementations to *play* with a 
> particular extension while it still being developed. The transient 
> capabilities must not be used once a draft becomes an RFC.

I understand the purpose of the document. I don't understand why the 
document needs to standardize anything to do with X-, and when in 
doubt, I think an RFC should not standardize _anything_ to do with X-.

What would make "X-DRAFT-number-name" better for the purpose than, say, 
"INTERNET-DRAFT-number-name"?

Arnt

Date: Thu, 04 Aug 2005 11:15:43 +0100
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: what I forgot while taking notes
Sender: [email-masked]

Arnt Gulbrandsen wrote:

>> Even though such are technically permitted, I think that standardized 
>> capabilities should eschew names starting with "X".
>
> I agree. However, that's not what the draft does. The draft 
> standardizes a name pattern for not-yet-standard capabilities, it does 
> not standardize a capability itself.
>
> Even at one remove, X- in an RFC makes me feel bad. There have been 
> too many threads on too many mailing lists in the past decade where 
> too many people have invoked too many bad arguments to standardize 
> X-something-or-other. I just want to stay away from that whole area.

I think you have missed the point. The drafts suggest transient 
capabilities that can be use by implementations to *play* with a 
particular extension while it still being developed. The transient 
capabilities must not be used once a draft becomes an RFC.

A recent example why this is useful: there are 3 existing servers 
implementing LISTEXT. They all implement different revisions of the 
draft, which results in implementing different syntaxes. Obviously no 
client can work without all three of them just by looking at the capability.

Date: Thu, 4 Aug 2005 10:29:57 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: what I forgot while taking notes
Cc: Philip Guenther <[email-masked]>, Mark Crispin <[email-masked]>
Sender: [email-masked]

Mark Crispin writes:
> However, as a matter of practicality, this is a difference that does 
> not make a difference.

Agreed.

> Even though such are technically permitted, I think that standardized 
> capabilities should eschew names starting with "X".

I agree. However, that's not what the draft does. The draft standardizes 
a name pattern for not-yet-standard capabilities, it does not 
standardize a capability itself.

Even at one remove, X- in an RFC makes me feel bad. There have been too 
many threads on too many mailing lists in the past decade where too 
many people have invoked too many bad arguments to standardize 
X-something-or-other. I just want to stay away from that whole area.

Arnt

Date: Thu, 4 Aug 2005 00:09:12 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Philip Guenther <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: what I forgot while taking notes 
Sender: [email-masked]

On Wed, 3 Aug 2005, Philip Guenther wrote:
> Arnt Gulbrandsen <[email-masked]> writes:
>> The capability name draft has a bit of a problem, in that it specifies
>> that which Shall Not Be Specified, namely X-blah.
> Actually, RFC 3501 doesn't say that capabilities that being with 'X'
> must be unstandardized, but rather the converse, that unstandardized
> capabilities must begin with an 'X'.  The capability name draft is
> therefore not in conflict with RFC 3501.

However, as a matter of practicality, this is a difference that does not 
make a difference.

Even though such are technically permitted, I think that standardized 
capabilities should eschew names starting with "X".

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked]
From: Philip Guenther <[email-masked]>
Subject: Re: what I forgot while taking notes 
Date: Wed, 03 Aug 2005 21:24:12 -0700
Sender: [email-masked]

Arnt Gulbrandsen <[email-masked]> writes:
>The capability name draft has a bit of a problem, in that it specifies 
>that which Shall Not Be Specified, namely X-blah.

Actually, RFC 3501 doesn't say that capabilities that being with 'X'
must be unstandardized, but rather the converse, that unstandardized
capabilities must begin with an 'X'.  The capability name draft is
therefore not in conflict with RFC 3501.

Philip Guenther

Date: Wed, 3 Aug 2005 13:54:25 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: what I forgot while taking notes
Sender: [email-masked]

Rereading the drafts yesterday, a few smallish things cropped up that I 
meant to mention today but forgot because I was taking notes all the 
time. Oops. Blame it on my newbie status.

The capability name draft has a bit of a problem, in that it specifies 
that which Shall Not Be Specified, namely X-blah. A Lemonade draft 
squeezed through doing that, and I guess specifying an X-blah naming 
scheme might too, but it _is_ borderline. My guess is that 
INTERNET-DRAFT-<capability>-<number> might pass IESG scrutiny more 
easily than X-DRAFT-ditto.

For the rest I'll send private mail to the editors, now or when I next review.

Arnt

Date: Tue, 2 Aug 2005 19:36:55 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: resurrected COMPRESS=DEFLATE draft
Cc: IMAP WG <[email-masked]>
Sender: [email-masked]

---
Content-Type: text/plain; format=flowed

Hi,

a couple of hallway discussions at IETF63 resulted in a resurrection of 
this old draft. I think I've updated it with whatever boilerplate is 
now required.

Please post it to the drafts directory when that is again permitted.

Arnt

---
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=utf-8
Content-Disposition: attachment; size=9295;
  filename=draft-gulbrandsen-imap-deflate-01.txt

Network Working Group                                   Arnt Gulbrandsen
Request for Comments: DRAFT                                         Oryx
draft-gulbrandsen-imap-deflate-01.txt                        August 2005

                  The IMAP COMPRESS=3DDEFLATE extension

Status of this Memo

    By submitting this Internet-Draft, each author represents that any
    applicable patent or other IPR claims of which he or she is aware
    have been or will be disclosed, and any of which he or she becomes
    aware will be disclosed, in accordance with Section 6 of BCP 79.

    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups.  Note that
    other groups may also distribute working documents as Internet-
    Drafts.

    Internet-Drafts are draft documents valid for a maximum of six
    months and may be updated, replaced, or obsoleted by other documents
    at any time.  It is inappropriate to use Internet-Drafts as
    reference material or to cite them other than as "work in progress."

    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/ietf/1id-abstracts.txt.  The list of Internet-
    Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.

Copyright Notice

    Copyright (C) The Internet Society 2005.  All Rights Reserved.

Abstract

    The COMPRESS=3DDEFLATE extension allows an IMAP connection to be
    compressed using the DEFLATE algorithm, such that effective
    compression is available even when TLS is used.

Conventions Used in This Document

    The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD
    NOT", and "MAY" in this document are to be interpreted as described
    in "Key words for use in RFCs to Indicate Requirement Levels"

Gulbrandsen               Expires February 2006         	[Page 1]
=0C
Internet-draft                                               August 2005

    [KEYWORDS]. Formal syntax is defined by [ABNF] as modified by
    [IMAP].

    In the example, "C:" and "S:" indicate lines sent by the client and
    server respectively.

Introduction and Overview

    An IMAP server that supports this extension announces
    "COMPRESS=3DDEFLATE" as one of its capabilities.

    The goal of COMPRESS=3DDEFLATE is to reduce the bandwidth usage of
    IMAP.  On regular IMAP connections, the PPP or MNP compression used
    with many low-bandwidth links compresses IMAP well. However, when
    TLS is used, PPP/MNP compression is ineffective. TLS too can provide
    compression, but currently few or no implementations do so in
    practice.

    In order to increase interoperation, it is desirable to have as few
    different compression algorithms as possible, so this document
    specifies only one.  The DEFLATE algorithm is standard, widely
    available, unencumbered by patents and fairly efficient.  Hopefully
    it will not be necessary to define additional algorithms.

    The extension adds one new command (COMPRESS) and no new responses.

The COMPRESS Command

    Arguments: Name of compression mechanism: "DEFLATE".

    Responses: None

    Result: OK    The server will compress its responses and expects the
                  client to compress its commands.
            NO    The connection already is compressed, or the server doesn=
't
                  support the requested mechanism.
            BAD   Command unknown or invalid argument.

    The COMPRESS command instructs the server to use the named
    compression mechanism ("DEFLATE" is the only one defined) for future
    commands and responses.

    For DEFLATE (as for many other compression mechanisms), the
    compressor can trade speed against quality.  When decompressing
    there isn't much of a tradeoff.  Consequently, the client and server
    are both free to pick the best reasonable rate of compression for

Gulbrandsen               Expires February 2006         	[Page 2]
=0C
Internet-draft                                               August 2005

    the data they send.

    The client MUST NOT send additional commands until it has seen the
    result of COMPRESS.

    If the client wants to use both TLS and compression, it SHOULD send
    STARTTLS before COMPRESS.

Example

    This example shows a simple login sequence. The client uses TLS for
    privacy and DEFLATE for compression.

         S: * OK [CAPABILITY IMAP4REV1 STARTTLS COMPRESS=3DDEFLATE]
         C: a starttls
         S: a OK
         C: b compress deflate
         S: b OK
         C: c login arnt tnra
         S: c OK

Implementation Notes

    When using the zlib library (see [DEFLATE]), the functions
    deflateInit(), deflate(), inflateInit() and inflate() suffice to
    implement this extension.

    Note that when using TLS, compression may actually decrease the CPU
    usage, depending on which algorithms are used in TLS. This is
    because fewer bytes need to be encrypted, and encryption is
    generally more expensive than compression.

Formal Syntax

    The following syntax specification uses the Augmented Backus-Naur
    Form (ABNF) notation as specified in [ABNF]. Non-terminals
    referenced but not defined below are as defined by [ABNF] (SP, CRLF)
    or [IMAP] (all others).

    Except as noted otherwise, all alphabetic characters are case-
    insensitive.  The use of upper or lower case characters to define
    token strings is for editorial clarity only.  Implementations MUST
    accept these strings in a case-insensitive fashion.

        command-any =3D/ compress

Gulbrandsen               Expires February 2006         	[Page 3]
=0C
Internet-draft                                               August 2005

        compress    =3D "COMPRESS" SP astring

Security considerations

    The proposed extension does not cause any security problems. It may
    marginally reduce the scope for plaintext attacks when used together
    with [TLS].

Credits

    (Your name here :)

References

    [ABNF]     Crocker, Overell, "Augmented BNF for Syntax
               Specifications: ABNF", RFC 2234, Internet Mail
               Consortium, Demon Internet Ltd, November 1997.

    [IMAP]     Crispin, M., "Internet Message Access Protocol - Version
               4rev1", RFC 3501, University of Washington, June 2003.

    [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
               Requirement Levels", RFC 2119, Harvard University, March
               1997.

    [DEFLATE]  Deutsch, P., "DEFLATE Compressed Data Format
               Specification version 1.3", RFC 1951, Aladdin
               Enterprises, May 1996.

    [STARTTLS] Newman, C. "Using TLS with IMAP, POP3 and ACAP", RFC
               2595, June 1999.

Author's Address

    Arnt Gulbrandsen
    Oryx Mail Systems GmbH
    Schweppermannstr. 8
    D-81671 Muenchen
    Germany

    Phone: +49 89 45029757
    Fax: +49 89 45029758

    Email: [email-masked]

Gulbrandsen               Expires February 2006         	[Page 4]
=0C
Internet-draft                                               August 2005

Intellectual Property Statement

    The IETF takes no position regarding the validity or scope of any
    Intellectual Property Rights or other rights that might be claimed to
    pertain to the implementation or use of the technology described in
    this document or the extent to which any license under such rights
    might or might not be available; nor does it represent that it has
    made any independent effort to identify any such rights.  Information
    on the procedures with respect to rights in RFC documents can be
    found in BCP 78 and BCP 79.

    Copies of IPR disclosures made to the IETF Secretariat and any
    assurances of licenses to be made available, or the result of an
    attempt made to obtain a general license or permission for the use of
    such proprietary rights by implementers or users of this
    specification can be obtained from the IETF on-line IPR repository at
    http://www.ietf.org/ipr.

    The IETF invites any interested party to bring to its attention any
    copyrights, patents or patent applications, or other proprietary
    rights that may cover technology that may be required to implement
    this standard.  Please address the information to the IETF at
    [email-masked].

Disclaimer of Validity

    This document and the information contained herein are provided on an
    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

    Copyright (C) The Internet Society (2005).  This document is subject
    to the rights, licenses and restrictions contained in BCP 78, and
    except as set forth therein, the authors retain all their rights.

Acknowledgment

    Funding for the RFC Editor function is currently provided by the
    Internet Society.

Gulbrandsen               Expires February 2006         	[Page 5]
=0C
-----

Date: Tue, 02 Aug 2005 11:35:36 -0400
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: ANNOTATE - changes after WGLC
Sender: [email-masked]

--==========5AB1D041A75424375570==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi folks,
In preparation for tomorrow's meeting, attached is a text document that 
shows the WGLC comments for the ANNOTATE draft that I extracted from the 
mailing list (all of which were addressed in the new revision) together 
with the actual 'changes' section for the new revision.

-- 
Cyrus Daboo
--==========5AB1D041A75424375570==========
Content-Type: text/plain; charset=us-ascii; name="Paris Changes"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="Paris Changes"; size=4738

ANNOTATE WGLC ISSUES FROM MAILING LIST:

+  Sync with change from DC meeting wrt 'r' right for both read and
write of .priv
+  Add text about 'n' right being a 'shared flag right' as defined in
2086upd
+  Allow NIL in /<section-part>/flags entries
+  Expand abstract to also indicate that annotations can apply on a
per-body part basis as well as per message
+  Fix resp-text-code to use nil instead of "NIL"
+  Use double-quotes conistently around ANNOTATESIZE etc
+  Fix typos: tyhe->the, UTF8->UTF-8, utf8->utf-8
+  Remove redundant second para of Introduction
+  Missing 'Conventions' section with RFC2119 reference
+  Describe S:, C: example behaviour in conventions section
+  Clarify that new rights must also be present if only old ACL is
present
+  Entry/attributes MUST NOT contain consecutive or trailing /
+  Clarify default charset for content-type text/plain
+  Recommend use of utf-8 for all non-ascii text
+  Clarify terminology of ANNOTATESIZE response code
+  Clarify behaviour if server does not return ANNOTATESIZE - MUST for
ANNOTATESIZE response
+  Change an example to use UID FETCH for variety
+  Clarify what to do about annotations exceeding allowed ANNOTATESIZE
when doing copy
+  Simplified select-param formal syntax - reference Alexey's document
+  Remove RFC1891 reference
+  capability syntax extension

Open Issues:

+  Dealing with content-type attribute: should servers validate the
value? - A: reference 2046

+  Should entry registration include a default content-type value? - A:
use recommended content-type in IANA registration.

+  Can values contain 'binary' data (i.e. possibly contain NULLs)?
There is no content-encoding so that is a possibility, in which case a
literal8 syntax element from the BINARY extension needs to be used, or a
new equivalent defined. - A: Alexey will extract literal8, ANNOTATE will
use that.

+  Should we restrict attribute names to exclude priv and shared
anywhere in the text? - A: ban 'shared' and 'priv' as separate hierarchy
elements.

+ UTF-8 entry/attribute names - lunch bof proposal to restrict to ascii
is fine by me - can we get WG consensus for that? - A: restrict
entry/attribute names - define displayname attribute

+  CATENATE has changed substantially since current ANNOTATE draft
reference. Now CATENATE is an extension to APPEND, so ANNOTATE only
needs to extend APPEND in a compatible way with CATENATE. I want to
reference Alexey's draft-melnikov-imap-ext-abnf-00 for that - CATENTATE
should do the same. - OK go ahead.

ACTUAL CHANGES IN DRAFT

 Changes from -12 to -13:
   1.  Sync with change from DC meeting wrt 'r' right for both read and
        write of .priv.
   2.  Add text about 'n' right being a 'shared flag right' as defined
        in 2086upd.
   3.  Allow NIL in /<section-part>/flags entries.
   4.  Expand abstract to also indicate that annotations can apply on a
        per-body part basis as well as per message.
   5.  Fix resp-text-code to use nil instead of "NIL".
   6.  Use double-quotes consistently around ANNOTATESIZE etc.
   7.  Fix typos.
   8.  Remove redundant second para of Introduction.
   9.  Added 'Conventions' section with RFC2119 reference..
   10.  Describe S:, C: example behaviour in conventions section..
   11.  Clarify that new rights must also be present if only old ACL is
        present.
   12.  Entry/attributes MUST NOT contain consecutive or trailing '/' or
        '.'.
   13.  Clarify default charset for content-type text/plain.
   14.  Recommend use of utf-8 for all non-ascii text.
   15.  Clarify terminology of ANNOTATESIZE response code.
   16.  Require servers to return ANNOTATESIZE on SELECT.
   17.  Change an example to use UID FETCH for variety.
   18.  Clarify what to do about annotations exceeding allowed
        ANNOTATESIZE when doing copy.
   19.  Use ABNFext document for extended SELECT etc.
   20.  Remove RFC1891 reference.
   21.  capability syntax extension.
   22.  Comment on validation content-type attribute.
   23.  Added recommended content-type in IANA registration.
   24.  Added use of literal8 for values.
   25.  Prevent use of 'shared' and 'priv' as separate hierarchy
        components.
   26.  Restrict entry/attribute names to ascii and added display-name
        attribute.
   27.  Remove references to CATENATE and use ABNFext for extended
        APPEND syntax.

--==========5AB1D041A75424375570==========--

Date: Tue, 2 Aug 2005 17:22:28 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Agenda for IMAPEXT WG meeting
Sender: [email-masked]

Lisa Dusseault writes:
> 20 min -- Adopting draft-newman-i18n-comparator in WG - Chris, Arnt
>  - Blocks draft-ietf-imapext-sort AND draft-ietf-imapext-i18n
>  - Therefore also blocks draft-ietf-annotate AND imapext-condstore AND 
>   individual submissions
>  - Arnt volunteered to edit, I volunteer to shepherd, WG reviews -- 
>  what  does WG think?

You will note that while I volunteered to do and Lisa volunteered to do, 
you just do. So please read that draft before tomorrow, OK? ;)

And also imapext-i18n, since the two are fairly tightly bound.

Arnt

Cc: "[email-masked]" <[email-masked]>
To: "IMAP WG" <[email-masked]>
Subject: Agenda for IMAPEXT WG meeting
Date: Tue, 02 Aug 2005 16:45:19 +0200
From: "Lisa Dusseault" <[email-masked]>
Organization: OSAF
Sender: [email-masked]

IMAPEXT is meeting tomorrow, 1030 Paris time in room 341 for 2 hours.   
These are the drafts you should
have read because they're working group drafts:

https://datatracker.ietf.org/public/idindex.cgi?command=show_wg_id&id=1409
  especially draft-ietf-imapext-annotate-13
             draft-ietf-imapext-list-extensions-13

In addition there are some individual contributions you should be aware of  
and ideally have read:
  - http://www.ietf.org/internet-drafts/draft-melnikov-imap-ext-abnf-02.txt
  - http://www.ietf.org/internet-drafts/draft-newman-i18n-comparator-04.txt

Agenda:

10 min -- Issues remaining with ListExt - Barry, Alexey
  - quick review of LIST-EXTENDED extensibility
  - interaction of REMOTE with RECURSIVEMATCH
  - are there any other issues that need to be addressed?
20 min -- next steps on ANNOTATE -- Randy, Cyrus
  - Do we need to redo WG last call?
  - Authors need to summarize changes since WG last call so that WG can  
decide this
20 min -- Issues remaining with IMAPABNF  
(draft-melnikov-imap-ext-abnf-02.txt)
  - use of common syntax for all extension elements
  - which extended commands should be listed (suggestion to add CREATE and  
maybe ESEARCH response)
  - discussion about wording requirements on future documents
20 min -- Adopting draft-newman-i18n-comparator in WG - Chris, Arnt
  - Blocks draft-ietf-imapext-sort AND draft-ietf-imapext-i18n
  - Therefore also blocks draft-ietf-annotate AND imapext-condstore AND  
individual submissions
  - Arnt volunteered to edit, I volunteer to shepherd, WG reviews -- what  
does WG think?

To: "Arnt Gulbrandsen" <[email-masked]>, [email-masked]
Subject: Re: Agenda so far...
Date: Mon, 01 Aug 2005 11:58:02 +0200
From: "Lisa Dusseault" <[email-masked]>
Organization: OSAF
Sender: [email-masked]

Yes to both!

Are you here in Paris already?  I'd like to run through with you some time  
what we're going to discuss on the comparator draft Weds.  I walked around  
and twisted a few arms this morning:
  - Barry Lieba, Randy Gellens and Philip Guenther to read draft and  
comment on any open issues
  - Chris Newman to sit down with us and actually work on the draft if we  
need that during this week

A good way to get in touch with me this week is using IM.  If you use AIM  
I'm "LisaDusseault" or if you use Jabber I'm  
"[email-masked]".  I also have some other IDs if necessary.

Lisa

On Sun, 31 Jul 2005 11:57:40 +0200, Arnt Gulbrandsen  
<[email-masked]> wrote:

>
> Lisa Dusseault writes:
>> If there are any additions, Pete will have to submit to  
>> [email-masked]  because i'm about to go on vacation (in Paris,  
>> naturally) until Jul 31.
>
> Had a fine vacation? Lots of mail to catch up on now that the IETF  
> starts?
>
> Arnt
>

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Date: Sun, 31 Jul 2005 11:57:40 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Agenda so far...
Sender: [email-masked]

Lisa Dusseault writes:
> If there are any additions, Pete will have to submit to 
> [email-masked]  because i'm about to go on vacation (in Paris, 
> naturally) until Jul 31.

Had a fine vacation? Lots of mail to catch up on now that the IETF starts?

Arnt

Date: Thu, 25 Aug 2005 15:46:10 +0400
From: Alexey Melnikov <[email-masked]>
To: Lisa Dusseault <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Revised IMAPEXT milestones...
Sender: [email-masked]

Lisa Dusseault wrote:

>
> To update the charter, looks like I have to add a year to every 
> milestone we haven't yet hit, plus add milestones for comparator:
>
> Done          Submit revised Sorting/Threading/Viewing spec(s) to IESG
> Done          Submit draft on conditional storage to help multiple 
> clients use a single mailbox to IESG
> Done          Standardize proposal to *update* existing ACL RFC, 
> explaining rights & listing rights in CAPABILITY response
> Aug 05        WG last call for comparator draft
> Aug 05          WG last call for annotate draft
> Aug 05          WG last call for LIST extensions draft, defining 
> syntax allowing much better extensibility in the frequently-extended 
> LIST command, and supporting other drafts in this WG

I think all three should be moved to September (August is almost over 
anyway).
Maybe even move comparator to October. I think 3 documents in WGLC is 
too much.

> Sep 05        Submit to IESG: comparator
> Sep 05          Submit to IESG: annotate
> Sep 05          WG last call for i18n draft
> Oct 05          Submit to IESG: List Extensions
> Oct 05          Submit to IESG: i18n
> Oct 05          New draft of ACL2 proposal which would *obsolete* 
> existing ACL RFC
> Feb 06          ACL2 to WG Last Call -- note that if this milestone is 
> not met we agreed to close the WG and defer ACL2 to another WG
>
> (compare to: http://www.ietf.org/html.charters/imapext-charter.html)
>
> If there are any problems with this, let me know.  Otherwise I'll 
> submit the revised milestones as a charter change, and let the public 
> shamings (for unfinished August tasks) begin in September...

Date: Wed, 24 Aug 2005 19:27:18 -0400
From: Cyrus Daboo <[email-masked]>
To: Lisa Dusseault <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Revised IMAPEXT milestones...
Sender: [email-masked]

Hi Lisa,

--On August 24, 2005 3:30:04 PM -0700 Lisa Dusseault 
<[email-masked]> wrote:

> If there are any problems with this, let me know.  Otherwise I'll submit
> the revised milestones as a charter change, and let the public shamings
> (for unfinished August tasks) begin in September...

Given the current date, I suggest you push back the annotate items by one 
month. I will have a new draft out with changes (as discussed on the list) 
next week.

-- 
Cyrus Daboo

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Revised IMAPEXT milestones...
Date: Wed, 24 Aug 2005 15:30:04 -0700
Sender: [email-masked]

To update the charter, looks like I have to add a year to every 
milestone we haven't yet hit, plus add milestones for comparator:

Done	  	Submit revised Sorting/Threading/Viewing spec(s) to IESG
Done	  	Submit draft on conditional storage to help multiple clients 
use a single mailbox to IESG
Done	  	Standardize proposal to *update* existing ACL RFC, explaining 
rights & listing rights in CAPABILITY response
Aug 05		WG last call for comparator draft
Aug 05	  	WG last call for annotate draft
Aug 05	  	WG last call for LIST extensions draft, defining syntax 
allowing much better extensibility in the frequently-extended LIST 
command, and supporting other drafts in this WG
Sep 05		Submit to IESG: comparator
Sep 05	  	Submit to IESG: annotate
Sep 05	  	WG last call for i18n draft
Oct 05	  	Submit to IESG: List Extensions
Oct 05	  	Submit to IESG: i18n
Oct 05	  	New draft of ACL2 proposal which would *obsolete* existing 
ACL RFC
Feb 06	  	ACL2 to WG Last Call -- note that if this milestone is not 
met we agreed to close the WG and defer ACL2 to another WG

(compare to: http://www.ietf.org/html.charters/imapext-charter.html)

If there are any problems with this, let me know.  Otherwise I'll 
submit the revised milestones as a charter change, and let the public 
shamings (for unfinished August tasks) begin in September...

Lisa

To: Dave Cridland <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, IMAP WG <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: Re: Confirm consensus on Annotate revision 
Date: Thu, 11 Aug 2005 00:12:52 -0700
Sender: [email-masked]

Dave Cridland <[email-masked]> writes:
...
>Secondly, I'm assuming these response codes incidate that annotations 
>are readonly except those mentioned in ANNOTATELEVEL, rather than 
>completely unavailable?

As Cyrus wants to use those indications when all the annotations on the
mailbox are read-only, I'm fairly sure he's thinking that they indicate
complete absence of one type of annotation.

Personally, I have a hard time seeing how that info would be useful when
the client isn't (or can't) do writes.  Defining them as meaning that
one type of annotation is read-only seems more useful to me, but then
the only IMAP client I hack on is a test suite, so I may easily be
missing a use case for the other interpretation.

Philip Guenther

Date: Wed, 10 Aug 2005 09:51:56 +0100
Subject: Re: Confirm consensus on Annotate revision
From: Dave Cridland <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Cc: Cyrus Daboo <[email-masked]>, IMAP WG <[email-masked]>
Sender: [email-masked]

On Tue Aug  9 07:06:10 2005, Lisa Dusseault wrote:
> Looks good to me but I would go slightly farther and make a 
> recommendation
> to servers that if they're only going to support one of 
> PRIVATE/SHARED, to
> consider supporting SHARED.

I think the recommendation should be that they are PRIVATE for 
private mailboxes, and SHARED for shared mailboxes. This has 
implications for COPY, in particular, since copying a message between 
mailboxes copies shared annotations as shared. Copying a message on a 
dumbed-down ANNOTATE capable server only doing [ANNOTATELEVEL SHARED] 
would therefore expose previously private annotations.

Secondly, I'm assuming these response codes incidate that annotations 
are readonly except those mentioned in ANNOTATELEVEL, rather than 
completely unavailable?

Dave.

Date: Wed, 10 Aug 2005 10:49:03 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Confirm consensus on Annotate revision
Cc: Cyrus Daboo <[email-masked]>, Philip Guenther <[email-masked]>
Sender: [email-masked]

Philip Guenther writes:
> Cyrus Daboo <[email-masked]> writes:
>> My proposal for this would be the following:
>>
>> Add a new [ANNOTATELEVEL xxx] response code to the SELECT/EXAMINE 
>> commands, where xxx can be one of:
>>
>>     NONE    - annotations are not supported on this mailbox
>>     PRIVATE - only private annotations are supported on this mailbox
>>     SHARED  - only shared annotations are supported on this mailbox
>>     BOTH    - both private and shared annotations are supported
>
> To paraphrase a comment that Arnt made to me after the WG session, we 
> should design things so that there's no increase in traffic if the 
> server is fully functional, supporting both private and shared 
> annotations.

My major reason is that it's an optimization. The server is saying "I'm 
just telling you in advance that if you send so-and-so, that command 
will fail" which is more natural to me than "I'm just telling you in 
advance that so-and-so commands will work".

But I don't care very much.

Arnt

To: Cyrus Daboo <[email-masked]>
Cc: IMAP WG <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: Re: Confirm consensus on Annotate revision 
Date: Tue, 09 Aug 2005 22:55:11 -0700
Sender: [email-masked]

Cyrus Daboo <[email-masked]> writes:
...
>I think that would need to be:
>
>      resp-text-code    =/ "ANNOTATE" SP "TOOBIG" /
>                           "ANNOTATE" SP "TOOMANY" /
>                           "ANNOTATE" SP "NOPRIVATE" /
>                           "ANNOTATE" SP "NOSHARED" /
>                           "ANNOTATIONS" SP ann-size
>                          ; new response codes
>
>      ann-size		= "NONE" /
>                     ("READ-ONLY" / nz-number)
>                        [SP ("NOPRIVATE" / "NOSHARED")])
>
>That would allow for a NOPRIVATE or NOSHARED with the READ-ONLY indicator 
>as well.

I'm not sure I see how a client would find those useful in the
READ-ONLY case, but there's an obvious meaning, so I don't object.

>Note I also added new response codes to use in a tagged NO if the 
>client attempts to use unsupported .priv or .shared.

Those only apply to STORE and not FETCH, right?  IMHO, it shouldn't
be an error to attempt to fetch, for example, a .priv annotation
on a message in a mailbox that is NOPRIVATE, it'll simply never be
there.

>Also I changed the name of the ANNOTATIONSIZE response code.

Yeah, ANNOTATIONS is a better choice.  Should there be an example
of a SELECT and the resulting responses?

Two other comments on the draft:
1) section 3.3, last paragraph say
	A search, fetch, or sort which specifies neither uses both.
   What does it mean to "use both" in sort?

2) section 3.4, paragraph 6, says
	The "n" right MUST NOT be present if the "r" is not present.
   I think that should be dropped, as there's no similar requirement
   for the 's', 'w', or 'd' rights.  If you have the 'i' and 'n'
   rights on a mailbox, you should be able to APPEND a message with
   a shared annotation, regardless of whether you can select the
   mailbox (i.e., there's no silly state).

   If the requirement is kept, it has to be reworded to be specific
   requirements on the server, client, or both.  Is it an error to
   remove just the 'r' right when the 'n' right is present or is
   the server supposed to remove the 'n' right too?  Or simply
   suppress it in GETACL output?

Philip Guenther

Date: Wed, 10 Aug 2005 00:44:54 -0400
From: Cyrus Daboo <[email-masked]>
To: Philip Guenther <[email-masked]>
cc: IMAP WG <[email-masked]>
Subject: Re: Confirm consensus on Annotate revision 
Sender: [email-masked]

Hi Philip,

--On August 9, 2005 4:34:49 PM -0700 Philip Guenther 
<[email-masked]> wrote:

> or maybe
>       resp-text-code    =/ "ANNOTATE" SP "TOOBIG" /
>                            "ANNOTATE" SP "TOOMANY" /
> 			   "ANNOTATIONSIZE" SP att-size
>                           ; new response codes
>
>       att-size		= "NONE" / "READ-ONLY" /
> 			  (nz-number [SP ("NOPRIVATE" / "NOSHARED")])
>
> (In the context of the ANNOTATIONSIZE response, I find the negative
> version, NOPRIVATE/NOSHARED, clearer than the positive PRIVATE/SHARED or
> even PRIVATE-ONLY/SHARED-ONLY.)

I think that would need to be:

      resp-text-code    =/ "ANNOTATE" SP "TOOBIG" /
                           "ANNOTATE" SP "TOOMANY" /
                           "ANNOTATE" SP "NOPRIVATE" /
                           "ANNOTATE" SP "NOSHARED" /
                	        "ANNOTATIONS" SP ann-size
                          ; new response codes

      ann-size		= "NONE" /
                     ("READ-ONLY" / nz-number)
                        [SP ("NOPRIVATE" / "NOSHARED")])

That would allow for a NOPRIVATE or NOSHARED with the READ-ONLY indicator 
as well. Note I also added new response codes to use in a tagged NO if the 
client attempts to use unsupported .priv or .shared. Also I changed the 
name of the ANNOTATIONSIZE response code.

-- 
Cyrus Daboo

To: Timo Sirainen <[email-masked]>
Cc: IMAP WG <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: Re: Confirm consensus on Annotate revision 
Date: Tue, 09 Aug 2005 18:15:39 -0700
Sender: [email-masked]

Timo Sirainen <[email-masked]> writes:
...
>I'm not sure if these are a good idea to use in non-shared mailboxes, 
>which really are a majority. If my server supports only shared 
>annotations (because they're easier to implement), but only one user 
>has access to the mailbox, is it still right to call those annotations 
>shared?

Is it possible for a given mailbox to made a shared mailbox in the
future, whether via SETACL, RENAME (name based restriction?), or some
means outside IMAP?  If so, your naming should be guided by how the
annotations would behave after the change were it to happen.

Even if that's not possible, the difference is detectable if the user
can copy messages from the given non-shared mailbox to a shared mailbox
that supports annotations: will the annotations be visible to other
users after the COPY?  If so, they were shared to start with.

If your server doesn't support annotations on shared mailboxes, period,
then the difference is not detectable and you can call them whatever you
want, though I would tend to call them private annotations so that
clients don't hold back from using them for truly private info.

Philip Guenther

Cc: Lisa Dusseault <[email-masked]>, IMAP WG <[email-masked]>
From: Timo Sirainen <[email-masked]>
Subject: Re: Confirm consensus on Annotate revision
Date: Wed, 10 Aug 2005 03:22:19 +0300
To: Cyrus Daboo <[email-masked]>
Sender: [email-masked]

--Apple-Mail-3--702748900
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed

On 9.8.2005, at 22:10, Cyrus Daboo wrote:

> Add a new [ANNOTATELEVEL xxx] response code to the SELECT/EXAMINE 
> commands, where xxx can be one of:
>
>    NONE    - annotations are not supported on this mailbox
>    PRIVATE - only private annotations are supported on this mailbox
>    SHARED  - only shared annotations are supported on this mailbox
>    BOTH    - both private and shared annotations are supported

I'm not sure if these are a good idea to use in non-shared mailboxes, 
which really are a majority. If my server supports only shared 
annotations (because they're easier to implement), but only one user 
has access to the mailbox, is it still right to call those annotations 
shared?

--Apple-Mail-3--702748900
content-type: application/pgp-signature; x-mac-type=70674453;
	name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

--Apple-Mail-3--702748900--

To: Cyrus Daboo <[email-masked]>
Cc: IMAP WG <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: Re: Confirm consensus on Annotate revision 
Date: Tue, 09 Aug 2005 16:34:49 -0700
Sender: [email-masked]

Cyrus Daboo <[email-masked]> writes:
>My proposal for this would be the following:
>
>Add a new [ANNOTATELEVEL xxx] response code to the SELECT/EXAMINE commands, 
>where xxx can be one of:
>
>    NONE    - annotations are not supported on this mailbox
>    PRIVATE - only private annotations are supported on this mailbox
>    SHARED  - only shared annotations are supported on this mailbox
>    BOTH    - both private and shared annotations are supported

To paraphrase a comment that Arnt made to me after the WG session, we
should design things so that there's no increase in traffic if the
server is fully functional, supporting both private and shared
annotations.  That can be achieved in at least a couple ways: 'BOTH'
could be made the default and the ANNOTATELEVEL response code could be
made optional or the indication of private-only/shared-only could rolled
into the existing ANNOTATIONSIZE response code (perhaps renaming it).

Offhand, I find the latter appealing.  The syntax could run something
like:
      resp-text-code    =/ "ANNOTATE" SP "TOOBIG" /
                           "ANNOTATE" SP "TOOMANY" /
			   "ANNOTATIONSIZE" SP (nil / att-size)
                          ; new response codes

      att-size		= number [SP ("NOPRIVATE" / "NOSHARED")]

or maybe
      resp-text-code    =/ "ANNOTATE" SP "TOOBIG" /
                           "ANNOTATE" SP "TOOMANY" /
			   "ANNOTATIONSIZE" SP att-size
                          ; new response codes

      att-size		= "NONE" / "READ-ONLY" /
			  (nz-number [SP ("NOPRIVATE" / "NOSHARED")])

(In the context of the ANNOTATIONSIZE response, I find the negative
version, NOPRIVATE/NOSHARED, clearer than the positive PRIVATE/SHARED or
even PRIVATE-ONLY/SHARED-ONLY.)

Philip Guenther

To: "Cyrus Daboo" <[email-masked]>, "IMAP WG" <[email-masked]>
Subject: Re: Confirm consensus on Annotate revision
Date: Tue, 09 Aug 2005 13:06:10 -0700
From: "Lisa Dusseault" <[email-masked]>
Organization: OSAF
Sender: [email-masked]

Looks good to me but I would go slightly farther and make a recommendation
to servers that if they're only going to support one of PRIVATE/SHARED, to
consider supporting SHARED.

(I'd almost equally go for a recommendation of "if you're only going to  
support
one, try supporting private" but I think that has a significantly bigger
implementation burden, and speaking as a client implementor, I think we can
do just fine with shared annotations only)

Lisa

On Tue, 09 Aug 2005 12:10:46 -0700, Cyrus Daboo <[email-masked]> wrote:

>
> Hi Lisa,
>
> --On August 8, 2005 6:25:07 PM -0700 Lisa Dusseault  
> <[email-masked]> wrote:
>
>> We discussed a number of options (check the meeting notes) such as
>> whether  to do something more drastic to the draft (definitely not a lot
>> of support  for drastic changes at this point) or whether to do nothing.
>> Please add  your 2 cents to this discussion (a clear vote, for example,
>> or some  considerations we missed) but please do read the meeting notes
>> first.  If  that's unclear please ask questions while the meeting is
>> still fresh in  the memories of the attendees, or check also the jabber
>> log
>
> My proposal for this would be the following:
>
> Add a new [ANNOTATELEVEL xxx] response code to the SELECT/EXAMINE  
> commands, where xxx can be one of:
>
>     NONE    - annotations are not supported on this mailbox
>     PRIVATE - only private annotations are supported on this mailbox
>     SHARED  - only shared annotations are supported on this mailbox
>     BOTH    - both private and shared annotations are supported
>
> Note that the NONE option will replace the current [ANNOTATIONSIZE NIL]  
> which is used to indicate lack of support for annotations.
>
> I believe this is a better solution than using separate CAPABILITY's. As  
> we have already recognized, there is a need to have a per-mailbox  
> indicator for annotation support because some mailbox formats may be  
> able to support them and others not. I see the issue of only supporting  
> one or other of private and shared as being along the same lines.
>

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Date: Tue, 9 Aug 2005 12:23:30 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Lisa Dusseault <[email-masked]>, IMAP WG <[email-masked]>
Subject: Re: Confirm consensus on Annotate revision
Organization: Networks & Distributed Computing
Sender: [email-masked]

Cyrus' proposal seems like a good idea to me.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Tue, 09 Aug 2005 15:10:46 -0400
From: Cyrus Daboo <[email-masked]>
To: Lisa Dusseault <[email-masked]>, IMAP WG <[email-masked]>
Subject: Re: Confirm consensus on Annotate revision
Sender: [email-masked]

Hi Lisa,

--On August 8, 2005 6:25:07 PM -0700 Lisa Dusseault 
<[email-masked]> wrote:

> We discussed a number of options (check the meeting notes) such as
> whether  to do something more drastic to the draft (definitely not a lot
> of support  for drastic changes at this point) or whether to do nothing.
> Please add  your 2 cents to this discussion (a clear vote, for example,
> or some  considerations we missed) but please do read the meeting notes
> first.  If  that's unclear please ask questions while the meeting is
> still fresh in  the memories of the attendees, or check also the jabber
> log

My proposal for this would be the following:

Add a new [ANNOTATELEVEL xxx] response code to the SELECT/EXAMINE commands, 
where xxx can be one of:

    NONE    - annotations are not supported on this mailbox
    PRIVATE - only private annotations are supported on this mailbox
    SHARED  - only shared annotations are supported on this mailbox
    BOTH    - both private and shared annotations are supported

Note that the NONE option will replace the current [ANNOTATIONSIZE NIL] 
which is used to indicate lack of support for annotations.

I believe this is a better solution than using separate CAPABILITY's. As we 
have already recognized, there is a need to have a per-mailbox indicator 
for annotation support because some mailbox formats may be able to support 
them and others not. I see the issue of only supporting one or other of 
private and shared as being along the same lines.

-- 
Cyrus Daboo

Date: Tue, 09 Aug 2005 12:00:16 +0100
From: Alexey Melnikov <[email-masked]>
To: Lisa Dusseault <[email-masked]>
CC: IMAP WG <[email-masked]>
Subject: Re: Proceedings for IMAPEXT meeting at IETF 63
Sender: [email-masked]

Lisa Dusseault wrote:

> Here are the notes and the slides from the IMAPEXT meeting last week.
>
> Notes:
> http://ietf.webdav.org/imapext/notes/IETF63-imapext-notes.txt

Some editorial/clarifying comments for the notes below:

> There's a suggestion to extend the grammar such that we can later include
> "max 100" blah, but the change makes the grammar much more complex.

I was talking about LIST paged results, i.e. the client ask "return me 
the first 100 mailboxes", later on it can ask "return the next 100", etc.

> Dave as
> client developer was in favour, Arnt was against until there are two good
> reasons. Alexey mentioned IMAPABNF, I didn't really get the point.

I think I've mentioned that it might be better if extended LIST ABNF is 
moved to IMAPABNF draft. For example, ACL2 might use extended LIST 
responses, without the need to require the servers to implement 
LIST-EXTENDED. But this is a separate issue to allowing option 
parameters in LIST.

I've also said that I would hate to do an extension to LIST extension.

> Food for
> thought, he said. Tony Hansen cautioned against painting ourselves into
> a corner.
>  
> Barry doesn't feel that he has guidance yet, just incidental opinions. 
> Arnt
> emphasizes that give two good reasons, etc. Chris proposes erring on the
> side of complexity, since we've had to many too-limited list 
> extensions in
> the past.

I think we had a weak consensus that extended LIST should allow for 
options. Chris' argument was very convincing, at least for me.

> Interaction of REMOTE and RECURSIVEMATCH. Alexey: Would it be reasonable
> to return all mailboxes that might have remote children? Tricky 
> discussion
> ensues - is it a no-op or not?

The question is what should the server that doesn't support any remote 
mailboxes do.
REMOTE is not "return only remote mailboxes", it is "return all local + 
remote mailboxes". So REMOTE RECURSIVE might be a bit counter intuitive, 
because it doesn't answer the question "all mailboxes with remote children".

> Scribe is not alone being puzzled. Document
> needs clarification. Dave will provide some text.
>  
> Currently, the CHILDINFO works like this: If the parent matches the
> pattern and the child the other requirement,

"the child doesn't match the pattern, but matches the selection criteria."

> the parent with CHILDINFO
> is returned. Is that what clients need? Phillip explains RECURSIVEMATCH:
> Clients want to find something, and doesn't want to use LIST *.
>  
> Barry shows parent-child relationships on a way he eventually explains.
> Revision will ensue, and will be reviewed by people who don't get it. New
> revision Aug 19, then probably WGLC.
>  
> ANNOTATE: Brief agreement that we don't need another WGLC. We'll push 
> it on.
>  
> IMAP ABNF:
>  
>  - purpose: use of common syntax for all extension elements
>    (refactoring)
>  - which extended commands should be listed (suggestion to add CREATE
>    and maybe ESEARCH response)
>  - discussion about wording requirements on future documents
>  
> Alexey has noted similar but different ABNF in several extensions, and
> wants that to be the same. Much silence in room. Arnt spoke in favour,
> saying we now have the experience to write such a document. Lisa
> suggests it's suitable individual submission and can be discussed on
> the list.

I've also clarified that consistent syntax doesn't change any existing 
extension, it just make grammar more permissive in certain cases. This 
should only affect future extensions.

>
> Alexey suggests adding ESEARCH to IMAP ABNF. Noone seems to understand
> the implications.

There are several extensions to SEARCH that need to be compatible with 
each others:
1). "IMAP extension for referencing the last SEARCH result" 
(draft-melnikov-imap-search-res-02.txt)
2). "IMAP4 extension to SEARCH command for controlling what kind of 
information is returned" (draft-melnikov-imap-search-ret-01.txt)

Also, CONDSTORE extends SEARCH response, in the future it probably 
should also use ESEARCH response as well.

>  
> Hairsplitting over draft names. It's good to name things clearly enough
> that grep can find it. It's also good to mention thing on lemonade, since
> a small group of people are paying attention there.
>  
> COMPARATOR and stuff: comparator is lost, can WG adopt? (Script edits
> that now.) Adoption carries. Phillip, Barry will review. Tony too. No
> rename is required. Arnt will submit with the right bullet, including
> Dave's comments.
>  
> Tony likes comparator, thinks it's close.
>  
> Lisa asks about who implements Annotate. Arnt, Dave, who else?
>  
> Annotatemore and annotate: Depend on each other? Dave says amore has

typo: annotatemore

> been deployed, annotate not. 

[...]

Date: Mon, 8 Aug 2005 18:39:40 -0700 (Pacific Daylight Time)
From: Mark Crispin <[email-masked]>
To: Lisa Dusseault <[email-masked]>
cc: IMAP WG <[email-masked]>
Subject: Re: Confirm consensus on Annotate revision
Organization: Networks & Distributed Computing
Sender: [email-masked]

I agree with the expressed sentiment that the implementation cost of the 
current ANNOTATE specification is too steep.  I do not wish to belabor the 
point, but I have expressed reservations in the past on the question of 
driving the design of IMAP extensions without adequate concern for server 
implementation considerations.

I support the idea of reducing/simplifying the ANNOTATE specification, 
with the goal of making server implementors feel less uncomfortable about 
the implementation cost.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Mon, 08 Aug 2005 18:25:07 -0700
To: "IMAP WG" <[email-masked]>
Subject: Confirm consensus on Annotate revision
From: "Lisa Dusseault" <[email-masked]>
Organization: OSAF
Sender: [email-masked]

I just sent the meeting notes to the list and to proceedings -- thanks  
Arnt for taking notes (and thanks Chris for being the jabber scribe).

The notes reminded me that we need to confirm the consensus we detected in  
the meeting to do a new version of the annotate draft, adding:
  - how a IMAP server may support shared annotations only (a per-folder  
response code, wasn't it?)
  - how an IMAP client may detect that
  - possibly some advice on whether it's appropriate for a client that  
would prefer to use private annotations to fall back to public annotations  
if that's all that the server supports

The impetus for this idea was that we noticed that hardly any IMAP servers  
planned to add support for annotations.  Most of the planned implementors  
were clients yet all the clients admitted that they were hoping for server  
implementations to come out first.  We polled server implementors a bit  
and the general impression was that the implementation cost, particularly  
for private annotations, was just too steep.  The client implementors in  
the room seemed to feel that a less ideal feature (shared annotations  
only) would still be useful.

We discussed a number of options (check the meeting notes) such as whether  
to do something more drastic to the draft (definitely not a lot of support  
for drastic changes at this point) or whether to do nothing.  Please add  
your 2 cents to this discussion (a clear vote, for example, or some  
considerations we missed) but please do read the meeting notes first.  If  
that's unclear please ask questions while the meeting is still fresh in  
the memories of the attendees, or check also the jabber log

http://www.xmpp.org/ietf-logs/[email-masked]/2005-08-03.html

thx,

Lisa

Date: Mon, 08 Aug 2005 18:16:11 -0700
To: "IMAP WG" <[email-masked]>, [email-masked]
Subject: Proceedings for IMAPEXT meeting at IETF 63 
From: "Lisa Dusseault" <[email-masked]>
Organization: OSAF
Sender: [email-masked]

Here are the notes and the slides from the IMAPEXT meeting last week.

Notes:
http://ietf.webdav.org/imapext/notes/IETF63-imapext-notes.txt

Slides
http://ietf.webdav.org/imapext/presentations/imapext-ietf63.ppt

Lisa

Date: Fri, 5 Aug 2005 01:28:12 +0200 (CEST)
From: "RL 'Bob' Morgan" <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Les amis du IMAPext
Sender: [email-masked]

Before:

   http://bobmorgan.org/pix/displayimage.php?album=5&pos=15

and during:

   http://bobmorgan.org/pix/displayimage.php?album=5&pos=16

a hardworking IETF dinner at which great progress was made settling many 
important issues, concerning which a full report will be issued at some 
later date (assuming someone was taking notes).

  - RL "Bob"

Date: Thu, 4 Aug 2005 13:29:52 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: ANNOTATEMORE
Sender: [email-masked]

On Thu, 4 Aug 2005, Cyrus Daboo wrote:
> The original thread on this was from June this year, and I have not updated 
> ANNOTATEMORE since then as I wanted to finish of ANNOTATE WGLC issues first. 
> However, your comment of string vs astring is also pertinent to ANNOTATE. 
> Only yourself and Phillip made any comment about this. Does anyone else have 
> an opinion? I am ambivalent myself. I think doing this change in ANNOTATE 
> post-WGLC is OK, but it will mean changing all the examples to remove 
> unnecessary quoting.

It isn't particularly necessary to change all the examples.  However, I 
feel that this change should be done as soon as possible.

It may also be necessary to change the capability name, if there are 
deployed servers that enforce string instead of astring.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Thu, 04 Aug 2005 16:27:45 -0400
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: ANNOTATEMORE
Sender: [email-masked]

Hi Mark,

--On Thursday, August 04, 2005 13:06 -0700 Mark Crispin 
<[email-masked]> wrote:

> I see that the ANNOTATEMORE draft still uses string instead of astring.
>
> I thought that we agreed to fix this.

The original thread on this was from June this year, and I have not updated 
ANNOTATEMORE since then as I wanted to finish of ANNOTATE WGLC issues 
first. However, your comment of string vs astring is also pertinent to 
ANNOTATE. Only yourself and Phillip made any comment about this. Does 
anyone else have an opinion? I am ambivalent myself. I think doing this 
change in ANNOTATE post-WGLC is OK, but it will mean changing all the 
examples to remove unnecessary quoting.

-- 
Cyrus Daboo

Date: Thu, 4 Aug 2005 13:06:14 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: ANNOTATEMORE
Sender: [email-masked]

I see that the ANNOTATEMORE draft still uses string instead of astring.

I thought that we agreed to fix this.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

Date: Thu, 04 Aug 2005 13:23:11 +0100
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: what I forgot while taking notes
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Alexey Melnikov writes:
>
>> I think you have missed the point. The drafts suggest transient 
>> capabilities that can be use by implementations to *play* with a 
>> particular extension while it still being developed. The transient 
>> capabilities must not be used once a draft becomes an RFC.
>
>
> I understand the purpose of the document. I don't understand why the 
> document needs to standardize anything to do with X-, and when in 
> doubt, I think an RFC should not standardize _anything_ to do with X-.
>
> What would make "X-DRAFT-number-name" better for the purpose than, 
> say, "INTERNET-DRAFT-number-name"?

Ah, I think I might be getting your point now.
My reading of RFC 3501 is that "X" prefix is reserved for private use. 
I've decided to use a part of this namespace for experimentation purposes.
It might be too late to use a different prefix for that, as I think this 
will require an update to RFC 3501.

Date: Thu, 4 Aug 2005 12:39:16 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Dinner tonight
Sender: [email-masked]

Hi,

dinner is at the Îlot Vache. We gather in the Concord (Concorde? don't 
know. don't stay there) lobby at eight, then go by Metro to l'Îlot 
Vache.

www.ilotvache.com is a fabulously bad web site. There is no reason at 
all to look at it.

(Should anyone wish to go there by themselves, the closest Metro station 
is Pont-Marie. Cross the bridge from the Pont Marie exit, go one block 
onwards, and you'll find yourself on the only street intersection worth 
speaking of. The "resto" is there.)

Arnt

To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked], Philip Guenther <[email-masked]>, Mark Crispin <[email-masked]>
Subject: Re: what I forgot while taking notes 
Date: Thu, 04 Aug 2005 03:33:27 -0700
From: Philip Guenther <[email-masked]>
Sender: [email-masked]

Arnt Gulbrandsen <[email-masked]> writes:
>Even at one remove, X- in an RFC makes me feel bad. There have been too 
>many threads on too many mailing lists in the past decade where too 
>many people have invoked too many bad arguments to standardize 
>X-something-or-other. I just want to stay away from that whole area.

RFC 3501 makes a requirement about using 'X' in capability name.  I see
the draft as making it more obvious that that requirement _often_
applies to early and intermediate I-Ds and then provides a specific
recommendation for how drafts can meet that requirement.  I believe the
experience with LISTEXT supports that this is a problem worth
documenting and giving direction on.

Philip Guenther

Date: Thu, 4 Aug 2005 12:19:59 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: what I forgot while taking notes
Cc: Alexey Melnikov <[email-masked]>
Sender: [email-masked]

Alexey Melnikov writes:
> I think you have missed the point. The drafts suggest transient 
> capabilities that can be use by implementations to *play* with a 
> particular extension while it still being developed. The transient 
> capabilities must not be used once a draft becomes an RFC.

I understand the purpose of the document. I don't understand why the 
document needs to standardize anything to do with X-, and when in 
doubt, I think an RFC should not standardize _anything_ to do with X-.

What would make "X-DRAFT-number-name" better for the purpose than, say, 
"INTERNET-DRAFT-number-name"?

Arnt

Date: Thu, 04 Aug 2005 11:15:43 +0100
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: what I forgot while taking notes
Sender: [email-masked]

Arnt Gulbrandsen wrote:

>> Even though such are technically permitted, I think that standardized 
>> capabilities should eschew names starting with "X".
>
> I agree. However, that's not what the draft does. The draft 
> standardizes a name pattern for not-yet-standard capabilities, it does 
> not standardize a capability itself.
>
> Even at one remove, X- in an RFC makes me feel bad. There have been 
> too many threads on too many mailing lists in the past decade where 
> too many people have invoked too many bad arguments to standardize 
> X-something-or-other. I just want to stay away from that whole area.

I think you have missed the point. The drafts suggest transient 
capabilities that can be use by implementations to *play* with a 
particular extension while it still being developed. The transient 
capabilities must not be used once a draft becomes an RFC.

A recent example why this is useful: there are 3 existing servers 
implementing LISTEXT. They all implement different revisions of the 
draft, which results in implementing different syntaxes. Obviously no 
client can work without all three of them just by looking at the capability.

Date: Thu, 4 Aug 2005 10:29:57 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: what I forgot while taking notes
Cc: Philip Guenther <[email-masked]>, Mark Crispin <[email-masked]>
Sender: [email-masked]

Mark Crispin writes:
> However, as a matter of practicality, this is a difference that does 
> not make a difference.

Agreed.

> Even though such are technically permitted, I think that standardized 
> capabilities should eschew names starting with "X".

I agree. However, that's not what the draft does. The draft standardizes 
a name pattern for not-yet-standard capabilities, it does not 
standardize a capability itself.

Even at one remove, X- in an RFC makes me feel bad. There have been too 
many threads on too many mailing lists in the past decade where too 
many people have invoked too many bad arguments to standardize 
X-something-or-other. I just want to stay away from that whole area.

Arnt

Date: Thu, 4 Aug 2005 00:09:12 -0700 (PDT)
From: Mark Crispin <[email-masked]>
To: Philip Guenther <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: what I forgot while taking notes 
Sender: [email-masked]

On Wed, 3 Aug 2005, Philip Guenther wrote:
> Arnt Gulbrandsen <[email-masked]> writes:
>> The capability name draft has a bit of a problem, in that it specifies
>> that which Shall Not Be Specified, namely X-blah.
> Actually, RFC 3501 doesn't say that capabilities that being with 'X'
> must be unstandardized, but rather the converse, that unstandardized
> capabilities must begin with an 'X'.  The capability name draft is
> therefore not in conflict with RFC 3501.

However, as a matter of practicality, this is a difference that does not 
make a difference.

Even though such are technically permitted, I think that standardized 
capabilities should eschew names starting with "X".

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked]
From: Philip Guenther <[email-masked]>
Subject: Re: what I forgot while taking notes 
Date: Wed, 03 Aug 2005 21:24:12 -0700
Sender: [email-masked]

Arnt Gulbrandsen <[email-masked]> writes:
>The capability name draft has a bit of a problem, in that it specifies 
>that which Shall Not Be Specified, namely X-blah.

Actually, RFC 3501 doesn't say that capabilities that being with 'X'
must be unstandardized, but rather the converse, that unstandardized
capabilities must begin with an 'X'.  The capability name draft is
therefore not in conflict with RFC 3501.

Philip Guenther

Date: Wed, 3 Aug 2005 13:54:25 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: what I forgot while taking notes
Sender: [email-masked]

Rereading the drafts yesterday, a few smallish things cropped up that I 
meant to mention today but forgot because I was taking notes all the 
time. Oops. Blame it on my newbie status.

The capability name draft has a bit of a problem, in that it specifies 
that which Shall Not Be Specified, namely X-blah. A Lemonade draft 
squeezed through doing that, and I guess specifying an X-blah naming 
scheme might too, but it _is_ borderline. My guess is that 
INTERNET-DRAFT-<capability>-<number> might pass IESG scrutiny more 
easily than X-DRAFT-ditto.

For the rest I'll send private mail to the editors, now or when I next review.

Arnt

Date: Tue, 2 Aug 2005 19:36:55 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: resurrected COMPRESS=DEFLATE draft
Cc: IMAP WG <[email-masked]>
Sender: [email-masked]

---
Content-Type: text/plain; format=flowed

Hi,

a couple of hallway discussions at IETF63 resulted in a resurrection of 
this old draft. I think I've updated it with whatever boilerplate is 
now required.

Please post it to the drafts directory when that is again permitted.

Arnt

---
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=utf-8
Content-Disposition: attachment; size=9295;
  filename=draft-gulbrandsen-imap-deflate-01.txt

Network Working Group                                   Arnt Gulbrandsen
Request for Comments: DRAFT                                         Oryx
draft-gulbrandsen-imap-deflate-01.txt                        August 2005

                  The IMAP COMPRESS=3DDEFLATE extension

Status of this Memo

    By submitting this Internet-Draft, each author represents that any
    applicable patent or other IPR claims of which he or she is aware
    have been or will be disclosed, and any of which he or she becomes
    aware will be disclosed, in accordance with Section 6 of BCP 79.

    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups.  Note that
    other groups may also distribute working documents as Internet-
    Drafts.

    Internet-Drafts are draft documents valid for a maximum of six
    months and may be updated, replaced, or obsoleted by other documents
    at any time.  It is inappropriate to use Internet-Drafts as
    reference material or to cite them other than as "work in progress."

    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/ietf/1id-abstracts.txt.  The list of Internet-
    Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.

Copyright Notice

    Copyright (C) The Internet Society 2005.  All Rights Reserved.

Abstract

    The COMPRESS=3DDEFLATE extension allows an IMAP connection to be
    compressed using the DEFLATE algorithm, such that effective
    compression is available even when TLS is used.

Conventions Used in This Document

    The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD
    NOT", and "MAY" in this document are to be interpreted as described
    in "Key words for use in RFCs to Indicate Requirement Levels"

Gulbrandsen               Expires February 2006         	[Page 1]
=0C
Internet-draft                                               August 2005

    [KEYWORDS]. Formal syntax is defined by [ABNF] as modified by
    [IMAP].

    In the example, "C:" and "S:" indicate lines sent by the client and
    server respectively.

Introduction and Overview

    An IMAP server that supports this extension announces
    "COMPRESS=3DDEFLATE" as one of its capabilities.

    The goal of COMPRESS=3DDEFLATE is to reduce the bandwidth usage of
    IMAP.  On regular IMAP connections, the PPP or MNP compression used
    with many low-bandwidth links compresses IMAP well. However, when
    TLS is used, PPP/MNP compression is ineffective. TLS too can provide
    compression, but currently few or no implementations do so in
    practice.

    In order to increase interoperation, it is desirable to have as few
    different compression algorithms as possible, so this document
    specifies only one.  The DEFLATE algorithm is standard, widely
    available, unencumbered by patents and fairly efficient.  Hopefully
    it will not be necessary to define additional algorithms.

    The extension adds one new command (COMPRESS) and no new responses.

The COMPRESS Command

    Arguments: Name of compression mechanism: "DEFLATE".

    Responses: None

    Result: OK    The server will compress its responses and expects the
                  client to compress its commands.
            NO    The connection already is compressed, or the server doesn=
't
                  support the requested mechanism.
            BAD   Command unknown or invalid argument.

    The COMPRESS command instructs the server to use the named
    compression mechanism ("DEFLATE" is the only one defined) for future
    commands and responses.

    For DEFLATE (as for many other compression mechanisms), the
    compressor can trade speed against quality.  When decompressing
    there isn't much of a tradeoff.  Consequently, the client and server
    are both free to pick the best reasonable rate of compression for

Gulbrandsen               Expires February 2006         	[Page 2]
=0C
Internet-draft                                               August 2005

    the data they send.

    The client MUST NOT send additional commands until it has seen the
    result of COMPRESS.

    If the client wants to use both TLS and compression, it SHOULD send
    STARTTLS before COMPRESS.

Example

    This example shows a simple login sequence. The client uses TLS for
    privacy and DEFLATE for compression.

         S: * OK [CAPABILITY IMAP4REV1 STARTTLS COMPRESS=3DDEFLATE]
         C: a starttls
         S: a OK
         C: b compress deflate
         S: b OK
         C: c login arnt tnra
         S: c OK

Implementation Notes

    When using the zlib library (see [DEFLATE]), the functions
    deflateInit(), deflate(), inflateInit() and inflate() suffice to
    implement this extension.

    Note that when using TLS, compression may actually decrease the CPU
    usage, depending on which algorithms are used in TLS. This is
    because fewer bytes need to be encrypted, and encryption is
    generally more expensive than compression.

Formal Syntax

    The following syntax specification uses the Augmented Backus-Naur
    Form (ABNF) notation as specified in [ABNF]. Non-terminals
    referenced but not defined below are as defined by [ABNF] (SP, CRLF)
    or [IMAP] (all others).

    Except as noted otherwise, all alphabetic characters are case-
    insensitive.  The use of upper or lower case characters to define
    token strings is for editorial clarity only.  Implementations MUST
    accept these strings in a case-insensitive fashion.

        command-any =3D/ compress

Gulbrandsen               Expires February 2006         	[Page 3]
=0C
Internet-draft                                               August 2005

        compress    =3D "COMPRESS" SP astring

Security considerations

    The proposed extension does not cause any security problems. It may
    marginally reduce the scope for plaintext attacks when used together
    with [TLS].

Credits

    (Your name here :)

References

    [ABNF]     Crocker, Overell, "Augmented BNF for Syntax
               Specifications: ABNF", RFC 2234, Internet Mail
               Consortium, Demon Internet Ltd, November 1997.

    [IMAP]     Crispin, M., "Internet Message Access Protocol - Version
               4rev1", RFC 3501, University of Washington, June 2003.

    [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
               Requirement Levels", RFC 2119, Harvard University, March
               1997.

    [DEFLATE]  Deutsch, P., "DEFLATE Compressed Data Format
               Specification version 1.3", RFC 1951, Aladdin
               Enterprises, May 1996.

    [STARTTLS] Newman, C. "Using TLS with IMAP, POP3 and ACAP", RFC
               2595, June 1999.

Author's Address

    Arnt Gulbrandsen
    Oryx Mail Systems GmbH
    Schweppermannstr. 8
    D-81671 Muenchen
    Germany

    Phone: +49 89 45029757
    Fax: +49 89 45029758

    Email: [email-masked]

Gulbrandsen               Expires February 2006         	[Page 4]
=0C
Internet-draft                                               August 2005

Intellectual Property Statement

    The IETF takes no position regarding the validity or scope of any
    Intellectual Property Rights or other rights that might be claimed to
    pertain to the implementation or use of the technology described in
    this document or the extent to which any license under such rights
    might or might not be available; nor does it represent that it has
    made any independent effort to identify any such rights.  Information
    on the procedures with respect to rights in RFC documents can be
    found in BCP 78 and BCP 79.

    Copies of IPR disclosures made to the IETF Secretariat and any
    assurances of licenses to be made available, or the result of an
    attempt made to obtain a general license or permission for the use of
    such proprietary rights by implementers or users of this
    specification can be obtained from the IETF on-line IPR repository at
    http://www.ietf.org/ipr.

    The IETF invites any interested party to bring to its attention any
    copyrights, patents or patent applications, or other proprietary
    rights that may cover technology that may be required to implement
    this standard.  Please address the information to the IETF at
    [email-masked].

Disclaimer of Validity

    This document and the information contained herein are provided on an
    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

    Copyright (C) The Internet Society (2005).  This document is subject
    to the rights, licenses and restrictions contained in BCP 78, and
    except as set forth therein, the authors retain all their rights.

Acknowledgment

    Funding for the RFC Editor function is currently provided by the
    Internet Society.

Gulbrandsen               Expires February 2006         	[Page 5]
=0C
-----

Date: Tue, 02 Aug 2005 11:35:36 -0400
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: ANNOTATE - changes after WGLC
Sender: [email-masked]

--==========5AB1D041A75424375570==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi folks,
In preparation for tomorrow's meeting, attached is a text document that 
shows the WGLC comments for the ANNOTATE draft that I extracted from the 
mailing list (all of which were addressed in the new revision) together 
with the actual 'changes' section for the new revision.

-- 
Cyrus Daboo
--==========5AB1D041A75424375570==========
Content-Type: text/plain; charset=us-ascii; name="Paris Changes"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="Paris Changes"; size=4738

ANNOTATE WGLC ISSUES FROM MAILING LIST:

+  Sync with change from DC meeting wrt 'r' right for both read and
write of .priv
+  Add text about 'n' right being a 'shared flag right' as defined in
2086upd
+  Allow NIL in /<section-part>/flags entries
+  Expand abstract to also indicate that annotations can apply on a
per-body part basis as well as per message
+  Fix resp-text-code to use nil instead of "NIL"
+  Use double-quotes conistently around ANNOTATESIZE etc
+  Fix typos: tyhe->the, UTF8->UTF-8, utf8->utf-8
+  Remove redundant second para of Introduction
+  Missing 'Conventions' section with RFC2119 reference
+  Describe S:, C: example behaviour in conventions section
+  Clarify that new rights must also be present if only old ACL is
present
+  Entry/attributes MUST NOT contain consecutive or trailing /
+  Clarify default charset for content-type text/plain
+  Recommend use of utf-8 for all non-ascii text
+  Clarify terminology of ANNOTATESIZE response code
+  Clarify behaviour if server does not return ANNOTATESIZE - MUST for
ANNOTATESIZE response
+  Change an example to use UID FETCH for variety
+  Clarify what to do about annotations exceeding allowed ANNOTATESIZE
when doing copy
+  Simplified select-param formal syntax - reference Alexey's document
+  Remove RFC1891 reference
+  capability syntax extension

Open Issues:

+  Dealing with content-type attribute: should servers validate the
value? - A: reference 2046

+  Should entry registration include a default content-type value? - A:
use recommended content-type in IANA registration.

+  Can values contain 'binary' data (i.e. possibly contain NULLs)?
There is no content-encoding so that is a possibility, in which case a
literal8 syntax element from the BINARY extension needs to be used, or a
new equivalent defined. - A: Alexey will extract literal8, ANNOTATE will
use that.

+  Should we restrict attribute names to exclude priv and shared
anywhere in the text? - A: ban 'shared' and 'priv' as separate hierarchy
elements.

+ UTF-8 entry/attribute names - lunch bof proposal to restrict to ascii
is fine by me - can we get WG consensus for that? - A: restrict
entry/attribute names - define displayname attribute

+  CATENATE has changed substantially since current ANNOTATE draft
reference. Now CATENATE is an extension to APPEND, so ANNOTATE only
needs to extend APPEND in a compatible way with CATENATE. I want to
reference Alexey's draft-melnikov-imap-ext-abnf-00 for that - CATENTATE
should do the same. - OK go ahead.

ACTUAL CHANGES IN DRAFT

 Changes from -12 to -13:
   1.  Sync with change from DC meeting wrt 'r' right for both read and
        write of .priv.
   2.  Add text about 'n' right being a 'shared flag right' as defined
        in 2086upd.
   3.  Allow NIL in /<section-part>/flags entries.
   4.  Expand abstract to also indicate that annotations can apply on a
        per-body part basis as well as per message.
   5.  Fix resp-text-code to use nil instead of "NIL".
   6.  Use double-quotes consistently around ANNOTATESIZE etc.
   7.  Fix typos.
   8.  Remove redundant second para of Introduction.
   9.  Added 'Conventions' section with RFC2119 reference..
   10.  Describe S:, C: example behaviour in conventions section..
   11.  Clarify that new rights must also be present if only old ACL is
        present.
   12.  Entry/attributes MUST NOT contain consecutive or trailing '/' or
        '.'.
   13.  Clarify default charset for content-type text/plain.
   14.  Recommend use of utf-8 for all non-ascii text.
   15.  Clarify terminology of ANNOTATESIZE response code.
   16.  Require servers to return ANNOTATESIZE on SELECT.
   17.  Change an example to use UID FETCH for variety.
   18.  Clarify what to do about annotations exceeding allowed
        ANNOTATESIZE when doing copy.
   19.  Use ABNFext document for extended SELECT etc.
   20.  Remove RFC1891 reference.
   21.  capability syntax extension.
   22.  Comment on validation content-type attribute.
   23.  Added recommended content-type in IANA registration.
   24.  Added use of literal8 for values.
   25.  Prevent use of 'shared' and 'priv' as separate hierarchy
        components.
   26.  Restrict entry/attribute names to ascii and added display-name
        attribute.
   27.  Remove references to CATENATE and use ABNFext for extended
        APPEND syntax.

--==========5AB1D041A75424375570==========--

Date: Tue, 2 Aug 2005 17:22:28 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Agenda for IMAPEXT WG meeting
Sender: [email-masked]

Lisa Dusseault writes:
> 20 min -- Adopting draft-newman-i18n-comparator in WG - Chris, Arnt
>  - Blocks draft-ietf-imapext-sort AND draft-ietf-imapext-i18n
>  - Therefore also blocks draft-ietf-annotate AND imapext-condstore AND 
>   individual submissions
>  - Arnt volunteered to edit, I volunteer to shepherd, WG reviews -- 
>  what  does WG think?

You will note that while I volunteered to do and Lisa volunteered to do, 
you just do. So please read that draft before tomorrow, OK? ;)

And also imapext-i18n, since the two are fairly tightly bound.

Arnt

Cc: "[email-masked]" <[email-masked]>
To: "IMAP WG" <[email-masked]>
Subject: Agenda for IMAPEXT WG meeting
Date: Tue, 02 Aug 2005 16:45:19 +0200
From: "Lisa Dusseault" <[email-masked]>
Organization: OSAF
Sender: [email-masked]

IMAPEXT is meeting tomorrow, 1030 Paris time in room 341 for 2 hours.   
These are the drafts you should
have read because they're working group drafts:

https://datatracker.ietf.org/public/idindex.cgi?command=show_wg_id&id=1409
  especially draft-ietf-imapext-annotate-13
             draft-ietf-imapext-list-extensions-13

In addition there are some individual contributions you should be aware of  
and ideally have read:
  - http://www.ietf.org/internet-drafts/draft-melnikov-imap-ext-abnf-02.txt
  - http://www.ietf.org/internet-drafts/draft-newman-i18n-comparator-04.txt

Agenda:

10 min -- Issues remaining with ListExt - Barry, Alexey
  - quick review of LIST-EXTENDED extensibility
  - interaction of REMOTE with RECURSIVEMATCH
  - are there any other issues that need to be addressed?
20 min -- next steps on ANNOTATE -- Randy, Cyrus
  - Do we need to redo WG last call?
  - Authors need to summarize changes since WG last call so that WG can  
decide this
20 min -- Issues remaining with IMAPABNF  
(draft-melnikov-imap-ext-abnf-02.txt)
  - use of common syntax for all extension elements
  - which extended commands should be listed (suggestion to add CREATE and  
maybe ESEARCH response)
  - discussion about wording requirements on future documents
20 min -- Adopting draft-newman-i18n-comparator in WG - Chris, Arnt
  - Blocks draft-ietf-imapext-sort AND draft-ietf-imapext-i18n
  - Therefore also blocks draft-ietf-annotate AND imapext-condstore AND  
individual submissions
  - Arnt volunteered to edit, I volunteer to shepherd, WG reviews -- what  
does WG think?

To: "Arnt Gulbrandsen" <[email-masked]>, [email-masked]
Subject: Re: Agenda so far...
Date: Mon, 01 Aug 2005 11:58:02 +0200
From: "Lisa Dusseault" <[email-masked]>
Organization: OSAF
Sender: [email-masked]

Yes to both!

Are you here in Paris already?  I'd like to run through with you some time  
what we're going to discuss on the comparator draft Weds.  I walked around  
and twisted a few arms this morning:
  - Barry Lieba, Randy Gellens and Philip Guenther to read draft and  
comment on any open issues
  - Chris Newman to sit down with us and actually work on the draft if we  
need that during this week

A good way to get in touch with me this week is using IM.  If you use AIM  
I'm "LisaDusseault" or if you use Jabber I'm  
"[email-masked]".  I also have some other IDs if necessary.

Lisa

On Sun, 31 Jul 2005 11:57:40 +0200, Arnt Gulbrandsen  
<[email-masked]> wrote:

>
> Lisa Dusseault writes:
>> If there are any additions, Pete will have to submit to  
>> [email-masked]  because i'm about to go on vacation (in Paris,  
>> naturally) until Jul 31.
>
> Had a fine vacation? Lots of mail to catch up on now that the IETF  
> starts?
>
> Arnt
>

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Date: Sun, 31 Jul 2005 11:57:40 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Agenda so far...
Sender: [email-masked]

Lisa Dusseault writes:
> If there are any additions, Pete will have to submit to 
> [email-masked]  because i'm about to go on vacation (in Paris, 
> naturally) until Jul 31.

Had a fine vacation? Lots of mail to catch up on now that the IETF starts?

Arnt