Subject: WG Action: Conclusion of Internet Message Access Protocol Extension (imapext)
From: The IESG <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Date: Tue, 17 Jun 2008 09:45:01 -0700 (PDT)
List-Id: IETF Announcements <ietf-announce.ietf.org>

The Internet Message Access Protocol Extension (imapext) working group in
the Applications Area has concluded.

The IESG contact persons are Lisa Dusseault and Chris Newman.

The mailing list will remain active.
_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf-announce

From: The IESG <[email-masked]>
To: [email-masked]
Subject: WG Action: Conclusion of Internet Message Access Protocol  Extension (imapext) 
Date: Tue, 17 Jun 2008 09:45:01 -0700 (PDT)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

The Internet Message Access Protocol Extension (imapext) working group in
the Applications Area has concluded.

The IESG contact persons are Lisa Dusseault and Chris Newman.

The mailing list will remain active.
_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf-announce

From: The IESG <[email-masked]>
To: [email-masked]
Subject: WG Action: Conclusion of Internet Message Access Protocol  Extension (imapext) 
Date: Tue, 17 Jun 2008 09:45:01 -0700 (PDT)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

The Internet Message Access Protocol Extension (imapext) working group in
the Applications Area has concluded.

The IESG contact persons are Lisa Dusseault and Chris Newman.

The mailing list will remain active.
_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf-announce

Date: Fri, 20 Jun 2008 19:35:33 +0100
From: Alexey Melnikov <[email-masked]>
To: Phil Pennock <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: IANA-registered vendor subtree (RFC2244)
Sender: [email-masked]

Hi Phil,

Phil Pennock wrote:

>The "vendor subtree" for ACAP, establishing a textual namespace for
>components in hierarchical metadata, has the registry of assignments at:
>
>  http://www.iana.org/assignments/acap-registrations
>
>This RFC 2244 data is also used by IMAP ANNOTATE (RFC 5257,
>experimental) and the ANNOTATEMORE/ANNOTATEMORE2/METADATA draft series
>(now: draft-daboo-imap-annotatemore-13.txt).
>
as well as RFC 5258.

>Given that ACAP has not been a success, is there a more up-to-date
>reference for valid syntax of these names, both for developers and as
>guidance to IANA?  As far as I can tell, four of the nine registrations
>are syntactically invalid and this appears to have arisen because of
>unfortunate labelling in RFC 2244.
>
If you are referring to the following text in section 4.1:

   The dataset namespace is a slash-separated hierarchy.  The first
   component of the dataset namespace is a dataset class.  Dataset
   classes MUST have a vendor prefix (vendor.<vendor/product>) or be
   specified in a standards track or IESG approved experimental RFC.
   See section 7.3 for the registration template.

then I agree it is unfortunate. The difference between 
vendor.<vendor/product> (i.e. vendor.<"vendor or product">) and 
vendor.<vendor>/<product> is a bit subtle.

>If there is a more up-to-date
>reference,
>
I am afraid not.

>or even if not, can guidance be provided to IANA?
>
Yes.

>What should happen about existing registrations?  I suspect that they can
>safely be truncated just before the invalid "/" and still provide a
>complete and consistent registry.
>
Your suggestion seems reasonable.
As a side not I would just note that people who would like to keep using 
"vendor.<vendor>/<product>" can still do that, because the structure of 
vendor specific namespace is up to the vendor.

>The vendor-token which has to be registered with IANA is described in
>RFC2244 as vendor.<vendor/product> which seems to have been interpreted
>as: "vendor." <vendor> "/" <product>
>Similarly, "vendor.<company/product name>." is used in section 7.4,
>which also makes it clear that all subtrees are covered by a given
>registration (leading to my belief that truncation in the existing
>registry is the correct approach).
>
>The ABNF in RFC2244 section 4.3 uses vendor-name twice and defines it:
>----------------------------8< cut here >8------------------------------
>   name-component  = 1*UTF8-CHAR
>                     ;; MUST NOT contain ".", "/", "%", or "*"
>[...]
>   vendor-name     = vendor-token *("." name-component)
>
>   vendor-token    = "vendor." name-component
>                     ;; MUST be registered with IANA
>----------------------------8< cut here >8------------------------------
>
>This ties in intuitively with the use of both "/" and "." as hierarchy
>separators by the various protocols using this registration.
>
>Furthermore, taken too literally, given the registration of
>vendor-token, the definition of vendor-token in RFC2244 and the
>reference to vendor-token in RFC5257, for a registration "vendor.foo" we
>would end up with IMAP annotation entries named "/vendor/vendor.foo/bar"
>when clearly what's intended is to end up with "/vendor/foo/bar".
>  
>
IMHO, I would suggest keep existing definitions in RFC5257 as is, unless 
there is a compelling reason to change.
I don't find "less ugly" to be a compelling reason in this case.

>Common sense makes it easy enough to pick out what is meant, but what is
>defined in ABNF in two RFCs doesn't match.
>
>With two RFCs and a draft on the way, what's the cleanest way to deal
>with this?
>
I think the best way is to publish a short draft that updates the vendor 
registry and makes it non-specific to ACAP.

Subject: Re: Implementation query: Read-only anonymous access
Date: Wed, 18 Jun 2008 17:50:13 +0100
From: Dave Cridland <[email-masked]>
To: Pete Resnick <[email-masked]>
Cc: IMAP Extensions <[email-masked]>
Sender: [email-masked]

On Wed Jun 18 17:05:31 2008, Pete Resnick wrote:
> 1. Are clients OK with connecting to a server with no login and  
> password?

Clients, by and large, don't really handle either IMAP URLs or  
anonymous access, but the users are usually smart enough to handle  
typing in "anonymous" as the username and any old thing as password,  
as long as the server can also do that hack.

> 2. Are clients good about keeping their own local flags if the  
> messages are read-only?

Keeping flag data locally isn't something I've considered before. I  
think some clients will always store read state (essentially \Seen)  
locally, even if they cannot propogate that to the server, but I'm  
not sure. I have seen some clients get really upset and throw toys  
from the pram when the STORE fails, though.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

Date: Wed, 18 Jun 2008 17:25:23 +0100
From: Alexey Melnikov <[email-masked]>
To: Pete Resnick <[email-masked]>
CC: IMAP Extensions <[email-masked]>
Subject: Re: Implementation query: Read-only anonymous access
Sender: [email-masked]

