Subject: Re: Work items for Alexey, Cyrus, Barry, Tony, Chris, Arnt
From: Barry Leiba <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Date: Tue, 29 Mar 2005 13:59:30 -0500
List-Id: <ietf-imapext.imc.org>

> below, in order  to come up with new milestone dates, I need to get
> date promises out of  the active draft authors (Cyrus, Randy, Barry,
> Alexey) for LISTEXT,  ANNOTATE and 2086upd as well as ACL2.

I have just converted the plain text for the -11 version of ListExt
into XML that works for xml2rfc -- that was a prerequisite for updates,
since dealing directly with the plain text is too painful.  I sent the
new text to Alexey the other day for review (to make sure I didn't
break anything).

I'll next be working on making the changes, and resolving the open
issues.  Expect a -12 version, along with a list of what still has to
be resolved, to be posted by 7 April.

I don't think the things that need to be resolved will be very
contentious, but, then, we thought that what we came up with at the
interim meeting would go smoothly, and it didn't.  Anyway, if I can lay
out the remaining issues clearly, we should be able to get through them
on the list and get a last-call document out as -13.  Maybe go for end
of April as the goal for making the last call?  Is that suitable?

Barry

--
Barry Leiba, Pervasive Computing Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam

Date: Wed, 23 Mar 2005 09:26:46 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: Work items for Alexey, Cyrus, Barry, Tony, Chris, Arnt
Sender: [email-masked]

On Wed, 23 Mar 2005, Cyrus Daboo wrote:
>> (Btw, I'll be at the next IETF, perhaps the next two. Are the dates for
>> the November IETF known yet? My schedule is a little tricky.)
> <http://www.ietf.org/meetings/0mtg-sites.txt>

For what it's worth, I won't be at Paris, but I probably will be in 
Vancouver.

-- Mark --

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

Date: Wed, 23 Mar 2005 11:29:21 -0500
From: Cyrus Daboo <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: Work items for Alexey, Cyrus, Barry, Tony, Chris, Arnt
Sender: [email-masked]

Hi Arnt,

--On March 23, 2005 10:40:16 +0100 Arnt Gulbrandsen 
<[email-masked]> wrote:

> (Btw, I'll be at the next IETF, perhaps the next two. Are the dates for
> the November IETF known yet? My schedule is a little tricky.)
>

<http://www.ietf.org/meetings/0mtg-sites.txt>

-- 
Cyrus Daboo

Date: Wed, 23 Mar 2005 10:40:16 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Work items for Alexey, Cyrus, Barry, Tony, Chris, Arnt
Sender: [email-masked]

>>> i18n Document [draft-ietf-imapext-i18n-04.txt]:
>>> - Chris asks if we can simplify the use of comparators in the search 
>>> program so that one comparator could be used for the entire 
>>> program.

I don't understand this. Didn't I do that already? How is it possible to 
use multipe comparators in one search program in the -04 draft?

(Btw, I'll be at the next IETF, perhaps the next two. Are the dates for 
the November IETF known yet? My schedule is a little tricky.)

Arnt

From: Lisa Dusseault <[email-masked]>
Subject: Work items for Alexey, Cyrus, Barry, Tony, Chris, Arnt
Date: Tue, 22 Mar 2005 11:32:26 -0800
To: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

Don't forget the deliverables from the IETF this month, both new drafts  
and promised reviews... in addition to the deliverables below, in order  
to come up with new milestone dates, I need to get date promises out of  
the active draft authors (Cyrus, Randy, Barry, Alexey) for LISTEXT,  
ANNOTATE and 2086upd as well as ACL2.

Lisa

On Mar 10, 2005, at 1:53 PM, Lisa Dusseault wrote:

>
> This is great.  I'll just use this opportunity to extract the  
> deliverables:
>  - Lisa to deliver recharter (new milestone dates) for WG
>  - Alexey to produce new draft of 2086upd addressing last-call and  
> post-last-call nits
>  - Cyrus to produce new draft of annotate addressing last call issues  
> and incorporating decisions recorded in these minutes
>  - Alexey and Barry to produce new draft of LISTEXT with no open or  
> editorial issues remaining, suitable for last call
>  - Alexey to produce syntax draft for Annotate to use
>  - Tony Hanson and Barry Leiba to review Chris's Comparator draft and  
> ping Chris about it
>  - Chris Newman to put cycles into Comparator
>  - Arnt (who was absent) to review Chris's proposed simplification  
> allowing only one comparator per search query
>
>
> On Mar 10, 2005, at 12:15 PM, Rob Siemborski wrote:
>
>>
>> Let me know your comments, I'll send this on to [email-masked]  
>> probably tomorrow sometime.
>>
>> IMAPEXT Meeting at IETF-62, 3-10-2005, 9-11am CST.
>>
>> These minutes are based off the Jabber log, available here:
>> http://www.xmpp.org/ietf-logs/[email-masked]/2005-03-10.htm
>>
>> Administrivia:
>>
>> Chairs welcomed the members to the IMAPEXT variety show.  The agenda  
>> was bashed.
>>
>> 2086upd [draft-ietf-imapext-2086upd-03.txt]:
>>
>> - Chair summarized that people have been reviewing the document,  
>> things are looking good and we're almost done.
>>
>> - Cyrus sent a large number of comments to the list this morning that  
>> were mostly minor nits.
>>
>> - Room consensus that no comments had invalidated last call, and we  
>> can move forward.
>>
>> ANNOTATE [draft-ietf-imapext-annotate-12.txt]:
>>
>> - Brief discussion about how references when replacing a document  
>> work (you don't have to reference a document you are obsoleting)
>>
>> - Lisa summarized Cyrus's recent changed for the room.
>>
>> - Use of UTF-8 for values: rough consensus for 'SHOULD' instead of  
>> 'MUST'
>>
>> - Discussion of open issues:
>>   - Should servers validate the syntax of the content-type value? Yes.
>>     (but should not have to validate that the actual content-type is
>>      correct).
>>     - We should reference RFC2046 for their content-type syntax.
>>   - Should entity registrations contain a default content-type value?
>>     - Other questions included:
>>       "Should entries be forced to a particular content type?" No
>>     - IANA registration will contain a recommended content-type value.
>>   - Can values contain binary data?  Can we use the literal8 syntax  
>> from
>>     BINARY?
>>     - Alternate ideas included tagging to indicate that a
>>       binary response was desired. (experience from LDAP indicated  
>> this
>>       was tricky to get right)
>>     - Desire to not require BINARY extension, just the syntax.
>>     - Desire to move literal8 syntax to the common syntax document.
>>     - Rough consensus to use literal8 syntax for all ANNOTATE  
>> literals,
>>       but no modifications for regular strings.
>>     - Rough consensus to move literal8 syntax to the syntax document  
>> (out
>>       of BINARY).
>>   - How to deal with hierarchy levels named 'shared' and 'priv'?
>>     - Ambiguity on first hierarchy level.
>>     - Rough consensus to just deny them on all levels.
>>   - UTF-8 entry/attribute names
>>     - We need stringprep for comparisons if they stay UTF-8
>>     - Recent lunch BOF proposal to restrict to US-ASCII and have  
>> another
>>       attribute for UTF-8 display name.
>>     - Additionally, clients are not required to use the display name  
>> for
>>       presentation if they choose not to.
>>       - Really, the display name attribute would only be necessary for
>>         custom entries (for standard entries, clients could know how  
>> they
>>         are used).
>>     - Point that we will need stringprep for mailbox names eventually
>>       anyway. (but this is likely a different stringprep profile).
>>     - Observation that mailbox names aren't registered, its much  
>> nicer to
>>       be able to just register US-ASCII names.
>>     - Rough consensus to restrict entry and attribute names to  
>> US-ASCII,
>>       and include a UTF-8 displayname attribute.
>>   - Interaction with CATENATE syntax (for APPEND), since the CATENATE
>>     draft is now APPEND-only.  Should we just reference the syntax  
>> draft?
>>     - Rough consensus: Yes.
>>
>> - Side discussion about making Alexey's syntax draft an official WG  
>> item. Rough consensus to decide after seeing it (Alexey promises to  
>> be quick with updates).
>>
>> - ANNOTATEMORE interaction: there are large blocks of shared text  
>> that should now be updated in both places.
>>
>> LISTEXT [draft-ietf-imapext-list-extensions-11.txt]:
>>
>> - Philip summarized the changes to LISTEXT proposed at the interim  
>> and subsequent list discussion, the main problem being that LIST  
>> responses cannot rely on the context of the command that prompted  
>> them.
>>   - Solution: move lots of this into CHILDINFO.
>>
>> - Discussion of possible difference in behavior with current RLIST  
>> and the
>> \Remote flag (currently a server does not need to actually declare  
>> what mailboxes are remote and which ones aren't).  This could cause  
>> problems for some type of proxies that choose to refer based on if  
>> the clients send an RLIST or not.
>>   - Probably not a problem, since LIST flags can change at any time,
>>     really..
>>
>> - Issue: The current ABNF is very complex, can it be simplified?
>>   - Observation: some of the syntax is performing validation that is
>>     really semantic in nature.
>>   - Cyrus offered to take a look and suggest text/new ABNF.
>>
>> - Chair asked authors of LISTEXT to propose strawman for open issues  
>> in the next document, continuing to have open issues will just delay  
>> the group.
>>   - Authors asked that members who disagree with the strawman propose
>>     alternates.
>>
>> Comparator (not a WG item) [draft-newman-i18n-comparator-03.txt]:
>> - We have several items that depend on this.
>> - Chris tried to find another author, and failed.  He will continue  
>> to try
>>   to find someone else to work on it, but will also commit some cycles
>>   near term.
>> - Chris is currently interrupt driven, and asks to be pinged.
>>
>> ACL2 & Working Group Future:
>> - In San Diego we agreed to drop ACL2 if there had been no progress  
>> by this meeting.  There hasn't been progress on ACL2, but there has  
>> been substantial other progress.  Chair asks if we want to extend our  
>> deadline given this (and adjust charter dates).
>>   - Scott (AD) is ok with this.
>>   - Rough consensus to revisit ACL2 in 6 months.
>>
>> - Members should watch the LEMONADE group for some of their  
>> encrypted/signed message issues.  IMAPEXT (or at least its members)  
>> should be involved in a deep way.
>>
>> i18n Document [draft-ietf-imapext-i18n-04.txt]:
>> - Chris asks if we can simplify the use of comparators in the search  
>> program so that one comparator could be used for the entire program.
>>   - Example use case: search for case-sensitive local part and
>>     case-insensitive domain part of an address.
>>   - Point that we could accomplish most of the usefulness of this with
>>     the ability to search within results.
>>   - Rough consensus to simplify in this way, and allow for a future
>>     extension to do the recursive search.  Chris will send a message  
>> to
>>     Arnt and the list.
>>
>>
>> ---------------------------------------------------------------------- 
>> ---
>> Rob Siemborski        |     PGP:0x5CE32FCC     |       
>> [email-masked] -----BEGIN GEEK CODE BLOCK----
>> Version: 3.12
>> GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K-  
>> w-- O-
>> M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r-  
>> y?
>> ------END GEEK CODE BLOCK-----
>>
>

Date: Thu, 17 Mar 2005 20:40:32 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: [email-masked]
Subject: listext comments
Sender: [email-masked]

Some comments I wrote up on the way back from IETF:

On Open Issue: "Each option (except for RECURSIVEMATCH) should have a 
corresponding mailbox attribute".

I don't believe this should be mandatory (I don't think it gets us much). 
Additionally, if RECURSIVEMATCH is an example of an option that doesn't 
directly correspond to a flag, it seems likely its not something we want to 
forbid.  (For example, say we wanted boolean operators as selection criteria, 
like NOT SUBSCRIBED?)  NOT doesn't exactly have a good flag to go with it :)

---

In the NonExistant discussion:

>
    The "\NonExistent" attribute indicates that a mailbox does not actually
    exist. Note that this attribute is not meaningful by itself, as mailboxes
>

I sort of want to say "level of mailbox hierarchy" as opposed to "mailbox", 
since technically, if they don't exist they're not mailboxes (though for 
SUBSCRIBED, this is somewhat less clear).

---

On Open Issue: ", but doesn't match the canonical LIST pattern." (referring to 
child mailboxes).

YES, please include that.

---

Can we break up section 3.[nil] into subsections (overview, selection options, 
return options).

---

To somewhat follow up on my comments about the REMOTE flag at the WG meeting...

The REMOTE selection option section states "The '\Remote' attribute MUST be 
accurately computed..."

It would be nice if a note was in there stating that if the server presents 
this flag it MAY, in fact, not issue a referral when the mailbox is accessed 
(for example, if the mailbox has become local in the intervening time). 
Likewise, a mailbox previously noted as local MAY get a referral anyway (since 
the mailbox may have been made non-local in the interim).

---

Not strictly necessary, but it took me a few seconds to realize why the REMOTE 
return option wasn't necessary (maybe I'm just slow).  A note of clarification 
in the remote options section or under the remote selection option might be 
nice but not necessary.

---

"as well as distinguish between solicited responses caused by multiple 
different LIST commands"

Of course, the client shouldn't be pipelining commands it can't distinguish the 
difference in results from anyway.

---

On open issue: "Suppressing redundant CHILDINFO when parent doesn't match the 
selection criteria but has a child that does AND the child also matches the 
canonical list pattern"

We should match present-day LSUB behavior in this case <<I think that is to 
return the parents, but I'm not certain>>

---

The table in section 3.3. greatly clarifies things, please keep it.

---

In the description of the HasChildren flag we suddenly start talking about 
access permissions -- yet elsewhere in the document we haven't mentioned it at 
all.  I don't think that we need to worry about it here, and we can just say 
that in some implementations it may be expensive to compute the existence of 
child mailboxes, and that \HasChildren is only a hint to clients.

If we really want to talk about access permissions in this document, we should 
think carefully about where else they may be hard to complute (\Remote?)

---

>> 
In particular, some servers may not be able to combine the SUBSCRIBED selection 
option and CHILDREN return option. <<

We need to seriously consider this.

What if in the future we find another combination that some implementations 
find computationally expensive?  Are we going to have to declare a hiearchy of 
priorities for the servers to process these in ("REMOTE SUBSCRIBED CHILDREN is 
hard for me, so I'll just do SUBSCRIBED....")?

Additionally, clients that want this information are still going to have to 
figure it out somehow (and based on what I've seen, its likely they will do a 
separate LIST command for each one).

---

"inbox" should probably be "INBOX" in the examples.

---

The discussion of the access permissions for security considerations with 
CHILDREN is probably better than having it in the middle of the document, 
because its really a special case of the overriding "HasChildren is only a 
hint" problem.

-Rob

-------------------------------------------------------------------------
Rob Siemborski        |     PGP:0x5CE32FCC     |      [email-masked] 
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

Date: Wed, 16 Mar 2005 16:23:36 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Tony Hansen <[email-masked]>
cc: [email-masked]
Subject: Re: Size Indications in IMAP (was Split Implementations of PGP)
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Wed, 16 Mar 2005, Tony Hansen wrote:
> I ran into a similar situation with a vendor of voice mail products. They 
> stored the voice messages in their imap servers in a proprietary format, but 
> when you asked for the messages, converted them on the fly into wav format. 
> It happens that the wav format was always smaller than the original format, 
> so the message body we'd get would be padded at the end with tons of 
> space-filled blank lines to make up for the size difference.

Did they also return a BODYSTRUCTURE showing that content as being in WAV 
format?

If so, it's regrettable that they had to do that, but that's not as bad as 
passing false data in the sizes.

> If this particular case had been done using content conversion extensions, 
> ala lemonade, the issue wouldn't arise.

Absolutely.  Content conversion extensions are the way to go.

-- Mark --

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

Date: Wed, 16 Mar 2005 19:14:33 -0500
From: Tony Hansen <[email-masked]>
CC: [email-masked]
Subject: Re: Size Indications in IMAP (was Split Implementations of PGP)
Sender: [email-masked]

I ran into a similar situation with a vendor of voice mail products. 
They stored the voice messages in their imap servers in a proprietary 
format, but when you asked for the messages, converted them on the fly 
into wav format. It happens that the wav format was always smaller than 
the original format, so the message body we'd get would be padded at the 
end with tons of space-filled blank lines to make up for the size 
difference.

If this particular case had been done using content conversion 
extensions, ala lemonade, the issue wouldn't arise.

	Tony Hansen
	[email-masked]

Date: Wed, 16 Mar 2005 13:38:38 -0800
From: Mark Crispin <[email-masked]>
To: Eric Burger <[email-masked]>
cc: [email-masked]
Subject: Re: Size Indications in IMAP (was Split Implementations of PGP)
Organization: Networks & Distributed Computing
Sender: [email-masked]

>> If there is anything that further work on IMAP, be it Lemonade, or
>> anything else does that could help security, it would be to break
>> IMAP's prissiness about message length.

I am totally and inalterably opposed to this.

There is a fundamental misunderstanding about IMAP that leads to this 
request.  The sizes in question are the sizes of the message as stored on 
the server (and presumably transmitted via the SMTP infrastructure). 
They are most emphatically *not* sizes of data as transformed by some 
mechanism such as decryption, or QUOTED-PRINTABLE/BASE64 decoding (which 
comes into this via a parallel example).

If decryption is to be done, it will be via an IMAP extension mechanism. 
That extension mechanism can decide whether or not to provide any sizes in 
the context of that mechanism.

A good example to see how this works is the BINARY extension.  BINARY is 
most definitely a precedent for how this should work.  BINARY has sizes as 
independent from RFC822.SIZE.

Personally, I consider inaccurate sizes to be far, far, worse than no 
sizes.  If a server-based decryption mechanism can not offer sizes 
efficiently then it shouldn't do so at all.  NNTP and POP3 stand as 
miserable examples of sizes that are worse than useless.

-- Mark --

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

Date: Wed, 16 Mar 2005 13:18:14 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, [email-masked], Eric Burger <[email-masked]>, Alexey Melnikov <[email-masked]>
Subject: Re: Size Indications in IMAP (was Split Implementations of PGP)
Sender: [email-masked]

On Wed, 16 Mar 2005, Timo Sirainen wrote:

>>>> I am not sure I undestand why it is a problem that IMAP returns exact size
>>>> when it is asked to.
>>>
>>> It forces the server to compute the size accurately, which isn't always easy.
>>> Suppose that to hand out a message in RFC822 format, you have to do some
>>> heavy crypto operations. Sign it, perhaps. Then how do you respond to this?
>>>
>>> a fetch 1:* rfc822.size
>>
>> Precompute it once (say, at delivery - but possibly when it is first
>> asked for) and cache the value for all time?
>
> I understood that the point was that server isn't able to decrypt
> messages without client specifically providing the decryption key
> separately for each message, ie. server never knows the user's private
> key. This rules out any pre-caching.

Arnt's example was "server signs the message" which is different, and can 
be precomputed.

Obviously if you don't have the key, you can't decrypt on delivery, you 
need to wait until you get the key (at which point, if the security model 
allows, you *can* cache the result).

> Doing this requires an IMAP extension to transfer the key though, so I
> don't see how this is really a problem if the extension just specifies
> that "when using this extension, the values returned by FETCH
> RFC822.SIZE aren't exact".

Uh, they'd be exact if you were to fetch the RFC822 message, which is 
still encrypted.

If you wanted to download the decrypted message (parts?), since we're 
extending the server anyway I'd expect the server to either provide a 
different (possibly non-exact) decrypted size, or not provide a decrypted 
size at all, as well as a mechanism to specify that you want to download 
the decrypted version.

-Rob

-------------------------------------------------------------------------
Rob Siemborski        |     PGP:0x5CE32FCC     |      [email-masked] 
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

Subject: Re: Size Indications in IMAP (was Split Implementations of PGP)
From: Timo Sirainen <[email-masked]>
To: Rob Siemborski <[email-masked]>
Cc: Arnt Gulbrandsen <[email-masked]>, [email-masked], Eric Burger <[email-masked]>, Alexey Melnikov <[email-masked]>
Date: Wed, 16 Mar 2005 19:48:40 +0200
Sender: [email-masked]

--=-lHZe7/gqvysxQaqrABHw
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2005-03-16 at 12:00 -0500, Rob Siemborski wrote:
> > Alexey Melnikov writes:
> >> I am not sure I undestand why it is a problem that IMAP returns exact =
size=20
> >> when it is asked to.
> >
> > It forces the server to compute the size accurately, which isn't always=
 easy.=20
> > Suppose that to hand out a message in RFC822 format, you have to do som=
e=20
> > heavy crypto operations. Sign it, perhaps. Then how do you respond to t=
his?
> >
> > a fetch 1:* rfc822.size
>=20
> Precompute it once (say, at delivery - but possibly when it is first=20
> asked for) and cache the value for all time?

I understood that the point was that server isn't able to decrypt
messages without client specifically providing the decryption key
separately for each message, ie. server never knows the user's private
key. This rules out any pre-caching.

And as for normal caching, it's good if they're already in cache, but if
you just received 10 new crypted messages and it has to do 10 key
exchanges with your slow mobile phone, it's not good for either speed or
security (as the original message said).

Doing this requires an IMAP extension to transfer the key though, so I
don't see how this is really a problem if the extension just specifies
that "when using this extension, the values returned by FETCH
RFC822.SIZE aren't exact".

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

--=-lHZe7/gqvysxQaqrABHw--

Date: Wed, 16 Mar 2005 12:00:33 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked], Eric Burger <[email-masked]>, Alexey Melnikov <[email-masked]>
Subject: Re: Size Indications in IMAP (was Split Implementations of PGP)
Sender: [email-masked]

On Wed, 16 Mar 2005, Arnt Gulbrandsen wrote:

> Alexey Melnikov writes:
>> I am not sure I undestand why it is a problem that IMAP returns exact size 
>> when it is asked to.
>
> It forces the server to compute the size accurately, which isn't always easy. 
> Suppose that to hand out a message in RFC822 format, you have to do some 
> heavy crypto operations. Sign it, perhaps. Then how do you respond to this?
>
> a fetch 1:* rfc822.size

Precompute it once (say, at delivery - but possibly when it is first 
asked for) and cache the value for all time?

Since the server can't return different message content each time a 
message is requested, you can only sign the thing once anyway.

-Rob

-------------------------------------------------------------------------
Rob Siemborski        |     PGP:0x5CE32FCC     |      [email-masked] 
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

Date: Wed, 16 Mar 2005 16:56:20 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Size Indications in IMAP (was Split Implementations of PGP)
Cc: Eric Burger <[email-masked]>, Alexey Melnikov <[email-masked]>
Sender: [email-masked]

Alexey Melnikov writes:
> I am not sure I undestand why it is a problem that IMAP returns exact 
> size when it is asked to.

It forces the server to compute the size accurately, which isn't always 
easy. Suppose that to hand out a message in RFC822 format, you have to 
do some heavy crypto operations. Sign it, perhaps. Then how do you 
respond to this?

a fetch 1:* rfc822.size

Arnt

Date: Wed, 16 Mar 2005 10:51:02 -0500
From: Cyrus Daboo <[email-masked]>
To: Eric Burger <[email-masked]>, [email-masked]
Subject: Re: Size Indications in IMAP (was Split Implementations of PGP)
Sender: [email-masked]

Hi Eric,

--On Wednesday, March 16, 2005 06:57:16 AM -0500 Eric Burger 
<[email-masked]> wrote:

>> We have the problem that while SMTP and POP consider size information
>> about a message to be advisory, IMAP considers it to be definitive.
>> When you have a message that is compressed, encrypted, signed, base64
>> encoded, put into quoted-printable, etc., it can be very hard
>> to answer
>> the question, "How big is that message?" definitively.