Pete Resnick wrote:

> Do folks know how well, if at all, clients handle read-only anonymous 
> access? Specifically, I'm wondering:
>
> 1. Are clients OK with connecting to a server with no login and password?

If you mean the client can omit the LOGIN command, then this is not 
allowed by IMAP.

Anonymous access is typically done in 1 of 2 ways: either the client 
authenticates with LOGIN "anonymous" "<anything>", or it uses 
AUTHENTICATE ANONYMOUS. Any client should be able to do at least the former.

> 2. Are clients good about keeping their own local flags if the 
> messages are read-only?

I haven't seen a client doing that apart from Eudora. I don't think 
clients store flags locally in such cases.

However clients should be able to handle server's inability to store 
flags. They should also cope with server returning READ-ONLY upon SELECT.

> 3. Any other known gopher holes?

Other holes are possible.

Date: Wed, 18 Jun 2008 11:05:31 -0500
To: IMAP Extensions <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Implementation query: Read-only anonymous access
Sender: [email-masked]

Do folks know how well, if at all, clients handle read-only anonymous 
access? Specifically, I'm wondering:

1. Are clients OK with connecting to a server with no login and password?
2. Are clients good about keeping their own local flags if the 
messages are read-only?
3. Any other known gopher holes?

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

From: The IESG <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: WG Action: Conclusion of Internet Message Access Protocol  Extension (imapext) 
Date: Tue, 17 Jun 2008 09:45:01 -0700 (PDT)
Sender: [email-masked]

The Internet Message Access Protocol Extension (imapext) working group in
the Applications Area has concluded.

The IESG contact persons are Lisa Dusseault and Chris Newman.

The mailing list will remain active.

Subject: Re: IMAPEXT prepared for shutdown
From: Timo Sirainen <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: IMAP Extensions <[email-masked]>, [email-masked]
Date: Tue, 17 Jun 2008 16:28:40 +0300
Sender: [email-masked]

--=-CBnkm6bNwNz7kKUlfUm1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, 2008-06-17 at 11:55 +0100, Alexey Melnikov wrote:
> Timo Sirainen wrote:
>=20
> > One thing somewhat related to ACLs that could be useful is the=20
> > ability  to find out and specify which message flags and keywords are=20
> > shared  and which are private (on per-flag level, not on per-message=20
> > level).  Perhaps with the ability to create/delete keywords with=20
> > explicit  commands.. Anyone else interested (for morg)?
>=20
> I am interested. I think I even had a pro-draft for this at some point.

I remember you had a new untagged reply listing shared flags:

* OK [SHAREDFLAGS (\Seen \Answered $hello $world)]

The commands could be something like:

1 FLAGS ADD PRIVATE ($pvt1 $pvt2 $foo) SHARED (\Seen \Answered)
* FLAGS ..
* OK [PERMANENTFLAGS ..]
=EF=BB=BF=EF=BB=BF* OK [SHAREDFLAGS (\Seen \Answered)]
1 OK
=EF=BB=BF2 FLAGS ADD SHARED ($shared1 $foo $shared2)
=EF=BB=BF=EF=BB=BF=EF=BB=BF* FLAGS ..
* OK [PERMANENTFLAGS ..]
=EF=BB=BF* OK [SHAREDFLAGS (\Seen \Answered $foo $shared1)]
2 NO [TOOMANYKEYWORDS] $shared2 not added

3 FLAGS REMOVE ($pvt1)
* FLAGS ..
* OK [PERMANENTFLAGS ..]
3 OK
4 FLAGS REMOVE ($shared1 \seen $shared2)
=EF=BB=BF* FLAGS ..
* OK [PERMANENTFLAGS ..]
=EF=BB=BF=EF=BB=BF* OK [SHAREDFLAGS (\Answered $foo)]
4 NO Unknown keyword $shared2

5 FLAGS ADD PRIVATE (\hello)
5 BAD

Adding and updating could be done with the same command. I don't think
there's much point in having them be separate.

--=-CBnkm6bNwNz7kKUlfUm1
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-CBnkm6bNwNz7kKUlfUm1--

Date: Tue, 17 Jun 2008 11:55:41 +0100
From: Alexey Melnikov <[email-masked]>
To: Timo Sirainen <[email-masked]>
CC: IMAP Extensions <[email-masked]>
Subject: Re: IMAPEXT prepared for shutdown
Sender: [email-masked]

Timo Sirainen wrote:

> One thing somewhat related to ACLs that could be useful is the 
> ability  to find out and specify which message flags and keywords are 
> shared  and which are private (on per-flag level, not on per-message 
> level).  Perhaps with the ability to create/delete keywords with 
> explicit  commands.. Anyone else interested (for morg)?

I am interested. I think I even had a pro-draft for this at some point.

From: Timo Sirainen <[email-masked]>
To: IMAP Extensions <[email-masked]>
Subject: Re: IMAPEXT prepared for shutdown
Date: Mon, 16 Jun 2008 23:02:30 +0300
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-2--883850290
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit

One thing somewhat related to ACLs that could be useful is the ability  
to find out and specify which message flags and keywords are shared  
and which are private (on per-flag level, not on per-message level).  
Perhaps with the ability to create/delete keywords with explicit  
commands.. Anyone else interested (for morg)?

--Apple-Mail-2--883850290
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-2--883850290--

Date: Mon, 16 Jun 2008 21:49:26 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: IMAPEXT prepared for shutdown
Cc: Mark Crispin <[email-masked]>, Pete Resnick <[email-masked]>
Sender: [email-masked]

Mark Crispin writes:
> ACL2 died in spite of my efforts, not because of them.

Then I was wrong, and the reasons for the deplorable manner in which 
ACL2 died have nothing to do with you.

That doesn't make it any less deplorable, but it does make me a fool for 
even mentioning your name.

Arnt

From: Mark Crispin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>, <[email-masked]>
CC: Pete Resnick <[email-masked]>
Subject: RE: IMAPEXT prepared for shutdown
Date: Mon, 16 Jun 2008 09:06:32 -0700
Importance: Normal
Sender: [email-masked]

> I didn't mean to say that you wanted to or tried to block it, merely
> that your actions had that outcome. Alexey told me I was wrong earlier
> today. Which doesn't make me like the outcome any more.

ACL2 died in spite of my efforts, not because of them.
_________________________________________________________________
Enjoy 5 GB of free, password-protected online storage.
http://www.windowslive.com/skydrive/overview.html?ocid=3DTXT_TAGLM_WL_Refre=
sh_skydrive_062008=

Date: Mon, 16 Jun 2008 17:53:10 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: IMAPEXT prepared for shutdown
Cc: Mark Crispin <[email-masked]>, Pete Resnick <[email-masked]>
Sender: [email-masked]

Mark Crispin writes:
>>  I suppose this means Mark blocked ACL2 for long enough to make the 
>>  block effectively permanent. I don't mind as a practical matter 
>>  (ACL does most of what I need), but somehow I don't like it.
>
> That was neither a nice, nor a true, thing to say.

I see what you mean, and apologise. It came out a little different than 
I meant. The final "it" was meant to represent "the way ACL2 died", 
nothing else.

I didn't mean to say that you wanted to or tried to block it, merely 
that your actions had that outcome. Alexey told me I was wrong earlier 
today. Which doesn't make me like the outcome any more. I would have 
liked it much better if ACL2 had been killed off actively a few years 
ago.

Arnt

From: Mark Crispin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>, Pete Resnick <[email-masked]>
CC: Lisa Dusseault <[email-masked]>, IMAP Extensions <[email-masked]>
Subject: RE: IMAPEXT prepared for shutdown
Date: Mon, 16 Jun 2008 08:23:24 -0700
Importance: Normal
Sender: [email-masked]

> I suppose this means Mark blocked ACL2 for long enough to make the block
> effectively permanent. I don't mind as a practical matter (ACL does
> most of what I need), but somehow I don't like it.

That was neither a nice, nor a true, thing to say.

_________________________________________________________________
Enjoy 5 GB of free, password-protected online storage.
http://www.windowslive.com/skydrive/overview.html?ocid=3DTXT_TAGLM_WL_Refre=
sh_skydrive_062008=

Date: Mon, 16 Jun 2008 16:39:50 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: IMAPEXT prepared for shutdown
Cc: Alexey Melnikov <[email-masked]>, Pete Resnick <[email-masked]>
Sender: [email-masked]

Alexey Melnikov writes:
> This is not correct. The main reason is that the editor ran out of 
> time/energy and considering other IETF committments can't get ACL2 
> finished.

OK.

Arnt

Date: Mon, 16 Jun 2008 11:00:42 +0100
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: Pete Resnick <[email-masked]>, Lisa Dusseault <[email-masked]>, IMAP Extensions <[email-masked]>
Subject: Re: IMAPEXT prepared for shutdown
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Pete Resnick wrote:
>
>> Our last RFC has posted, and I judge no energy left (at least in this=20
>> group at this time) to go forward with ACL2, so I am hereby=20
>> requesting the shutdown of the Internet Message Access Protocol=20
>> Extension Working Group. We can leave the mailing list alive.
>
> I suppose this means Mark blocked ACL2 for long enough to make the=20
> block  effectively permanent.

This is not correct. The main reason is that the editor ran out of=20
time/energy and considering other IETF committments can't get ACL2 finished.

> I don't mind as a practical matter (ACL does most of what I need), but=20
> somehow I don't like it.
>
> 1 2 3 4 5 6 7 8 10 11 12 13 14 15 =E2=88=9E. Small values of infinity suck=
,=20
> even when they don't hurt very much in practice.

Date: Mon, 16 Jun 2008 10:12:11 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: Pete Resnick <[email-masked]>
Cc: Lisa Dusseault <[email-masked]>, IMAP Extensions <[email-masked]>
Subject: Re: IMAPEXT prepared for shutdown
Sender: [email-masked]

Pete Resnick wrote:
> Our last RFC has posted, and I judge no energy left (at least in this=20
> group at this time) to go forward with ACL2, so I am hereby requesting=20
> the shutdown of the Internet Message Access Protocol Extension Working=20
> Group. We can leave the mailing list alive.

I suppose this means Mark blocked ACL2 for long enough to make the block=20
  effectively permanent. I don't mind as a practical matter (ACL does=20
most of what I need), but somehow I don't like it.

1 2 3 4 5 6 7 8 10 11 12 13 14 15 =E2=88=9E. Small values of infinity =
suck, even=20
when they don't hurt very much in practice.

Arnt

Date: Sun, 15 Jun 2008 18:29:18 +0100
From: Alexey Melnikov <[email-masked]>
To: Pete Resnick <[email-masked]>
CC: Lisa Dusseault <[email-masked]>, IMAP Extensions <[email-masked]>
Subject: Re: IMAPEXT prepared for shutdown
Sender: [email-masked]

Pete Resnick wrote:

> Hi Lisa,
>
> Our last RFC has posted, and I judge no energy left (at least in this 
> group at this time) to go forward with ACL2, so I am hereby requesting 
> the shutdown of the Internet Message Access Protocol Extension Working 
> Group.

Sounds right to me.

> We can leave the mailing list alive.

Yes please.

Date: Fri, 13 Jun 2008 20:57:08 -0500
To: Lisa Dusseault <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: IMAPEXT prepared for shutdown
Cc: IMAP Extensions <[email-masked]>
Sender: [email-masked]

Hi Lisa,

Our last RFC has posted, and I judge no energy left (at least in this 
group at this time) to go forward with ACL2, so I am hereby 
requesting the shutdown of the Internet Message Access Protocol 
Extension Working Group. We can leave the mailing list alive.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

To: [email-masked], [email-masked]
Subject: RFC 5257 on Internet Message Access Protocol - ANNOTATE Extension
From: [email-masked]
Cc: [email-masked], [email-masked]
Date: Fri, 13 Jun 2008 17:11:11 -0700 (PDT)
Sender: [email-masked]

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

        RFC 5257

        Title:      Internet Message Access Protocol - 
                    ANNOTATE Extension 
        Author:     C. Daboo, R. Gellens
        Status:     Experimental
        Date:       June 2008
        Mailbox:    [email-masked], 
                    [email-masked]
        Pages:      31
        Characters: 58786
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-imapext-annotate-16.txt

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

The ANNOTATE extension to the Internet Message Access Protocol
permits clients and servers to maintain "meta data" for messages, or
individual message parts, stored in a mailbox on the server.  For
example, this can be used to attach comments and other useful
information to a message.  It is also possible to attach annotations
to specific parts of a message, so that, for example, they could be
marked as seen, or important, or a comment added.