This question is ambiguous - does it mean 'the size of the message (or 
parts) after transfer encodings, encryption, compression etc are removed', 
or 'the size of the message as it is stored in its rfc2822 format on the 
server'? IMAP reports the later size - and there is in general no problem 
in reporting an accurate size for that as the byte count is accurately 
known. IMAP does not report the size of 'decoded' message parts (except for 
the BINARY extension).

Frankly, having implemented both PGP and SMIME support in a client with 
both POP and IMAP, I see no issue at all with the size info reported by 
IMAP. Of course, with the way things are right now wrt MIME multipart 
security, IMAP clients have to in effect behave as POP clients and download 
the entire message data (or at least the entire multipart) in order to do 
crypto processing...

-- 
Cyrus Daboo

Date: Wed, 16 Mar 2005 15:21:12 +0000
From: Alexey Melnikov <[email-masked]>
To: Eric Burger <[email-masked]>
CC: [email-masked]
Subject: Re: Size Indications in IMAP (was Split Implementations of PGP)
Sender: [email-masked]

Eric Burger wrote:

>This message came from the discussion of whether OpenPGP supported split
>decryption (key decryption on the client, body decryption on the server).
>Short answer is yes.  This is an issue that was raised, however.
>
>  
>
>>-----Original Message-----
>>From: [email-masked]
>>[mailto:[email-masked]]On Behalf Of Jon Callas
>>Sent: Wednesday, March 16, 2005 4:47 AM
>>To: OpenPGP
>>Subject: Re: Split Implementations of PGP
>>
>>
>>
>>Something that would help those of us doing crypto and IMAP would be 
>>for IMAP to be less fussy about message size.
>>
>>We have the problem that while SMTP and POP consider size information 
>>about a message to be advisory, IMAP considers it to be definitive. 
>>When you have a message that is compressed, encrypted, signed, base64 
>>encoded, put into quoted-printable, etc., it can be very hard 
>>to answer 
>>the question, "How big is that message?" definitively.
>>
>>While POP, for example, will accept the answer "Um, around 15K" and 
>>copes just fine with the real answer being either 3K or 50K, 
>>IMAP does not. The IMAP client will expect the size reported to be 
>>accurate down to the byte. If there is more, the client will never ask for 
>>it, and if there's less, the client hyperventilates and breaks down sobbing.
>>    
>>
That suggests a problem with an IMAP client. Or lack of understanding of 
IMAP from the author of the message. Or both.

IMAP allows to fetch a full message or a message chunk. In the former 
case the client doesn't need to know the size. In the second case the 
client can ask for a chunk and if it is beyond message end an IMAP 
server should handle this correctly and will return no data.
I am not sure I undestand why it is a problem that IMAP returns exact 
size when it is asked to.

Alexey

From: Eric Burger <[email-masked]>
To: [email-masked]
Subject: Size Indications in IMAP (was Split Implementations of PGP)
Date: Wed, 16 Mar 2005 06:57:16 -0500
Sender: [email-masked]

This message came from the discussion of whether OpenPGP supported split
decryption (key decryption on the client, body decryption on the server).
Short answer is yes.  This is an issue that was raised, however.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jon Callas
> Sent: Wednesday, March 16, 2005 4:47 AM
> To: OpenPGP
> Subject: Re: Split Implementations of PGP
> 
> 
> 
> Something that would help those of us doing crypto and IMAP would be 
> for IMAP to be less fussy about message size.
> 
> We have the problem that while SMTP and POP consider size information 
> about a message to be advisory, IMAP considers it to be definitive. 
> When you have a message that is compressed, encrypted, signed, base64 
> encoded, put into quoted-printable, etc., it can be very hard 
> to answer 
> the question, "How big is that message?" definitively.
> 
> While POP, for example, will accept the answer "Um, around 15K" and 
> copes just fine with the real answer being either 3K or 50K, 
> IMAP does 
> not. The IMAP client will expect the size reported to be 
> accurate down 
> to the byte. If there is more, the client will never ask for 
> it, and if 
> there's less, the client hyperventilates and breaks down sobbing.
> 
> If there is anything that further work on IMAP, be it Lemonade, or 
> anything else does that could help security, it would be to break 
> IMAP's prissiness about message length. The main advantage that this 
> sesson-key decrypting protocol has is that it exposes the server to 
> relatively little of the actual plaintext. However, while this is a 
> theoretic benefit, the practical benefit is lessened by the length 
> requirements.
> 
> Let's suppose I connect to my server and have ten new 
> messages, all of 
> which are encrypted, say five with OpenPGP and five with S/MIME. My 
> client program is going to display the lengths of the messages, but 
> that isn't knowable without decrypting them. So immediately with the 
> headers, all ten of those messages have to be decrypted and processed 
> so that the lengths will be accurate. This slows the system down, 
> because it requires a complete round-trip of session key 
> decryption for 
> each message as well as preliminary processing of the message on the 
> server. If that client program is a mobile device, this is especially 
> bad because the heavy lifting (the public key crypto) is 
> being done on 
> the light device, and the easy lifting (the bulk crypto 
> processing) is 
> being done on the powerful device. What happens is that this 
> architecture maximally slows the email processing down, with 
> relatively 
> low security gains, because the server has gotten the session key for 
> all ten messages, even though I've read exactly zero of them.
> 
> I'd like to see a change to IMAP that allows for the message's length 
> to be advisory until it's actually read. It's relatively easy 
> to do -- 
> you have to have a way to ask the server simply, "Is there more?" as 
> well as the server to be able to return a short (even 
> zero-length) glob 
> of message text.
> 
> This gives a slightly counter-intuitive display on the 
> client. I might 
> look at a list of messages and see that one is 8K long, and 
> when I read 
> that message its length updates to 13K. But in return, we'd 
> be able to 
> defer the cryptography to when a message is actually read, 
> rather than 
> when it enters my inbox.
> 
> 	Jon
> 

Date: Mon, 14 Mar 2005 10:07:31 -0800
From: Himanshu Chatterjee <[email-masked]>
Reply-To: Himanshu Chatterjee <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Subject: Re: rfc 2086 extention
Cc: [email-masked]
Sender: [email-masked]

Thanks Alexey, do you think that we should have some standard ( or
good practice ) of implementing hierarchical acl. I can have a
implementation where from any intermediate parent folder when we
cascade the acl downwards, we can associate some unique tag, with each
of the child folder acl, where this acl is propagating, runtime acl
evaluation can merge the acl at each respective folder. The unique tag
can be helpful in recognizing acl from child folders when we remove
acl from any parent. Other implementation can have a dynamic acl
evaluation maintaining the acl at only at a parent level. But both are
non standard, and i am looking ( or trying to find a  )  a more mature
way to do the things.

Himanshu

On Thu, 10 Mar 2005 19:40:19 +0000, Alexey Melnikov
<[email-masked]> wrote:
> Himanshu Chatterjee wrote:
> 
> >Is there any draft which describes how the hierarchical acl on a
> >folder ( acl given at parent folder and should flow down to all childs
> >) should be implemented. ( Implementation details like when acl is
> >given to a grantee on a folder how the acl is is to be merged and if
> >acl is revoked from parent folder how to remove acl from childs etc.)
> >
> >
> There is none so far, but I've discussed this with my co-workers. So if
> you have any questions/suggestions, feel free to ask.
> 
> Currently my server only allows to attach ACLs to a mailbox and the ACL
> propogates to all submailboxes. So this is a kind of "poor man"s
> hierarchical ACLs.
> 
> Are you planning to implement hierarchical ACLs?
> 
>

Date: Sat, 12 Mar 2005 23:41:15 +0000
From: Alexey Melnikov <[email-masked]>
To: Dave Cridland <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: 2086upd comments
Sender: [email-masked]

Dave Cridland wrote:

> On Thu Mar 10 22:34:26 2005, Alexey Melnikov wrote:
>
>> Cyrus Daboo wrote:
>>
>>> -- Section 4.1: add example with either + or - for rights.
>>
>> I've replaced the first example with the following:
>>
>>               C: A001 GETACL INBOX/Drafts
>>               S: * ACL INBOX/Drafts Fred rwipslxeta Chris lrswi
>>               S: A001 OK Getacl complete
>>               C: A002 SETACL INBOX/Drafts Chris +cda
>>               S: A002 OK Setacl complete
>>               C: A003 GETACL INBOX/Drafts
>>               S: * ACL INBOX/Drafts Fred rwipslxeta Chris lrswicda
>>               S: A003 OK Getacl complete
>
>
> Fred needs additional listing of "d" right, Chris needs additional 
> listing of "kxet" rights, surely?

Thanks, fixed.
The "d" right was missing from the example in section 4.2 as well.

Alexey

From: Dave Cridland <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>, Cyrus Daboo <[email-masked]>
Subject: Re: 2086upd comments
Date: Fri, 11 Mar 2005 11:45:43 +0000
Sender: [email-masked]

On Thu Mar 10 22:34:26 2005, Alexey Melnikov wrote:
> 
> Cyrus Daboo wrote:
> 
>> -- Section 4.1: add example with either + or - for rights.
> 
> I've replaced the first example with the following:
> 
>               C: A001 GETACL INBOX/Drafts
>               S: * ACL INBOX/Drafts Fred rwipslxeta Chris lrswi
>               S: A001 OK Getacl complete
>               C: A002 SETACL INBOX/Drafts Chris +cda
>               S: A002 OK Setacl complete
>               C: A003 GETACL INBOX/Drafts
>               S: * ACL INBOX/Drafts Fred rwipslxeta Chris lrswicda
>               S: A003 OK Getacl complete
> 

Fred needs additional listing of "d" right, Chris needs additional listing of "kxet" rights, surely?

Dave.

Date: Thu, 10 Mar 2005 22:40:18 +0000
From: Alexey Melnikov <[email-masked]>
To: Philip Guenther <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: 2086upd (-03) notes
Sender: [email-masked]

Philip Guenther wrote:

>Is the last paragraph of 6.1.1 trying to say that a single
>SETACL/DELETEACL may affects the ACLs for multiple mailboxes, or
>just that multiple entries in the ACL for the named mailbox?  I
>_think_ the latter was intended, in which case I would suggest
>replacing the paragraph with:
>  
>
Actually both :-), even though the latter is the most common case.

>	A server MAY modify entries in the ACL for more identifiers
>	than just the one in the request.  If such additional entries
>	are modified, the server MUST send an ACL response to inform
>	the client of the change.
>
The current text is:
   An ACL server MAY modify one or more ACL for one or more identifier as a
   side effect of modifying the ACL specified in a SETACL/DELETEACL.
   If the server does that it MUST send untagged ACL response(s) to 
notify the
   client about the changes made.

Note that I've added "(s)" after "response", so if the server modifies 
ACLs for multiple mailboxes, than it will have to send multiple ACL 
responses.

I would rather keep the existing text. Any objections?

Alexey

Date: Thu, 10 Mar 2005 22:34:26 +0000
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: 2086upd comments
Sender: [email-masked]

Cyrus Daboo wrote:

> -- 
> Section 4.1: add example with either + or - for rights.

I've replaced the first example with the following:

               C: A001 GETACL INBOX/Drafts
               S: * ACL INBOX/Drafts Fred rwipslxeta Chris lrswi
               S: A001 OK Getacl complete
               C: A002 SETACL INBOX/Drafts Chris +cda
               S: A002 OK Setacl complete
               C: A003 GETACL INBOX/Drafts
               S: * ACL INBOX/Drafts Fred rwipslxeta Chris lrswicda
               S: A003 OK Getacl complete

Date: Thu, 10 Mar 2005 22:26:01 +0000
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: 2086upd (-03) notes
Sender: [email-masked]

Philip Guenther wrote:

>In section 7 (Security Considerations), what is the restriction on
>LISTRIGHTS to protect against?  If you can use LISTRIGHTS, then you
>can also use SETACL, which provides an avenue for probing for users
>as well.  Must a server _not_ check for the existance of users in
>SETACL too?  If so, there's a lot of servers broken by this.
>
As per recent discussion I've removed:

   LISTRIGHTS command MUST NOT check that a particular identifier exists,
   however it SHOULD recognize special identifiers like "anyone".

If you want it back, please scream now!

Date: Thu, 10 Mar 2005 13:59:27 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Lisa Dusseault <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Recharter
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Thu, 10 Mar 2005, Lisa Dusseault wrote:
> Scott asked us this morning to recharter IMAPEXT to reflect the delayed 
> milestones for all active documents. Can the WG document authors contact me 
> with delivery commitments for next drafts, WG  last call and  submission to 
> IESG (except if you've already met any of those goals)?

I believe that SORT/THREAD is done, and any further needed work on it 
would be entirely editorial in nature.

-- Mark --

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

Cc: [email-masked]
From: Lisa Dusseault <[email-masked]>
Subject: Re: imapext minutes from IETF-62 [DRAFT]
Date: Thu, 10 Mar 2005 13:53:32 -0800
To: Rob Siemborski <[email-masked]>
Sender: [email-masked]

This is great.  I'll just use this opportunity to extract the  
deliverables:
  - Lisa to deliver recharter (new milestone dates) for WG
  - Alexey to produce new draft of 2086upd addressing last-call and  
post-last-call nits
  - Cyrus to produce new draft of annotate addressing last call issues  
and incorporating decisions recorded in these minutes
  - Alexey and Barry to produce new draft of LISTEXT with no open or  
editorial issues remaining, suitable for last call
  - Alexey to produce syntax draft for Annotate to use
  - Tony Hanson and Barry Leiba to review Chris's Comparator draft and  
ping Chris about it
  - Chris Newman to put cycles into Comparator
  - Arnt (who was absent) to review Chris's proposed simplification  
allowing only one comparator per search query

On Mar 10, 2005, at 12:15 PM, Rob Siemborski wrote:

>
> Let me know your comments, I'll send this on to [email-masked]  
> probably tomorrow sometime.
>
> IMAPEXT Meeting at IETF-62, 3-10-2005, 9-11am CST.
>
> These minutes are based off the Jabber log, available here:
> http://www.xmpp.org/ietf-logs/[email-masked]/2005-03-10.htm
>
> Administrivia:
>
> Chairs welcomed the members to the IMAPEXT variety show.  The agenda  
> was bashed.
>
> 2086upd [draft-ietf-imapext-2086upd-03.txt]:
>
> - Chair summarized that people have been reviewing the document,  
> things are looking good and we're almost done.
>
> - Cyrus sent a large number of comments to the list this morning that  
> were mostly minor nits.
>
> - Room consensus that no comments had invalidated last call, and we  
> can move forward.
>
> ANNOTATE [draft-ietf-imapext-annotate-12.txt]:
>
> - Brief discussion about how references when replacing a document work  
> (you don't have to reference a document you are obsoleting)
>
> - Lisa summarized Cyrus's recent changed for the room.
>
> - Use of UTF-8 for values: rough consensus for 'SHOULD' instead of  
> 'MUST'
>
> - Discussion of open issues:
>   - Should servers validate the syntax of the content-type value? Yes.
>     (but should not have to validate that the actual content-type is
>      correct).
>     - We should reference RFC2046 for their content-type syntax.
>   - Should entity registrations contain a default content-type value?
>     - Other questions included:
>       "Should entries be forced to a particular content type?" No
>     - IANA registration will contain a recommended content-type value.
>   - Can values contain binary data?  Can we use the literal8 syntax  
> from
>     BINARY?
>     - Alternate ideas included tagging to indicate that a
>       binary response was desired. (experience from LDAP indicated this
>       was tricky to get right)
>     - Desire to not require BINARY extension, just the syntax.
>     - Desire to move literal8 syntax to the common syntax document.
>     - Rough consensus to use literal8 syntax for all ANNOTATE literals,
>       but no modifications for regular strings.
>     - Rough consensus to move literal8 syntax to the syntax document  
> (out
>       of BINARY).
>   - How to deal with hierarchy levels named 'shared' and 'priv'?
>     - Ambiguity on first hierarchy level.
>     - Rough consensus to just deny them on all levels.
>   - UTF-8 entry/attribute names
>     - We need stringprep for comparisons if they stay UTF-8
>     - Recent lunch BOF proposal to restrict to US-ASCII and have  
> another
>       attribute for UTF-8 display name.
>     - Additionally, clients are not required to use the display name  
> for
>       presentation if they choose not to.
>       - Really, the display name attribute would only be necessary for
>         custom entries (for standard entries, clients could know how  
> they
>         are used).
>     - Point that we will need stringprep for mailbox names eventually
>       anyway. (but this is likely a different stringprep profile).
>     - Observation that mailbox names aren't registered, its much nicer  
> to
>       be able to just register US-ASCII names.
>     - Rough consensus to restrict entry and attribute names to  
> US-ASCII,
>       and include a UTF-8 displayname attribute.
>   - Interaction with CATENATE syntax (for APPEND), since the CATENATE
>     draft is now APPEND-only.  Should we just reference the syntax  
> draft?
>     - Rough consensus: Yes.
>
> - Side discussion about making Alexey's syntax draft an official WG  
> item. Rough consensus to decide after seeing it (Alexey promises to be  
> quick with updates).
>
> - ANNOTATEMORE interaction: there are large blocks of shared text that  
> should now be updated in both places.
>
> LISTEXT [draft-ietf-imapext-list-extensions-11.txt]:
>
> - Philip summarized the changes to LISTEXT proposed at the interim and  
> subsequent list discussion, the main problem being that LIST responses  
> cannot rely on the context of the command that prompted them.
>   - Solution: move lots of this into CHILDINFO.
>
> - Discussion of possible difference in behavior with current RLIST and  
> the
> \Remote flag (currently a server does not need to actually declare  
> what mailboxes are remote and which ones aren't).  This could cause  
> problems for some type of proxies that choose to refer based on if the  
> clients send an RLIST or not.
>   - Probably not a problem, since LIST flags can change at any time,
>     really..
>
> - Issue: The current ABNF is very complex, can it be simplified?
>   - Observation: some of the syntax is performing validation that is
>     really semantic in nature.
>   - Cyrus offered to take a look and suggest text/new ABNF.
>
> - Chair asked authors of LISTEXT to propose strawman for open issues  
> in the next document, continuing to have open issues will just delay  
> the group.
>   - Authors asked that members who disagree with the strawman propose
>     alternates.
>
> Comparator (not a WG item) [draft-newman-i18n-comparator-03.txt]:
> - We have several items that depend on this.
> - Chris tried to find another author, and failed.  He will continue to  
> try
>   to find someone else to work on it, but will also commit some cycles
>   near term.
> - Chris is currently interrupt driven, and asks to be pinged.
>
> ACL2 & Working Group Future:
> - In San Diego we agreed to drop ACL2 if there had been no progress by  
> this meeting.  There hasn't been progress on ACL2, but there has been  
> substantial other progress.  Chair asks if we want to extend our  
> deadline given this (and adjust charter dates).
>   - Scott (AD) is ok with this.
>   - Rough consensus to revisit ACL2 in 6 months.
>
> - Members should watch the LEMONADE group for some of their  
> encrypted/signed message issues.  IMAPEXT (or at least its members)  
> should be involved in a deep way.
>
> i18n Document [draft-ietf-imapext-i18n-04.txt]:
> - Chris asks if we can simplify the use of comparators in the search  
> program so that one comparator could be used for the entire program.
>   - Example use case: search for case-sensitive local part and
>     case-insensitive domain part of an address.
>   - Point that we could accomplish most of the usefulness of this with
>     the ability to search within results.
>   - Rough consensus to simplify in this way, and allow for a future
>     extension to do the recursive search.  Chris will send a message to
>     Arnt and the list.
>
>
> ----------------------------------------------------------------------- 
> --
> Rob Siemborski        |     PGP:0x5CE32FCC     |       
> [email-masked] -----BEGIN GEEK CODE BLOCK----
> Version: 3.12
> GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w--  
> O-
> M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
> ------END GEEK CODE BLOCK-----
>

From: "Scott Hollenbeck" <[email-masked]>
To: "'Lisa Dusseault'" <[email-masked]>, "'IMAP Extensions WG'" <[email-masked]>
Subject: RE: Recharter
Date: Thu, 10 Mar 2005 16:53:33 -0500
Importance: Normal
Sender: [email-masked]

I wouldn't exactly call what's needed a "recharter" since the charter itself
should remain unchanged and IESG approval won't be required.  "Update the
milestones" would be a better way to describe what I asked for.

-Scott-

> -----Original Message-----
> From: Lisa Dusseault [mailto:[email-masked]] 
> Sent: Thursday, March 10, 2005 4:46 PM
> To: IMAP Extensions WG
> Subject: Recharter
> 
> 
> 
> Scott asked us this morning to recharter IMAPEXT to reflect 
> the delayed 
> milestones for all active documents. Can the WG document authors 
> contact me with delivery commitments for next drafts, WG  
> last call and 
>   submission to IESG (except if you've already met any of 
> those goals)?
> 
> thx,
> Lisa
> 
> 

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Recharter
Date: Thu, 10 Mar 2005 13:46:19 -0800
Sender: [email-masked]

Scott asked us this morning to recharter IMAPEXT to reflect the delayed 
milestones for all active documents. Can the WG document authors 
contact me with delivery commitments for next drafts, WG  last call and 
  submission to IESG (except if you've already met any of those goals)?

thx,
Lisa

Date: Thu, 10 Mar 2005 21:28:17 +0000
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: 2086upd comments
Sender: [email-masked]

Cyrus Daboo wrote:

> -- 
> Really ought to have i18n considerations section that restates the 
> SASLprep usage.

I've added:

10.   Internationalization Considerations

   Section 4 states requirements on servers regarding internationalization
   of identifiers.

===
I would rather not to repeat the text already stated elsewhere.

> Should the term 'authentication identifier' actually be 'authorization 
> identifier'? We are dealing with authorization here.
>
> -- 
> Some places 'identifier' is used others 'authentication identifier' - 
> needs to be conistent. In fact I would prefer to remove 
> 'authentication' (or 'authorization') entirely and just use identifier 
> or another term (e.g. WebDAV uses 'principal'). This is because these 
> items refer to things like groups as well.

I've replaced "authentication identifier" with just "identifier" everywhere.
I would rather not use the term "principal", as this has a strong 
association with Kerberos principals, at least for me.

Alexey

Date: Thu, 10 Mar 2005 15:15:58 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: [email-masked]
Subject: imapext minutes from IETF-62 [DRAFT]
Sender: [email-masked]

Let me know your comments, I'll send this on to [email-masked] probably 
tomorrow sometime.

IMAPEXT Meeting at IETF-62, 3-10-2005, 9-11am CST.

These minutes are based off the Jabber log, available here:
http://www.xmpp.org/ietf-logs/[email-masked]/2005-03-10.htm

Administrivia:

Chairs welcomed the members to the IMAPEXT variety show.  The agenda was 
bashed.

2086upd [draft-ietf-imapext-2086upd-03.txt]:

- Chair summarized that people have been reviewing the document, things 
are looking good and we're almost done.

- Cyrus sent a large number of comments to the list this morning that were 
mostly minor nits.

- Room consensus that no comments had invalidated last call, and we can 
move forward.

ANNOTATE [draft-ietf-imapext-annotate-12.txt]:

- Brief discussion about how references when replacing a document work 
(you don't have to reference a document you are obsoleting)

- Lisa summarized Cyrus's recent changed for the room.

- Use of UTF-8 for values: rough consensus for 'SHOULD' instead of 'MUST'

- Discussion of open issues:
   - Should servers validate the syntax of the content-type value? Yes.
     (but should not have to validate that the actual content-type is
      correct).
     - We should reference RFC2046 for their content-type syntax.
   - Should entity registrations contain a default content-type value?
     - Other questions included:
       "Should entries be forced to a particular content type?" No
     - IANA registration will contain a recommended content-type value.
   - Can values contain binary data?  Can we use the literal8 syntax from
     BINARY?
     - Alternate ideas included tagging to indicate that a
       binary response was desired. (experience from LDAP indicated this
       was tricky to get right)
     - Desire to not require BINARY extension, just the syntax.
     - Desire to move literal8 syntax to the common syntax document.
     - Rough consensus to use literal8 syntax for all ANNOTATE literals,
       but no modifications for regular strings.
     - Rough consensus to move literal8 syntax to the syntax document (out
       of BINARY).
   - How to deal with hierarchy levels named 'shared' and 'priv'?
     - Ambiguity on first hierarchy level.
     - Rough consensus to just deny them on all levels.
   - UTF-8 entry/attribute names
     - We need stringprep for comparisons if they stay UTF-8
     - Recent lunch BOF proposal to restrict to US-ASCII and have another
       attribute for UTF-8 display name.
     - Additionally, clients are not required to use the display name for
       presentation if they choose not to.
       - Really, the display name attribute would only be necessary for
         custom entries (for standard entries, clients could know how they
         are used).
     - Point that we will need stringprep for mailbox names eventually
       anyway. (but this is likely a different stringprep profile).
     - Observation that mailbox names aren't registered, its much nicer to
       be able to just register US-ASCII names.
     - Rough consensus to restrict entry and attribute names to US-ASCII,
       and include a UTF-8 displayname attribute.
   - Interaction with CATENATE syntax (for APPEND), since the CATENATE
     draft is now APPEND-only.  Should we just reference the syntax draft?
     - Rough consensus: Yes.

- Side discussion about making Alexey's syntax draft an official WG item. 
Rough consensus to decide after seeing it (Alexey promises to be quick 
with updates).

- ANNOTATEMORE interaction: there are large blocks of shared text that 
should now be updated in both places.

LISTEXT [draft-ietf-imapext-list-extensions-11.txt]:

- Philip summarized the changes to LISTEXT proposed at the interim and 
subsequent list discussion, the main problem being that LIST responses 
cannot rely on the context of the command that prompted them.
   - Solution: move lots of this into CHILDINFO.

- Discussion of possible difference in behavior with current RLIST and the
\Remote flag (currently a server does not need to actually declare what 
mailboxes are remote and which ones aren't).  This could cause problems 
for some type of proxies that choose to refer based on if the clients send 
an RLIST or not.
   - Probably not a problem, since LIST flags can change at any time,
     really..

- Issue: The current ABNF is very complex, can it be simplified?
   - Observation: some of the syntax is performing validation that is
     really semantic in nature.
   - Cyrus offered to take a look and suggest text/new ABNF.

- Chair asked authors of LISTEXT to propose strawman for open issues in 
the next document, continuing to have open issues will just delay the 
group.
   - Authors asked that members who disagree with the strawman propose
     alternates.

Comparator (not a WG item) [draft-newman-i18n-comparator-03.txt]:
- We have several items that depend on this.
- Chris tried to find another author, and failed.  He will continue to try
   to find someone else to work on it, but will also commit some cycles
   near term.
- Chris is currently interrupt driven, and asks to be pinged.

ACL2 & Working Group Future:
- In San Diego we agreed to drop ACL2 if there had been no progress by 
this meeting.  There hasn't been progress on ACL2, but there has been 
substantial other progress.  Chair asks if we want to extend our deadline 
given this (and adjust charter dates).
   - Scott (AD) is ok with this.
   - Rough consensus to revisit ACL2 in 6 months.

- Members should watch the LEMONADE group for some of their 
encrypted/signed message issues.  IMAPEXT (or at least its members) should 
be involved in a deep way.

i18n Document [draft-ietf-imapext-i18n-04.txt]:
- Chris asks if we can simplify the use of comparators in the search 
program so that one comparator could be used for the entire program.
   - Example use case: search for case-sensitive local part and
     case-insensitive domain part of an address.
   - Point that we could accomplish most of the usefulness of this with
     the ability to search within results.
   - Rough consensus to simplify in this way, and allow for a future
     extension to do the recursive search.  Chris will send a message to
     Arnt and the list.

-------------------------------------------------------------------------
Rob Siemborski        |     PGP:0x5CE32FCC     |      [email-masked] 
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

Date: Thu, 10 Mar 2005 19:31:13 +0000
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: 2086upd comments
Sender: [email-masked]

Cyrus Daboo wrote:

> Section 6.1.2 - client cannot preserve an unknown tied right, when 
> changing the known tied right. e.g. if we have tied rights 'r1', and 
> the client does not understand '1', it must still be able to remove 
> 'r' (and thus '1') without violating spec.

The client should ask the user if she wants to either set both, or 
remove both. That was the intent.
The text is trying to say that the default should be to set both.
This needs to be clarified.

Alexey

Date: Thu, 10 Mar 2005 12:20:55 -0500
From: Tony Hansen <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: 2086upd comments
Sender: [email-masked]

If you >>update<< a previous document, then you need a normative 
reference to the previous document for the parts that are still relevant.

A prerequisite to being able to say that you are obsoleting a previous 
document is that you must be totally replacing the previous document. So 
there is nothing in the previous document that you need in order to 
implement the updated version. If you can't make this statement, then 
you either need to change your claim to "updates" OR change your 
document such that you *can* make the statement that it "obsoletes" the 
previous document. Once you pass this litmus test, it's clear that the 
previous document is not required and should not be a normative reference.

	Tony Hansen
	[email-masked]

Alexey Melnikov wrote:
> 
> Cyrus Daboo wrote:
> 
>> Hi Alexey,
>>
>> --On March 10, 2005 2:56:42 PM +0000 Alexey Melnikov 
>> <[email-masked]> wrote:
>>
>>>> Is 2086 reference really only informative?
>>>
>>>
>>> 2086upd obsoletes RFC 2086. Can it have a normative reference to the
>>> document being obsoleted?
>>
>>
>> Well, is 2086 original needed in order to implement 2086upd.
> 
> 
> Not needed.
> 
>> Actually looking at it I think not, so maybe it can be informative.
> 
> 
> 
> 

Date: Thu, 10 Mar 2005 17:02:31 +0000
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: 2086upd comments
Sender: [email-masked]

Cyrus Daboo wrote:

> Hi Alexey,
>
> --On March 10, 2005 2:56:42 PM +0000 Alexey Melnikov 
> <[email-masked]> wrote:
>
>>> Is 2086 reference really only informative?
>>
>> 2086upd obsoletes RFC 2086. Can it have a normative reference to the
>> document being obsoleted?
>
> Well, is 2086 original needed in order to implement 2086upd.

Not needed.

> Actually looking at it I think not, so maybe it can be informative.

Cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Re: 2086upd comments
Date: Thu, 10 Mar 2005 08:08:50 -0800
To: Cyrus Daboo <[email-masked]>
Sender: [email-masked]

>> ("/=" ==> "=/")
>>
>> Sure, this is an easy addition.
>
> I would also like to request the chairs to also 'enforce' that for the 
> other extensions, including the lemonade ones.
>
>
Sounds good; probalby the cleanest way to start this is to send a mail 
to Lemonade as there are quite a few reading that list and not this 
list.

Lisa

Date: Thu, 10 Mar 2005 15:09:14 +0000
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: 2086upd comments
Sender: [email-masked]

Cyrus Daboo wrote:

> In Section 'Rights required to perform different IMAP4rev1 commands' - 
> this is not quite right for the LIST/LSUB case. For those, executing 
> the command is always allowed - but there are no results. That is 
> different from e.g. SELECT, where lack of the r right causes a NO 
> response.

Ok, I've added:

    However, unlike other commands (e.g. SELECT) the server MUST NOT 
return a NO response if it can't list a mailbox.

Is this sufficient?

Date: Thu, 10 Mar 2005 10:05:21 -0500
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: 2086upd comments
Sender: [email-masked]

Hi Alexey,

--On March 10, 2005 2:56:42 PM +0000 Alexey Melnikov 
<[email-masked]> wrote:

>> Is 2086 reference really only informative?
>
> 2086upd obsoletes RFC 2086. Can it have a normative reference to the
> document being obsoleted?

Well, is 2086 original needed in order to implement 2086upd. Actually 
looking at it I think not, so maybe it can be informative.

>> --
>> General issue with extensions: shouldn't the capability identifier be
>> clearly defined in the formal syntax? Most extensions just state what
>> the capability is in the text - I now think that is wrong and that
>> they should extend the 3501 capability syntax item. e.g.:
>>
>> for 2086upd:
>>
>>     capability      /= rights-capa
>>
>> for ANNOTATE:
>>
>>     capability        /= "ANNOTATE"
>
> ("/=" ==> "=/")
>
> Sure, this is an easy addition.

I would also like to request the chairs to also 'enforce' that for the 
other extensions, including the lemonade ones.

-- 
Cyrus Daboo

Date: Thu, 10 Mar 2005 14:56:42 +0000
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: 2086upd comments
Sender: [email-masked]

Answering to some of the comments.

Cyrus Daboo wrote:

> Section 1: says '/' is used as hierarchy separator, but many examples 
> also use '.'.

Fixed, even thought I can pretend that "INBOX.Drafts" is just a 
non-hierarchical name ;-).
...

> -- 
> What about existing extensions: NAMESPACE, UNSELECT, RLIST, IDLE? I 
> think 2086upd should say something about those since they do exit now.

I don't want to have any unnecessary dependencies. There is a separate 
draft (draft-melnikov-acl-rights-XX.txt) that lists rights for URLAUTH 
commands, I can describe NAMESPACE, UNSELECT and IDLE there.

RLIST - I think it is deprecated by LISTEXT, so I wouldn't bother.

> In formal syntax:
>
>   rights          = astring
>                      ;; only lowercase ASCII letters and digits
>                      ;; are allowed.
>     
>     why not use explicit character ranges for defining this?

I don't really care. Any opinions?

> -- 
> Is 2086 reference really only informative?

2086upd obsoletes RFC 2086. Can it have a normative reference to the 
document being obsoleted?

> -- 
> General issue with extensions: shouldn't the capability identifier be 
> clearly defined in the formal syntax? Most extensions just state what 
> the capability is in the text - I now think that is wrong and that 
> they should extend the 3501 capability syntax item. e.g.:
>
> for 2086upd:
>
>     capability      /= rights-capa
>
> for ANNOTATE:
>
>     capability        /= "ANNOTATE"

("/=" ==> "=/")

Sure, this is an easy addition.
  
Alexey

Date: Thu, 10 Mar 2005 09:50:30 -0500
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: listext issue
Sender: [email-masked]

Problem in Formal Syntax:

   list-select-opts   = "(" [*(list-select-mod-opt SP) list-select-base-opt

                                       ^                       ^

That should be:

   list-select-opts   = "(" [*(list-sel-mod-opt SP) list-sel-base-opt

-- 
Cyrus Daboo

Date: Thu, 10 Mar 2005 09:22:35 -0500
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: 2086upd comments
Sender: [email-masked]

--
Section 1: says '/' is used as hierarchy separator, but many examples also 
use '.'.

--
Really ought to have i18n considerations section that restates the SASLprep 
usage.

--
Section 4.1: add example with either + or - for rights.

--
Should the term 'authentication identifier' actually be 'authorization 
identifier'? We are dealing with authorization here.

--
Some places 'identifier' is used others 'authentication identifier' - needs 
to be conistent. In fact I would prefer to remove 'authentication' (or 
'authorization') entirely and just use identifier or another term (e.g. 
WebDAV uses 'principal'). This is because these items refer to things like 
groups as well.

--
In Section 'Rights required to perform different IMAP4rev1 commands' - this 
is not quite right for the LIST/LSUB case. For those, executing the command 
is always allowed - but there are no results. That is different from e.g. 
SELECT, where lack of the r right causes a NO response.

--
In rights table, use 'i' to indicate 'implicit' rights. e.g. for FETCH, the 
'r' right is implicit as that is needed to first SELECT the mailbox. 
Alternatively, provide clear splits in the table for sections based on IMAP 
state (unauthenticate, authenticated, selected)

--
What about existing extensions: NAMESPACE, UNSELECT, RLIST, IDLE? I think 
2086upd should say something about those since they do exit now.

--
Section 6.1.2 - client cannot preserve an unknown tied right, when changing 
the known tied right. e.g. if we have tied rights 'r1', and the client does 
not understand '1', it must still be able to remove 'r' (and thus '1') 
without violating spec.

--
In formal syntax:

   rights          = astring
                      ;; only lowercase ASCII letters and digits
                      ;; are allowed.
	
	why not use explicit character ranges for defining this?

--
Is 2086 reference really only informative?

--
General issue with extensions: shouldn't the capability identifier be 
clearly defined in the formal syntax? Most extensions just state what the 
capability is in the text - I now think that is wrong and that they should 
extend the 3501 capability syntax item. e.g.:

for 2086upd:

	capability      /= rights-capa

for ANNOTATE:

	capability		/= "ANNOTATE"

-- 
Cyrus Daboo

Date: Wed, 9 Mar 2005 17:04:09 -0800
From: Himanshu Chatterjee <[email-masked]>
Reply-To: Himanshu Chatterjee <[email-masked]>
To: [email-masked]
Subject: rfc 2086 extention
Sender: [email-masked]

Is there any draft which describes how the hierarchical acl on a
folder ( acl given at parent folder and should flow down to all childs
) should be implemented. ( Implementation details like when acl is
given to a grantee on a folder how the acl is is to be merged and if
acl is revoked from parent folder how to remove acl from childs etc.)

Himanshu

Date: Wed, 9 Mar 2005 16:31:27 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: Philip Guenther <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: 2086upd (-03) notes
Sender: [email-masked]

On Wed, 9 Mar 2005, Alexey Melnikov wrote:

> The text is trying to say that the server should not disclose non-existence 
> of a user, i.e. it should not do the following:
>
>  C: a001 LISTRIGHTS Drafts foo
>  S: a001 NO user foo is not a valid user.

Ah, I was confusing LISTRIGHTS with GETACL.

This seems like it can be removed.

>> I also just noticed that Appendix C omits another ACL deficiency: the fact 
>> that users, groups, and special identifiers (e.g. anyone) exist in the 
>> same namespace (which ACL2 was solving with user=foo and group=bar type 
>> identifiers).
>
> I've added this to the Appendix C, thanks.

-Rob

-------------------------------------------------------------------------
Rob Siemborski        |     PGP:0x5CE32FCC     |      [email-masked] 
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

Date: Wed, 09 Mar 2005 21:26:34 +0000
From: Alexey Melnikov <[email-masked]>
To: Philip Guenther <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: 2086upd (-03) notes
Sender: [email-masked]

Philip Guenther wrote:

>Word-smithing *suggestions*:
>
>section 3.1:
>	Add FETCH BODY[...] to list for 's' right
>  
>
Ok.

>	Wording between 's', 'w', and 't' rights is inconsistent;
>	suggest changing to match 't'.
>  
>
Done.

>section 3.1.1:
>	Footnotes are not permitted by RFC editor.  The first
>	footnote can be made the second sentence of the second
>	paragraph.  The second footnote can be made the last paragraph
>	of the section, perhaps with additional indentation?
>
I would rather leave this for now and let an RFC editor decide.

>
>
>	Replace "rights to access a mailbox" with "rights on a mailbox"
>  
>
Done.

>section 3.2:
>	Replace the entire contents of the section with
>		The "RIGHTS=" capability MUST NOT include any of
>		the rights defined in RFC 2086: "l", "r", "s", "w",
>		"i", "p", "a", "c", "d", and the digits.
>  
>
Done.

>section 6.2:
>	The phrase "ACL server" should be changed to just "server"
>	in two places.  (That, or "server supporting ACL")
>
I've added:

   The phrase "ACL server" is just a short cut for saying "IMAP server
   that supports ACL extension as defined in this document".

to the section 1 instead, is it Ok?

Alexey

Date: Wed, 09 Mar 2005 21:07:57 +0000
From: Alexey Melnikov <[email-masked]>
To: Rob Siemborski <[email-masked]>
CC: Philip Guenther <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: 2086upd (-03) notes
Sender: [email-masked]

Rob Siemborski wrote:

>> In section 7 (Security Considerations), what is the restriction on
>> LISTRIGHTS to protect against?  If you can use LISTRIGHTS, then you
>> can also use SETACL, which provides an avenue for probing for users
>> as well.  Must a server _not_ check for the existance of users in
>> SETACL too?  If so, there's a lot of servers broken by this.
>
>
> Isn't this basicly saying "If you see an identifier that isn't in your 
> identifier database, please transmit it anyway and don't blow up?"

Not quite.

The text is trying to say that the server should not disclose 
non-existence of a user, i.e. it should not do the following:

   C: a001 LISTRIGHTS Drafts foo
   S: a001 NO user foo is not a valid user.

Now, Philip has pointed out that LISTRIGHTS and SETACL require the same 
privileges (the "a" right), and SETACL can be used to probe for users.

So, do people think that the recommendation should be removed?

> I'm not sure why this is a security consideration.
>
> I also just noticed that Appendix C omits another ACL deficiency: the 
> fact that users, groups, and special identifiers (e.g. anyone) exist 
> in the same namespace (which ACL2 was solving with user=foo and 
> group=bar type identifiers).

I've added this to the Appendix C, thanks.

Alexey

Date: Wed, 9 Mar 2005 10:54:22 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Philip Guenther <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: 2086upd (-03) notes
Sender: [email-masked]

On Wed, 9 Mar 2005, Philip Guenther wrote:

> Overall, I think this is practically ready to go.

Likewise.

> In section 7 (Security Considerations), what is the restriction on
> LISTRIGHTS to protect against?  If you can use LISTRIGHTS, then you
> can also use SETACL, which provides an avenue for probing for users
> as well.  Must a server _not_ check for the existance of users in
> SETACL too?  If so, there's a lot of servers broken by this.

Isn't this basicly saying "If you see an identifier that isn't in your 
identifier database, please transmit it anyway and don't blow up?"

I'm not sure why this is a security consideration.

I also just noticed that Appendix C omits another ACL deficiency: the fact 
that users, groups, and special identifiers (e.g. anyone) exist in the 
same namespace (which ACL2 was solving with user=foo and group=bar type 
identifiers).

-Rob

-------------------------------------------------------------------------
Rob Siemborski        |     PGP:0x5CE32FCC     |      [email-masked] 
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

To: IMAP Extensions WG <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: 2086upd (-03) notes
Date: Wed, 09 Mar 2005 07:32:46 -0800
Sender: [email-masked]

Overall, I think this is practically ready to go.  I have some
word-smithing suggestions below, but first a couple substantive
items.

Is the last paragraph of 6.1.1 trying to say that a single
SETACL/DELETEACL may affects the ACLs for multiple mailboxes, or
just that multiple entries in the ACL for the named mailbox?  I
_think_ the latter was intended, in which case I would suggest
replacing the paragraph with:
	A server MAY modify entries in the ACL for more identifiers
	than just the one in the request.  If such additional entries
	are modified, the server MUST send an ACL response to inform
	the client of the change.

In section 7 (Security Considerations), what is the restriction on
LISTRIGHTS to protect against?  If you can use LISTRIGHTS, then you
can also use SETACL, which provides an avenue for probing for users
as well.  Must a server _not_ check for the existance of users in
SETACL too?  If so, there's a lot of servers broken by this.

Word-smithing *suggestions*:

section 3.1:
	Add FETCH BODY[...] to list for 's' right

	Wording between 's', 'w', and 't' rights is inconsistent;
	suggest changing to match 't'.

section 3.1.1:
	Footnotes are not permitted by RFC editor.  The first
	footnote can be made the second sentence of the second
	paragraph.  The second footnote can be made the last paragraph
	of the section, perhaps with additional indentation?

	Replace "rights to access a mailbox" with "rights on a mailbox"

section 3.2:
	Replace the entire contents of the section with
		The "RIGHTS=" capability MUST NOT include any of
		the rights defined in RFC 2088: "l", "r", "s", "w",
		"i", "p", "a", "c", "d", and the digits.

section 6.2:
	The phrase "ACL server" should be changed to just "server"
	in two places.  (That, or "server supporting ACL")

Philip Guenther

To: Cyrus Daboo <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: Re: Revised Agenda for IMAPEXT 
Date: Tue, 08 Mar 2005 14:04:58 -0800
Sender: [email-masked]

Cyrus Daboo <[email-masked]> writes:
>--On March 8, 2005 1:18:19 PM -0800 Mark Crispin <[email-masked]> 
>wrote:
...
>> No.  We need a stringprep profile for mailbox names in IMAP.
>>
>> It's not just URLs.
>
>Right - that's what I meant, but we need it BEFORE we start deploying 
>CATENATE and URLAUTH otherwise we are asking for trouble.

How so?  An imap: URL is going to be generated by an IMAP client, the
mailbox part being recoded from a LIST or LSUB response.  You do *no*
canonicalization when generating imap: URLs, just recoding.

Philip Guenther

To: Cyrus Daboo <[email-masked]>
Cc: Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: Re: Revised Agenda for IMAPEXT 
Date: Tue, 08 Mar 2005 13:45:01 -0800
Sender: [email-masked]

Cyrus Daboo <[email-masked]> writes:
...
>What do you want to do about ANNOTATEMORE - that has mailbox names in the 
>entries. I think it would be a big mistake to have to go back to using 
>modified-utf7 there.

Cyrus, where in ANNOTATEMORE are mailbox names in entries?  Looking at
draft -06, I only see them as separate arguments to GETANNOTATION and
SETANNOTATION commands...

Philip Guenther

Date: Tue, 08 Mar 2005 16:41:39 -0500
From: Cyrus Daboo <[email-masked]>
To: Lisa Dusseault <[email-masked]>
cc: Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Character sets, encodings and names of things
Sender: [email-masked]

Hi Lisa,

--On March 8, 2005 1:33:25 PM -0800 Lisa Dusseault <[email-masked]> 
wrote:

> Trying to follow, but Philip and I are confused about this exchange, or
> at least I'm confused and Philip hasn't been able to remove my confusion.
>
> What do mailbox names being in UTF-8 or UTF-8 requiring stringprep have
> to do with attribute names (IDs) being ASCII?  Your message that sparked
> this thead implied that ANNOTATEMORE did something with mailbox names
> that would affect the character set requirements of attribute names, but
> I don't see that in looking at ANNOTATEMORE.
>

Ignore my ANNOTATEMORE comments - utf8 mailbox names are not going to be 
any more of an issue there than it is elsewhere. ANNOTATEMORE can use ascii 
for entry and attribute names as per new proposal for ANNOTATE.

-- 
Cyrus Daboo

To: Cyrus Daboo <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: Re: Revised Agenda for IMAPEXT 
Date: Tue, 08 Mar 2005 13:40:26 -0800
Sender: [email-masked]

Cyrus Daboo <[email-masked]> writes:
...
>But, isn't it the case that we need a stringprep profile for mailbox names 
>in IMAP URLs used in CATENATE and URLAUTH?

I don't think so: they're just referencing (recoded) names from the IMAP
protocol.  The interpretation of an IMAP URL is described as being "as
if" the client authenticated and used SELECT with the mUTF-7 form of the
mailbox name; matching is the responsibility of IMAP's SELECT and not
CATENATE or URLAUTH.

Philip Guenther

Date: Tue, 08 Mar 2005 16:37:16 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Lisa Dusseault <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Revised Agenda for IMAPEXT
Sender: [email-masked]

Hi Mark,

--On March 8, 2005 1:18:19 PM -0800 Mark Crispin <[email-masked]> 
wrote:

>> But, isn't it the case that we need a stringprep profile for mailbox
>> names in  IMAP URLs used in CATENATE and URLAUTH?
>
> No.  We need a stringprep profile for mailbox names in IMAP.
>
> It's not just URLs.

Right - that's what I meant, but we need it BEFORE we start deploying 
CATENATE and URLAUTH otherwise we are asking for trouble.

-- 
Cyrus Daboo

Cc: Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Character sets, encodings and names of things
Date: Tue, 8 Mar 2005 13:33:25 -0800
To: Cyrus Daboo <[email-masked]>
Sender: [email-masked]

Trying to follow, but Philip and I are confused about this exchange, or 
at least I'm confused and Philip hasn't been able to remove my 
confusion.

What do mailbox names being in UTF-8 or UTF-8 requiring stringprep have 
to do with attribute names (IDs) being ASCII?  Your message that 
sparked this thead implied that ANNOTATEMORE did something with mailbox 
names that would affect the character set requirements of attribute 
names, but I don't see that in looking at ANNOTATEMORE.

Lisa

On Mar 8, 2005, at 12:59 PM, Cyrus Daboo wrote:

> Hi Mark,
>
> --On March 8, 2005 12:50:16 PM -0800 Mark Crispin 
> <[email-masked]> wrote:
>
>>> No - isn't it %-style encoding UTF8 within the URL?
>>
>> We're splitting semantics here, but %-style encoding is not UTF-8, 
>> even
>> if it represents UTF-8 octets.  UTF-8 is 8-bit.
>>
>> Even though %-style encoding may appear to be "just" a trivial 
>> encoding
>> of UTF-8, it is nonetheless a separate way of encoding Unicode.
>>
>
> Well, OK.
>
> But, isn't it the case that we need a stringprep profile for mailbox 
> names in IMAP URLs used in CATENATE and URLAUTH?
>
> -- 
> Cyrus Daboo

Date: Tue, 8 Mar 2005 13:18:19 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Lisa Dusseault <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Revised Agenda for IMAPEXT
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 8 Mar 2005, Cyrus Daboo wrote:
> But, isn't it the case that we need a stringprep profile for mailbox names in 
> IMAP URLs used in CATENATE and URLAUTH?

No.  We need a stringprep profile for mailbox names in IMAP.

It's not just URLs.

-- Mark --

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

Date: Tue, 08 Mar 2005 15:59:21 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Lisa Dusseault <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Revised Agenda for IMAPEXT
Sender: [email-masked]

Hi Mark,

--On March 8, 2005 12:50:16 PM -0800 Mark Crispin <[email-masked]> 
wrote:

>> No - isn't it %-style encoding UTF8 within the URL?
>
> We're splitting semantics here, but %-style encoding is not UTF-8, even
> if it represents UTF-8 octets.  UTF-8 is 8-bit.
>
> Even though %-style encoding may appear to be "just" a trivial encoding
> of UTF-8, it is nonetheless a separate way of encoding Unicode.
>

Well, OK.

But, isn't it the case that we need a stringprep profile for mailbox names 
in IMAP URLs used in CATENATE and URLAUTH?

-- 
Cyrus Daboo

Date: Tue, 8 Mar 2005 12:50:16 -0800
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Lisa Dusseault <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Revised Agenda for IMAPEXT
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 8 Mar 2005, Cyrus Daboo wrote:
> No - isn't it %-style encoding UTF8 within the URL?

We're splitting semantics here, but %-style encoding is not UTF-8, even if 
it represents UTF-8 octets.  UTF-8 is 8-bit.

Even though %-style encoding may appear to be "just" a trivial encoding of 
UTF-8, it is nonetheless a separate way of encoding Unicode.

-- Mark --

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

Date: Tue, 08 Mar 2005 20:48:00 +0000
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: Revised Agenda for IMAPEXT
Sender: [email-masked]

Lisa Dusseault wrote:

> 30 min -- Issues remaining with Annotate - Randy
>     - Use of StringPrep to handle UTF8 entry/attribute names
>     - OR proposal to replace UTF8 attribute name with ASCII attribute 
> name + UTF8 "displayname"
>     - Plans for next draft, possible reissue of Last Call

I've just submitted my initial proposal with IMAP4 ABNF extensions, 
extracted from CONDSTORE, ANNOTATE, CATENATE and ESEARCH.
Before it is announced, you can view it at
<http://ietf.webdav.org/users/amelnikov/draft-melnikov-imap-ext-abnf-00.txt>

Alexey

Date: Tue, 08 Mar 2005 15:45:20 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Lisa Dusseault <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Revised Agenda for IMAPEXT
Sender: [email-masked]

Hi Mark,

--On March 8, 2005 12:32:45 PM -0800 Mark Crispin <[email-masked]> 
wrote:

>> BTW Both CATENEATE and URLAUTH use IMAP URL's which use UTF8 encoded
>> mailbox  names - so in some sense we are already mixing mUTF7 and UTF8
>> with those...
>
> Sigh, yes.  Section 9 of RFC 2192 was IMHO a mistake, but it's there.
>
> However, note that the URLs are still encoded in 7-bit, albeit in a
> different way than mUTF7.  So this isn't actually UTF-8, but rather
> YA7BEOU (Yet Another 7-Bit Encoding Of Unicode).
>

No - isn't it %-style encoding UTF8 within the URL? That my reading of 
Section 9, but I see the example in Section 10 does not have valid UTF8 
%-encoded characters...maybe I am missing something here.

-- 
Cyrus Daboo

Date: Tue, 8 Mar 2005 12:32:45 -0800
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Lisa Dusseault <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Revised Agenda for IMAPEXT
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 8 Mar 2005, Cyrus Daboo wrote:
> BTW Both CATENEATE and URLAUTH use IMAP URL's which use UTF8 encoded mailbox 
> names - so in some sense we are already mixing mUTF7 and UTF8 with those...

Sigh, yes.  Section 9 of RFC 2192 was IMHO a mistake, but it's there.

However, note that the URLs are still encoded in 7-bit, albeit in a 
different way than mUTF7.  So this isn't actually UTF-8, but rather 
YA7BEOU (Yet Another 7-Bit Encoding Of Unicode).

-- Mark --

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

Date: Tue, 08 Mar 2005 15:08:18 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Lisa Dusseault <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Revised Agenda for IMAPEXT
Sender: [email-masked]

Hi Mark,

--On March 8, 2005 11:52:17 AM -0800 Mark Crispin <[email-masked]> 
wrote:

>> What do you want to do about ANNOTATEMORE - that has mailbox names in
>> the  entries. I think it would be a big mistake to have to go back to
>> using  modified-utf7 there.
>
> I think that all uses of mailbox names in IMAP should follow the same
> scheme.  I think that it is far worse to have modified UTF-7 for mailbox
> names in one place and UTF-8 for mailbox names in another.

BTW Both CATENEATE and URLAUTH use IMAP URL's which use UTF8 encoded 
mailbox names - so in some sense we are already mixing mUTF7 and UTF8 with 
those...

-- 
Cyrus Daboo

Date: Tue, 08 Mar 2005 14:56:50 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Lisa Dusseault <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Revised Agenda for IMAPEXT
Sender: [email-masked]

Hi Mark,

--On March 8, 2005 11:52:17 AM -0800 Mark Crispin <[email-masked]> 
wrote:

>> What do you want to do about ANNOTATEMORE - that has mailbox names in
>> the  entries. I think it would be a big mistake to have to go back to
>> using  modified-utf7 there.
>
> I think that all uses of mailbox names in IMAP should follow the same
> scheme.  I think that it is far worse to have modified UTF-7 for mailbox
> names in one place and UTF-8 for mailbox names in another.
>
> I would support the addition of a negotiated extension to repeal the
> modified UTF-7 requirement in IMAP.

If we are going to do that then we need to do it now and get the mailbox 
name stringprep profile (which will be required for this) into the 
appropriate i18n draft that defines stringpreps for SEARCH. I think we 
should do this all in one go rather than bit by bit.

-- 
Cyrus Daboo

Date: Tue, 8 Mar 2005 11:52:17 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Lisa Dusseault <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Revised Agenda for IMAPEXT
Sender: [email-masked]

On Tue, 8 Mar 2005, Cyrus Daboo wrote:
> What do you want to do about ANNOTATEMORE - that has mailbox names in the 
> entries. I think it would be a big mistake to have to go back to using 
> modified-utf7 there.

I think that all uses of mailbox names in IMAP should follow the same 
scheme.  I think that it is far worse to have modified UTF-7 for mailbox 
names in one place and UTF-8 for mailbox names in another.

I would support the addition of a negotiated extension to repeal the 
modified UTF-7 requirement in IMAP.

-- Mark --

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

Date: Tue, 08 Mar 2005 19:51:45 +0000
From: Alexey Melnikov <[email-masked]>
To: Lisa Dusseault <[email-masked]>
CC: [email-masked], IMAP Extensions WG <[email-masked]>
Subject: Re: Revised Agenda for IMAPEXT
Sender: [email-masked]

Lisa Dusseault wrote:

>
> Thursday, 9:00 am to 11:30 am
>
> 5 min -- Agenda-bashing and find note-taker and jabber scribe
> 5 min -- Status of 2086 upd -- Lisa
>     - NEED MORE REVIEWERS - send note to list if you've reviewed
> 30 min -- Issues remaining with Annotate - Randy
>     - Use of StringPrep to handle UTF8 entry/attribute names
>     - OR proposal to replace UTF8 attribute name with ASCII attribute 
> name + UTF8 "displayname"
>     - Plans for next draft, possible reissue of Last Call

Another issue:

ABNF for select/examine is wrong:

      select            =/ *(SP "(" select-param *(SP select-param) ")"
                          ; modifies the original IMAP select command to
                          ; accept optional parameters

      select-param      = astring / "(" astring SP astring *(SP astring) ")"
                          ; parameters to SELECT may contain one or
                          ; more atoms or strings - multiple items
                          ; are always parenthesised

select is defined in RFC 3501 as:
      select          = "SELECT" SP mailbox

Suggestion:

      select          = "SELECT" SP mailbox [select-params]
                              ;; modifies the original IMAP SELECT 
command to
                              ;; accept optional parameters

      select-params   = SP "(" select-param *(SP select-param) ")"
 
      select-param    = astring / "(" astring 1*(SP astring) ")"
                                ;; parameters to SELECT may contain one or
                                ;; more atoms or strings - multiple items
                                ;; are always parenthesised

A similar change for the EXAMINE is required.

> 30 min -- Issues remaining with ListExt - Barry
>     - ATTENDEES SHOULD READ LATEST (-11) DRAFT
>     - Comment on << editorial>> issues on list or at meeting
>     - selection and return command options and mailbox attributes
> 10 min -- Comparator status -- Chris Newman
>     - Comparator is not a WG document but I18N and SORT rely on it
>
> Time estimates are very rough and since we have the time we'll discuss 
> what comes up
>
> Audio streaming information: http://videolab.uoregon.edu/events/ietf/
> Text chat information: http://www.xmpp.org/ietf-chat.html

Date: Tue, 08 Mar 2005 14:42:16 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>, Lisa Dusseault <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Revised Agenda for IMAPEXT
Sender: [email-masked]

Hi Mark,

--On March 8, 2005 11:31:04 AM -0800 Mark Crispin <[email-masked]> 
wrote:

>> 30 min -- Issues remaining with Annotate - Randy
>> 	- Use of StringPrep to handle UTF8 entry/attribute names
>> 	- OR proposal to replace UTF8 attribute name with ASCII attribute name
>> 	+ UTF8 "displayname"
>
> For what it's worth, I think that the proposal to replace UTF-8 attribute
> names with an ASCII attribute name and a UTF-8 display name is a good
> idea.
>

What do you want to do about ANNOTATEMORE - that has mailbox names in the 
entries. I think it would be a big mistake to have to go back to using 
modified-utf7 there.

-- 
Cyrus Daboo

Date: Tue, 8 Mar 2005 11:31:04 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Lisa Dusseault <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Revised Agenda for IMAPEXT
Sender: [email-masked]

On Tue, 8 Mar 2005, Lisa Dusseault wrote:
> 30 min -- Issues remaining with Annotate - Randy
> 	- Use of StringPrep to handle UTF8 entry/attribute names
> 	- OR proposal to replace UTF8 attribute name with ASCII attribute name + UTF8 "displayname"

For what it's worth, I think that the proposal to replace UTF-8 attribute 
names with an ASCII attribute name and a UTF-8 display name is a good 
idea.

-- Mark --

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

Cc: [email-masked], IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Revised Agenda for IMAPEXT
Date: Tue, 8 Mar 2005 11:06:51 -0800
To: Lisa Dusseault <[email-masked]>
Sender: [email-masked]

Thursday, 9:00 am to 11:30 am

5 min -- Agenda-bashing and find note-taker and jabber scribe
5 min -- Status of 2086 upd -- Lisa
	- NEED MORE REVIEWERS - send note to list if you've reviewed
30 min -- Issues remaining with Annotate - Randy
	- Use of StringPrep to handle UTF8 entry/attribute names
	- OR proposal to replace UTF8 attribute name with ASCII attribute name 
+ UTF8 "displayname"
	- Plans for next draft, possible reissue of Last Call
30 min -- Issues remaining with ListExt - Barry
	- ATTENDEES SHOULD READ LATEST (-11) DRAFT
	- Comment on << editorial>> issues on list or at meeting
	- selection and return command options and mailbox attributes
10 min -- Comparator status -- Chris Newman
	- Comparator is not a WG document but I18N and SORT rely on it

Time estimates are very rough and since we have the time we'll discuss 
what comes up

Audio streaming information: http://videolab.uoregon.edu/events/ietf/
Text chat information: http://www.xmpp.org/ietf-chat.html

Lisa

To: webdav WG <[email-masked]>, IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Fwd: IESG Document Review Process Update
Date: Mon, 7 Mar 2005 13:24:00 -0800
Sender: [email-masked]

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

FYI

Begin forwarded message:

> From: "Scott Hollenbeck" <[email-masked]>
> Date: March 7, 2005 9:24:11 AM PST
> To: [email-masked], [email-masked], 
> [email-masked], [email-masked], [email-masked], 
> [email-masked], [email-masked], [email-masked], 
> [email-masked], [email-masked], [email-masked], 
> [email-masked], [email-masked], [email-masked], 
> [email-masked], [email-masked], [email-masked], 
> [email-masked], [email-masked], [email-masked], 
> [email-masked], [email-masked], 
> [email-masked]
> Cc: "'Ted Hardie'" <[email-masked]>, [email-masked]
> Subject: IESG Document Review Process Update
>
> All Applications Area Working Group chairs:
>
> Over the last few years the IESG has been looking at ways to improve 
> our
> document review process.  The effort is described here:
>
> http://psg.com/~mrw/PROTO-Team/
>
> During today's open apparea meeting I announced that Ted and I will be 
> using
> the PROTO Team process for all new documents brought to us by your 
> working
> groups from now on.  That means that you as chairs have a few specific 
> tasks
> to complete as part of the document review process:
>
> 1. Completing a write-up describing the document that you want the 
> IESG to
> review:
> http://psg.com/~mrw/PROTO-Team/WGChair-Writeup.html
>
> 2. Shepherding resolution of AD review comments:
> http://psg.com/~mrw/PROTO-Team/ad-review-draft.txt
>
> 3. Shepherding resolution of IESG review comments:
> http://psg.com/~mrw/PROTO-Team/discuss-draft.txt
>
> On our end, Ted and I will strive to perform our reviews of your 
> documents
> before or during the IETF last call period.  This will hopefully speed
> things up a bit once the last call has been completed.
>
> Please review the material described above and let me know if you have 
> any
> questions.  Remember, too, that I am covering all of Ted's working 
> groups
> while he is enjoying paternity leave.
>
> Feel free to share this with your groups.
>
> -Scott-
>
>

--Apple-Mail-1-926938022
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
	charset=US-ASCII

FYI

Begin forwarded message:

<excerpt><bold><color><param>0000,0000,0000</param>From:
</color></bold>"Scott Hollenbeck" <<[email-masked]>

<bold><color><param>0000,0000,0000</param>Date: </color></bold>March
7, 2005 9:24:11 AM PST

<bold><color><param>0000,0000,0000</param>To:
</color></bold>[email-masked], [email-masked],
[email-masked], [email-masked], [email-masked],
[email-masked], [email-masked], [email-masked],
[email-masked], [email-masked], [email-masked],
[email-masked], [email-masked], [email-masked],
[email-masked], [email-masked], [email-masked],
[email-masked], [email-masked], [email-masked],
[email-masked], [email-masked], [email-masked]

<bold><color><param>0000,0000,0000</param>Cc: </color></bold>"'Ted
Hardie'" <<[email-masked]>, [email-masked]

<bold><color><param>0000,0000,0000</param>Subject: </color>IESG
Document Review Process Update

</bold>

All Applications Area Working Group chairs:

Over the last few years the IESG has been looking at ways to improve
our

document review process.  The effort is described here:

http://psg.com/~mrw/PROTO-Team/

During today's open apparea meeting I announced that Ted and I will be
using

the PROTO Team process for all new documents brought to us by your
working

groups from now on.  That means that you as chairs have a few specific
tasks

to complete as part of the document review process:

1. Completing a write-up describing the document that you want the
IESG to

review:

http://psg.com/~mrw/PROTO-Team/WGChair-Writeup.html

2. Shepherding resolution of AD review comments:

http://psg.com/~mrw/PROTO-Team/ad-review-draft.txt

3. Shepherding resolution of IESG review comments:

http://psg.com/~mrw/PROTO-Team/discuss-draft.txt

On our end, Ted and I will strive to perform our reviews of your
documents

before or during the IETF last call period.  This will hopefully speed

things up a bit once the last call has been completed.

Please review the material described above and let me know if you have
any

questions.  Remember, too, that I am covering all of Ted's working
groups

while he is enjoying paternity leave.

Feel free to share this with your groups.

-Scott-

</excerpt>
--Apple-Mail-1-926938022--

Cc: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Re: Last minute agenda
Date: Fri, 4 Mar 2005 22:44:51 -0800
To: Lisa Dusseault <[email-masked]>
Sender: [email-masked]

BTW, it looks like the most recent draft that was submitted on ListExt 
was accepted Feb 10, but it's draft -11, not draft -12.

Sorry,
Lisa

On Mar 3, 2005, at 12:01 PM, Lisa Dusseault wrote:

>
> I didn't see any agenda items proposed, so as usual this is last 
> minute:
>
> 5 min -- Agenda-bashing and find note-taker
> 5 min -- Status of 2086 upd
> 30 min -- Issues remaining with Annotate
> 	- Use of StringPrep
> 	- UTF8 entry/attribute names
> 	- Post-last-call draft due... ?
> 30 min -- Issues remaining with ListExt
> 	- ATTENDEES SHOULD READ LATEST (-12) DRAFT
> 	- Comment on << editorial>> issues on list or at meeting
> 	- selection and return command options and mailbox attributes
>
> I know Cyrus won't be there, how about Randy to discuss Annotate?  
> Alexey and Barry, will one of you be there to discuss ListExt?
>
> Any other topics?
>
> Lisa
>

Date: Fri, 04 Mar 2005 18:12:48 +0000
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Last minute agenda
Sender: [email-masked]

Cyrus Daboo wrote:

> Hi Alexey,
>
> --On Friday, March 04, 2005 05:28:45 PM +0000 Alexey Melnikov 
> <[email-masked]> wrote:
>
>> I also have a proposal to extract all ABNF/text that extends various
>> standard IMAP commands (like SELECT, FETCH, STORE and STATUS and APPEND)
>> into a separate document. This will avoid unnecessary dependencies, for
>> example between CATENATE and ANNOTATE.
>> In fact, I've already written it, just waiting for the moment when
>> submission will be allowed.
>> Does this sound interesting to the WG?
>
>
> Well of course there was the command+ draft that Barry and I wrote a 
> while ago - though that took an entirely different approach.

> I guess at this point we have to do a case-by-case command extension 
> syntax.

Yes and yes.

> It would certainly make it easier to have a syntax reference document 
> that all relevant extensions could reference. It would certainly be 
> useful for helping resolve the CATENATE / ANNOTATE inter-dependency.
>
> Of course this adds yet another blocking dependency to all the current 
> drafts...

I bet this draft will be done before CATENATE or ANNOTATE are approved. 
Especially if we choose to restrict its scope, for example if the SEARCH 
extensions go into a separate document.

Alexey

Date: Fri, 04 Mar 2005 13:03:57 -0500
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>, Lisa Dusseault <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Last minute agenda
Sender: [email-masked]

Hi Alexey,

--On Friday, March 04, 2005 05:28:45 PM +0000 Alexey Melnikov 
<[email-masked]> wrote:

> I also have a proposal to extract all ABNF/text that extends various
> standard IMAP commands (like SELECT, FETCH, STORE and STATUS and APPEND)
> into a separate document. This will avoid unnecessary dependencies, for
> example between CATENATE and ANNOTATE.
> In fact, I've already written it, just waiting for the moment when
> submission will be allowed.
> Does this sound interesting to the WG?

Well of course there was the command+ draft that Barry and I wrote a while 
ago - though that took an entirely different approach. I guess at this 
point we have to do a case-by-case command extension syntax. It would 
certainly make it easier to have a syntax reference document that all 
relevant extensions could reference. It would certainly be useful for 
helping resolve the CATENATE / ANNOTATE inter-dependency.

Of course this adds yet another blocking dependency to all the current 
drafts...

-- 
Cyrus Daboo

Date: Fri, 04 Mar 2005 17:28:45 +0000
From: Alexey Melnikov <[email-masked]>
To: Lisa Dusseault <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Last minute agenda
Sender: [email-masked]

Lisa Dusseault wrote:

> I didn't see any agenda items proposed, so as usual this is last minute:
>
> 5 min -- Agenda-bashing and find note-taker
> 5 min -- Status of 2086 upd
> 30 min -- Issues remaining with Annotate
>     - Use of StringPrep
>     - UTF8 entry/attribute names
>     - Post-last-call draft due... ?
> 30 min -- Issues remaining with ListExt
>     - ATTENDEES SHOULD READ LATEST (-12) DRAFT
>     - Comment on << editorial>> issues on list or at meeting
>     - selection and return command options and mailbox attributes
>
> I know Cyrus won't be there, how about Randy to discuss Annotate?  
> Alexey and Barry, will one of you be there to discuss ListExt?

Barry should be in Minneapolist.

> Any other topics?

Do we have a closure on the minor editorial change you've proposed for 
2086upd?

I also have a proposal to extract all ABNF/text that extends various 
standard IMAP commands (like SELECT, FETCH, STORE and STATUS and APPEND) 
into a separate document. This will avoid unnecessary dependencies, for 
example between CATENATE and ANNOTATE.
In fact, I've already written it, just waiting for the moment when 
submission will be allowed.
Does this sound interesting to the WG?

Alexey

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Last minute agenda
Date: Thu, 3 Mar 2005 12:01:17 -0800
Sender: [email-masked]

I didn't see any agenda items proposed, so as usual this is last minute:

5 min -- Agenda-bashing and find note-taker
5 min -- Status of 2086 upd
30 min -- Issues remaining with Annotate
	- Use of StringPrep
	- UTF8 entry/attribute names
	- Post-last-call draft due... ?
30 min -- Issues remaining with ListExt
	- ATTENDEES SHOULD READ LATEST (-12) DRAFT
	- Comment on << editorial>> issues on list or at meeting
	- selection and return command options and mailbox attributes

I know Cyrus won't be there, how about Randy to discuss Annotate?  
Alexey and Barry, will one of you be there to discuss ListExt?

Any other topics?

Lisa

Date: Tue, 29 Mar 2005 13:59:30 -0500
From: Barry Leiba <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: Work items for Alexey, Cyrus, Barry, Tony, Chris, Arnt
Sender: [email-masked]

> below, in order  to come up with new milestone dates, I need to get
> date promises out of  the active draft authors (Cyrus, Randy, Barry,
> Alexey) for LISTEXT,  ANNOTATE and 2086upd as well as ACL2.

I have just converted the plain text for the -11 version of ListExt
into XML that works for xml2rfc -- that was a prerequisite for updates,
since dealing directly with the plain text is too painful.  I sent the
new text to Alexey the other day for review (to make sure I didn't
break anything).

I'll next be working on making the changes, and resolving the open
issues.  Expect a -12 version, along with a list of what still has to
be resolved, to be posted by 7 April.

I don't think the things that need to be resolved will be very
contentious, but, then, we thought that what we came up with at the
interim meeting would go smoothly, and it didn't.  Anyway, if I can lay
out the remaining issues clearly, we should be able to get through them
on the list and get a last-call document out as -13.  Maybe go for end
of April as the goal for making the last call?  Is that suitable?

Barry

--
Barry Leiba, Pervasive Computing Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam

Date: Wed, 23 Mar 2005 09:26:46 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: Work items for Alexey, Cyrus, Barry, Tony, Chris, Arnt
Sender: [email-masked]

On Wed, 23 Mar 2005, Cyrus Daboo wrote:
>> (Btw, I'll be at the next IETF, perhaps the next two. Are the dates for
>> the November IETF known yet? My schedule is a little tricky.)
> <http://www.ietf.org/meetings/0mtg-sites.txt>

For what it's worth, I won't be at Paris, but I probably will be in 
Vancouver.

-- Mark --

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

Date: Wed, 23 Mar 2005 11:29:21 -0500
From: Cyrus Daboo <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: Work items for Alexey, Cyrus, Barry, Tony, Chris, Arnt
Sender: [email-masked]

Hi Arnt,

--On March 23, 2005 10:40:16 +0100 Arnt Gulbrandsen 
<[email-masked]> wrote:

> (Btw, I'll be at the next IETF, perhaps the next two. Are the dates for
> the November IETF known yet? My schedule is a little tricky.)
>

<http://www.ietf.org/meetings/0mtg-sites.txt>

-- 
Cyrus Daboo

Date: Wed, 23 Mar 2005 10:40:16 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Work items for Alexey, Cyrus, Barry, Tony, Chris, Arnt
Sender: [email-masked]

>>> i18n Document [draft-ietf-imapext-i18n-04.txt]:
>>> - Chris asks if we can simplify the use of comparators in the search 
>>> program so that one comparator could be used for the entire 
>>> program.

I don't understand this. Didn't I do that already? How is it possible to 
use multipe comparators in one search program in the -04 draft?

(Btw, I'll be at the next IETF, perhaps the next two. Are the dates for 
the November IETF known yet? My schedule is a little tricky.)

Arnt

From: Lisa Dusseault <[email-masked]>
Subject: Work items for Alexey, Cyrus, Barry, Tony, Chris, Arnt
Date: Tue, 22 Mar 2005 11:32:26 -0800
To: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

Don't forget the deliverables from the IETF this month, both new drafts  
and promised reviews... in addition to the deliverables below, in order  
to come up with new milestone dates, I need to get date promises out of  
the active draft authors (Cyrus, Randy, Barry, Alexey) for LISTEXT,  
ANNOTATE and 2086upd as well as ACL2.

Lisa

On Mar 10, 2005, at 1:53 PM, Lisa Dusseault wrote:

>
> This is great.  I'll just use this opportunity to extract the  
> deliverables:
>  - Lisa to deliver recharter (new milestone dates) for WG
>  - Alexey to produce new draft of 2086upd addressing last-call and  
> post-last-call nits
>  - Cyrus to produce new draft of annotate addressing last call issues  
> and incorporating decisions recorded in these minutes
>  - Alexey and Barry to produce new draft of LISTEXT with no open or  
> editorial issues remaining, suitable for last call
>  - Alexey to produce syntax draft for Annotate to use
>  - Tony Hanson and Barry Leiba to review Chris's Comparator draft and  
> ping Chris about it
>  - Chris Newman to put cycles into Comparator
>  - Arnt (who was absent) to review Chris's proposed simplification  
> allowing only one comparator per search query
>
>
> On Mar 10, 2005, at 12:15 PM, Rob Siemborski wrote:
>
>>
>> Let me know your comments, I'll send this on to [email-masked]  
>> probably tomorrow sometime.
>>
>> IMAPEXT Meeting at IETF-62, 3-10-2005, 9-11am CST.
>>
>> These minutes are based off the Jabber log, available here:
>> http://www.xmpp.org/ietf-logs/[email-masked]/2005-03-10.htm
>>
>> Administrivia:
>>
>> Chairs welcomed the members to the IMAPEXT variety show.  The agenda  
>> was bashed.
>>
>> 2086upd [draft-ietf-imapext-2086upd-03.txt]:
>>
>> - Chair summarized that people have been reviewing the document,  
>> things are looking good and we're almost done.
>>
>> - Cyrus sent a large number of comments to the list this morning that  
>> were mostly minor nits.
>>
>> - Room consensus that no comments had invalidated last call, and we  
>> can move forward.
>>
>> ANNOTATE [draft-ietf-imapext-annotate-12.txt]:
>>
>> - Brief discussion about how references when replacing a document  
>> work (you don't have to reference a document you are obsoleting)
>>
>> - Lisa summarized Cyrus's recent changed for the room.
>>
>> - Use of UTF-8 for values: rough consensus for 'SHOULD' instead of  
>> 'MUST'
>>
>> - Discussion of open issues:
>>   - Should servers validate the syntax of the content-type value? Yes.
>>     (but should not have to validate that the actual content-type is
>>      correct).
>>     - We should reference RFC2046 for their content-type syntax.
>>   - Should entity registrations contain a default content-type value?
>>     - Other questions included:
>>       "Should entries be forced to a particular content type?" No
>>     - IANA registration will contain a recommended content-type value.
>>   - Can values contain binary data?  Can we use the literal8 syntax  
>> from
>>     BINARY?
>>     - Alternate ideas included tagging to indicate that a
>>       binary response was desired. (experience from LDAP indicated  
>> this
>>       was tricky to get right)
>>     - Desire to not require BINARY extension, just the syntax.
>>     - Desire to move literal8 syntax to the common syntax document.
>>     - Rough consensus to use literal8 syntax for all ANNOTATE  
>> literals,
>>       but no modifications for regular strings.
>>     - Rough consensus to move literal8 syntax to the syntax document  
>> (out
>>       of BINARY).
>>   - How to deal with hierarchy levels named 'shared' and 'priv'?
>>     - Ambiguity on first hierarchy level.
>>     - Rough consensus to just deny them on all levels.
>>   - UTF-8 entry/attribute names
>>     - We need stringprep for comparisons if they stay UTF-8
>>     - Recent lunch BOF proposal to restrict to US-ASCII and have  
>> another
>>       attribute for UTF-8 display name.
>>     - Additionally, clients are not required to use the display name  
>> for
>>       presentation if they choose not to.
>>       - Really, the display name attribute would only be necessary for
>>         custom entries (for standard entries, clients could know how  
>> they
>>         are used).
>>     - Point that we will need stringprep for mailbox names eventually
>>       anyway. (but this is likely a different stringprep profile).
>>     - Observation that mailbox names aren't registered, its much  
>> nicer to
>>       be able to just register US-ASCII names.
>>     - Rough consensus to restrict entry and attribute names to  
>> US-ASCII,
>>       and include a UTF-8 displayname attribute.
>>   - Interaction with CATENATE syntax (for APPEND), since the CATENATE
>>     draft is now APPEND-only.  Should we just reference the syntax  
>> draft?
>>     - Rough consensus: Yes.
>>
>> - Side discussion about making Alexey's syntax draft an official WG  
>> item. Rough consensus to decide after seeing it (Alexey promises to  
>> be quick with updates).
>>
>> - ANNOTATEMORE interaction: there are large blocks of shared text  
>> that should now be updated in both places.
>>
>> LISTEXT [draft-ietf-imapext-list-extensions-11.txt]:
>>
>> - Philip summarized the changes to LISTEXT proposed at the interim  
>> and subsequent list discussion, the main problem being that LIST  
>> responses cannot rely on the context of the command that prompted  
>> them.
>>   - Solution: move lots of this into CHILDINFO.
>>
>> - Discussion of possible difference in behavior with current RLIST  
>> and the
>> \Remote flag (currently a server does not need to actually declare  
>> what mailboxes are remote and which ones aren't).  This could cause  
>> problems for some type of proxies that choose to refer based on if  
>> the clients send an RLIST or not.
>>   - Probably not a problem, since LIST flags can change at any time,
>>     really..
>>
>> - Issue: The current ABNF is very complex, can it be simplified?
>>   - Observation: some of the syntax is performing validation that is
>>     really semantic in nature.
>>   - Cyrus offered to take a look and suggest text/new ABNF.
>>
>> - Chair asked authors of LISTEXT to propose strawman for open issues  
>> in the next document, continuing to have open issues will just delay  
>> the group.
>>   - Authors asked that members who disagree with the strawman propose
>>     alternates.
>>
>> Comparator (not a WG item) [draft-newman-i18n-comparator-03.txt]:
>> - We have several items that depend on this.
>> - Chris tried to find another author, and failed.  He will continue  
>> to try
>>   to find someone else to work on it, but will also commit some cycles
>>   near term.
>> - Chris is currently interrupt driven, and asks to be pinged.
>>
>> ACL2 & Working Group Future:
>> - In San Diego we agreed to drop ACL2 if there had been no progress  
>> by this meeting.  There hasn't been progress on ACL2, but there has  
>> been substantial other progress.  Chair asks if we want to extend our  
>> deadline given this (and adjust charter dates).
>>   - Scott (AD) is ok with this.
>>   - Rough consensus to revisit ACL2 in 6 months.
>>
>> - Members should watch the LEMONADE group for some of their  
>> encrypted/signed message issues.  IMAPEXT (or at least its members)  
>> should be involved in a deep way.
>>
>> i18n Document [draft-ietf-imapext-i18n-04.txt]:
>> - Chris asks if we can simplify the use of comparators in the search  
>> program so that one comparator could be used for the entire program.
>>   - Example use case: search for case-sensitive local part and
>>     case-insensitive domain part of an address.
>>   - Point that we could accomplish most of the usefulness of this with
>>     the ability to search within results.
>>   - Rough consensus to simplify in this way, and allow for a future
>>     extension to do the recursive search.  Chris will send a message  
>> to
>>     Arnt and the list.
>>
>>
>> ---------------------------------------------------------------------- 
>> ---
>> Rob Siemborski        |     PGP:0x5CE32FCC     |       
>> [email-masked] -----BEGIN GEEK CODE BLOCK----
>> Version: 3.12
>> GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K-  
>> w-- O-
>> M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r-  
>> y?
>> ------END GEEK CODE BLOCK-----
>>
>

Date: Thu, 17 Mar 2005 20:40:32 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: [email-masked]
Subject: listext comments
Sender: [email-masked]

Some comments I wrote up on the way back from IETF:

On Open Issue: "Each option (except for RECURSIVEMATCH) should have a 
corresponding mailbox attribute".

I don't believe this should be mandatory (I don't think it gets us much). 
Additionally, if RECURSIVEMATCH is an example of an option that doesn't 
directly correspond to a flag, it seems likely its not something we want to 
forbid.  (For example, say we wanted boolean operators as selection criteria, 
like NOT SUBSCRIBED?)  NOT doesn't exactly have a good flag to go with it :)

---

In the NonExistant discussion:

>
    The "\NonExistent" attribute indicates that a mailbox does not actually
    exist. Note that this attribute is not meaningful by itself, as mailboxes
>

I sort of want to say "level of mailbox hierarchy" as opposed to "mailbox", 
since technically, if they don't exist they're not mailboxes (though for 
SUBSCRIBED, this is somewhat less clear).

---

On Open Issue: ", but doesn't match the canonical LIST pattern." (referring to 
child mailboxes).

YES, please include that.

---

Can we break up section 3.[nil] into subsections (overview, selection options, 
return options).

---

To somewhat follow up on my comments about the REMOTE flag at the WG meeting...

The REMOTE selection option section states "The '\Remote' attribute MUST be 
accurately computed..."

It would be nice if a note was in there stating that if the server presents 
this flag it MAY, in fact, not issue a referral when the mailbox is accessed 
(for example, if the mailbox has become local in the intervening time). 
Likewise, a mailbox previously noted as local MAY get a referral anyway (since 
the mailbox may have been made non-local in the interim).

---

Not strictly necessary, but it took me a few seconds to realize why the REMOTE 
return option wasn't necessary (maybe I'm just slow).  A note of clarification 
in the remote options section or under the remote selection option might be 
nice but not necessary.

---

"as well as distinguish between solicited responses caused by multiple 
different LIST commands"

Of course, the client shouldn't be pipelining commands it can't distinguish the 
difference in results from anyway.

---

On open issue: "Suppressing redundant CHILDINFO when parent doesn't match the 
selection criteria but has a child that does AND the child also matches the 
canonical list pattern"

We should match present-day LSUB behavior in this case <<I think that is to 
return the parents, but I'm not certain>>

---

The table in section 3.3. greatly clarifies things, please keep it.

---

In the description of the HasChildren flag we suddenly start talking about 
access permissions -- yet elsewhere in the document we haven't mentioned it at 
all.  I don't think that we need to worry about it here, and we can just say 
that in some implementations it may be expensive to compute the existence of 
child mailboxes, and that \HasChildren is only a hint to clients.

If we really want to talk about access permissions in this document, we should 
think carefully about where else they may be hard to complute (\Remote?)

---

>> 
In particular, some servers may not be able to combine the SUBSCRIBED selection 
option and CHILDREN return option. <<

We need to seriously consider this.

What if in the future we find another combination that some implementations 
find computationally expensive?  Are we going to have to declare a hiearchy of 
priorities for the servers to process these in ("REMOTE SUBSCRIBED CHILDREN is 
hard for me, so I'll just do SUBSCRIBED....")?

Additionally, clients that want this information are still going to have to 
figure it out somehow (and based on what I've seen, its likely they will do a 
separate LIST command for each one).

---

"inbox" should probably be "INBOX" in the examples.

---

The discussion of the access permissions for security considerations with 
CHILDREN is probably better than having it in the middle of the document, 
because its really a special case of the overriding "HasChildren is only a 
hint" problem.

-Rob

-------------------------------------------------------------------------
Rob Siemborski        |     PGP:0x5CE32FCC     |      [email-masked] 
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

Date: Wed, 16 Mar 2005 16:23:36 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Tony Hansen <[email-masked]>
cc: [email-masked]
Subject: Re: Size Indications in IMAP (was Split Implementations of PGP)
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Wed, 16 Mar 2005, Tony Hansen wrote:
> I ran into a similar situation with a vendor of voice mail products. They 
> stored the voice messages in their imap servers in a proprietary format, but 
> when you asked for the messages, converted them on the fly into wav format. 
> It happens that the wav format was always smaller than the original format, 
> so the message body we'd get would be padded at the end with tons of 
> space-filled blank lines to make up for the size difference.

Did they also return a BODYSTRUCTURE showing that content as being in WAV 
format?

If so, it's regrettable that they had to do that, but that's not as bad as 
passing false data in the sizes.

> If this particular case had been done using content conversion extensions, 
> ala lemonade, the issue wouldn't arise.

Absolutely.  Content conversion extensions are the way to go.

-- Mark --

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

Date: Wed, 16 Mar 2005 19:14:33 -0500
From: Tony Hansen <[email-masked]>
CC: [email-masked]
Subject: Re: Size Indications in IMAP (was Split Implementations of PGP)
Sender: [email-masked]

I ran into a similar situation with a vendor of voice mail products. 
They stored the voice messages in their imap servers in a proprietary 
format, but when you asked for the messages, converted them on the fly 
into wav format. It happens that the wav format was always smaller than 
the original format, so the message body we'd get would be padded at the 
end with tons of space-filled blank lines to make up for the size 
difference.

If this particular case had been done using content conversion 
extensions, ala lemonade, the issue wouldn't arise.

	Tony Hansen
	[email-masked]

Date: Wed, 16 Mar 2005 13:38:38 -0800
From: Mark Crispin <[email-masked]>
To: Eric Burger <[email-masked]>
cc: [email-masked]
Subject: Re: Size Indications in IMAP (was Split Implementations of PGP)
Organization: Networks & Distributed Computing
Sender: [email-masked]

>> If there is anything that further work on IMAP, be it Lemonade, or
>> anything else does that could help security, it would be to break
>> IMAP's prissiness about message length.

I am totally and inalterably opposed to this.

There is a fundamental misunderstanding about IMAP that leads to this 
request.  The sizes in question are the sizes of the message as stored on 
the server (and presumably transmitted via the SMTP infrastructure). 
They are most emphatically *not* sizes of data as transformed by some 
mechanism such as decryption, or QUOTED-PRINTABLE/BASE64 decoding (which 
comes into this via a parallel example).

If decryption is to be done, it will be via an IMAP extension mechanism. 
That extension mechanism can decide whether or not to provide any sizes in 
the context of that mechanism.

A good example to see how this works is the BINARY extension.  BINARY is 
most definitely a precedent for how this should work.  BINARY has sizes as 
independent from RFC822.SIZE.

Personally, I consider inaccurate sizes to be far, far, worse than no 
sizes.  If a server-based decryption mechanism can not offer sizes 
efficiently then it shouldn't do so at all.  NNTP and POP3 stand as 
miserable examples of sizes that are worse than useless.

-- Mark --

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

Date: Wed, 16 Mar 2005 13:18:14 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, [email-masked], Eric Burger <[email-masked]>, Alexey Melnikov <[email-masked]>
Subject: Re: Size Indications in IMAP (was Split Implementations of PGP)
Sender: [email-masked]

On Wed, 16 Mar 2005, Timo Sirainen wrote:

>>>> I am not sure I undestand why it is a problem that IMAP returns exact size
>>>> when it is asked to.
>>>
>>> It forces the server to compute the size accurately, which isn't always easy.
>>> Suppose that to hand out a message in RFC822 format, you have to do some
>>> heavy crypto operations. Sign it, perhaps. Then how do you respond to this?
>>>
>>> a fetch 1:* rfc822.size
>>
>> Precompute it once (say, at delivery - but possibly when it is first
>> asked for) and cache the value for all time?
>
> I understood that the point was that server isn't able to decrypt
> messages without client specifically providing the decryption key
> separately for each message, ie. server never knows the user's private
> key. This rules out any pre-caching.

Arnt's example was "server signs the message" which is different, and can 
be precomputed.

Obviously if you don't have the key, you can't decrypt on delivery, you 
need to wait until you get the key (at which point, if the security model 
allows, you *can* cache the result).

> Doing this requires an IMAP extension to transfer the key though, so I
> don't see how this is really a problem if the extension just specifies
> that "when using this extension, the values returned by FETCH
> RFC822.SIZE aren't exact".

Uh, they'd be exact if you were to fetch the RFC822 message, which is 
still encrypted.

If you wanted to download the decrypted message (parts?), since we're 
extending the server anyway I'd expect the server to either provide a 
different (possibly non-exact) decrypted size, or not provide a decrypted 
size at all, as well as a mechanism to specify that you want to download 
the decrypted version.

-Rob

-------------------------------------------------------------------------
Rob Siemborski        |     PGP:0x5CE32FCC     |      [email-masked] 
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

Subject: Re: Size Indications in IMAP (was Split Implementations of PGP)
From: Timo Sirainen <[email-masked]>
To: Rob Siemborski <[email-masked]>
Cc: Arnt Gulbrandsen <[email-masked]>, [email-masked], Eric Burger <[email-masked]>, Alexey Melnikov <[email-masked]>
Date: Wed, 16 Mar 2005 19:48:40 +0200
Sender: [email-masked]

--=-lHZe7/gqvysxQaqrABHw
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2005-03-16 at 12:00 -0500, Rob Siemborski wrote:
> > Alexey Melnikov writes:
> >> I am not sure I undestand why it is a problem that IMAP returns exact =
size=20
> >> when it is asked to.
> >
> > It forces the server to compute the size accurately, which isn't always=
 easy.=20
> > Suppose that to hand out a message in RFC822 format, you have to do som=
e=20
> > heavy crypto operations. Sign it, perhaps. Then how do you respond to t=
his?
> >
> > a fetch 1:* rfc822.size
>=20
> Precompute it once (say, at delivery - but possibly when it is first=20
> asked for) and cache the value for all time?

I understood that the point was that server isn't able to decrypt
messages without client specifically providing the decryption key
separately for each message, ie. server never knows the user's private
key. This rules out any pre-caching.

And as for normal caching, it's good if they're already in cache, but if
you just received 10 new crypted messages and it has to do 10 key
exchanges with your slow mobile phone, it's not good for either speed or
security (as the original message said).

Doing this requires an IMAP extension to transfer the key though, so I
don't see how this is really a problem if the extension just specifies
that "when using this extension, the values returned by FETCH
RFC822.SIZE aren't exact".

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

--=-lHZe7/gqvysxQaqrABHw--

Date: Wed, 16 Mar 2005 12:00:33 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked], Eric Burger <[email-masked]>, Alexey Melnikov <[email-masked]>
Subject: Re: Size Indications in IMAP (was Split Implementations of PGP)
Sender: [email-masked]

On Wed, 16 Mar 2005, Arnt Gulbrandsen wrote:

> Alexey Melnikov writes:
>> I am not sure I undestand why it is a problem that IMAP returns exact size 
>> when it is asked to.
>
> It forces the server to compute the size accurately, which isn't always easy. 
> Suppose that to hand out a message in RFC822 format, you have to do some 
> heavy crypto operations. Sign it, perhaps. Then how do you respond to this?
>
> a fetch 1:* rfc822.size

Precompute it once (say, at delivery - but possibly when it is first 
asked for) and cache the value for all time?

Since the server can't return different message content each time a 
message is requested, you can only sign the thing once anyway.

-Rob

-------------------------------------------------------------------------
Rob Siemborski        |     PGP:0x5CE32FCC     |      [email-masked] 
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

Date: Wed, 16 Mar 2005 16:56:20 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Size Indications in IMAP (was Split Implementations of PGP)
Cc: Eric Burger <[email-masked]>, Alexey Melnikov <[email-masked]>
Sender: [email-masked]

Alexey Melnikov writes:
> I am not sure I undestand why it is a problem that IMAP returns exact 
> size when it is asked to.

It forces the server to compute the size accurately, which isn't always 
easy. Suppose that to hand out a message in RFC822 format, you have to 
do some heavy crypto operations. Sign it, perhaps. Then how do you 
respond to this?

a fetch 1:* rfc822.size

Arnt

Date: Wed, 16 Mar 2005 10:51:02 -0500
From: Cyrus Daboo <[email-masked]>
To: Eric Burger <[email-masked]>, [email-masked]
Subject: Re: Size Indications in IMAP (was Split Implementations of PGP)
Sender: [email-masked]

Hi Eric,

--On Wednesday, March 16, 2005 06:57:16 AM -0500 Eric Burger 
<[email-masked]> wrote:

>> We have the problem that while SMTP and POP consider size information
>> about a message to be advisory, IMAP considers it to be definitive.
>> When you have a message that is compressed, encrypted, signed, base64
>> encoded, put into quoted-printable, etc., it can be very hard
>> to answer
>> the question, "How big is that message?" definitively.

This question is ambiguous - does it mean 'the size of the message (or 
parts) after transfer encodings, encryption, compression etc are removed', 
or 'the size of the message as it is stored in its rfc2822 format on the 
server'? IMAP reports the later size - and there is in general no problem 
in reporting an accurate size for that as the byte count is accurately 
known. IMAP does not report the size of 'decoded' message parts (except for 
the BINARY extension).

Frankly, having implemented both PGP and SMIME support in a client with 
both POP and IMAP, I see no issue at all with the size info reported by 
IMAP. Of course, with the way things are right now wrt MIME multipart 
security, IMAP clients have to in effect behave as POP clients and download 
the entire message data (or at least the entire multipart) in order to do 
crypto processing...

-- 
Cyrus Daboo

Date: Wed, 16 Mar 2005 15:21:12 +0000
From: Alexey Melnikov <[email-masked]>
To: Eric Burger <[email-masked]>
CC: [email-masked]
Subject: Re: Size Indications in IMAP (was Split Implementations of PGP)
Sender: [email-masked]

Eric Burger wrote:

>This message came from the discussion of whether OpenPGP supported split
>decryption (key decryption on the client, body decryption on the server).
>Short answer is yes.  This is an issue that was raised, however.
>
>  
>
>>-----Original Message-----
>>From: [email-masked]
>>[mailto:[email-masked]]On Behalf Of Jon Callas
>>Sent: Wednesday, March 16, 2005 4:47 AM
>>To: OpenPGP
>>Subject: Re: Split Implementations of PGP
>>
>>
>>
>>Something that would help those of us doing crypto and IMAP would be 
>>for IMAP to be less fussy about message size.
>>
>>We have the problem that while SMTP and POP consider size information 
>>about a message to be advisory, IMAP considers it to be definitive. 
>>When you have a message that is compressed, encrypted, signed, base64 
>>encoded, put into quoted-printable, etc., it can be very hard 
>>to answer 
>>the question, "How big is that message?" definitively.
>>
>>While POP, for example, will accept the answer "Um, around 15K" and 
>>copes just fine with the real answer being either 3K or 50K, 
>>IMAP does not. The IMAP client will expect the size reported to be 
>>accurate down to the byte. If there is more, the client will never ask for 
>>it, and if there's less, the client hyperventilates and breaks down sobbing.
>>    
>>
That suggests a problem with an IMAP client. Or lack of understanding of 
IMAP from the author of the message. Or both.

IMAP allows to fetch a full message or a message chunk. In the former 
case the client doesn't need to know the size. In the second case the 
client can ask for a chunk and if it is beyond message end an IMAP 
server should handle this correctly and will return no data.
I am not sure I undestand why it is a problem that IMAP returns exact 
size when it is asked to.

Alexey

From: Eric Burger <[email-masked]>
To: [email-masked]
Subject: Size Indications in IMAP (was Split Implementations of PGP)
Date: Wed, 16 Mar 2005 06:57:16 -0500
Sender: [email-masked]

This message came from the discussion of whether OpenPGP supported split
decryption (key decryption on the client, body decryption on the server).
Short answer is yes.  This is an issue that was raised, however.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jon Callas
> Sent: Wednesday, March 16, 2005 4:47 AM
> To: OpenPGP
> Subject: Re: Split Implementations of PGP
> 
> 
> 
> Something that would help those of us doing crypto and IMAP would be 
> for IMAP to be less fussy about message size.
> 
> We have the problem that while SMTP and POP consider size information 
> about a message to be advisory, IMAP considers it to be definitive. 
> When you have a message that is compressed, encrypted, signed, base64 
> encoded, put into quoted-printable, etc., it can be very hard 
> to answer 
> the question, "How big is that message?" definitively.
> 
> While POP, for example, will accept the answer "Um, around 15K" and 
> copes just fine with the real answer being either 3K or 50K, 
> IMAP does 
> not. The IMAP client will expect the size reported to be 
> accurate down 
> to the byte. If there is more, the client will never ask for 
> it, and if 
> there's less, the client hyperventilates and breaks down sobbing.
> 
> If there is anything that further work on IMAP, be it Lemonade, or 
> anything else does that could help security, it would be to break 
> IMAP's prissiness about message length. The main advantage that this 
> sesson-key decrypting protocol has is that it exposes the server to 
> relatively little of the actual plaintext. However, while this is a 
> theoretic benefit, the practical benefit is lessened by the length 
> requirements.
> 
> Let's suppose I connect to my server and have ten new 
> messages, all of 
> which are encrypted, say five with OpenPGP and five with S/MIME. My 
> client program is going to display the lengths of the messages, but 
> that isn't knowable without decrypting them. So immediately with the 
> headers, all ten of those messages have to be decrypted and processed 
> so that the lengths will be accurate. This slows the system down, 
> because it requires a complete round-trip of session key 
> decryption for 
> each message as well as preliminary processing of the message on the 
> server. If that client program is a mobile device, this is especially 
> bad because the heavy lifting (the public key crypto) is 
> being done on 
> the light device, and the easy lifting (the bulk crypto 
> processing) is 
> being done on the powerful device. What happens is that this 
> architecture maximally slows the email processing down, with 
> relatively 
> low security gains, because the server has gotten the session key for 
> all ten messages, even though I've read exactly zero of them.
> 
> I'd like to see a change to IMAP that allows for the message's length 
> to be advisory until it's actually read. It's relatively easy 
> to do -- 
> you have to have a way to ask the server simply, "Is there more?" as 
> well as the server to be able to return a short (even 
> zero-length) glob 
> of message text.
> 
> This gives a slightly counter-intuitive display on the 
> client. I might 
> look at a list of messages and see that one is 8K long, and 
> when I read 
> that message its length updates to 13K. But in return, we'd 
> be able to 
> defer the cryptography to when a message is actually read, 
> rather than 
> when it enters my inbox.
> 
> 	Jon
> 

Date: Mon, 14 Mar 2005 10:07:31 -0800
From: Himanshu Chatterjee <[email-masked]>
Reply-To: Himanshu Chatterjee <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Subject: Re: rfc 2086 extention
Cc: [email-masked]
Sender: [email-masked]

Thanks Alexey, do you think that we should have some standard ( or
good practice ) of implementing hierarchical acl. I can have a
implementation where from any intermediate parent folder when we
cascade the acl downwards, we can associate some unique tag, with each
of the child folder acl, where this acl is propagating, runtime acl
evaluation can merge the acl at each respective folder. The unique tag
can be helpful in recognizing acl from child folders when we remove
acl from any parent. Other implementation can have a dynamic acl
evaluation maintaining the acl at only at a parent level. But both are
non standard, and i am looking ( or trying to find a  )  a more mature
way to do the things.

Himanshu

On Thu, 10 Mar 2005 19:40:19 +0000, Alexey Melnikov
<[email-masked]> wrote:
> Himanshu Chatterjee wrote:
> 
> >Is there any draft which describes how the hierarchical acl on a
> >folder ( acl given at parent folder and should flow down to all childs
> >) should be implemented. ( Implementation details like when acl is
> >given to a grantee on a folder how the acl is is to be merged and if
> >acl is revoked from parent folder how to remove acl from childs etc.)
> >
> >
> There is none so far, but I've discussed this with my co-workers. So if
> you have any questions/suggestions, feel free to ask.
> 
> Currently my server only allows to attach ACLs to a mailbox and the ACL
> propogates to all submailboxes. So this is a kind of "poor man"s
> hierarchical ACLs.
> 
> Are you planning to implement hierarchical ACLs?
> 
>

Date: Sat, 12 Mar 2005 23:41:15 +0000
From: Alexey Melnikov <[email-masked]>
To: Dave Cridland <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: 2086upd comments
Sender: [email-masked]

Dave Cridland wrote:

> On Thu Mar 10 22:34:26 2005, Alexey Melnikov wrote:
>
>> Cyrus Daboo wrote:
>>
>>> -- Section 4.1: add example with either + or - for rights.
>>
>> I've replaced the first example with the following:
>>
>>               C: A001 GETACL INBOX/Drafts
>>               S: * ACL INBOX/Drafts Fred rwipslxeta Chris lrswi
>>               S: A001 OK Getacl complete
>>               C: A002 SETACL INBOX/Drafts Chris +cda
>>               S: A002 OK Setacl complete
>>               C: A003 GETACL INBOX/Drafts
>>               S: * ACL INBOX/Drafts Fred rwipslxeta Chris lrswicda
>>               S: A003 OK Getacl complete
>
>
> Fred needs additional listing of "d" right, Chris needs additional 
> listing of "kxet" rights, surely?

Thanks, fixed.
The "d" right was missing from the example in section 4.2 as well.

Alexey

From: Dave Cridland <[email-masked]>
To: Alexey Melnikov <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>, Cyrus Daboo <[email-masked]>
Subject: Re: 2086upd comments
Date: Fri, 11 Mar 2005 11:45:43 +0000
Sender: [email-masked]

On Thu Mar 10 22:34:26 2005, Alexey Melnikov wrote:
> 
> Cyrus Daboo wrote:
> 
>> -- Section 4.1: add example with either + or - for rights.
> 
> I've replaced the first example with the following:
> 
>               C: A001 GETACL INBOX/Drafts
>               S: * ACL INBOX/Drafts Fred rwipslxeta Chris lrswi
>               S: A001 OK Getacl complete
>               C: A002 SETACL INBOX/Drafts Chris +cda
>               S: A002 OK Setacl complete
>               C: A003 GETACL INBOX/Drafts
>               S: * ACL INBOX/Drafts Fred rwipslxeta Chris lrswicda
>               S: A003 OK Getacl complete
> 

Fred needs additional listing of "d" right, Chris needs additional listing of "kxet" rights, surely?

Dave.

Date: Thu, 10 Mar 2005 22:40:18 +0000
From: Alexey Melnikov <[email-masked]>
To: Philip Guenther <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: 2086upd (-03) notes
Sender: [email-masked]

Philip Guenther wrote:

>Is the last paragraph of 6.1.1 trying to say that a single
>SETACL/DELETEACL may affects the ACLs for multiple mailboxes, or
>just that multiple entries in the ACL for the named mailbox?  I
>_think_ the latter was intended, in which case I would suggest
>replacing the paragraph with:
>  
>
Actually both :-), even though the latter is the most common case.

>	A server MAY modify entries in the ACL for more identifiers
>	than just the one in the request.  If such additional entries
>	are modified, the server MUST send an ACL response to inform
>	the client of the change.
>
The current text is:
   An ACL server MAY modify one or more ACL for one or more identifier as a
   side effect of modifying the ACL specified in a SETACL/DELETEACL.
   If the server does that it MUST send untagged ACL response(s) to 
notify the
   client about the changes made.

Note that I've added "(s)" after "response", so if the server modifies 
ACLs for multiple mailboxes, than it will have to send multiple ACL 
responses.

I would rather keep the existing text. Any objections?

Alexey

Date: Thu, 10 Mar 2005 22:34:26 +0000
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: 2086upd comments
Sender: [email-masked]

Cyrus Daboo wrote:

> -- 
> Section 4.1: add example with either + or - for rights.

I've replaced the first example with the following:

               C: A001 GETACL INBOX/Drafts
               S: * ACL INBOX/Drafts Fred rwipslxeta Chris lrswi
               S: A001 OK Getacl complete
               C: A002 SETACL INBOX/Drafts Chris +cda
               S: A002 OK Setacl complete
               C: A003 GETACL INBOX/Drafts
               S: * ACL INBOX/Drafts Fred rwipslxeta Chris lrswicda
               S: A003 OK Getacl complete

Date: Thu, 10 Mar 2005 22:26:01 +0000
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: 2086upd (-03) notes
Sender: [email-masked]

Philip Guenther wrote:

>In section 7 (Security Considerations), what is the restriction on
>LISTRIGHTS to protect against?  If you can use LISTRIGHTS, then you
>can also use SETACL, which provides an avenue for probing for users
>as well.  Must a server _not_ check for the existance of users in
>SETACL too?  If so, there's a lot of servers broken by this.
>
As per recent discussion I've removed:

   LISTRIGHTS command MUST NOT check that a particular identifier exists,
   however it SHOULD recognize special identifiers like "anyone".

If you want it back, please scream now!

Date: Thu, 10 Mar 2005 13:59:27 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Lisa Dusseault <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Recharter
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Thu, 10 Mar 2005, Lisa Dusseault wrote:
> Scott asked us this morning to recharter IMAPEXT to reflect the delayed 
> milestones for all active documents. Can the WG document authors contact me 
> with delivery commitments for next drafts, WG  last call and  submission to 
> IESG (except if you've already met any of those goals)?

I believe that SORT/THREAD is done, and any further needed work on it 
would be entirely editorial in nature.

-- Mark --

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

Cc: [email-masked]
From: Lisa Dusseault <[email-masked]>
Subject: Re: imapext minutes from IETF-62 [DRAFT]
Date: Thu, 10 Mar 2005 13:53:32 -0800
To: Rob Siemborski <[email-masked]>
Sender: [email-masked]

This is great.  I'll just use this opportunity to extract the  
deliverables:
  - Lisa to deliver recharter (new milestone dates) for WG
  - Alexey to produce new draft of 2086upd addressing last-call and  
post-last-call nits
  - Cyrus to produce new draft of annotate addressing last call issues  
and incorporating decisions recorded in these minutes
  - Alexey and Barry to produce new draft of LISTEXT with no open or  
editorial issues remaining, suitable for last call
  - Alexey to produce syntax draft for Annotate to use
  - Tony Hanson and Barry Leiba to review Chris's Comparator draft and  
ping Chris about it
  - Chris Newman to put cycles into Comparator
  - Arnt (who was absent) to review Chris's proposed simplification  
allowing only one comparator per search query

On Mar 10, 2005, at 12:15 PM, Rob Siemborski wrote:

>
> Let me know your comments, I'll send this on to [email-masked]  
> probably tomorrow sometime.
>
> IMAPEXT Meeting at IETF-62, 3-10-2005, 9-11am CST.
>
> These minutes are based off the Jabber log, available here:
> http://www.xmpp.org/ietf-logs/[email-masked]/2005-03-10.htm
>
> Administrivia:
>
> Chairs welcomed the members to the IMAPEXT variety show.  The agenda  
> was bashed.
>
> 2086upd [draft-ietf-imapext-2086upd-03.txt]:
>
> - Chair summarized that people have been reviewing the document,  
> things are looking good and we're almost done.
>
> - Cyrus sent a large number of comments to the list this morning that  
> were mostly minor nits.
>
> - Room consensus that no comments had invalidated last call, and we  
> can move forward.
>
> ANNOTATE [draft-ietf-imapext-annotate-12.txt]:
>
> - Brief discussion about how references when replacing a document work  
> (you don't have to reference a document you are obsoleting)
>
> - Lisa summarized Cyrus's recent changed for the room.
>
> - Use of UTF-8 for values: rough consensus for 'SHOULD' instead of  
> 'MUST'
>
> - Discussion of open issues:
>   - Should servers validate the syntax of the content-type value? Yes.
>     (but should not have to validate that the actual content-type is
>      correct).
>     - We should reference RFC2046 for their content-type syntax.
>   - Should entity registrations contain a default content-type value?
>     - Other questions included:
>       "Should entries be forced to a particular content type?" No
>     - IANA registration will contain a recommended content-type value.
>   - Can values contain binary data?  Can we use the literal8 syntax  
> from
>     BINARY?
>     - Alternate ideas included tagging to indicate that a
>       binary response was desired. (experience from LDAP indicated this
>       was tricky to get right)
>     - Desire to not require BINARY extension, just the syntax.
>     - Desire to move literal8 syntax to the common syntax document.
>     - Rough consensus to use literal8 syntax for all ANNOTATE literals,
>       but no modifications for regular strings.
>     - Rough consensus to move literal8 syntax to the syntax document  
> (out
>       of BINARY).
>   - How to deal with hierarchy levels named 'shared' and 'priv'?
>     - Ambiguity on first hierarchy level.
>     - Rough consensus to just deny them on all levels.
>   - UTF-8 entry/attribute names
>     - We need stringprep for comparisons if they stay UTF-8
>     - Recent lunch BOF proposal to restrict to US-ASCII and have  
> another
>       attribute for UTF-8 display name.
>     - Additionally, clients are not required to use the display name  
> for
>       presentation if they choose not to.
>       - Really, the display name attribute would only be necessary for
>         custom entries (for standard entries, clients could know how  
> they
>         are used).
>     - Point that we will need stringprep for mailbox names eventually
>       anyway. (but this is likely a different stringprep profile).
>     - Observation that mailbox names aren't registered, its much nicer  
> to
>       be able to just register US-ASCII names.
>     - Rough consensus to restrict entry and attribute names to  
> US-ASCII,
>       and include a UTF-8 displayname attribute.
>   - Interaction with CATENATE syntax (for APPEND), since the CATENATE
>     draft is now APPEND-only.  Should we just reference the syntax  
> draft?
>     - Rough consensus: Yes.
>
> - Side discussion about making Alexey's syntax draft an official WG  
> item. Rough consensus to decide after seeing it (Alexey promises to be  
> quick with updates).
>
> - ANNOTATEMORE interaction: there are large blocks of shared text that  
> should now be updated in both places.
>
> LISTEXT [draft-ietf-imapext-list-extensions-11.txt]:
>
> - Philip summarized the changes to LISTEXT proposed at the interim and  
> subsequent list discussion, the main problem being that LIST responses  
> cannot rely on the context of the command that prompted them.
>   - Solution: move lots of this into CHILDINFO.
>
> - Discussion of possible difference in behavior with current RLIST and  
> the
> \Remote flag (currently a server does not need to actually declare  
> what mailboxes are remote and which ones aren't).  This could cause  
> problems for some type of proxies that choose to refer based on if the  
> clients send an RLIST or not.
>   - Probably not a problem, since LIST flags can change at any time,
>     really..
>
> - Issue: The current ABNF is very complex, can it be simplified?
>   - Observation: some of the syntax is performing validation that is
>     really semantic in nature.
>   - Cyrus offered to take a look and suggest text/new ABNF.
>
> - Chair asked authors of LISTEXT to propose strawman for open issues  
> in the next document, continuing to have open issues will just delay  
> the group.
>   - Authors asked that members who disagree with the strawman propose
>     alternates.
>
> Comparator (not a WG item) [draft-newman-i18n-comparator-03.txt]:
> - We have several items that depend on this.
> - Chris tried to find another author, and failed.  He will continue to  
> try
>   to find someone else to work on it, but will also commit some cycles
>   near term.
> - Chris is currently interrupt driven, and asks to be pinged.
>
> ACL2 & Working Group Future:
> - In San Diego we agreed to drop ACL2 if there had been no progress by  
> this meeting.  There hasn't been progress on ACL2, but there has been  
> substantial other progress.  Chair asks if we want to extend our  
> deadline given this (and adjust charter dates).
>   - Scott (AD) is ok with this.
>   - Rough consensus to revisit ACL2 in 6 months.
>
> - Members should watch the LEMONADE group for some of their  
> encrypted/signed message issues.  IMAPEXT (or at least its members)  
> should be involved in a deep way.
>
> i18n Document [draft-ietf-imapext-i18n-04.txt]:
> - Chris asks if we can simplify the use of comparators in the search  
> program so that one comparator could be used for the entire program.
>   - Example use case: search for case-sensitive local part and
>     case-insensitive domain part of an address.
>   - Point that we could accomplish most of the usefulness of this with
>     the ability to search within results.
>   - Rough consensus to simplify in this way, and allow for a future
>     extension to do the recursive search.  Chris will send a message to
>     Arnt and the list.
>
>
> ----------------------------------------------------------------------- 
> --
> Rob Siemborski        |     PGP:0x5CE32FCC     |       
> [email-masked] -----BEGIN GEEK CODE BLOCK----
> Version: 3.12
> GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w--  
> O-
> M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
> ------END GEEK CODE BLOCK-----
>

From: "Scott Hollenbeck" <[email-masked]>
To: "'Lisa Dusseault'" <[email-masked]>, "'IMAP Extensions WG'" <[email-masked]>
Subject: RE: Recharter
Date: Thu, 10 Mar 2005 16:53:33 -0500
Importance: Normal
Sender: [email-masked]

I wouldn't exactly call what's needed a "recharter" since the charter itself
should remain unchanged and IESG approval won't be required.  "Update the
milestones" would be a better way to describe what I asked for.

-Scott-

> -----Original Message-----
> From: Lisa Dusseault [mailto:[email-masked]] 
> Sent: Thursday, March 10, 2005 4:46 PM
> To: IMAP Extensions WG
> Subject: Recharter
> 
> 
> 
> Scott asked us this morning to recharter IMAPEXT to reflect 
> the delayed 
> milestones for all active documents. Can the WG document authors 
> contact me with delivery commitments for next drafts, WG  
> last call and 
>   submission to IESG (except if you've already met any of 
> those goals)?
> 
> thx,
> Lisa
> 
> 

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Recharter
Date: Thu, 10 Mar 2005 13:46:19 -0800
Sender: [email-masked]

Scott asked us this morning to recharter IMAPEXT to reflect the delayed 
milestones for all active documents. Can the WG document authors 
contact me with delivery commitments for next drafts, WG  last call and 
  submission to IESG (except if you've already met any of those goals)?

thx,
Lisa

Date: Thu, 10 Mar 2005 21:28:17 +0000
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: 2086upd comments
Sender: [email-masked]

Cyrus Daboo wrote:

> -- 
> Really ought to have i18n considerations section that restates the 
> SASLprep usage.

I've added:

10.   Internationalization Considerations

   Section 4 states requirements on servers regarding internationalization
   of identifiers.

===
I would rather not to repeat the text already stated elsewhere.

> Should the term 'authentication identifier' actually be 'authorization 
> identifier'? We are dealing with authorization here.
>
> -- 
> Some places 'identifier' is used others 'authentication identifier' - 
> needs to be conistent. In fact I would prefer to remove 
> 'authentication' (or 'authorization') entirely and just use identifier 
> or another term (e.g. WebDAV uses 'principal'). This is because these 
> items refer to things like groups as well.

I've replaced "authentication identifier" with just "identifier" everywhere.
I would rather not use the term "principal", as this has a strong 
association with Kerberos principals, at least for me.

Alexey

Date: Thu, 10 Mar 2005 15:15:58 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: [email-masked]
Subject: imapext minutes from IETF-62 [DRAFT]
Sender: [email-masked]

Let me know your comments, I'll send this on to [email-masked] probably 
tomorrow sometime.

IMAPEXT Meeting at IETF-62, 3-10-2005, 9-11am CST.

These minutes are based off the Jabber log, available here:
http://www.xmpp.org/ietf-logs/[email-masked]/2005-03-10.htm

Administrivia:

Chairs welcomed the members to the IMAPEXT variety show.  The agenda was 
bashed.

2086upd [draft-ietf-imapext-2086upd-03.txt]:

- Chair summarized that people have been reviewing the document, things 
are looking good and we're almost done.

- Cyrus sent a large number of comments to the list this morning that were 
mostly minor nits.

- Room consensus that no comments had invalidated last call, and we can 
move forward.

ANNOTATE [draft-ietf-imapext-annotate-12.txt]:

- Brief discussion about how references when replacing a document work 
(you don't have to reference a document you are obsoleting)

- Lisa summarized Cyrus's recent changed for the room.

- Use of UTF-8 for values: rough consensus for 'SHOULD' instead of 'MUST'

- Discussion of open issues:
   - Should servers validate the syntax of the content-type value? Yes.
     (but should not have to validate that the actual content-type is
      correct).
     - We should reference RFC2046 for their content-type syntax.
   - Should entity registrations contain a default content-type value?
     - Other questions included:
       "Should entries be forced to a particular content type?" No
     - IANA registration will contain a recommended content-type value.
   - Can values contain binary data?  Can we use the literal8 syntax from
     BINARY?
     - Alternate ideas included tagging to indicate that a
       binary response was desired. (experience from LDAP indicated this
       was tricky to get right)
     - Desire to not require BINARY extension, just the syntax.
     - Desire to move literal8 syntax to the common syntax document.
     - Rough consensus to use literal8 syntax for all ANNOTATE literals,
       but no modifications for regular strings.
     - Rough consensus to move literal8 syntax to the syntax document (out
       of BINARY).
   - How to deal with hierarchy levels named 'shared' and 'priv'?
     - Ambiguity on first hierarchy level.
     - Rough consensus to just deny them on all levels.
   - UTF-8 entry/attribute names
     - We need stringprep for comparisons if they stay UTF-8
     - Recent lunch BOF proposal to restrict to US-ASCII and have another
       attribute for UTF-8 display name.
     - Additionally, clients are not required to use the display name for
       presentation if they choose not to.
       - Really, the display name attribute would only be necessary for
         custom entries (for standard entries, clients could know how they
         are used).
     - Point that we will need stringprep for mailbox names eventually
       anyway. (but this is likely a different stringprep profile).
     - Observation that mailbox names aren't registered, its much nicer to
       be able to just register US-ASCII names.
     - Rough consensus to restrict entry and attribute names to US-ASCII,
       and include a UTF-8 displayname attribute.
   - Interaction with CATENATE syntax (for APPEND), since the CATENATE
     draft is now APPEND-only.  Should we just reference the syntax draft?
     - Rough consensus: Yes.

- Side discussion about making Alexey's syntax draft an official WG item. 
Rough consensus to decide after seeing it (Alexey promises to be quick 
with updates).

- ANNOTATEMORE interaction: there are large blocks of shared text that 
should now be updated in both places.

LISTEXT [draft-ietf-imapext-list-extensions-11.txt]:

- Philip summarized the changes to LISTEXT proposed at the interim and 
subsequent list discussion, the main problem being that LIST responses 
cannot rely on the context of the command that prompted them.
   - Solution: move lots of this into CHILDINFO.

- Discussion of possible difference in behavior with current RLIST and the
\Remote flag (currently a server does not need to actually declare what 
mailboxes are remote and which ones aren't).  This could cause problems 
for some type of proxies that choose to refer based on if the clients send 
an RLIST or not.
   - Probably not a problem, since LIST flags can change at any time,
     really..

- Issue: The current ABNF is very complex, can it be simplified?
   - Observation: some of the syntax is performing validation that is
     really semantic in nature.
   - Cyrus offered to take a look and suggest text/new ABNF.

- Chair asked authors of LISTEXT to propose strawman for open issues in 
the next document, continuing to have open issues will just delay the 
group.
   - Authors asked that members who disagree with the strawman propose
     alternates.

Comparator (not a WG item) [draft-newman-i18n-comparator-03.txt]:
- We have several items that depend on this.
- Chris tried to find another author, and failed.  He will continue to try
   to find someone else to work on it, but will also commit some cycles
   near term.
- Chris is currently interrupt driven, and asks to be pinged.

ACL2 & Working Group Future:
- In San Diego we agreed to drop ACL2 if there had been no progress by 
this meeting.  There hasn't been progress on ACL2, but there has been 
substantial other progress.  Chair asks if we want to extend our deadline 
given this (and adjust charter dates).
   - Scott (AD) is ok with this.
   - Rough consensus to revisit ACL2 in 6 months.

- Members should watch the LEMONADE group for some of their 
encrypted/signed message issues.  IMAPEXT (or at least its members) should 
be involved in a deep way.

i18n Document [draft-ietf-imapext-i18n-04.txt]:
- Chris asks if we can simplify the use of comparators in the search 
program so that one comparator could be used for the entire program.
   - Example use case: search for case-sensitive local part and
     case-insensitive domain part of an address.
   - Point that we could accomplish most of the usefulness of this with
     the ability to search within results.
   - Rough consensus to simplify in this way, and allow for a future
     extension to do the recursive search.  Chris will send a message to
     Arnt and the list.

-------------------------------------------------------------------------
Rob Siemborski        |     PGP:0x5CE32FCC     |      [email-masked] 
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

Date: Thu, 10 Mar 2005 19:31:13 +0000
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: 2086upd comments
Sender: [email-masked]

Cyrus Daboo wrote:

> Section 6.1.2 - client cannot preserve an unknown tied right, when 
> changing the known tied right. e.g. if we have tied rights 'r1', and 
> the client does not understand '1', it must still be able to remove 
> 'r' (and thus '1') without violating spec.

The client should ask the user if she wants to either set both, or 
remove both. That was the intent.
The text is trying to say that the default should be to set both.
This needs to be clarified.

Alexey

Date: Thu, 10 Mar 2005 12:20:55 -0500
From: Tony Hansen <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: 2086upd comments
Sender: [email-masked]

If you >>update<< a previous document, then you need a normative 
reference to the previous document for the parts that are still relevant.

A prerequisite to being able to say that you are obsoleting a previous 
document is that you must be totally replacing the previous document. So 
there is nothing in the previous document that you need in order to 
implement the updated version. If you can't make this statement, then 
you either need to change your claim to "updates" OR change your 
document such that you *can* make the statement that it "obsoletes" the 
previous document. Once you pass this litmus test, it's clear that the 
previous document is not required and should not be a normative reference.

	Tony Hansen
	[email-masked]

Alexey Melnikov wrote:
> 
> Cyrus Daboo wrote:
> 
>> Hi Alexey,
>>
>> --On March 10, 2005 2:56:42 PM +0000 Alexey Melnikov 
>> <[email-masked]> wrote:
>>
>>>> Is 2086 reference really only informative?
>>>
>>>
>>> 2086upd obsoletes RFC 2086. Can it have a normative reference to the
>>> document being obsoleted?
>>
>>
>> Well, is 2086 original needed in order to implement 2086upd.
> 
> 
> Not needed.
> 
>> Actually looking at it I think not, so maybe it can be informative.
> 
> 
> 
> 

Date: Thu, 10 Mar 2005 17:02:31 +0000
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: 2086upd comments
Sender: [email-masked]

Cyrus Daboo wrote:

> Hi Alexey,
>
> --On March 10, 2005 2:56:42 PM +0000 Alexey Melnikov 
> <[email-masked]> wrote:
>
>>> Is 2086 reference really only informative?
>>
>> 2086upd obsoletes RFC 2086. Can it have a normative reference to the
>> document being obsoleted?
>
> Well, is 2086 original needed in order to implement 2086upd.

Not needed.

> Actually looking at it I think not, so maybe it can be informative.

Cc: Alexey Melnikov <[email-masked]>, IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Re: 2086upd comments
Date: Thu, 10 Mar 2005 08:08:50 -0800
To: Cyrus Daboo <[email-masked]>
Sender: [email-masked]

>> ("/=" ==> "=/")
>>
>> Sure, this is an easy addition.
>
> I would also like to request the chairs to also 'enforce' that for the 
> other extensions, including the lemonade ones.
>
>
Sounds good; probalby the cleanest way to start this is to send a mail 
to Lemonade as there are quite a few reading that list and not this 
list.

Lisa

Date: Thu, 10 Mar 2005 15:09:14 +0000
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: 2086upd comments
Sender: [email-masked]

Cyrus Daboo wrote:

> In Section 'Rights required to perform different IMAP4rev1 commands' - 
> this is not quite right for the LIST/LSUB case. For those, executing 
> the command is always allowed - but there are no results. That is 
> different from e.g. SELECT, where lack of the r right causes a NO 
> response.

Ok, I've added:

    However, unlike other commands (e.g. SELECT) the server MUST NOT 
return a NO response if it can't list a mailbox.

Is this sufficient?

Date: Thu, 10 Mar 2005 10:05:21 -0500
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: 2086upd comments
Sender: [email-masked]

Hi Alexey,

--On March 10, 2005 2:56:42 PM +0000 Alexey Melnikov 
<[email-masked]> wrote:

>> Is 2086 reference really only informative?
>
> 2086upd obsoletes RFC 2086. Can it have a normative reference to the
> document being obsoleted?

Well, is 2086 original needed in order to implement 2086upd. Actually 
looking at it I think not, so maybe it can be informative.

>> --
>> General issue with extensions: shouldn't the capability identifier be
>> clearly defined in the formal syntax? Most extensions just state what
>> the capability is in the text - I now think that is wrong and that
>> they should extend the 3501 capability syntax item. e.g.:
>>
>> for 2086upd:
>>
>>     capability      /= rights-capa
>>
>> for ANNOTATE:
>>
>>     capability        /= "ANNOTATE"
>
> ("/=" ==> "=/")
>
> Sure, this is an easy addition.

I would also like to request the chairs to also 'enforce' that for the 
other extensions, including the lemonade ones.

-- 
Cyrus Daboo

Date: Thu, 10 Mar 2005 14:56:42 +0000
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: 2086upd comments
Sender: [email-masked]

Answering to some of the comments.

Cyrus Daboo wrote:

> Section 1: says '/' is used as hierarchy separator, but many examples 
> also use '.'.

Fixed, even thought I can pretend that "INBOX.Drafts" is just a 
non-hierarchical name ;-).
...

> -- 
> What about existing extensions: NAMESPACE, UNSELECT, RLIST, IDLE? I 
> think 2086upd should say something about those since they do exit now.

I don't want to have any unnecessary dependencies. There is a separate 
draft (draft-melnikov-acl-rights-XX.txt) that lists rights for URLAUTH 
commands, I can describe NAMESPACE, UNSELECT and IDLE there.

RLIST - I think it is deprecated by LISTEXT, so I wouldn't bother.

> In formal syntax:
>
>   rights          = astring
>                      ;; only lowercase ASCII letters and digits
>                      ;; are allowed.
>     
>     why not use explicit character ranges for defining this?

I don't really care. Any opinions?

> -- 
> Is 2086 reference really only informative?

2086upd obsoletes RFC 2086. Can it have a normative reference to the 
document being obsoleted?

> -- 
> General issue with extensions: shouldn't the capability identifier be 
> clearly defined in the formal syntax? Most extensions just state what 
> the capability is in the text - I now think that is wrong and that 
> they should extend the 3501 capability syntax item. e.g.:
>
> for 2086upd:
>
>     capability      /= rights-capa
>
> for ANNOTATE:
>
>     capability        /= "ANNOTATE"

("/=" ==> "=/")

Sure, this is an easy addition.
  
Alexey

Date: Thu, 10 Mar 2005 09:50:30 -0500
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: listext issue
Sender: [email-masked]

Problem in Formal Syntax:

   list-select-opts   = "(" [*(list-select-mod-opt SP) list-select-base-opt

                                       ^                       ^

That should be:

   list-select-opts   = "(" [*(list-sel-mod-opt SP) list-sel-base-opt

-- 
Cyrus Daboo

Date: Thu, 10 Mar 2005 09:22:35 -0500
From: Cyrus Daboo <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: 2086upd comments
Sender: [email-masked]

--
Section 1: says '/' is used as hierarchy separator, but many examples also 
use '.'.

--
Really ought to have i18n considerations section that restates the SASLprep 
usage.

--
Section 4.1: add example with either + or - for rights.

--
Should the term 'authentication identifier' actually be 'authorization 
identifier'? We are dealing with authorization here.

--
Some places 'identifier' is used others 'authentication identifier' - needs 
to be conistent. In fact I would prefer to remove 'authentication' (or 
'authorization') entirely and just use identifier or another term (e.g. 
WebDAV uses 'principal'). This is because these items refer to things like 
groups as well.

--
In Section 'Rights required to perform different IMAP4rev1 commands' - this 
is not quite right for the LIST/LSUB case. For those, executing the command 
is always allowed - but there are no results. That is different from e.g. 
SELECT, where lack of the r right causes a NO response.

--
In rights table, use 'i' to indicate 'implicit' rights. e.g. for FETCH, the 
'r' right is implicit as that is needed to first SELECT the mailbox. 
Alternatively, provide clear splits in the table for sections based on IMAP 
state (unauthenticate, authenticated, selected)

--
What about existing extensions: NAMESPACE, UNSELECT, RLIST, IDLE? I think 
2086upd should say something about those since they do exit now.

--
Section 6.1.2 - client cannot preserve an unknown tied right, when changing 
the known tied right. e.g. if we have tied rights 'r1', and the client does 
not understand '1', it must still be able to remove 'r' (and thus '1') 
without violating spec.

--
In formal syntax:

   rights          = astring
                      ;; only lowercase ASCII letters and digits
                      ;; are allowed.
	
	why not use explicit character ranges for defining this?

--
Is 2086 reference really only informative?

--
General issue with extensions: shouldn't the capability identifier be 
clearly defined in the formal syntax? Most extensions just state what the 
capability is in the text - I now think that is wrong and that they should 
extend the 3501 capability syntax item. e.g.:

for 2086upd:

	capability      /= rights-capa

for ANNOTATE:

	capability		/= "ANNOTATE"

-- 
Cyrus Daboo

Date: Wed, 9 Mar 2005 17:04:09 -0800
From: Himanshu Chatterjee <[email-masked]>
Reply-To: Himanshu Chatterjee <[email-masked]>
To: [email-masked]
Subject: rfc 2086 extention
Sender: [email-masked]

Is there any draft which describes how the hierarchical acl on a
folder ( acl given at parent folder and should flow down to all childs
) should be implemented. ( Implementation details like when acl is
given to a grantee on a folder how the acl is is to be merged and if
acl is revoked from parent folder how to remove acl from childs etc.)

Himanshu

Date: Wed, 9 Mar 2005 16:31:27 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Alexey Melnikov <[email-masked]>
cc: Philip Guenther <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: 2086upd (-03) notes
Sender: [email-masked]

On Wed, 9 Mar 2005, Alexey Melnikov wrote:

> The text is trying to say that the server should not disclose non-existence 
> of a user, i.e. it should not do the following:
>
>  C: a001 LISTRIGHTS Drafts foo
>  S: a001 NO user foo is not a valid user.

Ah, I was confusing LISTRIGHTS with GETACL.

This seems like it can be removed.

>> I also just noticed that Appendix C omits another ACL deficiency: the fact 
>> that users, groups, and special identifiers (e.g. anyone) exist in the 
>> same namespace (which ACL2 was solving with user=foo and group=bar type 
>> identifiers).
>
> I've added this to the Appendix C, thanks.

-Rob

-------------------------------------------------------------------------
Rob Siemborski        |     PGP:0x5CE32FCC     |      [email-masked] 
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

Date: Wed, 09 Mar 2005 21:26:34 +0000
From: Alexey Melnikov <[email-masked]>
To: Philip Guenther <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: 2086upd (-03) notes
Sender: [email-masked]

Philip Guenther wrote:

>Word-smithing *suggestions*:
>
>section 3.1:
>	Add FETCH BODY[...] to list for 's' right
>  
>
Ok.

>	Wording between 's', 'w', and 't' rights is inconsistent;
>	suggest changing to match 't'.
>  
>
Done.

>section 3.1.1:
>	Footnotes are not permitted by RFC editor.  The first
>	footnote can be made the second sentence of the second
>	paragraph.  The second footnote can be made the last paragraph
>	of the section, perhaps with additional indentation?
>
I would rather leave this for now and let an RFC editor decide.

>
>
>	Replace "rights to access a mailbox" with "rights on a mailbox"
>  
>
Done.

>section 3.2:
>	Replace the entire contents of the section with
>		The "RIGHTS=" capability MUST NOT include any of
>		the rights defined in RFC 2086: "l", "r", "s", "w",
>		"i", "p", "a", "c", "d", and the digits.
>  
>
Done.

>section 6.2:
>	The phrase "ACL server" should be changed to just "server"
>	in two places.  (That, or "server supporting ACL")
>
I've added:

   The phrase "ACL server" is just a short cut for saying "IMAP server
   that supports ACL extension as defined in this document".

to the section 1 instead, is it Ok?

Alexey

Date: Wed, 09 Mar 2005 21:07:57 +0000
From: Alexey Melnikov <[email-masked]>
To: Rob Siemborski <[email-masked]>
CC: Philip Guenther <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: 2086upd (-03) notes
Sender: [email-masked]

Rob Siemborski wrote:

>> In section 7 (Security Considerations), what is the restriction on
>> LISTRIGHTS to protect against?  If you can use LISTRIGHTS, then you
>> can also use SETACL, which provides an avenue for probing for users
>> as well.  Must a server _not_ check for the existance of users in
>> SETACL too?  If so, there's a lot of servers broken by this.
>
>
> Isn't this basicly saying "If you see an identifier that isn't in your 
> identifier database, please transmit it anyway and don't blow up?"

Not quite.

The text is trying to say that the server should not disclose 
non-existence of a user, i.e. it should not do the following:

   C: a001 LISTRIGHTS Drafts foo
   S: a001 NO user foo is not a valid user.

Now, Philip has pointed out that LISTRIGHTS and SETACL require the same 
privileges (the "a" right), and SETACL can be used to probe for users.

So, do people think that the recommendation should be removed?

> I'm not sure why this is a security consideration.
>
> I also just noticed that Appendix C omits another ACL deficiency: the 
> fact that users, groups, and special identifiers (e.g. anyone) exist 
> in the same namespace (which ACL2 was solving with user=foo and 
> group=bar type identifiers).

I've added this to the Appendix C, thanks.

Alexey

Date: Wed, 9 Mar 2005 10:54:22 -0500 (EST)
From: Rob Siemborski <[email-masked]>
To: Philip Guenther <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: 2086upd (-03) notes
Sender: [email-masked]

On Wed, 9 Mar 2005, Philip Guenther wrote:

> Overall, I think this is practically ready to go.

Likewise.

> In section 7 (Security Considerations), what is the restriction on
> LISTRIGHTS to protect against?  If you can use LISTRIGHTS, then you
> can also use SETACL, which provides an avenue for probing for users
> as well.  Must a server _not_ check for the existance of users in
> SETACL too?  If so, there's a lot of servers broken by this.

Isn't this basicly saying "If you see an identifier that isn't in your 
identifier database, please transmit it anyway and don't blow up?"

I'm not sure why this is a security consideration.

I also just noticed that Appendix C omits another ACL deficiency: the fact 
that users, groups, and special identifiers (e.g. anyone) exist in the 
same namespace (which ACL2 was solving with user=foo and group=bar type 
identifiers).

-Rob

-------------------------------------------------------------------------
Rob Siemborski        |     PGP:0x5CE32FCC     |      [email-masked] 
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----

To: IMAP Extensions WG <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: 2086upd (-03) notes
Date: Wed, 09 Mar 2005 07:32:46 -0800
Sender: [email-masked]

Overall, I think this is practically ready to go.  I have some
word-smithing suggestions below, but first a couple substantive
items.

Is the last paragraph of 6.1.1 trying to say that a single
SETACL/DELETEACL may affects the ACLs for multiple mailboxes, or
just that multiple entries in the ACL for the named mailbox?  I
_think_ the latter was intended, in which case I would suggest
replacing the paragraph with:
	A server MAY modify entries in the ACL for more identifiers
	than just the one in the request.  If such additional entries
	are modified, the server MUST send an ACL response to inform
	the client of the change.

In section 7 (Security Considerations), what is the restriction on
LISTRIGHTS to protect against?  If you can use LISTRIGHTS, then you
can also use SETACL, which provides an avenue for probing for users
as well.  Must a server _not_ check for the existance of users in
SETACL too?  If so, there's a lot of servers broken by this.

Word-smithing *suggestions*:

section 3.1:
	Add FETCH BODY[...] to list for 's' right

	Wording between 's', 'w', and 't' rights is inconsistent;
	suggest changing to match 't'.

section 3.1.1:
	Footnotes are not permitted by RFC editor.  The first
	footnote can be made the second sentence of the second
	paragraph.  The second footnote can be made the last paragraph
	of the section, perhaps with additional indentation?

	Replace "rights to access a mailbox" with "rights on a mailbox"

section 3.2:
	Replace the entire contents of the section with
		The "RIGHTS=" capability MUST NOT include any of
		the rights defined in RFC 2088: "l", "r", "s", "w",
		"i", "p", "a", "c", "d", and the digits.

section 6.2:
	The phrase "ACL server" should be changed to just "server"
	in two places.  (That, or "server supporting ACL")

Philip Guenther

To: Cyrus Daboo <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: Re: Revised Agenda for IMAPEXT 
Date: Tue, 08 Mar 2005 14:04:58 -0800
Sender: [email-masked]

Cyrus Daboo <[email-masked]> writes:
>--On March 8, 2005 1:18:19 PM -0800 Mark Crispin <[email-masked]> 
>wrote:
...
>> No.  We need a stringprep profile for mailbox names in IMAP.
>>
>> It's not just URLs.
>
>Right - that's what I meant, but we need it BEFORE we start deploying 
>CATENATE and URLAUTH otherwise we are asking for trouble.

How so?  An imap: URL is going to be generated by an IMAP client, the
mailbox part being recoded from a LIST or LSUB response.  You do *no*
canonicalization when generating imap: URLs, just recoding.

Philip Guenther

To: Cyrus Daboo <[email-masked]>
Cc: Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: Re: Revised Agenda for IMAPEXT 
Date: Tue, 08 Mar 2005 13:45:01 -0800
Sender: [email-masked]

Cyrus Daboo <[email-masked]> writes:
...
>What do you want to do about ANNOTATEMORE - that has mailbox names in the 
>entries. I think it would be a big mistake to have to go back to using 
>modified-utf7 there.

Cyrus, where in ANNOTATEMORE are mailbox names in entries?  Looking at
draft -06, I only see them as separate arguments to GETANNOTATION and
SETANNOTATION commands...

Philip Guenther

Date: Tue, 08 Mar 2005 16:41:39 -0500
From: Cyrus Daboo <[email-masked]>
To: Lisa Dusseault <[email-masked]>
cc: Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Character sets, encodings and names of things
Sender: [email-masked]

Hi Lisa,

--On March 8, 2005 1:33:25 PM -0800 Lisa Dusseault <[email-masked]> 
wrote:

> Trying to follow, but Philip and I are confused about this exchange, or
> at least I'm confused and Philip hasn't been able to remove my confusion.
>
> What do mailbox names being in UTF-8 or UTF-8 requiring stringprep have
> to do with attribute names (IDs) being ASCII?  Your message that sparked
> this thead implied that ANNOTATEMORE did something with mailbox names
> that would affect the character set requirements of attribute names, but
> I don't see that in looking at ANNOTATEMORE.
>

Ignore my ANNOTATEMORE comments - utf8 mailbox names are not going to be 
any more of an issue there than it is elsewhere. ANNOTATEMORE can use ascii 
for entry and attribute names as per new proposal for ANNOTATE.

-- 
Cyrus Daboo

To: Cyrus Daboo <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
From: Philip Guenther <[email-masked]>
Subject: Re: Revised Agenda for IMAPEXT 
Date: Tue, 08 Mar 2005 13:40:26 -0800
Sender: [email-masked]

Cyrus Daboo <[email-masked]> writes:
...
>But, isn't it the case that we need a stringprep profile for mailbox names 
>in IMAP URLs used in CATENATE and URLAUTH?

I don't think so: they're just referencing (recoded) names from the IMAP
protocol.  The interpretation of an IMAP URL is described as being "as
if" the client authenticated and used SELECT with the mUTF-7 form of the
mailbox name; matching is the responsibility of IMAP's SELECT and not
CATENATE or URLAUTH.

Philip Guenther

Date: Tue, 08 Mar 2005 16:37:16 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Lisa Dusseault <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Revised Agenda for IMAPEXT
Sender: [email-masked]

Hi Mark,

--On March 8, 2005 1:18:19 PM -0800 Mark Crispin <[email-masked]> 
wrote:

>> But, isn't it the case that we need a stringprep profile for mailbox
>> names in  IMAP URLs used in CATENATE and URLAUTH?
>
> No.  We need a stringprep profile for mailbox names in IMAP.
>
> It's not just URLs.

Right - that's what I meant, but we need it BEFORE we start deploying 
CATENATE and URLAUTH otherwise we are asking for trouble.

-- 
Cyrus Daboo

Cc: Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Character sets, encodings and names of things
Date: Tue, 8 Mar 2005 13:33:25 -0800
To: Cyrus Daboo <[email-masked]>
Sender: [email-masked]

Trying to follow, but Philip and I are confused about this exchange, or 
at least I'm confused and Philip hasn't been able to remove my 
confusion.

What do mailbox names being in UTF-8 or UTF-8 requiring stringprep have 
to do with attribute names (IDs) being ASCII?  Your message that 
sparked this thead implied that ANNOTATEMORE did something with mailbox 
names that would affect the character set requirements of attribute 
names, but I don't see that in looking at ANNOTATEMORE.

Lisa

On Mar 8, 2005, at 12:59 PM, Cyrus Daboo wrote:

> Hi Mark,
>
> --On March 8, 2005 12:50:16 PM -0800 Mark Crispin 
> <[email-masked]> wrote:
>
>>> No - isn't it %-style encoding UTF8 within the URL?
>>
>> We're splitting semantics here, but %-style encoding is not UTF-8, 
>> even
>> if it represents UTF-8 octets.  UTF-8 is 8-bit.
>>
>> Even though %-style encoding may appear to be "just" a trivial 
>> encoding
>> of UTF-8, it is nonetheless a separate way of encoding Unicode.
>>
>
> Well, OK.
>
> But, isn't it the case that we need a stringprep profile for mailbox 
> names in IMAP URLs used in CATENATE and URLAUTH?
>
> -- 
> Cyrus Daboo

Date: Tue, 8 Mar 2005 13:18:19 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Lisa Dusseault <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Revised Agenda for IMAPEXT
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 8 Mar 2005, Cyrus Daboo wrote:
> But, isn't it the case that we need a stringprep profile for mailbox names in 
> IMAP URLs used in CATENATE and URLAUTH?

No.  We need a stringprep profile for mailbox names in IMAP.

It's not just URLs.

-- Mark --

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

Date: Tue, 08 Mar 2005 15:59:21 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Lisa Dusseault <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Revised Agenda for IMAPEXT
Sender: [email-masked]

Hi Mark,

--On March 8, 2005 12:50:16 PM -0800 Mark Crispin <[email-masked]> 
wrote:

>> No - isn't it %-style encoding UTF8 within the URL?
>
> We're splitting semantics here, but %-style encoding is not UTF-8, even
> if it represents UTF-8 octets.  UTF-8 is 8-bit.
>
> Even though %-style encoding may appear to be "just" a trivial encoding
> of UTF-8, it is nonetheless a separate way of encoding Unicode.
>

Well, OK.

But, isn't it the case that we need a stringprep profile for mailbox names 
in IMAP URLs used in CATENATE and URLAUTH?

-- 
Cyrus Daboo

Date: Tue, 8 Mar 2005 12:50:16 -0800
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Lisa Dusseault <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Revised Agenda for IMAPEXT
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 8 Mar 2005, Cyrus Daboo wrote:
> No - isn't it %-style encoding UTF8 within the URL?

We're splitting semantics here, but %-style encoding is not UTF-8, even if 
it represents UTF-8 octets.  UTF-8 is 8-bit.

Even though %-style encoding may appear to be "just" a trivial encoding of 
UTF-8, it is nonetheless a separate way of encoding Unicode.

-- Mark --

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

Date: Tue, 08 Mar 2005 20:48:00 +0000
From: Alexey Melnikov <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: Revised Agenda for IMAPEXT
Sender: [email-masked]

Lisa Dusseault wrote:

> 30 min -- Issues remaining with Annotate - Randy
>     - Use of StringPrep to handle UTF8 entry/attribute names
>     - OR proposal to replace UTF8 attribute name with ASCII attribute 
> name + UTF8 "displayname"
>     - Plans for next draft, possible reissue of Last Call

I've just submitted my initial proposal with IMAP4 ABNF extensions, 
extracted from CONDSTORE, ANNOTATE, CATENATE and ESEARCH.
Before it is announced, you can view it at
<http://ietf.webdav.org/users/amelnikov/draft-melnikov-imap-ext-abnf-00.txt>

Alexey

Date: Tue, 08 Mar 2005 15:45:20 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Lisa Dusseault <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Revised Agenda for IMAPEXT
Sender: [email-masked]

Hi Mark,

--On March 8, 2005 12:32:45 PM -0800 Mark Crispin <[email-masked]> 
wrote:

>> BTW Both CATENEATE and URLAUTH use IMAP URL's which use UTF8 encoded
>> mailbox  names - so in some sense we are already mixing mUTF7 and UTF8
>> with those...
>
> Sigh, yes.  Section 9 of RFC 2192 was IMHO a mistake, but it's there.
>
> However, note that the URLs are still encoded in 7-bit, albeit in a
> different way than mUTF7.  So this isn't actually UTF-8, but rather
> YA7BEOU (Yet Another 7-Bit Encoding Of Unicode).
>

No - isn't it %-style encoding UTF8 within the URL? That my reading of 
Section 9, but I see the example in Section 10 does not have valid UTF8 
%-encoded characters...maybe I am missing something here.

-- 
Cyrus Daboo

Date: Tue, 8 Mar 2005 12:32:45 -0800
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Lisa Dusseault <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Revised Agenda for IMAPEXT
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Tue, 8 Mar 2005, Cyrus Daboo wrote:
> BTW Both CATENEATE and URLAUTH use IMAP URL's which use UTF8 encoded mailbox 
> names - so in some sense we are already mixing mUTF7 and UTF8 with those...

Sigh, yes.  Section 9 of RFC 2192 was IMHO a mistake, but it's there.

However, note that the URLs are still encoded in 7-bit, albeit in a 
different way than mUTF7.  So this isn't actually UTF-8, but rather 
YA7BEOU (Yet Another 7-Bit Encoding Of Unicode).

-- Mark --

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

Date: Tue, 08 Mar 2005 15:08:18 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Lisa Dusseault <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Revised Agenda for IMAPEXT
Sender: [email-masked]

Hi Mark,

--On March 8, 2005 11:52:17 AM -0800 Mark Crispin <[email-masked]> 
wrote:

>> What do you want to do about ANNOTATEMORE - that has mailbox names in
>> the  entries. I think it would be a big mistake to have to go back to
>> using  modified-utf7 there.
>
> I think that all uses of mailbox names in IMAP should follow the same
> scheme.  I think that it is far worse to have modified UTF-7 for mailbox
> names in one place and UTF-8 for mailbox names in another.

BTW Both CATENEATE and URLAUTH use IMAP URL's which use UTF8 encoded 
mailbox names - so in some sense we are already mixing mUTF7 and UTF8 with 
those...

-- 
Cyrus Daboo

Date: Tue, 08 Mar 2005 14:56:50 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>
cc: Lisa Dusseault <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Revised Agenda for IMAPEXT
Sender: [email-masked]

Hi Mark,

--On March 8, 2005 11:52:17 AM -0800 Mark Crispin <[email-masked]> 
wrote:

>> What do you want to do about ANNOTATEMORE - that has mailbox names in
>> the  entries. I think it would be a big mistake to have to go back to
>> using  modified-utf7 there.
>
> I think that all uses of mailbox names in IMAP should follow the same
> scheme.  I think that it is far worse to have modified UTF-7 for mailbox
> names in one place and UTF-8 for mailbox names in another.
>
> I would support the addition of a negotiated extension to repeal the
> modified UTF-7 requirement in IMAP.

If we are going to do that then we need to do it now and get the mailbox 
name stringprep profile (which will be required for this) into the 
appropriate i18n draft that defines stringpreps for SEARCH. I think we 
should do this all in one go rather than bit by bit.

-- 
Cyrus Daboo

Date: Tue, 8 Mar 2005 11:52:17 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Cyrus Daboo <[email-masked]>
cc: Lisa Dusseault <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: Revised Agenda for IMAPEXT
Sender: [email-masked]

On Tue, 8 Mar 2005, Cyrus Daboo wrote:
> What do you want to do about ANNOTATEMORE - that has mailbox names in the 
> entries. I think it would be a big mistake to have to go back to using 
> modified-utf7 there.

I think that all uses of mailbox names in IMAP should follow the same 
scheme.  I think that it is far worse to have modified UTF-7 for mailbox 
names in one place and UTF-8 for mailbox names in another.

I would support the addition of a negotiated extension to repeal the 
modified UTF-7 requirement in IMAP.

-- Mark --

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

Date: Tue, 08 Mar 2005 19:51:45 +0000
From: Alexey Melnikov <[email-masked]>
To: Lisa Dusseault <[email-masked]>
CC: [email-masked], IMAP Extensions WG <[email-masked]>
Subject: Re: Revised Agenda for IMAPEXT
Sender: [email-masked]

Lisa Dusseault wrote:

>
> Thursday, 9:00 am to 11:30 am
>
> 5 min -- Agenda-bashing and find note-taker and jabber scribe
> 5 min -- Status of 2086 upd -- Lisa
>     - NEED MORE REVIEWERS - send note to list if you've reviewed
> 30 min -- Issues remaining with Annotate - Randy
>     - Use of StringPrep to handle UTF8 entry/attribute names
>     - OR proposal to replace UTF8 attribute name with ASCII attribute 
> name + UTF8 "displayname"
>     - Plans for next draft, possible reissue of Last Call

Another issue:

ABNF for select/examine is wrong:

      select            =/ *(SP "(" select-param *(SP select-param) ")"
                          ; modifies the original IMAP select command to
                          ; accept optional parameters

      select-param      = astring / "(" astring SP astring *(SP astring) ")"
                          ; parameters to SELECT may contain one or
                          ; more atoms or strings - multiple items
                          ; are always parenthesised

select is defined in RFC 3501 as:
      select          = "SELECT" SP mailbox

Suggestion:

      select          = "SELECT" SP mailbox [select-params]
                              ;; modifies the original IMAP SELECT 
command to
                              ;; accept optional parameters

      select-params   = SP "(" select-param *(SP select-param) ")"
 
      select-param    = astring / "(" astring 1*(SP astring) ")"
                                ;; parameters to SELECT may contain one or
                                ;; more atoms or strings - multiple items
                                ;; are always parenthesised

A similar change for the EXAMINE is required.

> 30 min -- Issues remaining with ListExt - Barry
>     - ATTENDEES SHOULD READ LATEST (-11) DRAFT
>     - Comment on << editorial>> issues on list or at meeting
>     - selection and return command options and mailbox attributes
> 10 min -- Comparator status -- Chris Newman
>     - Comparator is not a WG document but I18N and SORT rely on it
>
> Time estimates are very rough and since we have the time we'll discuss 
> what comes up
>
> Audio streaming information: http://videolab.uoregon.edu/events/ietf/
> Text chat information: http://www.xmpp.org/ietf-chat.html

Date: Tue, 08 Mar 2005 14:42:16 -0500
From: Cyrus Daboo <[email-masked]>
To: Mark Crispin <[email-masked]>, Lisa Dusseault <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Revised Agenda for IMAPEXT
Sender: [email-masked]

Hi Mark,

--On March 8, 2005 11:31:04 AM -0800 Mark Crispin <[email-masked]> 
wrote:

>> 30 min -- Issues remaining with Annotate - Randy
>> 	- Use of StringPrep to handle UTF8 entry/attribute names
>> 	- OR proposal to replace UTF8 attribute name with ASCII attribute name
>> 	+ UTF8 "displayname"
>
> For what it's worth, I think that the proposal to replace UTF-8 attribute
> names with an ASCII attribute name and a UTF-8 display name is a good
> idea.
>

What do you want to do about ANNOTATEMORE - that has mailbox names in the 
entries. I think it would be a big mistake to have to go back to using 
modified-utf7 there.

-- 
Cyrus Daboo

Date: Tue, 8 Mar 2005 11:31:04 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Lisa Dusseault <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Revised Agenda for IMAPEXT
Sender: [email-masked]

On Tue, 8 Mar 2005, Lisa Dusseault wrote:
> 30 min -- Issues remaining with Annotate - Randy
> 	- Use of StringPrep to handle UTF8 entry/attribute names
> 	- OR proposal to replace UTF8 attribute name with ASCII attribute name + UTF8 "displayname"

For what it's worth, I think that the proposal to replace UTF-8 attribute 
names with an ASCII attribute name and a UTF-8 display name is a good 
idea.

-- Mark --

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

Cc: [email-masked], IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Revised Agenda for IMAPEXT
Date: Tue, 8 Mar 2005 11:06:51 -0800
To: Lisa Dusseault <[email-masked]>
Sender: [email-masked]

Thursday, 9:00 am to 11:30 am

5 min -- Agenda-bashing and find note-taker and jabber scribe
5 min -- Status of 2086 upd -- Lisa
	- NEED MORE REVIEWERS - send note to list if you've reviewed
30 min -- Issues remaining with Annotate - Randy
	- Use of StringPrep to handle UTF8 entry/attribute names
	- OR proposal to replace UTF8 attribute name with ASCII attribute name 
+ UTF8 "displayname"
	- Plans for next draft, possible reissue of Last Call
30 min -- Issues remaining with ListExt - Barry
	- ATTENDEES SHOULD READ LATEST (-11) DRAFT
	- Comment on << editorial>> issues on list or at meeting
	- selection and return command options and mailbox attributes
10 min -- Comparator status -- Chris Newman
	- Comparator is not a WG document but I18N and SORT rely on it

Time estimates are very rough and since we have the time we'll discuss 
what comes up

Audio streaming information: http://videolab.uoregon.edu/events/ietf/
Text chat information: http://www.xmpp.org/ietf-chat.html

Lisa

To: webdav WG <[email-masked]>, IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Fwd: IESG Document Review Process Update
Date: Mon, 7 Mar 2005 13:24:00 -0800
Sender: [email-masked]

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

FYI

Begin forwarded message:

> From: "Scott Hollenbeck" <[email-masked]>
> Date: March 7, 2005 9:24:11 AM PST
> To: [email-masked], [email-masked], 
> [email-masked], [email-masked], [email-masked], 
> [email-masked], [email-masked], [email-masked], 
> [email-masked], [email-masked], [email-masked], 
> [email-masked], [email-masked], [email-masked], 
> [email-masked], [email-masked], [email-masked], 
> [email-masked], [email-masked], [email-masked], 
> [email-masked], [email-masked], 
> [email-masked]
> Cc: "'Ted Hardie'" <[email-masked]>, [email-masked]
> Subject: IESG Document Review Process Update
>
> All Applications Area Working Group chairs:
>
> Over the last few years the IESG has been looking at ways to improve 
> our
> document review process.  The effort is described here:
>
> http://psg.com/~mrw/PROTO-Team/
>
> During today's open apparea meeting I announced that Ted and I will be 
> using
> the PROTO Team process for all new documents brought to us by your 
> working
> groups from now on.  That means that you as chairs have a few specific 
> tasks
> to complete as part of the document review process:
>
> 1. Completing a write-up describing the document that you want the 
> IESG to
> review:
> http://psg.com/~mrw/PROTO-Team/WGChair-Writeup.html
>
> 2. Shepherding resolution of AD review comments:
> http://psg.com/~mrw/PROTO-Team/ad-review-draft.txt
>
> 3. Shepherding resolution of IESG review comments:
> http://psg.com/~mrw/PROTO-Team/discuss-draft.txt
>
> On our end, Ted and I will strive to perform our reviews of your 
> documents
> before or during the IETF last call period.  This will hopefully speed
> things up a bit once the last call has been completed.
>
> Please review the material described above and let me know if you have 
> any
> questions.  Remember, too, that I am covering all of Ted's working 
> groups
> while he is enjoying paternity leave.
>
> Feel free to share this with your groups.
>
> -Scott-
>
>

--Apple-Mail-1-926938022
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
	charset=US-ASCII

FYI

Begin forwarded message:

<excerpt><bold><color><param>0000,0000,0000</param>From:
</color></bold>"Scott Hollenbeck" <<[email-masked]>

<bold><color><param>0000,0000,0000</param>Date: </color></bold>March
7, 2005 9:24:11 AM PST

<bold><color><param>0000,0000,0000</param>To:
</color></bold>[email-masked], [email-masked],
[email-masked], [email-masked], [email-masked],
[email-masked], [email-masked], [email-masked],
[email-masked], [email-masked], [email-masked],
[email-masked], [email-masked], [email-masked],
[email-masked], [email-masked], [email-masked],
[email-masked], [email-masked], [email-masked],
[email-masked], [email-masked], [email-masked]

<bold><color><param>0000,0000,0000</param>Cc: </color></bold>"'Ted
Hardie'" <<[email-masked]>, [email-masked]

<bold><color><param>0000,0000,0000</param>Subject: </color>IESG
Document Review Process Update

</bold>

All Applications Area Working Group chairs:

Over the last few years the IESG has been looking at ways to improve
our

document review process.  The effort is described here:

http://psg.com/~mrw/PROTO-Team/

During today's open apparea meeting I announced that Ted and I will be
using

the PROTO Team process for all new documents brought to us by your
working

groups from now on.  That means that you as chairs have a few specific
tasks

to complete as part of the document review process:

1. Completing a write-up describing the document that you want the
IESG to

review:

http://psg.com/~mrw/PROTO-Team/WGChair-Writeup.html

2. Shepherding resolution of AD review comments:

http://psg.com/~mrw/PROTO-Team/ad-review-draft.txt

3. Shepherding resolution of IESG review comments:

http://psg.com/~mrw/PROTO-Team/discuss-draft.txt

On our end, Ted and I will strive to perform our reviews of your
documents

before or during the IETF last call period.  This will hopefully speed

things up a bit once the last call has been completed.

Please review the material described above and let me know if you have
any

questions.  Remember, too, that I am covering all of Ted's working
groups

while he is enjoying paternity leave.

Feel free to share this with your groups.

-Scott-

</excerpt>
--Apple-Mail-1-926938022--

Cc: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Re: Last minute agenda
Date: Fri, 4 Mar 2005 22:44:51 -0800
To: Lisa Dusseault <[email-masked]>
Sender: [email-masked]

BTW, it looks like the most recent draft that was submitted on ListExt 
was accepted Feb 10, but it's draft -11, not draft -12.

Sorry,
Lisa

On Mar 3, 2005, at 12:01 PM, Lisa Dusseault wrote:

>
> I didn't see any agenda items proposed, so as usual this is last 
> minute:
>
> 5 min -- Agenda-bashing and find note-taker
> 5 min -- Status of 2086 upd
> 30 min -- Issues remaining with Annotate
> 	- Use of StringPrep
> 	- UTF8 entry/attribute names
> 	- Post-last-call draft due... ?
> 30 min -- Issues remaining with ListExt
> 	- ATTENDEES SHOULD READ LATEST (-12) DRAFT
> 	- Comment on << editorial>> issues on list or at meeting
> 	- selection and return command options and mailbox attributes
>
> I know Cyrus won't be there, how about Randy to discuss Annotate?  
> Alexey and Barry, will one of you be there to discuss ListExt?
>
> Any other topics?
>
> Lisa
>

Date: Fri, 04 Mar 2005 18:12:48 +0000
From: Alexey Melnikov <[email-masked]>
To: Cyrus Daboo <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Last minute agenda
Sender: [email-masked]

Cyrus Daboo wrote:

> Hi Alexey,
>
> --On Friday, March 04, 2005 05:28:45 PM +0000 Alexey Melnikov 
> <[email-masked]> wrote:
>
>> I also have a proposal to extract all ABNF/text that extends various
>> standard IMAP commands (like SELECT, FETCH, STORE and STATUS and APPEND)
>> into a separate document. This will avoid unnecessary dependencies, for
>> example between CATENATE and ANNOTATE.
>> In fact, I've already written it, just waiting for the moment when
>> submission will be allowed.
>> Does this sound interesting to the WG?
>
>
> Well of course there was the command+ draft that Barry and I wrote a 
> while ago - though that took an entirely different approach.

> I guess at this point we have to do a case-by-case command extension 
> syntax.

Yes and yes.

> It would certainly make it easier to have a syntax reference document 
> that all relevant extensions could reference. It would certainly be 
> useful for helping resolve the CATENATE / ANNOTATE inter-dependency.
>
> Of course this adds yet another blocking dependency to all the current 
> drafts...

I bet this draft will be done before CATENATE or ANNOTATE are approved. 
Especially if we choose to restrict its scope, for example if the SEARCH 
extensions go into a separate document.

Alexey

Date: Fri, 04 Mar 2005 13:03:57 -0500
From: Cyrus Daboo <[email-masked]>
To: Alexey Melnikov <[email-masked]>, Lisa Dusseault <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Last minute agenda
Sender: [email-masked]

Hi Alexey,

--On Friday, March 04, 2005 05:28:45 PM +0000 Alexey Melnikov 
<[email-masked]> wrote:

> I also have a proposal to extract all ABNF/text that extends various
> standard IMAP commands (like SELECT, FETCH, STORE and STATUS and APPEND)
> into a separate document. This will avoid unnecessary dependencies, for
> example between CATENATE and ANNOTATE.
> In fact, I've already written it, just waiting for the moment when
> submission will be allowed.
> Does this sound interesting to the WG?

Well of course there was the command+ draft that Barry and I wrote a while 
ago - though that took an entirely different approach. I guess at this 
point we have to do a case-by-case command extension syntax. It would 
certainly make it easier to have a syntax reference document that all 
relevant extensions could reference. It would certainly be useful for 
helping resolve the CATENATE / ANNOTATE inter-dependency.

Of course this adds yet another blocking dependency to all the current 
drafts...

-- 
Cyrus Daboo

Date: Fri, 04 Mar 2005 17:28:45 +0000
From: Alexey Melnikov <[email-masked]>
To: Lisa Dusseault <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Last minute agenda
Sender: [email-masked]

Lisa Dusseault wrote:

> I didn't see any agenda items proposed, so as usual this is last minute:
>
> 5 min -- Agenda-bashing and find note-taker
> 5 min -- Status of 2086 upd
> 30 min -- Issues remaining with Annotate
>     - Use of StringPrep
>     - UTF8 entry/attribute names
>     - Post-last-call draft due... ?
> 30 min -- Issues remaining with ListExt
>     - ATTENDEES SHOULD READ LATEST (-12) DRAFT
>     - Comment on << editorial>> issues on list or at meeting
>     - selection and return command options and mailbox attributes
>
> I know Cyrus won't be there, how about Randy to discuss Annotate?  
> Alexey and Barry, will one of you be there to discuss ListExt?

Barry should be in Minneapolist.

> Any other topics?

Do we have a closure on the minor editorial change you've proposed for 
2086upd?

I also have a proposal to extract all ABNF/text that extends various 
standard IMAP commands (like SELECT, FETCH, STORE and STATUS and APPEND) 
into a separate document. This will avoid unnecessary dependencies, for 
example between CATENATE and ANNOTATE.
In fact, I've already written it, just waiting for the moment when 
submission will be allowed.
Does this sound interesting to the WG?

Alexey

To: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Last minute agenda
Date: Thu, 3 Mar 2005 12:01:17 -0800
Sender: [email-masked]

I didn't see any agenda items proposed, so as usual this is last minute:

5 min -- Agenda-bashing and find note-taker
5 min -- Status of 2086 upd
30 min -- Issues remaining with Annotate
	- Use of StringPrep
	- UTF8 entry/attribute names
	- Post-last-call draft due... ?
30 min -- Issues remaining with ListExt
	- ATTENDEES SHOULD READ LATEST (-12) DRAFT
	- Comment on << editorial>> issues on list or at meeting
	- selection and return command options and mailbox attributes

I know Cyrus won't be there, how about Randy to discuss Annotate?  
Alexey and Barry, will one of you be there to discuss ListExt?

Any other topics?

Lisa