Note that this document was the product of a WG that had good
consensus on how to approach the problem.  Nevertheless, the WG felt
it did not have enough information on implementation and deployment
hurdles to meet all of the requirements of a Proposed Standard.  The
IETF solicits implementations and implementation reports in order to
make further progress.

Implementers should be aware that this specification may change in an
incompatible manner when going to Proposed Standard status.
However, any incompatible changes will result in a new capability
name being used to prevent problems with any deployments of the
experimental extension.  This memo defines an Experimental Protocol 
for the Internet community.

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

EXPERIMENTAL: This memo defines an Experimental Protocol for the
Internet community.  It does not specify an Internet standard of any
kind. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
USC/Information Sciences Institute

Date: Mon, 9 Jun 2008 23:00:18 -0500
To: Dan Karp <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: all done?
Cc: Timo Sirainen <[email-masked]>, IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On 6/9/08 at 3:57 PM -0700, Dan Karp wrote:

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

It will be published soon as RFC 5257.

>I believe its capability string was changed to ANNOTATE_EXPERIMENTAL-1.

Correct.

After that, we'll close the group (though leave the mailing list).

pr
-- 
Pete Resnick <http://www.episteme-software.com/>
All connections to the world are tenuous at best

Date: Mon, 9 Jun 2008 15:57:01 -0700 (PDT)
From: Dan Karp <[email-masked]>
To: Timo Sirainen <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Subject: Re: all done?
Sender: [email-masked]

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

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

Subject: all done?
From: Timo Sirainen <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Date: Tue, 10 Jun 2008 01:40:20 +0300
Sender: [email-masked]

--=-mpHJZ1EPRpzL/G5a61bL
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

ACL2 apparently was/will be dropped?

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

--=-mpHJZ1EPRpzL/G5a61bL
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-mpHJZ1EPRpzL/G5a61bL--

To: [email-masked], [email-masked]
Subject: RFC 5258 on Internet Message Access Protocol version 4 - LIST Command Extensions
From: [email-masked]
Cc: [email-masked], [email-masked]
Date: Mon,  9 Jun 2008 15:16:51 -0700 (PDT)
Sender: [email-masked]

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

        RFC 5258

        Title:      Internet Message Access Protocol version 
                    4 - LIST Command Extensions 
        Author:     B. Leiba, A. Melnikov
        Status:     Standards Track
        Date:       June 2008
        Mailbox:    [email-masked], 
                    [email-masked]
        Pages:      31
        Characters: 65074
        Updates/Obsoletes/SeeAlso:   None

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

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

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

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

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
USC/Information Sciences Institute

To: [email-masked], [email-masked]
Subject: RFC 5255 on Internet Message Access Protocol Internationalization
From: [email-masked]
Cc: [email-masked], [email-masked]
Date: Mon,  9 Jun 2008 15:16:49 -0700 (PDT)
Sender: [email-masked]

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

        RFC 5255

        Title:      Internet Message Access Protocol Internationalization 
        Author:     C. Newman, A. Gulbrandsen, A. Melnikov
        Status:     Standards Track
        Date:       June 2008
        Mailbox:    [email-masked], 
                    [email-masked], 
                    [email-masked]
        Pages:      20
        Characters: 41403
        Updates/Obsoletes/SeeAlso:   None

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

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

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

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

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
USC/Information Sciences Institute

To: [email-masked], [email-masked]
Subject: RFC 5256 on Internet Message Access Protocol - SORT and THREAD Extensions
From: [email-masked]
Cc: [email-masked], [email-masked]
Date: Mon,  9 Jun 2008 15:16:50 -0700 (PDT)
Sender: [email-masked]

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

        RFC 5256

        Title:      Internet Message Access Protocol - 
                    SORT and THREAD Extensions 
        Author:     M. Crispin, K. Murchison
        Status:     Standards Track
        Date:       June 2008
        Mailbox:    [email-masked], 
                    [email-masked]
        Pages:      19
        Characters: 40779
        Updates/Obsoletes/SeeAlso:   None

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

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

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

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

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
USC/Information Sciences Institute

Date: Thu, 05 Jun 2008 16:56:44 +0100
From: Alexey Melnikov <[email-masked]>
To: Timo Sirainen <[email-masked]>
CC: Dan Karp <[email-masked]>, IMAP Extensions WG <[email-masked]>, Enhancements to Internet email to support diverse service enivronments <[email-masked]>
Subject: Re: [lemonade] SORT and CONDSTORE
Sender: [email-masked]

Timo Sirainen wrote:

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

Subject: Re: [lemonade] SORT and CONDSTORE
From: Timo Sirainen <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Dan Karp <[email-masked]>, IMAP Extensions WG <[email-masked]>, Enhancements to Internet email to support diverse service enivronments <[email-masked]>
Date: Wed, 04 Jun 2008 19:12:42 +0300
Sender: [email-masked]

--=-KQ3zD7tin5mww1uhb+fc
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

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

And what about THREAD?

--=-KQ3zD7tin5mww1uhb+fc
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-KQ3zD7tin5mww1uhb+fc--

Date: Wed, 4 Jun 2008 07:46:21 -0700 (PDT)
From: Dan Karp <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>, Enhancements to Internet email to support diverse service enivronments <[email-masked]>
Subject: Re: [lemonade] SORT and CONDSTORE
Sender: [email-masked]

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

Such a command should also be regarded as a CONDSTORE-enabling command.

Date: Wed, 04 Jun 2008 14:35:49 +0100
From: Alexey Melnikov <[email-masked]>
To: Dan Karp <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>, Enhancements to Internet email to support diverse service enivronments <[email-masked]>
Subject: Re: [lemonade] SORT and CONDSTORE
Sender: [email-masked]

Dan Karp wrote:

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

Date: Tue, 3 Jun 2008 20:11:59 -0700 (PDT)
From: Dan Karp <[email-masked]>
To: IMAP Extensions WG <[email-masked]>, Enhancements to Internet email to support diverse service enivronments <[email-masked]>
Subject: SORT and CONDSTORE
Sender: [email-masked]

Quick question: Should

   A001 SORT (DATE) UTF-8 MODSEQ 500

cause a " (MODSEQ 4551)" to be appended to the SORT result?  The
SORT extension doesn't indicate it, but it seems as necessary as
adding it to the corresponding SEARCH.

From: The IESG <[email-masked]>
To: [email-masked]
Subject: WG Action: Conclusion of Internet Message Access Protocol  Extension (imapext) 
Date: Tue, 17 Jun 2008 09:45:01 -0700 (PDT)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

The Internet Message Access Protocol Extension (imapext) working group in
the Applications Area has concluded.

The IESG contact persons are Lisa Dusseault and Chris Newman.

The mailing list will remain active.
_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf-announce

From: The IESG <[email-masked]>
To: [email-masked]
Subject: WG Action: Conclusion of Internet Message Access Protocol  Extension (imapext) 
Date: Tue, 17 Jun 2008 09:45:01 -0700 (PDT)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

The Internet Message Access Protocol Extension (imapext) working group in
the Applications Area has concluded.

The IESG contact persons are Lisa Dusseault and Chris Newman.

The mailing list will remain active.
_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf-announce

From: The IESG <[email-masked]>
To: [email-masked]
Subject: WG Action: Conclusion of Internet Message Access Protocol  Extension (imapext) 
Date: Tue, 17 Jun 2008 09:45:01 -0700 (PDT)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

The Internet Message Access Protocol Extension (imapext) working group in
the Applications Area has concluded.

The IESG contact persons are Lisa Dusseault and Chris Newman.

The mailing list will remain active.
_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf-announce

Date: Fri, 20 Jun 2008 19:35:33 +0100
From: Alexey Melnikov <[email-masked]>
To: Phil Pennock <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: IANA-registered vendor subtree (RFC2244)
Sender: [email-masked]

Hi Phil,

Phil Pennock wrote:

>The "vendor subtree" for ACAP, establishing a textual namespace for
>components in hierarchical metadata, has the registry of assignments at:
>
>  http://www.iana.org/assignments/acap-registrations
>
>This RFC 2244 data is also used by IMAP ANNOTATE (RFC 5257,
>experimental) and the ANNOTATEMORE/ANNOTATEMORE2/METADATA draft series
>(now: draft-daboo-imap-annotatemore-13.txt).
>
as well as RFC 5258.

>Given that ACAP has not been a success, is there a more up-to-date
>reference for valid syntax of these names, both for developers and as
>guidance to IANA?  As far as I can tell, four of the nine registrations
>are syntactically invalid and this appears to have arisen because of
>unfortunate labelling in RFC 2244.
>
If you are referring to the following text in section 4.1:

   The dataset namespace is a slash-separated hierarchy.  The first
   component of the dataset namespace is a dataset class.  Dataset
   classes MUST have a vendor prefix (vendor.<vendor/product>) or be
   specified in a standards track or IESG approved experimental RFC.
   See section 7.3 for the registration template.

then I agree it is unfortunate. The difference between 
vendor.<vendor/product> (i.e. vendor.<"vendor or product">) and 
vendor.<vendor>/<product> is a bit subtle.

>If there is a more up-to-date
>reference,
>
I am afraid not.

>or even if not, can guidance be provided to IANA?
>
Yes.

>What should happen about existing registrations?  I suspect that they can
>safely be truncated just before the invalid "/" and still provide a
>complete and consistent registry.
>
Your suggestion seems reasonable.
As a side not I would just note that people who would like to keep using 
"vendor.<vendor>/<product>" can still do that, because the structure of 
vendor specific namespace is up to the vendor.

>The vendor-token which has to be registered with IANA is described in
>RFC2244 as vendor.<vendor/product> which seems to have been interpreted
>as: "vendor." <vendor> "/" <product>
>Similarly, "vendor.<company/product name>." is used in section 7.4,
>which also makes it clear that all subtrees are covered by a given
>registration (leading to my belief that truncation in the existing
>registry is the correct approach).
>
>The ABNF in RFC2244 section 4.3 uses vendor-name twice and defines it:
>----------------------------8< cut here >8------------------------------
>   name-component  = 1*UTF8-CHAR
>                     ;; MUST NOT contain ".", "/", "%", or "*"
>[...]
>   vendor-name     = vendor-token *("." name-component)
>
>   vendor-token    = "vendor." name-component
>                     ;; MUST be registered with IANA
>----------------------------8< cut here >8------------------------------
>
>This ties in intuitively with the use of both "/" and "." as hierarchy
>separators by the various protocols using this registration.
>
>Furthermore, taken too literally, given the registration of
>vendor-token, the definition of vendor-token in RFC2244 and the
>reference to vendor-token in RFC5257, for a registration "vendor.foo" we
>would end up with IMAP annotation entries named "/vendor/vendor.foo/bar"
>when clearly what's intended is to end up with "/vendor/foo/bar".
>  
>
IMHO, I would suggest keep existing definitions in RFC5257 as is, unless 
there is a compelling reason to change.
I don't find "less ugly" to be a compelling reason in this case.

>Common sense makes it easy enough to pick out what is meant, but what is
>defined in ABNF in two RFCs doesn't match.
>
>With two RFCs and a draft on the way, what's the cleanest way to deal
>with this?
>
I think the best way is to publish a short draft that updates the vendor 
registry and makes it non-specific to ACAP.

Subject: Re: Implementation query: Read-only anonymous access
Date: Wed, 18 Jun 2008 17:50:13 +0100
From: Dave Cridland <[email-masked]>
To: Pete Resnick <[email-masked]>
Cc: IMAP Extensions <[email-masked]>
Sender: [email-masked]

On Wed Jun 18 17:05:31 2008, Pete Resnick wrote:
> 1. Are clients OK with connecting to a server with no login and  
> password?

Clients, by and large, don't really handle either IMAP URLs or  
anonymous access, but the users are usually smart enough to handle  
typing in "anonymous" as the username and any old thing as password,  
as long as the server can also do that hack.

> 2. Are clients good about keeping their own local flags if the  
> messages are read-only?

Keeping flag data locally isn't something I've considered before. I  
think some clients will always store read state (essentially \Seen)  
locally, even if they cannot propogate that to the server, but I'm  
not sure. I have seen some clients get really upset and throw toys  
from the pram when the STORE fails, though.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

Date: Wed, 18 Jun 2008 17:25:23 +0100
From: Alexey Melnikov <[email-masked]>
To: Pete Resnick <[email-masked]>
CC: IMAP Extensions <[email-masked]>
Subject: Re: Implementation query: Read-only anonymous access
Sender: [email-masked]

Pete Resnick wrote:

> Do folks know how well, if at all, clients handle read-only anonymous 
> access? Specifically, I'm wondering:
>
> 1. Are clients OK with connecting to a server with no login and password?

If you mean the client can omit the LOGIN command, then this is not 
allowed by IMAP.

Anonymous access is typically done in 1 of 2 ways: either the client 
authenticates with LOGIN "anonymous" "<anything>", or it uses 
AUTHENTICATE ANONYMOUS. Any client should be able to do at least the former.

> 2. Are clients good about keeping their own local flags if the 
> messages are read-only?

I haven't seen a client doing that apart from Eudora. I don't think 
clients store flags locally in such cases.

However clients should be able to handle server's inability to store 
flags. They should also cope with server returning READ-ONLY upon SELECT.

> 3. Any other known gopher holes?

Other holes are possible.

Date: Wed, 18 Jun 2008 11:05:31 -0500
To: IMAP Extensions <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Implementation query: Read-only anonymous access
Sender: [email-masked]

Do folks know how well, if at all, clients handle read-only anonymous 
access? Specifically, I'm wondering:

1. Are clients OK with connecting to a server with no login and password?
2. Are clients good about keeping their own local flags if the 
messages are read-only?
3. Any other known gopher holes?

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

From: The IESG <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: WG Action: Conclusion of Internet Message Access Protocol  Extension (imapext) 
Date: Tue, 17 Jun 2008 09:45:01 -0700 (PDT)
Sender: [email-masked]

The Internet Message Access Protocol Extension (imapext) working group in
the Applications Area has concluded.

The IESG contact persons are Lisa Dusseault and Chris Newman.

The mailing list will remain active.

Subject: Re: IMAPEXT prepared for shutdown
From: Timo Sirainen <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: IMAP Extensions <[email-masked]>, [email-masked]
Date: Tue, 17 Jun 2008 16:28:40 +0300
Sender: [email-masked]

--=-CBnkm6bNwNz7kKUlfUm1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, 2008-06-17 at 11:55 +0100, Alexey Melnikov wrote:
> Timo Sirainen wrote:
>=20
> > One thing somewhat related to ACLs that could be useful is the=20
> > ability  to find out and specify which message flags and keywords are=20
> > shared  and which are private (on per-flag level, not on per-message=20
> > level).  Perhaps with the ability to create/delete keywords with=20
> > explicit  commands.. Anyone else interested (for morg)?
>=20
> I am interested. I think I even had a pro-draft for this at some point.

I remember you had a new untagged reply listing shared flags:

* OK [SHAREDFLAGS (\Seen \Answered $hello $world)]

The commands could be something like:

1 FLAGS ADD PRIVATE ($pvt1 $pvt2 $foo) SHARED (\Seen \Answered)
* FLAGS ..
* OK [PERMANENTFLAGS ..]
=EF=BB=BF=EF=BB=BF* OK [SHAREDFLAGS (\Seen \Answered)]
1 OK
=EF=BB=BF2 FLAGS ADD SHARED ($shared1 $foo $shared2)
=EF=BB=BF=EF=BB=BF=EF=BB=BF* FLAGS ..
* OK [PERMANENTFLAGS ..]
=EF=BB=BF* OK [SHAREDFLAGS (\Seen \Answered $foo $shared1)]
2 NO [TOOMANYKEYWORDS] $shared2 not added

3 FLAGS REMOVE ($pvt1)
* FLAGS ..
* OK [PERMANENTFLAGS ..]
3 OK
4 FLAGS REMOVE ($shared1 \seen $shared2)
=EF=BB=BF* FLAGS ..
* OK [PERMANENTFLAGS ..]
=EF=BB=BF=EF=BB=BF* OK [SHAREDFLAGS (\Answered $foo)]
4 NO Unknown keyword $shared2

5 FLAGS ADD PRIVATE (\hello)
5 BAD

Adding and updating could be done with the same command. I don't think
there's much point in having them be separate.

--=-CBnkm6bNwNz7kKUlfUm1
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-CBnkm6bNwNz7kKUlfUm1--

Date: Tue, 17 Jun 2008 11:55:41 +0100
From: Alexey Melnikov <[email-masked]>
To: Timo Sirainen <[email-masked]>
CC: IMAP Extensions <[email-masked]>
Subject: Re: IMAPEXT prepared for shutdown
Sender: [email-masked]

Timo Sirainen wrote:

> One thing somewhat related to ACLs that could be useful is the 
> ability  to find out and specify which message flags and keywords are 
> shared  and which are private (on per-flag level, not on per-message 
> level).  Perhaps with the ability to create/delete keywords with 
> explicit  commands.. Anyone else interested (for morg)?

I am interested. I think I even had a pro-draft for this at some point.

From: Timo Sirainen <[email-masked]>
To: IMAP Extensions <[email-masked]>
Subject: Re: IMAPEXT prepared for shutdown
Date: Mon, 16 Jun 2008 23:02:30 +0300
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--Apple-Mail-2--883850290
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit

One thing somewhat related to ACLs that could be useful is the ability  
to find out and specify which message flags and keywords are shared  
and which are private (on per-flag level, not on per-message level).  
Perhaps with the ability to create/delete keywords with explicit  
commands.. Anyone else interested (for morg)?

--Apple-Mail-2--883850290
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-2--883850290--

Date: Mon, 16 Jun 2008 21:49:26 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: IMAPEXT prepared for shutdown
Cc: Mark Crispin <[email-masked]>, Pete Resnick <[email-masked]>
Sender: [email-masked]

Mark Crispin writes:
> ACL2 died in spite of my efforts, not because of them.

Then I was wrong, and the reasons for the deplorable manner in which 
ACL2 died have nothing to do with you.

That doesn't make it any less deplorable, but it does make me a fool for 
even mentioning your name.

Arnt

From: Mark Crispin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>, <[email-masked]>
CC: Pete Resnick <[email-masked]>
Subject: RE: IMAPEXT prepared for shutdown
Date: Mon, 16 Jun 2008 09:06:32 -0700
Importance: Normal
Sender: [email-masked]

> I didn't mean to say that you wanted to or tried to block it, merely
> that your actions had that outcome. Alexey told me I was wrong earlier
> today. Which doesn't make me like the outcome any more.

ACL2 died in spite of my efforts, not because of them.
_________________________________________________________________
Enjoy 5 GB of free, password-protected online storage.
http://www.windowslive.com/skydrive/overview.html?ocid=3DTXT_TAGLM_WL_Refre=
sh_skydrive_062008=

Date: Mon, 16 Jun 2008 17:53:10 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: IMAPEXT prepared for shutdown
Cc: Mark Crispin <[email-masked]>, Pete Resnick <[email-masked]>
Sender: [email-masked]

Mark Crispin writes:
>>  I suppose this means Mark blocked ACL2 for long enough to make the 
>>  block effectively permanent. I don't mind as a practical matter 
>>  (ACL does most of what I need), but somehow I don't like it.
>
> That was neither a nice, nor a true, thing to say.

I see what you mean, and apologise. It came out a little different than 
I meant. The final "it" was meant to represent "the way ACL2 died", 
nothing else.

I didn't mean to say that you wanted to or tried to block it, merely 
that your actions had that outcome. Alexey told me I was wrong earlier 
today. Which doesn't make me like the outcome any more. I would have 
liked it much better if ACL2 had been killed off actively a few years 
ago.

Arnt

From: Mark Crispin <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>, Pete Resnick <[email-masked]>
CC: Lisa Dusseault <[email-masked]>, IMAP Extensions <[email-masked]>
Subject: RE: IMAPEXT prepared for shutdown
Date: Mon, 16 Jun 2008 08:23:24 -0700
Importance: Normal
Sender: [email-masked]

> I suppose this means Mark blocked ACL2 for long enough to make the block
> effectively permanent. I don't mind as a practical matter (ACL does
> most of what I need), but somehow I don't like it.

That was neither a nice, nor a true, thing to say.

_________________________________________________________________
Enjoy 5 GB of free, password-protected online storage.
http://www.windowslive.com/skydrive/overview.html?ocid=3DTXT_TAGLM_WL_Refre=
sh_skydrive_062008=

Date: Mon, 16 Jun 2008 16:39:50 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: IMAPEXT prepared for shutdown
Cc: Alexey Melnikov <[email-masked]>, Pete Resnick <[email-masked]>
Sender: [email-masked]

Alexey Melnikov writes:
> This is not correct. The main reason is that the editor ran out of 
> time/energy and considering other IETF committments can't get ACL2 
> finished.

OK.

Arnt

Date: Mon, 16 Jun 2008 11:00:42 +0100
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: Pete Resnick <[email-masked]>, Lisa Dusseault <[email-masked]>, IMAP Extensions <[email-masked]>
Subject: Re: IMAPEXT prepared for shutdown
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Pete Resnick wrote:
>
>> Our last RFC has posted, and I judge no energy left (at least in this=20
>> group at this time) to go forward with ACL2, so I am hereby=20
>> requesting the shutdown of the Internet Message Access Protocol=20
>> Extension Working Group. We can leave the mailing list alive.
>
> I suppose this means Mark blocked ACL2 for long enough to make the=20
> block  effectively permanent.

This is not correct. The main reason is that the editor ran out of=20
time/energy and considering other IETF committments can't get ACL2 finished.

> I don't mind as a practical matter (ACL does most of what I need), but=20
> somehow I don't like it.
>
> 1 2 3 4 5 6 7 8 10 11 12 13 14 15 =E2=88=9E. Small values of infinity suck=
,=20
> even when they don't hurt very much in practice.

Date: Mon, 16 Jun 2008 10:12:11 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: Pete Resnick <[email-masked]>
Cc: Lisa Dusseault <[email-masked]>, IMAP Extensions <[email-masked]>
Subject: Re: IMAPEXT prepared for shutdown
Sender: [email-masked]

Pete Resnick wrote:
> Our last RFC has posted, and I judge no energy left (at least in this=20
> group at this time) to go forward with ACL2, so I am hereby requesting=20
> the shutdown of the Internet Message Access Protocol Extension Working=20
> Group. We can leave the mailing list alive.

I suppose this means Mark blocked ACL2 for long enough to make the block=20
  effectively permanent. I don't mind as a practical matter (ACL does=20
most of what I need), but somehow I don't like it.

1 2 3 4 5 6 7 8 10 11 12 13 14 15 =E2=88=9E. Small values of infinity =
suck, even=20
when they don't hurt very much in practice.

Arnt

Date: Sun, 15 Jun 2008 18:29:18 +0100
From: Alexey Melnikov <[email-masked]>
To: Pete Resnick <[email-masked]>
CC: Lisa Dusseault <[email-masked]>, IMAP Extensions <[email-masked]>
Subject: Re: IMAPEXT prepared for shutdown
Sender: [email-masked]

Pete Resnick wrote:

> Hi Lisa,
>
> Our last RFC has posted, and I judge no energy left (at least in this 
> group at this time) to go forward with ACL2, so I am hereby requesting 
> the shutdown of the Internet Message Access Protocol Extension Working 
> Group.

Sounds right to me.

> We can leave the mailing list alive.

Yes please.

Date: Fri, 13 Jun 2008 20:57:08 -0500
To: Lisa Dusseault <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: IMAPEXT prepared for shutdown
Cc: IMAP Extensions <[email-masked]>
Sender: [email-masked]

Hi Lisa,

Our last RFC has posted, and I judge no energy left (at least in this 
group at this time) to go forward with ACL2, so I am hereby 
requesting the shutdown of the Internet Message Access Protocol 
Extension Working Group. We can leave the mailing list alive.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

To: [email-masked], [email-masked]
Subject: RFC 5257 on Internet Message Access Protocol - ANNOTATE Extension
From: [email-masked]
Cc: [email-masked], [email-masked]
Date: Fri, 13 Jun 2008 17:11:11 -0700 (PDT)
Sender: [email-masked]

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

        RFC 5257

        Title:      Internet Message Access Protocol - 
                    ANNOTATE Extension 
        Author:     C. Daboo, R. Gellens
        Status:     Experimental
        Date:       June 2008
        Mailbox:    [email-masked], 
                    [email-masked]
        Pages:      31
        Characters: 58786
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-imapext-annotate-16.txt

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

The ANNOTATE extension to the Internet Message Access Protocol
permits clients and servers to maintain "meta data" for messages, or
individual message parts, stored in a mailbox on the server.  For
example, this can be used to attach comments and other useful
information to a message.  It is also possible to attach annotations
to specific parts of a message, so that, for example, they could be
marked as seen, or important, or a comment added.

Note that this document was the product of a WG that had good
consensus on how to approach the problem.  Nevertheless, the WG felt
it did not have enough information on implementation and deployment
hurdles to meet all of the requirements of a Proposed Standard.  The
IETF solicits implementations and implementation reports in order to
make further progress.

Implementers should be aware that this specification may change in an
incompatible manner when going to Proposed Standard status.
However, any incompatible changes will result in a new capability
name being used to prevent problems with any deployments of the
experimental extension.  This memo defines an Experimental Protocol 
for the Internet community.

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

EXPERIMENTAL: This memo defines an Experimental Protocol for the
Internet community.  It does not specify an Internet standard of any
kind. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
USC/Information Sciences Institute

Date: Mon, 9 Jun 2008 23:00:18 -0500
To: Dan Karp <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: all done?
Cc: Timo Sirainen <[email-masked]>, IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

On 6/9/08 at 3:57 PM -0700, Dan Karp wrote:

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

It will be published soon as RFC 5257.

>I believe its capability string was changed to ANNOTATE_EXPERIMENTAL-1.

Correct.

After that, we'll close the group (though leave the mailing list).

pr
-- 
Pete Resnick <http://www.episteme-software.com/>
All connections to the world are tenuous at best

Date: Mon, 9 Jun 2008 15:57:01 -0700 (PDT)
From: Dan Karp <[email-masked]>
To: Timo Sirainen <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Subject: Re: all done?
Sender: [email-masked]

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

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

Subject: all done?
From: Timo Sirainen <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Date: Tue, 10 Jun 2008 01:40:20 +0300
Sender: [email-masked]

--=-mpHJZ1EPRpzL/G5a61bL
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

ACL2 apparently was/will be dropped?

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

--=-mpHJZ1EPRpzL/G5a61bL
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-mpHJZ1EPRpzL/G5a61bL--

To: [email-masked], [email-masked]
Subject: RFC 5258 on Internet Message Access Protocol version 4 - LIST Command Extensions
From: [email-masked]
Cc: [email-masked], [email-masked]
Date: Mon,  9 Jun 2008 15:16:51 -0700 (PDT)
Sender: [email-masked]

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

        RFC 5258

        Title:      Internet Message Access Protocol version 
                    4 - LIST Command Extensions 
        Author:     B. Leiba, A. Melnikov
        Status:     Standards Track
        Date:       June 2008
        Mailbox:    [email-masked], 
                    [email-masked]
        Pages:      31
        Characters: 65074
        Updates/Obsoletes/SeeAlso:   None

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

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

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

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

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
USC/Information Sciences Institute

To: [email-masked], [email-masked]
Subject: RFC 5255 on Internet Message Access Protocol Internationalization
From: [email-masked]
Cc: [email-masked], [email-masked]
Date: Mon,  9 Jun 2008 15:16:49 -0700 (PDT)
Sender: [email-masked]

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

        RFC 5255

        Title:      Internet Message Access Protocol Internationalization 
        Author:     C. Newman, A. Gulbrandsen, A. Melnikov
        Status:     Standards Track
        Date:       June 2008
        Mailbox:    [email-masked], 
                    [email-masked], 
                    [email-masked]
        Pages:      20
        Characters: 41403
        Updates/Obsoletes/SeeAlso:   None

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

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

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

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

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
USC/Information Sciences Institute

To: [email-masked], [email-masked]
Subject: RFC 5256 on Internet Message Access Protocol - SORT and THREAD Extensions
From: [email-masked]
Cc: [email-masked], [email-masked]
Date: Mon,  9 Jun 2008 15:16:50 -0700 (PDT)
Sender: [email-masked]

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

        RFC 5256

        Title:      Internet Message Access Protocol - 
                    SORT and THREAD Extensions 
        Author:     M. Crispin, K. Murchison
        Status:     Standards Track
        Date:       June 2008
        Mailbox:    [email-masked], 
                    [email-masked]
        Pages:      19
        Characters: 40779
        Updates/Obsoletes/SeeAlso:   None

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

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

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

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

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
USC/Information Sciences Institute

Date: Thu, 05 Jun 2008 16:56:44 +0100
From: Alexey Melnikov <[email-masked]>
To: Timo Sirainen <[email-masked]>
CC: Dan Karp <[email-masked]>, IMAP Extensions WG <[email-masked]>, Enhancements to Internet email to support diverse service enivronments <[email-masked]>
Subject: Re: [lemonade] SORT and CONDSTORE
Sender: [email-masked]

Timo Sirainen wrote:

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

Subject: Re: [lemonade] SORT and CONDSTORE
From: Timo Sirainen <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: Dan Karp <[email-masked]>, IMAP Extensions WG <[email-masked]>, Enhancements to Internet email to support diverse service enivronments <[email-masked]>
Date: Wed, 04 Jun 2008 19:12:42 +0300
Sender: [email-masked]

--=-KQ3zD7tin5mww1uhb+fc
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

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

And what about THREAD?

--=-KQ3zD7tin5mww1uhb+fc
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-KQ3zD7tin5mww1uhb+fc--

Date: Wed, 4 Jun 2008 07:46:21 -0700 (PDT)
From: Dan Karp <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>, Enhancements to Internet email to support diverse service enivronments <[email-masked]>
Subject: Re: [lemonade] SORT and CONDSTORE
Sender: [email-masked]

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

Such a command should also be regarded as a CONDSTORE-enabling command.

Date: Wed, 04 Jun 2008 14:35:49 +0100
From: Alexey Melnikov <[email-masked]>
To: Dan Karp <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>, Enhancements to Internet email to support diverse service enivronments <[email-masked]>
Subject: Re: [lemonade] SORT and CONDSTORE
Sender: [email-masked]

Dan Karp wrote:

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

Date: Tue, 3 Jun 2008 20:11:59 -0700 (PDT)
From: Dan Karp <[email-masked]>
To: IMAP Extensions WG <[email-masked]>, Enhancements to Internet email to support diverse service enivronments <[email-masked]>
Subject: SORT and CONDSTORE
Sender: [email-masked]

Quick question: Should

   A001 SORT (DATE) UTF-8 MODSEQ 500

cause a " (MODSEQ 4551)" to be appended to the SORT result?  The
SORT extension doesn't indicate it, but it seems as necessary as
adding it to the corresponding SEARCH.