Subject: Re: Use of LIST-EXTENDED
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Date: Tue, 31 Jan 2006 12:54:15 +0100
List-Id: <ietf-imapext.imc.org>

Alexey Melnikov writes:
> Arnt Gulbrandsen wrote:
>> I'm trying to use it, and I want to use it. My major problems have 
>> been dealt with. The extended data items trip me up, though: My data 
>> aren't easily expressed as a list of nstrings.
>
> Can you elaborate on this?

Sure. I'm trying to, but the internet-drafts editor is sitting on the 
document ;) I want to return a search. (The search has been sent to the 
server earlier.)

I can either invent some syntax that fits in nstring or use search-key. 
I can either enclose the lot on a single nstring or use some real 
syntax. That makes four possibilities.

Sending a single nstring containing (search-key 1*(SP search-key)), all 
quoted, is bad, IMO. Quoting hell, and difficult to express in ABNF.

Sending a single nstring containing some new syntax is almost as bad. 
Inventing new search syntax just because of how listext defined future 
syntax? That's the tail wagging the dog.

Etc.

Sending search-key is the right thing to do, but the extended data 
options don't allow it, since that may not be parsable as a list of 
nstrings.

Arnt

Date: Tue, 31 Jan 2006 11:01:49 +0000
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: Use of LIST-EXTENDED
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Lisa Dusseault writes:
>
>> Anybody else, would you use LIST-EXTENDED if it went forward in its  
>> *current* form?  Or only if it did hypothetical extensions such as  
>> the one outlined by Dave?
>
> I'm trying to use it, and I want to use it. My major problems have 
> been dealt with. The extended data items trip me up, though: My data 
> aren't easily expressed as a list of nstrings.

Can you elaborate on this?

Date: Tue, 31 Jan 2006 11:00:05 +0000
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: LISTEXT to IESG?
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> The thing that gets me the extended data item syntax. That syntax 
> seems to be flexibility waiting for a task, hoping to be flexible 
> enough for whatever the task may turn out to be. In other words, a 
> solution looking for a problem.

Well, I had a similar discussion with Philip and Mark regarding generic 
syntax defined in draft-melnikov-imap-ext-abnf-08.txt and Marks position 
is that documents should provide guidance for future extensions.

The generic syntax for extensions defined in LIST-EXTENDED is the same 
as in draft-melnikov-imap-ext-abnf-08.txt. This helps to insure 
consistency between extensions to different commands and thus can 
minimize the number of different parsers people have to write.

> I'd rather let each future extension define its own syntax,

Each future extension should define own syntax which ideally should 
conform to the generic syntax specified in LIST-EXTENDED ("ideally 
should conform" because it might turn out that the generic syntax is not 
flexible enough. However I don't think this is very likely.)

> and forbid the server from adding extended data items unsolicited (ie. 
> striking the third sentence on page 8 of draft -15

Ok, let me talk about this for a bit. The sentence you are referring to 
reads:

   The server MAY return data in the extended fields that was not 
solicited by the client.

This sentence might need some clarification.

Firstly, there are 2 types of "solicited" fields: fields explicitly 
requested in the extended LIST command and fields implicitly requested 
by enabling some feature on the server (I can't think of such LIST field 
at the moment, but CONDSTORE defines a similar behavior when FETCH 
MODSEQ items are enabled on SELECT or other condstore-enabling command).

Secondly, IMAP has philosophy that any data can send by an IMAP server 
at any time and an IMAP client MUST be able to cope with that. This "MAY 
return" refers to this part. In general the server has no reason to 
return such data, unless it is explicitly or implicitly asked for it.

> ). The general syntax could be:
>
>     ... [ SP 1*(extended-data-item-name SP extended-data-item) ]
>
> The -name would be an nstring, the -item's syntax specified by the 
> IANA registration of the -name. If a client knows the name, it can 
> parse the item. If not, it can't. Full stop.
>
> I know I've muttered about this before. Sorry for sounding like a 
> broken record.

Date: Tue, 31 Jan 2006 11:35:30 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: Use of LIST-EXTENDED
Sender: [email-masked]

[email-masked] writes:
> Arnt's point - that the one-size-fits-all syntax for extended data 
> items is a little ugly - I've also run into, both in the hypothetical 
> RECENT extension I outlined, plus any number of other more complex 
> extensions I've outlined privately. At this stage, I can't conceive 
> of any extended data items I'd like the server to send me 
> unilaterally, so I suspect Arnt's broken record needs another spin, 
> as it were.

FYI, I don't really mind "a little ugly". I really mind "can't make it 
do what I'm trying to do".

(And I mind ugly, too. But I could live with that if it would get the 
document done.)

Arnt

Date: Mon, 30 Jan 2006 22:47:16 +0000
From: [email-masked]
To: undisclosed-recipients:;
Sender: [email-masked]

Subject: Re: Use of LIST-EXTENDED

References: <[email-masked]>

 <[email-masked]>

In-Reply-To: <[email-masked]>

MIME-Version: 1.0

Message-Id: <[email-masked]>

From: Dave Cridland <[email-masked]>

To: Lisa Dusseault <[email-masked]>

Cc:  <[email-masked]>

Content-Type: text/plain; charset="us-ascii"; format="flowed"

On Mon Jan 30 19:48:51 2006, Lisa Dusseault wrote:

> Anybody else, would you use LIST-EXTENDED if it went forward in its 

>  *current* form?  Or only if it did hypothetical extensions such as 

>  the one outlined by Dave?

The point of the hypothetical extension is mainly that RECURSIVEMATCH 

may actually be the wrong thing. The only circumstances where descent 

criteria are the same as for listing criteria (where listing criteria 

are normal selection options, I forget the correct term) are for 

"views" of the mailbox heirarchy, I think.

Currently, we have only one such view, that of Subscribed mailboxes. 

We may have more in the future, but I can easily think of various 

possibilities for cases where descent criteria differ from listing 

criteria.

Arnt's point - that the one-size-fits-all syntax for extended data 

items is a little ugly - I've also run into, both in the hypothetical 

RECENT extension I outlined, plus any number of other more complex 

extensions I've outlined privately. At this stage, I can't conceive 

of any extended data items I'd like the server to send me 

unilaterally, so I suspect Arnt's broken record needs another spin, 

as it were.

That all said, I've implemented LIST-EXTENDED and POSTADDRESS, as 

well as LISTEXT/LIST-SUBSCRIBED (because I was bored). The RECENT 

extension can be achieved by pipelining LIST commands, easily enough, 

as can every extension I've contemplated, so I'm hardly stating that 

my concerns are show-stoppers, I'm merely questioning whether they've 

been adequately reviewed.

Dave.

-- 

           You see things; and you say "Why?"

   But I dream things that never were; and I say "Why not?"

    - George Bernard Shaw

Date: Mon, 30 Jan 2006 22:37:03 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Use of LIST-EXTENDED
Sender: [email-masked]

Lisa Dusseault writes:
> Anybody else, would you use LIST-EXTENDED if it went forward in its  
> *current* form?  Or only if it did hypothetical extensions such as  
> the one outlined by Dave?

I'm trying to use it, and I want to use it. My major problems have been 
dealt with. The extended data items trip me up, though: My data aren't 
easily expressed as a list of nstrings.

Arnt

Date: Mon, 30 Jan 2006 19:59:08 +0000
From: Alexey Melnikov <[email-masked]>
To: Lisa Dusseault <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Use of LIST-EXTENDED
Sender: [email-masked]

Lisa Dusseault wrote:

> We have in the past had several documents depending on LIST- 
> EXTENDED.  Since this document has taken so long, various authors  
> have reduced those dependencies and we now have no more active drafts  
> that depend on LIST-EXTENDED.  This URL will show the drafts that  
> depend and note they're all expired:
>
> http://rtg.ietf.org/~fenner/ietf/deps/index.cgi?dep=list-extensions
>
> Alexey, Michael,

Michael is no longer with Nokia, as far as I know.

> it would be good to get a sense of what you'd be  doing with 
> LIST-EXTENDED if it did go forward -- reissue those  drafts?

I would certainly reissue mine at some points. There are some other LIST 
extensions I have in mind as well.

> Or is it no longer needed?
>
> Anybody else, would you use LIST-EXTENDED if it went forward in its  
> *current* form?  Or only if it did hypothetical extensions such as  
> the one outlined by Dave? 

I am discussing privately with Dave if some tweaks to LIST-EXTENDED are 
needed. I will let you know the outcome of our discussion.

Cc: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Use of LIST-EXTENDED
Date: Mon, 30 Jan 2006 11:48:51 -0800
To: [email-masked], Alexey Melnikov <[email-masked]>
Sender: [email-masked]

We have in the past had several documents depending on LIST- 
EXTENDED.  Since this document has taken so long, various authors  
have reduced those dependencies and we now have no more active drafts  
that depend on LIST-EXTENDED.  This URL will show the drafts that  
depend and note they're all expired:

http://rtg.ietf.org/~fenner/ietf/deps/index.cgi?dep=list-extensions

Alexey, Michael, it would be good to get a sense of what you'd be  
doing with LIST-EXTENDED if it did go forward -- reissue those  
drafts?  Or is it no longer needed?

Anybody else, would you use LIST-EXTENDED if it went forward in its  
*current* form?  Or only if it did hypothetical extensions such as  
the one outlined by Dave?

Lisa

On Jan 26, 2006, at 7:25 AM, Dave Cridland wrote:

>
> Let's define a hypothetical extension to LIST-EXTENDED:
>
> It has a return option RECENT, which returns the recent count of a  
> mailbox.
>
> It also has a "base" selection option RECENT, which restricts the  
> selection to mailboxes which have a non-zero recent message count.  
> Being a base option, it means that this may be used with  
> RECURSIVEMATCH. We'll make it imply the RECENT return option, as is  
> traditional.
>
> Now... What I'd like to do with this extension is show my GUI tree  
> control of mailboxes which are subscribed, with little expander  
> buttons for those that have subscribed children, and also highlight  
> those mailboxes which have recent messages - or subscribed children  
> which have recent messages.
>
> In other words, assuming:
>
> A01 LIST (SUBSCRIBED) "" "*" RETURN (RECENT)
> * LIST (\Subscribed \UnMarked) "/" Foo
> * LIST (\Subscribed \Marked) "/" Foo/Bar/Baz ((RECENT "24"))
> * LIST (\Subscribed \Marked) "/" Zab ((RECENT "42"))
> * LIST (\Subscribed \UnMarked) "/" Boring
> A01 OK
>
> Then I want to show Foo, Zab, and Boring. Foo and Zab will both be  
> highlighted, Boring will not be. Zab will have a recent count  
> displayed next to it.
>
> In order to do this, I need to:
>
> B01 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
> B02 LIST (SUBSCRIBED RECENT RECURSIVEMATCH) "" "%"
>
> B01 here gets the mailbox listing and the tree "expander"  
> information. B02 gets the highlighting information. The server has  
> to recusrively search twice.
>
> What I'd really like to do, though, is the imaginary syntax:
>
> C01 LIST (SUBSCRIBED RECURSIVEMATCH (SUBSCRIBED) RECURSIVEMATCH  
> (SUBSCRIBED RECENT)) "" "%" RETURN (RECENT)
>
> In other words, "Tell me all the subscribed mailboxes at the top  
> level, and also include CHILDINFO blocks for SUBSCRIBED and  
> SUBSCRIBED+RECENT".
>
> I can think of more use-cases for this than for multiple mailbox  
> patterns, incidentally.
>
> From the server's perspective, it now has to perform the recursive  
> mailbox search only once through, rather than twice, which seems  
> more efficient.
>
> Is this worth considering at this late stage?
>
> Dave.
> -- 
>           You see things; and you say "Why?"
>   But I dream things that never were; and I say "Why not?"
>    - George Bernard Shaw
>
>

To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Subject: Last Call: 'IMAP Extension for Conditional STORE operation' to  Proposed Standard 
Reply-to: [email-masked]
CC: <[email-masked]>
Date: Thu, 26 Jan 2006 12:03:34 -0500
Sender: [email-masked]

The IESG has received a request from the Internet Message Access Protocol 
Extension WG to consider the following document:

- 'IMAP Extension for Conditional STORE operation '
   <draft-ietf-imapext-condstore-08.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2006-02-09.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-imapext-condstore-08.txt

On 25 January 2006 the IMAPEXT working group chairs request sent a request
to their area advisor to ask the IESG to evaluate
draft-ietf-imapext-condstore-08.txt as a replacement for
draft-ietf-imapext-condstore-05.txt.  The IESG approved
draft-ietf-imapext-condstore-05.txt for publication as a Proposed Standard
RFC on 4 December 2003.

Changes from -05:
1. Reworded not to have a normative reference to ANNOTATE.
2. Updated ABNF to reference IMAP ABNF.
3. Clarified that STATUS (HIGHESTMODSEQ) also enables CONDSTORE notifications.
4. Fixed few typos in examples or example titles.
5. Updated boilerplate, references.

Date: Thu, 26 Jan 2006 15:25:56 +0000
Subject: A hypothetical extension
From: Dave Cridland <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Let's define a hypothetical extension to LIST-EXTENDED:

It has a return option RECENT, which returns the recent count of a 
mailbox.

It also has a "base" selection option RECENT, which restricts the 
selection to mailboxes which have a non-zero recent message count. 
Being a base option, it means that this may be used with 
RECURSIVEMATCH. We'll make it imply the RECENT return option, as is 
traditional.

Now... What I'd like to do with this extension is show my GUI tree 
control of mailboxes which are subscribed, with little expander 
buttons for those that have subscribed children, and also highlight 
those mailboxes which have recent messages - or subscribed children 
which have recent messages.

In other words, assuming:

A01 LIST (SUBSCRIBED) "" "*" RETURN (RECENT)
* LIST (\Subscribed \UnMarked) "/" Foo
* LIST (\Subscribed \Marked) "/" Foo/Bar/Baz ((RECENT "24"))
* LIST (\Subscribed \Marked) "/" Zab ((RECENT "42"))
* LIST (\Subscribed \UnMarked) "/" Boring
A01 OK

Then I want to show Foo, Zab, and Boring. Foo and Zab will both be 
highlighted, Boring will not be. Zab will have a recent count 
displayed next to it.

In order to do this, I need to:

B01 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
B02 LIST (SUBSCRIBED RECENT RECURSIVEMATCH) "" "%"

B01 here gets the mailbox listing and the tree "expander" 
information. B02 gets the highlighting information. The server has to 
recusrively search twice.

What I'd really like to do, though, is the imaginary syntax:

C01 LIST (SUBSCRIBED RECURSIVEMATCH (SUBSCRIBED) RECURSIVEMATCH 
(SUBSCRIBED RECENT)) "" "%" RETURN (RECENT)

In other words, "Tell me all the subscribed mailboxes at the top 
level, and also include CHILDINFO blocks for SUBSCRIBED and 
SUBSCRIBED+RECENT".

I can think of more use-cases for this than for multiple mailbox 
patterns, incidentally.

 From the server's perspective, it now has to perform the recursive 
mailbox search only once through, rather than twice, which seems more 
efficient.

Is this worth considering at this late stage?

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Thu, 26 Jan 2006 15:11:13 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: LISTEXT to IESG?
Cc: Barry Leiba <[email-masked]>, Ken Murchison <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

Arnt Gulbrandsen writes:
>     ... [ SP 1*(extended-data-item-name SP extended-data-item) ]

Sorry. ... [ 1* (SP extended-data-item-name SP extended-data-item) ] of course.

Date: Thu, 26 Jan 2006 15:01:35 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: LISTEXT to IESG?
Cc: Barry Leiba <[email-masked]>, Ken Murchison <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

Ken Murchison writes:
> Dave Cridland wrote:
>> 1) Are the server implementors happy, in particular with multiple 
>> mailbox patterns?
>
> I'm not thrilled about it.  I wonder if this feature is something that 
> clients really need, given the potential complexity for server 
> implementors.

What potential complexity? The ban on multiple responses was lifted, the 
rest doesn't seem too bad. Mildly pointless, not harmful or horribly 
complex.

The thing that gets me the extended data item syntax. That syntax seems 
to be flexibility waiting for a task, hoping to be flexible enough for 
whatever the task may turn out to be. In other words, a solution 
looking for a problem.

I'd rather let each future extension define its own syntax, and forbid 
the server from adding extended data items unsolicited (ie. striking 
the third sentence on page 8 of draft -15). The general syntax could 
be:

     ... [ SP 1*(extended-data-item-name SP extended-data-item) ]

The -name would be an nstring, the -item's syntax specified by the IANA 
registration of the -name. If a client knows the name, it can parse the 
item. If not, it can't. Full stop.

I know I've muttered about this before. Sorry for sounding like a broken 
record.

Arnt

Date: Thu, 26 Jan 2006 08:04:17 -0500
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: Dave Cridland <[email-masked]>
CC: Lisa Dusseault <[email-masked]>, [email-masked], Barry Leiba <[email-masked]>
Subject: Re: LISTEXT to IESG?
Sender: [email-masked]

Dave Cridland wrote:
> 
> On Wed Jan 25 20:22:35 2006, Lisa Dusseault wrote:
> 
>>
>> Dave Cridland was the only one who responded to this revision of  
>> LISTEXT, and raised no new issues.  Is anybody aware of open issues?   
>> Because I'm starting to think this is ready to go to IESG.  Speak up  
>> now.
>>
>>
> Well, I did respond to Barry's new revision, but I questioned:
> 
> 1) Are the server implementors happy, in particular with multiple 
> mailbox patterns?

I'm not thrilled about it.  I wonder if this feature is something that 
clients really need, given the potential complexity for server implementors.

-- 
Kenneth Murchison
Project Cyrus Developer/Maintainer
Carnegie Mellon University

Date: Thu, 26 Jan 2006 06:25:04 +0100
From: Arnaud Taddei <[email-masked]>
Subject: Re: LISTEXT to IESG?
To: Lisa Dusseault <[email-masked]>
Cc: Barry Leiba <[email-masked]>, [email-masked]
Sender: [email-masked]

Lisa Dusseault wrote:

>
> Dave Cridland was the only one who responded to this revision of  
> LISTEXT, and raised no new issues.  Is anybody aware of open issues?   
> Because I'm starting to think this is ready to go to IESG.  Speak up  
> now.

Am stuck since 2 weeks at 18 hours per day + too many buis trips. I have 
all my ideas in my head but need 2 hours to complete reading Dave's 
mails and making a second pass as I have several things to check but I 
think I found a way to align a proposal. Can I beg for doing this wait 
for Monday? I think I will work on it this week end.

A++

>
> Lisa
>
> On Jan 17, 2006, at 8:43 AM, Barry Leiba wrote:
>
>> I've attached an edited diff of the changes I've made based on  comments
>> so far.  They're minor -- mostly typo corrections and minor rewordings
>> and clarifications.  I've also changed the markup for the examples so
>> that the client/server exchanges are not double-spaced.
>>
>> My specific responses to comments are below.
>>
>>
>>>>> but also because I spent some ten minutes
>>>>> looking for the LIST response
>>>>>
>>>
>>> A note at the beginning in the introductory prose saying where the
>>> LIST response is defined is all that's needed.
>>>
>>
>> Dave, see if you like what I've done.  I put text in both the ABNF
>> introduction AND the definition of mailbox-list.
>>
>>
>>>> I believe that no matter what happens to ACAP,
>>>>
>>
>> I've reworded the ACAP text; let me know if you think that's OK.
>>
>>
>>> Page 7. Both examples appear to be missing spaces between the closing
>>> of one parenthesized list and the opening of the next.
>>>
>>
>> Fixed.
>>
>>
>>> 5) "[...] similar to the command <RLSUB "" "%">." - Should be "*",
>>> not "%".
>>> Extraneous comma in "mailboxes, which".
>>> 6) Extraneous comma.
>>> 8) "demonstates" typo.
>>> A1) "instead" should be "as well", surely? The "or even this" clause
>>> and example doesn't make sense to me - it's simply added
>>> \HasChildren, but the client didn't request it.
>>>
>>
>> Fixed all.
>>
>>
>>> C) "none of them is" should be "none of them are".
>>>
>>
>> Nah; "none" is singular, though it's acceptable to give it plural  usage
>> if one likes that sort of thing.  Actually, I've instead changed the
>> OTHER use of "none" to be singular, to match this one.
>>
>>
>>>>> a) So far, I've not seen any server implementation supporting
>>>>> multiple mailbox patterns.
>>>>>
>> ...
>>
>>> Yes, I think it could prove useful later, certainly. At this stage,
>>> it makes no real difference to clients, and it's additional
>>> complexity for servers - and server developers have historically
>>> preferred to avoid complexity at almost any cost.
>>>
>>
>> But we've had a couple of comments to leave it.  Do we have a
>> resolution for this issue?
>>
>> Dave has responded adequately to Arnaud's comments, so I'll refer to
>> Dave's note on it:
>>
>>
>>>   • I have a problem (which is surely my Frenglish) to understand
>>> 'or any combination of therof', I don't scan the word therof.
>>>   • Page 9 on the paragraph for REMOTE, the 3 last lines are really
>>> some byzantinism that is really a pain to explain operationally.
>>> Could we favor eliminating exceptions and enhancing protocol
>>> readability?
>>>   • Page 14, paragraph \HasChildren, I think I disagree with the
>>> security perspective
>>>   • Page 16, I am not familiar with the \Marked in example 2. What
>>> does this attribute mean? Where is it defined?
>>>   • Page 17, I think Example 6 requires much more explanations
>>>   • Page 19, Example 8: typo: it should be demonstrate and not
>>> demonstate, there is a missing r
>>>   • Page 26, I am not comfortable with the comment on ACAP at the
>>> beginning of section 6
>>>   • Page 30, at the end I dsiagree with the Security statement here
>>>   • Page 32, first paragrapha very small typo: there is a space
>>> between options/ extended, it should be options/extended to be
>>> consistent with the others after
>>>   • Page 34, the registration number 3 is almost a duplicate of
>>> registration number 1, you want to remove one or the other.
>>>
>>
>>
>>>>    * I disagree in the abstract on the Mailbox Referrals mention. No
>>>>      one implements it even not Microsoft correct? I think there are
>>>>      much more important issues to be covered in the abstract
>>>>
>>>
>>> I implement Mailbox Referrals in my client, and Cyrus IMAP implements
>>> it in the server. I think Mulberry implements it client-side too. In
>>> any case, the mention here is illustrating that its addition forces
>>> additional duplicate commands such as RLIST, RLSUB, etc, and I think
>>> that's justified.
>>>
>>
>> Agreed; it's staying.
>>
>>
>>> That's page 6 section 3 paragraph two. Should be "any combination
>>> thereof".
>>>
>>
>> Fixed typo.
>>
>>
>>>>    * Page 9 on the paragraph for REMOTE, the 3 last lines are really
>>>>      some byzantinism that is really a pain to explain
>>>> operationally.
>>>>      Could we favor eliminating exceptions and enhancing protocol
>>>>      readability?
>>>>
>>>
>>> It was tricky to explain at all. The nature of what's wrong with
>>> REMOTE RECURSIVEMATCH isn't echoed fully in the subsection on
>>> RECURSIVEMATCH, incidentally.
>>>
>>
>> I've added a phrase to the RECURSIVEMATCH subsection to deal with  that.
>> Arnaud, if you have a better suggestion for how to explain the
>> interaction of REMOTE, give me text (Franglish is OK; I can cope).
>> What you see there is the best we could come up with (and, really, I
>> don't think it's that confusing).
>>
>>
>>>>    * Page 14, paragraph \HasChildren, I think I disagree with the
>>>>      security perspective
>>>>
>>>
>>> Rereading this section, I note that "the server MUST return these
>>> attributes", but "a server MAY exclude both the [...] attributes".
>>>
>>
>> I presume, Arnaud, that you're referring to the bit about returning
>> \HasNoChildren if there are no children that the requester has access
>> to.  That statement represents established consensus here, so unless
>> there are others who want to change it, it'll stay.
>>
>> Dave, you're right that there's an unintended conflict there.  I did a
>> little rewording; let me know what you think of it.
>>
>>
>>>>    * Page 17, I think Example 6 requires much more explanations
>>>>
>>>
>>> I think I see why. Could you suggest some alternate text for
>>> explaining both example 5 and example 6? (I should think both would
>>> need to be changed to express the difference more clearly).
>>>
>>
>> Yes, text.
>> I'm afraid that at this point in the process I have to insist that
>> comments that say that text is needed MUST come with suggested text.
>> I'll accept suggestions for minor tweaks, of course, but if you think
>> something needs to be written at this point... please write it.
>>
>>
>>>>    * Page 30, at the end I dsiagree with the Security statement here
>>>>
>>>
>>> No, this is a security concern, and should be addressed by
>>> implementors.
>>>
>>
>> Agreed; this is an exposure of a "covert channel" -- a back door to
>> retrieve information that you couldn't normally retrieve.  It has  to be
>> documented.
>>
>>
>> Further comments?  Is -15a ready to go to the IESG as -16?
>>
>> Barry
>>
>> -- 
>> Barry Leiba, Pervasive Computing Technology  ([email-masked])
>> http://www.research.ibm.com/people/l/leiba
>> http://www.research.ibm.com/spam
>>
>> <draft-ietf-imapext-list-extensions-15to15adiff.txt>
>> <draft-ietf-imapext-list-extensions-15a.txt>
>>
>
>

Date: Wed, 25 Jan 2006 23:55:14 +0000
From: Alexey Melnikov <[email-masked]>
To: Dave Cridland <[email-masked]>
CC: Barry Leiba <[email-masked]>, [email-masked]
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
Sender: [email-masked]

Dave Cridland wrote:

>> >>> a) So far, I've not seen any server implementation supporting
>> >>> multiple mailbox patterns.
>> ...
>> > Yes, I think it could prove useful later, certainly. At this stage,
>> > it makes no real difference to clients, and it's additional
>> > complexity for servers - and server developers have historically
>> > preferred to avoid complexity at almost any cost.
>>
>> But we've had a couple of comments to leave it.  Do we have a
>> resolution for this issue?
>
> I've seen very little comment. My general suspicion is that those 
> server implementors who expressed any opinion at all aren't entirely 
> happy with it. Personally, I'd be happy to leave it in, but I'll defer 
> to the server folk.

Dave, if this make you happier, I am willing to fix Isode implementation 
to support multiple patterns ;-).

Date: Wed, 25 Jan 2006 22:58:02 +0000
Subject: Re: LISTEXT to IESG?
From: Dave Cridland <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: Lisa Dusseault <[email-masked]>, <[email-masked]>, Barry Leiba <[email-masked]>
Sender: [email-masked]

On Wed Jan 25 21:50:31 2006, Mark Crispin wrote:
> On Wed, 25 Jan 2006, Dave Cridland wrote:
>> 1) Are the server implementors happy, in particular with multiple 
>> mailbox patterns?
> 
> I'm not sure that I'm happy with it, but if (when I go to implement 
> it) LISTEXT proves to be impractical, I'll just punt.  I don't see 
> a clamoring market groundswell for LISTEXT.
> 
> 
I think there may be market groundswell for extensions which use 
LIST-EXTENDED as a base, so I for one would appreciate it if you 
could take the time to see whether there's anything obvious that'd 
cause you to punt.

>> 2) How is it possible for a server to be incapable of knowing 
>> whether there are child mailboxes, when a subsequent LIST of those 
>> children (if any) must be possible?
> 
> I agree that no server would be "incapable of knowing", but it may 
> be "excessively costly" depending upon how the store is designed.
> 
> 
I agree with your arguments here.

FWIW, I think based on this, Barry's changes in 15a aren't right.

What about, referencing -15:

1) Changing the last sentence of Section 4, second para, to:

	If the CHILDREN return option is present, the server SHOULD return 
these attributes even if their computation is expensive.

2) Replacing the last two sentences of the \HasChildren explanatory 
paragraph (third para) with:

	In such a case, the server MUST NOT set this attribute.

making the \HasChildren attribute definitive. I disagree with 
attributes which are not definitive.

There's also an error here - preceding sentence should read "[...] 
access to any child mailboxes."

In other words, servers say a mailbox has children or doesn't have 
children, or else they say nothing.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Wed, 25 Jan 2006 13:50:31 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: Lisa Dusseault <[email-masked]>, [email-masked], Barry Leiba <[email-masked]>
Subject: Re: LISTEXT to IESG?
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Wed, 25 Jan 2006, Dave Cridland wrote:
> 1) Are the server implementors happy, in particular with multiple mailbox 
> patterns?

I'm not sure that I'm happy with it, but if (when I go to implement it) 
LISTEXT proves to be impractical, I'll just punt.  I don't see a clamoring 
market groundswell for LISTEXT.

> 2) How is it possible for a server to be incapable of knowing whether there 
> are child mailboxes, when a subsequent LIST of those children (if any) must 
> be possible?

I agree that no server would be "incapable of knowing", but it may be 
"excessively costly" depending upon how the store is designed.

For example, it is a non-trivial exercise to determine whether or not a 
directory has contents that could be considered "children".  It is not 
enough to identify that it is a directory.  The directory's contents must 
also be examined.  Not all contents may qualify as "children", and some 
actions must be taken to discriminate.

For clients that do "*", it's silly for the server to calculate children; 
it already knows.  Leave aside the small matter that "*" is not good.

For clients that do "%/%", the question is answered for the upper level. 
What's more, clients have to do this anyway if the server doesn't support 
LISTEXT or CHILDREN.

So it comes down to the case of a client that does "%".  It knows (by the 
absence of \NoSelect) that it is reasonable to offer an "open messages" 
button.  It knows (by the absence of \NoInferiors) that it is reasonable 
to offer an "open inferiors" method.  The whole point of a server 
reporting children is to enable such a client to omit the "open inferiors" 
method.

This is undoubtably useful and user-friendly.  Time will tell if it wins 
on the cost/benefit question.

-- Mark --

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

Date: Wed, 25 Jan 2006 21:26:59 +0000
Subject: Re: LISTEXT to IESG?
From: Dave Cridland <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Cc: <[email-masked]>, Barry Leiba <[email-masked]>
Sender: [email-masked]

On Wed Jan 25 20:22:35 2006, Lisa Dusseault wrote:
> 
> Dave Cridland was the only one who responded to this revision of  
> LISTEXT, and raised no new issues.  Is anybody aware of open 
> issues?   Because I'm starting to think this is ready to go to 
> IESG.  Speak up  now.
> 
> 
Well, I did respond to Barry's new revision, but I questioned:

1) Are the server implementors happy, in particular with multiple 
mailbox patterns?

2) How is it possible for a server to be incapable of knowing whether 
there are child mailboxes, when a subsequent LIST of those children 
(if any) must be possible?

Everyone must have seen it. Possibly even more than once. (No, not my 
fault, as far as I'm able to detirmine.)

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Cc: [email-masked]
From: Lisa Dusseault <[email-masked]>
Subject: LISTEXT to IESG?
Date: Wed, 25 Jan 2006 12:22:35 -0800
To: Barry Leiba <[email-masked]>
Sender: [email-masked]

Dave Cridland was the only one who responded to this revision of  
LISTEXT, and raised no new issues.  Is anybody aware of open issues?   
Because I'm starting to think this is ready to go to IESG.  Speak up  
now.

Lisa

On Jan 17, 2006, at 8:43 AM, Barry Leiba wrote:

> I've attached an edited diff of the changes I've made based on  
> comments
> so far.  They're minor -- mostly typo corrections and minor rewordings
> and clarifications.  I've also changed the markup for the examples so
> that the client/server exchanges are not double-spaced.
>
> My specific responses to comments are below.
>
>
>>>> but also because I spent some ten minutes
>>>> looking for the LIST response
>>>>
>>
>> A note at the beginning in the introductory prose saying where the
>> LIST response is defined is all that's needed.
>>
>
> Dave, see if you like what I've done.  I put text in both the ABNF
> introduction AND the definition of mailbox-list.
>
>
>>> I believe that no matter what happens to ACAP,
>>>
>
> I've reworded the ACAP text; let me know if you think that's OK.
>
>
>> Page 7. Both examples appear to be missing spaces between the closing
>> of one parenthesized list and the opening of the next.
>>
>
> Fixed.
>
>
>> 5) "[...] similar to the command <RLSUB "" "%">." - Should be "*",
>> not "%".
>> Extraneous comma in "mailboxes, which".
>> 6) Extraneous comma.
>> 8) "demonstates" typo.
>> A1) "instead" should be "as well", surely? The "or even this" clause
>> and example doesn't make sense to me - it's simply added
>> \HasChildren, but the client didn't request it.
>>
>
> Fixed all.
>
>
>> C) "none of them is" should be "none of them are".
>>
>
> Nah; "none" is singular, though it's acceptable to give it plural  
> usage
> if one likes that sort of thing.  Actually, I've instead changed the
> OTHER use of "none" to be singular, to match this one.
>
>
>>>> a) So far, I've not seen any server implementation supporting
>>>> multiple mailbox patterns.
>>>>
> ...
>
>> Yes, I think it could prove useful later, certainly. At this stage,
>> it makes no real difference to clients, and it's additional
>> complexity for servers - and server developers have historically
>> preferred to avoid complexity at almost any cost.
>>
>
> But we've had a couple of comments to leave it.  Do we have a
> resolution for this issue?
>
> Dave has responded adequately to Arnaud's comments, so I'll refer to
> Dave's note on it:
>
>
>>   • I have a problem (which is surely my Frenglish) to understand
>> 'or any combination of therof', I don't scan the word therof.
>>   • Page 9 on the paragraph for REMOTE, the 3 last lines are really
>> some byzantinism that is really a pain to explain operationally.
>> Could we favor eliminating exceptions and enhancing protocol
>> readability?
>>   • Page 14, paragraph \HasChildren, I think I disagree with the
>> security perspective
>>   • Page 16, I am not familiar with the \Marked in example 2. What
>> does this attribute mean? Where is it defined?
>>   • Page 17, I think Example 6 requires much more explanations
>>   • Page 19, Example 8: typo: it should be demonstrate and not
>> demonstate, there is a missing r
>>   • Page 26, I am not comfortable with the comment on ACAP at the
>> beginning of section 6
>>   • Page 30, at the end I dsiagree with the Security statement here
>>   • Page 32, first paragrapha very small typo: there is a space
>> between options/ extended, it should be options/extended to be
>> consistent with the others after
>>   • Page 34, the registration number 3 is almost a duplicate of
>> registration number 1, you want to remove one or the other.
>>
>
>
>>>    * I disagree in the abstract on the Mailbox Referrals mention. No
>>>      one implements it even not Microsoft correct? I think there are
>>>      much more important issues to be covered in the abstract
>>>
>>
>> I implement Mailbox Referrals in my client, and Cyrus IMAP implements
>> it in the server. I think Mulberry implements it client-side too. In
>> any case, the mention here is illustrating that its addition forces
>> additional duplicate commands such as RLIST, RLSUB, etc, and I think
>> that's justified.
>>
>
> Agreed; it's staying.
>
>
>> That's page 6 section 3 paragraph two. Should be "any combination
>> thereof".
>>
>
> Fixed typo.
>
>
>>>    * Page 9 on the paragraph for REMOTE, the 3 last lines are really
>>>      some byzantinism that is really a pain to explain
>>> operationally.
>>>      Could we favor eliminating exceptions and enhancing protocol
>>>      readability?
>>>
>>
>> It was tricky to explain at all. The nature of what's wrong with
>> REMOTE RECURSIVEMATCH isn't echoed fully in the subsection on
>> RECURSIVEMATCH, incidentally.
>>
>
> I've added a phrase to the RECURSIVEMATCH subsection to deal with  
> that.
> Arnaud, if you have a better suggestion for how to explain the
> interaction of REMOTE, give me text (Franglish is OK; I can cope).
> What you see there is the best we could come up with (and, really, I
> don't think it's that confusing).
>
>
>>>    * Page 14, paragraph \HasChildren, I think I disagree with the
>>>      security perspective
>>>
>>
>> Rereading this section, I note that "the server MUST return these
>> attributes", but "a server MAY exclude both the [...] attributes".
>>
>
> I presume, Arnaud, that you're referring to the bit about returning
> \HasNoChildren if there are no children that the requester has access
> to.  That statement represents established consensus here, so unless
> there are others who want to change it, it'll stay.
>
> Dave, you're right that there's an unintended conflict there.  I did a
> little rewording; let me know what you think of it.
>
>
>>>    * Page 17, I think Example 6 requires much more explanations
>>>
>>
>> I think I see why. Could you suggest some alternate text for
>> explaining both example 5 and example 6? (I should think both would
>> need to be changed to express the difference more clearly).
>>
>
> Yes, text.
> I'm afraid that at this point in the process I have to insist that
> comments that say that text is needed MUST come with suggested text.
> I'll accept suggestions for minor tweaks, of course, but if you think
> something needs to be written at this point... please write it.
>
>
>>>    * Page 30, at the end I dsiagree with the Security statement here
>>>
>>
>> No, this is a security concern, and should be addressed by
>> implementors.
>>
>
> Agreed; this is an exposure of a "covert channel" -- a back door to
> retrieve information that you couldn't normally retrieve.  It has  
> to be
> documented.
>
>
> Further comments?  Is -15a ready to go to the IESG as -16?
>
> Barry
>
> --
> Barry Leiba, Pervasive Computing Technology  ([email-masked])
> http://www.research.ibm.com/people/l/leiba
> http://www.research.ibm.com/spam
>
> <draft-ietf-imapext-list-extensions-15to15adiff.txt>
> <draft-ietf-imapext-list-extensions-15a.txt>
>

Date: Tue, 17 Jan 2006 17:45:19 -0500
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
From: "Dave Cridland" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Content-Class: urn:content-classes:message
Importance: normal
Status:   
Sender: [email-masked]

On Tue Jan 17 16:43:36 2006, Barry Leiba wrote:
> >> > but also because I spent some ten minutes
> >> > looking for the LIST response
> > > A note at the beginning in the introductory prose saying where 
> the
> > LIST response is defined is all that's needed.
> 
> Dave, see if you like what I've done.  I put text in both the ABNF
> introduction AND the definition of mailbox-list.
> 
> 
That looks good.

> >> I believe that no matter what happens to ACAP,
> 
> I've reworded the ACAP text; let me know if you think that's OK.
> 
> 
Better.

> > C) "none of them is" should be "none of them are".
> 
> Nah; "none" is singular, though it's acceptable to give it plural 
> usage
> if one likes that sort of thing.  Actually, I've instead changed the
> OTHER use of "none" to be singular, to match this one.
> 
> 
Fairy nuff.

> >>> a) So far, I've not seen any server implementation supporting
> >>> multiple mailbox patterns.
> ...
> > Yes, I think it could prove useful later, certainly. At this 
> stage,
> > it makes no real difference to clients, and it's additional
> > complexity for servers - and server developers have historically
> > preferred to avoid complexity at almost any cost.
> 
> But we've had a couple of comments to leave it.  Do we have a
> resolution for this issue?
> 
> 
I've seen very little comment. My general suspicion is that those 
server implementors who expressed any opinion at all aren't entirely 
happy with it. Personally, I'd be happy to leave it in, but I'll 
defer to the server folk.

> Dave has responded adequately to Arnaud's comments, so I'll refer to
> Dave's note on it:

> >>    * Page 14, paragraph \HasChildren, I think I disagree with the
> >>      security perspective
> > > Rereading this section, I note that "the server MUST return 
> these
> > attributes", but "a server MAY exclude both the [...] attributes".
> 
> I presume, Arnaud, that you're referring to the bit about returning
> \HasNoChildren if there are no children that the requester has 
> access
> to.  That statement represents established consensus here, so unless
> there are others who want to change it, it'll stay.
> 
> Dave, you're right that there's an unintended conflict there.  I 
> did a
> little rewording; let me know what you think of it.
> 
> 
Right. You're saying that in the case where some architectural issue 
means that the server simply cannot detirmine whether a mailbox has 
children or not, then it can omit both attributes.

I understand what you're trying to say, I'm just not clear on how 
that can arise. Specifically, if a mailbox A exists, but the server 
finds it impossible to provide either CHILDREN attribute, then surely 
it also cannot handle a subsequent LIST of A's inferior mailboxes?

I can certainly follow that it may be expensive to find the 
information, that it may be equivalent to performing the second LIST 
internally, etc, but if it were impossible, then the subsequent LIST 
would also be impossible.

If by impossible you mean "*really* difficult", then you're 
essentially licensing servers to omit both flags when they feel like 
it - this is actually acceptable to me in this case, I'd just like to 
understand this issue a little better.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 17 Jan 2006 17:31:10 -0500
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
From: "Dave Cridland" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Content-Class: urn:content-classes:message
Importance: normal
Status:   
Sender: [email-masked]

On Tue Jan 17 16:43:36 2006, Barry Leiba wrote:
> >> > but also because I spent some ten minutes
> >> > looking for the LIST response
> > > A note at the beginning in the introductory prose saying where 
> the
> > LIST response is defined is all that's needed.
> 
> Dave, see if you like what I've done.  I put text in both the ABNF
> introduction AND the definition of mailbox-list.
> 
> 
That looks good.

> >> I believe that no matter what happens to ACAP,
> 
> I've reworded the ACAP text; let me know if you think that's OK.
> 
> 
Better.

> > C) "none of them is" should be "none of them are".
> 
> Nah; "none" is singular, though it's acceptable to give it plural 
> usage
> if one likes that sort of thing.  Actually, I've instead changed the
> OTHER use of "none" to be singular, to match this one.
> 
> 
Fairy nuff.

> >>> a) So far, I've not seen any server implementation supporting
> >>> multiple mailbox patterns.
> ...
> > Yes, I think it could prove useful later, certainly. At this 
> stage,
> > it makes no real difference to clients, and it's additional
> > complexity for servers - and server developers have historically
> > preferred to avoid complexity at almost any cost.
> 
> But we've had a couple of comments to leave it.  Do we have a
> resolution for this issue?
> 
> 
I've seen very little comment. My general suspicion is that those 
server implementors who expressed any opinion at all aren't entirely 
happy with it. Personally, I'd be happy to leave it in, but I'll 
defer to the server folk.

> Dave has responded adequately to Arnaud's comments, so I'll refer to
> Dave's note on it:

> >>    * Page 14, paragraph \HasChildren, I think I disagree with the
> >>      security perspective
> > > Rereading this section, I note that "the server MUST return 
> these
> > attributes", but "a server MAY exclude both the [...] attributes".
> 
> I presume, Arnaud, that you're referring to the bit about returning
> \HasNoChildren if there are no children that the requester has 
> access
> to.  That statement represents established consensus here, so unless
> there are others who want to change it, it'll stay.
> 
> Dave, you're right that there's an unintended conflict there.  I 
> did a
> little rewording; let me know what you think of it.
> 
> 
Right. You're saying that in the case where some architectural issue 
means that the server simply cannot detirmine whether a mailbox has 
children or not, then it can omit both attributes.

I understand what you're trying to say, I'm just not clear on how 
that can arise. Specifically, if a mailbox A exists, but the server 
finds it impossible to provide either CHILDREN attribute, then surely 
it also cannot handle a subsequent LIST of A's inferior mailboxes?

I can certainly follow that it may be expensive to find the 
information, that it may be equivalent to performing the second LIST 
internally, etc, but if it were impossible, then the subsequent LIST 
would also be impossible.

If by impossible you mean "*really* difficult", then you're 
essentially licensing servers to omit both flags when they feel like 
it - this is actually acceptable to me in this case, I'd just like to 
understand this issue a little better.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 17 Jan 2006 17:15:57 -0500
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
From: "Dave Cridland" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Content-Class: urn:content-classes:message
Importance: normal
Status:   
Sender: [email-masked]

On Tue Jan 17 16:43:36 2006, Barry Leiba wrote:
> >> > but also because I spent some ten minutes
> >> > looking for the LIST response
> > > A note at the beginning in the introductory prose saying where 
> the
> > LIST response is defined is all that's needed.
> 
> Dave, see if you like what I've done.  I put text in both the ABNF
> introduction AND the definition of mailbox-list.
> 
> 
That looks good.

> >> I believe that no matter what happens to ACAP,
> 
> I've reworded the ACAP text; let me know if you think that's OK.
> 
> 
Better.

> > C) "none of them is" should be "none of them are".
> 
> Nah; "none" is singular, though it's acceptable to give it plural 
> usage
> if one likes that sort of thing.  Actually, I've instead changed the
> OTHER use of "none" to be singular, to match this one.
> 
> 
Fairy nuff.

> >>> a) So far, I've not seen any server implementation supporting
> >>> multiple mailbox patterns.
> ...
> > Yes, I think it could prove useful later, certainly. At this 
> stage,
> > it makes no real difference to clients, and it's additional
> > complexity for servers - and server developers have historically
> > preferred to avoid complexity at almost any cost.
> 
> But we've had a couple of comments to leave it.  Do we have a
> resolution for this issue?
> 
> 
I've seen very little comment. My general suspicion is that those 
server implementors who expressed any opinion at all aren't entirely 
happy with it. Personally, I'd be happy to leave it in, but I'll 
defer to the server folk.

> Dave has responded adequately to Arnaud's comments, so I'll refer to
> Dave's note on it:

> >>    * Page 14, paragraph \HasChildren, I think I disagree with the
> >>      security perspective
> > > Rereading this section, I note that "the server MUST return 
> these
> > attributes", but "a server MAY exclude both the [...] attributes".
> 
> I presume, Arnaud, that you're referring to the bit about returning
> \HasNoChildren if there are no children that the requester has 
> access
> to.  That statement represents established consensus here, so unless
> there are others who want to change it, it'll stay.
> 
> Dave, you're right that there's an unintended conflict there.  I 
> did a
> little rewording; let me know what you think of it.
> 
> 
Right. You're saying that in the case where some architectural issue 
means that the server simply cannot detirmine whether a mailbox has 
children or not, then it can omit both attributes.

I understand what you're trying to say, I'm just not clear on how 
that can arise. Specifically, if a mailbox A exists, but the server 
finds it impossible to provide either CHILDREN attribute, then surely 
it also cannot handle a subsequent LIST of A's inferior mailboxes?

I can certainly follow that it may be expensive to find the 
information, that it may be equivalent to performing the second LIST 
internally, etc, but if it were impossible, then the subsequent LIST 
would also be impossible.

If by impossible you mean "*really* difficult", then you're 
essentially licensing servers to omit both flags when they feel like 
it - this is actually acceptable to me in this case, I'd just like to 
understand this issue a little better.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 17 Jan 2006 17:00:38 -0500
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
From: "Dave Cridland" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Content-Class: urn:content-classes:message
Importance: normal
Status:   
Sender: [email-masked]

On Tue Jan 17 16:43:36 2006, Barry Leiba wrote:
> >> > but also because I spent some ten minutes
> >> > looking for the LIST response
> > > A note at the beginning in the introductory prose saying where 
> the
> > LIST response is defined is all that's needed.
> 
> Dave, see if you like what I've done.  I put text in both the ABNF
> introduction AND the definition of mailbox-list.
> 
> 
That looks good.

> >> I believe that no matter what happens to ACAP,
> 
> I've reworded the ACAP text; let me know if you think that's OK.
> 
> 
Better.

> > C) "none of them is" should be "none of them are".
> 
> Nah; "none" is singular, though it's acceptable to give it plural 
> usage
> if one likes that sort of thing.  Actually, I've instead changed the
> OTHER use of "none" to be singular, to match this one.
> 
> 
Fairy nuff.

> >>> a) So far, I've not seen any server implementation supporting
> >>> multiple mailbox patterns.
> ...
> > Yes, I think it could prove useful later, certainly. At this 
> stage,
> > it makes no real difference to clients, and it's additional
> > complexity for servers - and server developers have historically
> > preferred to avoid complexity at almost any cost.
> 
> But we've had a couple of comments to leave it.  Do we have a
> resolution for this issue?
> 
> 
I've seen very little comment. My general suspicion is that those 
server implementors who expressed any opinion at all aren't entirely 
happy with it. Personally, I'd be happy to leave it in, but I'll 
defer to the server folk.

> Dave has responded adequately to Arnaud's comments, so I'll refer to
> Dave's note on it:

> >>    * Page 14, paragraph \HasChildren, I think I disagree with the
> >>      security perspective
> > > Rereading this section, I note that "the server MUST return 
> these
> > attributes", but "a server MAY exclude both the [...] attributes".
> 
> I presume, Arnaud, that you're referring to the bit about returning
> \HasNoChildren if there are no children that the requester has 
> access
> to.  That statement represents established consensus here, so unless
> there are others who want to change it, it'll stay.
> 
> Dave, you're right that there's an unintended conflict there.  I 
> did a
> little rewording; let me know what you think of it.
> 
> 
Right. You're saying that in the case where some architectural issue 
means that the server simply cannot detirmine whether a mailbox has 
children or not, then it can omit both attributes.

I understand what you're trying to say, I'm just not clear on how 
that can arise. Specifically, if a mailbox A exists, but the server 
finds it impossible to provide either CHILDREN attribute, then surely 
it also cannot handle a subsequent LIST of A's inferior mailboxes?

I can certainly follow that it may be expensive to find the 
information, that it may be equivalent to performing the second LIST 
internally, etc, but if it were impossible, then the subsequent LIST 
would also be impossible.

If by impossible you mean "*really* difficult", then you're 
essentially licensing servers to omit both flags when they feel like 
it - this is actually acceptable to me in this case, I'd just like to 
understand this issue a little better.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 17 Jan 2006 16:46:26 -0500
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
From: "Dave Cridland" <[email-masked]>
Cc: <[email-masked]>
To: <[email-masked]>
Content-Class: urn:content-classes:message
Importance: normal
Status:   
Sender: [email-masked]

On Tue Jan 17 16:43:36 2006, Barry Leiba wrote:
> >> > but also because I spent some ten minutes
> >> > looking for the LIST response
> > > A note at the beginning in the introductory prose saying where 
> the
> > LIST response is defined is all that's needed.
> 
> Dave, see if you like what I've done.  I put text in both the ABNF
> introduction AND the definition of mailbox-list.
> 
> 
That looks good.

> >> I believe that no matter what happens to ACAP,
> 
> I've reworded the ACAP text; let me know if you think that's OK.
> 
> 
Better.

> > C) "none of them is" should be "none of them are".
> 
> Nah; "none" is singular, though it's acceptable to give it plural 
> usage
> if one likes that sort of thing.  Actually, I've instead changed the
> OTHER use of "none" to be singular, to match this one.
> 
> 
Fairy nuff.

> >>> a) So far, I've not seen any server implementation supporting
> >>> multiple mailbox patterns.
> ...
> > Yes, I think it could prove useful later, certainly. At this 
> stage,
> > it makes no real difference to clients, and it's additional
> > complexity for servers - and server developers have historically
> > preferred to avoid complexity at almost any cost.
> 
> But we've had a couple of comments to leave it.  Do we have a
> resolution for this issue?
> 
> 
I've seen very little comment. My general suspicion is that those 
server implementors who expressed any opinion at all aren't entirely 
happy with it. Personally, I'd be happy to leave it in, but I'll 
defer to the server folk.

> Dave has responded adequately to Arnaud's comments, so I'll refer to
> Dave's note on it:

> >>    * Page 14, paragraph \HasChildren, I think I disagree with the
> >>      security perspective
> > > Rereading this section, I note that "the server MUST return 
> these
> > attributes", but "a server MAY exclude both the [...] attributes".
> 
> I presume, Arnaud, that you're referring to the bit about returning
> \HasNoChildren if there are no children that the requester has 
> access
> to.  That statement represents established consensus here, so unless
> there are others who want to change it, it'll stay.
> 
> Dave, you're right that there's an unintended conflict there.  I 
> did a
> little rewording; let me know what you think of it.
> 
> 
Right. You're saying that in the case where some architectural issue 
means that the server simply cannot detirmine whether a mailbox has 
children or not, then it can omit both attributes.

I understand what you're trying to say, I'm just not clear on how 
that can arise. Specifically, if a mailbox A exists, but the server 
finds it impossible to provide either CHILDREN attribute, then surely 
it also cannot handle a subsequent LIST of A's inferior mailboxes?

I can certainly follow that it may be expensive to find the 
information, that it may be equivalent to performing the second LIST 
internally, etc, but if it were impossible, then the subsequent LIST 
would also be impossible.

If by impossible you mean "*really* difficult", then you're 
essentially licensing servers to omit both flags when they feel like 
it - this is actually acceptable to me in this case, I'd just like to 
understand this issue a little better.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 17 Jan 2006 16:31:24 -0500
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
From: "Dave Cridland" <[email-masked]>
Cc: <[email-masked]>
To: <[email-masked]>
Content-Class: urn:content-classes:message
Importance: normal
Status:   
Sender: [email-masked]

On Tue Jan 17 16:43:36 2006, Barry Leiba wrote:
> >> > but also because I spent some ten minutes
> >> > looking for the LIST response
> > > A note at the beginning in the introductory prose saying where 
> the
> > LIST response is defined is all that's needed.
> 
> Dave, see if you like what I've done.  I put text in both the ABNF
> introduction AND the definition of mailbox-list.
> 
> 
That looks good.

> >> I believe that no matter what happens to ACAP,
> 
> I've reworded the ACAP text; let me know if you think that's OK.
> 
> 
Better.

> > C) "none of them is" should be "none of them are".
> 
> Nah; "none" is singular, though it's acceptable to give it plural 
> usage
> if one likes that sort of thing.  Actually, I've instead changed the
> OTHER use of "none" to be singular, to match this one.
> 
> 
Fairy nuff.

> >>> a) So far, I've not seen any server implementation supporting
> >>> multiple mailbox patterns.
> ...
> > Yes, I think it could prove useful later, certainly. At this 
> stage,
> > it makes no real difference to clients, and it's additional
> > complexity for servers - and server developers have historically
> > preferred to avoid complexity at almost any cost.
> 
> But we've had a couple of comments to leave it.  Do we have a
> resolution for this issue?
> 
> 
I've seen very little comment. My general suspicion is that those 
server implementors who expressed any opinion at all aren't entirely 
happy with it. Personally, I'd be happy to leave it in, but I'll 
defer to the server folk.

> Dave has responded adequately to Arnaud's comments, so I'll refer to
> Dave's note on it:

> >>    * Page 14, paragraph \HasChildren, I think I disagree with the
> >>      security perspective
> > > Rereading this section, I note that "the server MUST return 
> these
> > attributes", but "a server MAY exclude both the [...] attributes".
> 
> I presume, Arnaud, that you're referring to the bit about returning
> \HasNoChildren if there are no children that the requester has 
> access
> to.  That statement represents established consensus here, so unless
> there are others who want to change it, it'll stay.
> 
> Dave, you're right that there's an unintended conflict there.  I 
> did a
> little rewording; let me know what you think of it.
> 
> 
Right. You're saying that in the case where some architectural issue 
means that the server simply cannot detirmine whether a mailbox has 
children or not, then it can omit both attributes.

I understand what you're trying to say, I'm just not clear on how 
that can arise. Specifically, if a mailbox A exists, but the server 
finds it impossible to provide either CHILDREN attribute, then surely 
it also cannot handle a subsequent LIST of A's inferior mailboxes?

I can certainly follow that it may be expensive to find the 
information, that it may be equivalent to performing the second LIST 
internally, etc, but if it were impossible, then the subsequent LIST 
would also be impossible.

If by impossible you mean "*really* difficult", then you're 
essentially licensing servers to omit both flags when they feel like 
it - this is actually acceptable to me in this case, I'd just like to 
understand this issue a little better.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 17 Jan 2006 16:15:41 -0500
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
From: "Dave Cridland" <[email-masked]>
Cc: <[email-masked]>
To: <[email-masked]>
Content-Class: urn:content-classes:message
Importance: normal
Status:   
Sender: [email-masked]

On Tue Jan 17 16:43:36 2006, Barry Leiba wrote:
> >> > but also because I spent some ten minutes
> >> > looking for the LIST response
> > > A note at the beginning in the introductory prose saying where 
> the
> > LIST response is defined is all that's needed.
> 
> Dave, see if you like what I've done.  I put text in both the ABNF
> introduction AND the definition of mailbox-list.
> 
> 
That looks good.

> >> I believe that no matter what happens to ACAP,
> 
> I've reworded the ACAP text; let me know if you think that's OK.
> 
> 
Better.

> > C) "none of them is" should be "none of them are".
> 
> Nah; "none" is singular, though it's acceptable to give it plural 
> usage
> if one likes that sort of thing.  Actually, I've instead changed the
> OTHER use of "none" to be singular, to match this one.
> 
> 
Fairy nuff.

> >>> a) So far, I've not seen any server implementation supporting
> >>> multiple mailbox patterns.
> ...
> > Yes, I think it could prove useful later, certainly. At this 
> stage,
> > it makes no real difference to clients, and it's additional
> > complexity for servers - and server developers have historically
> > preferred to avoid complexity at almost any cost.
> 
> But we've had a couple of comments to leave it.  Do we have a
> resolution for this issue?
> 
> 
I've seen very little comment. My general suspicion is that those 
server implementors who expressed any opinion at all aren't entirely 
happy with it. Personally, I'd be happy to leave it in, but I'll 
defer to the server folk.

> Dave has responded adequately to Arnaud's comments, so I'll refer to
> Dave's note on it:

> >>    * Page 14, paragraph \HasChildren, I think I disagree with the
> >>      security perspective
> > > Rereading this section, I note that "the server MUST return 
> these
> > attributes", but "a server MAY exclude both the [...] attributes".
> 
> I presume, Arnaud, that you're referring to the bit about returning
> \HasNoChildren if there are no children that the requester has 
> access
> to.  That statement represents established consensus here, so unless
> there are others who want to change it, it'll stay.
> 
> Dave, you're right that there's an unintended conflict there.  I 
> did a
> little rewording; let me know what you think of it.
> 
> 
Right. You're saying that in the case where some architectural issue 
means that the server simply cannot detirmine whether a mailbox has 
children or not, then it can omit both attributes.

I understand what you're trying to say, I'm just not clear on how 
that can arise. Specifically, if a mailbox A exists, but the server 
finds it impossible to provide either CHILDREN attribute, then surely 
it also cannot handle a subsequent LIST of A's inferior mailboxes?

I can certainly follow that it may be expensive to find the 
information, that it may be equivalent to performing the second LIST 
internally, etc, but if it were impossible, then the subsequent LIST 
would also be impossible.

If by impossible you mean "*really* difficult", then you're 
essentially licensing servers to omit both flags when they feel like 
it - this is actually acceptable to me in this case, I'd just like to 
understand this issue a little better.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 17 Jan 2006 16:00:19 -0500
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
From: "Dave Cridland" <[email-masked]>
Cc: <[email-masked]>
To: <[email-masked]>
Content-Class: urn:content-classes:message
Importance: normal
Status:   
Sender: [email-masked]

On Tue Jan 17 16:43:36 2006, Barry Leiba wrote:
> >> > but also because I spent some ten minutes
> >> > looking for the LIST response
> > > A note at the beginning in the introductory prose saying where 
> the
> > LIST response is defined is all that's needed.
> 
> Dave, see if you like what I've done.  I put text in both the ABNF
> introduction AND the definition of mailbox-list.
> 
> 
That looks good.

> >> I believe that no matter what happens to ACAP,
> 
> I've reworded the ACAP text; let me know if you think that's OK.
> 
> 
Better.

> > C) "none of them is" should be "none of them are".
> 
> Nah; "none" is singular, though it's acceptable to give it plural 
> usage
> if one likes that sort of thing.  Actually, I've instead changed the
> OTHER use of "none" to be singular, to match this one.
> 
> 
Fairy nuff.

> >>> a) So far, I've not seen any server implementation supporting
> >>> multiple mailbox patterns.
> ...
> > Yes, I think it could prove useful later, certainly. At this 
> stage,
> > it makes no real difference to clients, and it's additional
> > complexity for servers - and server developers have historically
> > preferred to avoid complexity at almost any cost.
> 
> But we've had a couple of comments to leave it.  Do we have a
> resolution for this issue?
> 
> 
I've seen very little comment. My general suspicion is that those 
server implementors who expressed any opinion at all aren't entirely 
happy with it. Personally, I'd be happy to leave it in, but I'll 
defer to the server folk.

> Dave has responded adequately to Arnaud's comments, so I'll refer to
> Dave's note on it:

> >>    * Page 14, paragraph \HasChildren, I think I disagree with the
> >>      security perspective
> > > Rereading this section, I note that "the server MUST return 
> these
> > attributes", but "a server MAY exclude both the [...] attributes".
> 
> I presume, Arnaud, that you're referring to the bit about returning
> \HasNoChildren if there are no children that the requester has 
> access
> to.  That statement represents established consensus here, so unless
> there are others who want to change it, it'll stay.
> 
> Dave, you're right that there's an unintended conflict there.  I 
> did a
> little rewording; let me know what you think of it.
> 
> 
Right. You're saying that in the case where some architectural issue 
means that the server simply cannot detirmine whether a mailbox has 
children or not, then it can omit both attributes.

I understand what you're trying to say, I'm just not clear on how 
that can arise. Specifically, if a mailbox A exists, but the server 
finds it impossible to provide either CHILDREN attribute, then surely 
it also cannot handle a subsequent LIST of A's inferior mailboxes?

I can certainly follow that it may be expensive to find the 
information, that it may be equivalent to performing the second LIST 
internally, etc, but if it were impossible, then the subsequent LIST 
would also be impossible.

If by impossible you mean "*really* difficult", then you're 
essentially licensing servers to omit both flags when they feel like 
it - this is actually acceptable to me in this case, I'd just like to 
understand this issue a little better.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 17 Jan 2006 15:46:08 -0500
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
From: "Dave Cridland" <[email-masked]>
Cc: <[email-masked]>
To: <[email-masked]>
Content-Class: urn:content-classes:message
Importance: normal
Status:   
Sender: [email-masked]

On Tue Jan 17 16:43:36 2006, Barry Leiba wrote:
> >> > but also because I spent some ten minutes
> >> > looking for the LIST response
> > > A note at the beginning in the introductory prose saying where 
> the
> > LIST response is defined is all that's needed.
> 
> Dave, see if you like what I've done.  I put text in both the ABNF
> introduction AND the definition of mailbox-list.
> 
> 
That looks good.

> >> I believe that no matter what happens to ACAP,
> 
> I've reworded the ACAP text; let me know if you think that's OK.
> 
> 
Better.

> > C) "none of them is" should be "none of them are".
> 
> Nah; "none" is singular, though it's acceptable to give it plural 
> usage
> if one likes that sort of thing.  Actually, I've instead changed the
> OTHER use of "none" to be singular, to match this one.
> 
> 
Fairy nuff.

> >>> a) So far, I've not seen any server implementation supporting
> >>> multiple mailbox patterns.
> ...
> > Yes, I think it could prove useful later, certainly. At this 
> stage,
> > it makes no real difference to clients, and it's additional
> > complexity for servers - and server developers have historically
> > preferred to avoid complexity at almost any cost.
> 
> But we've had a couple of comments to leave it.  Do we have a
> resolution for this issue?
> 
> 
I've seen very little comment. My general suspicion is that those 
server implementors who expressed any opinion at all aren't entirely 
happy with it. Personally, I'd be happy to leave it in, but I'll 
defer to the server folk.

> Dave has responded adequately to Arnaud's comments, so I'll refer to
> Dave's note on it:

> >>    * Page 14, paragraph \HasChildren, I think I disagree with the
> >>      security perspective
> > > Rereading this section, I note that "the server MUST return 
> these
> > attributes", but "a server MAY exclude both the [...] attributes".
> 
> I presume, Arnaud, that you're referring to the bit about returning
> \HasNoChildren if there are no children that the requester has 
> access
> to.  That statement represents established consensus here, so unless
> there are others who want to change it, it'll stay.
> 
> Dave, you're right that there's an unintended conflict there.  I 
> did a
> little rewording; let me know what you think of it.
> 
> 
Right. You're saying that in the case where some architectural issue 
means that the server simply cannot detirmine whether a mailbox has 
children or not, then it can omit both attributes.

I understand what you're trying to say, I'm just not clear on how 
that can arise. Specifically, if a mailbox A exists, but the server 
finds it impossible to provide either CHILDREN attribute, then surely 
it also cannot handle a subsequent LIST of A's inferior mailboxes?

I can certainly follow that it may be expensive to find the 
information, that it may be equivalent to performing the second LIST 
internally, etc, but if it were impossible, then the subsequent LIST 
would also be impossible.

If by impossible you mean "*really* difficult", then you're 
essentially licensing servers to omit both flags when they feel like 
it - this is actually acceptable to me in this case, I'd just like to 
understand this issue a little better.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 17 Jan 2006 15:30:57 -0500
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
From: "Dave Cridland" <[email-masked]>
Cc: <[email-masked]>
To: <[email-masked]>
Content-Class: urn:content-classes:message
Importance: normal
Status:   
Sender: [email-masked]

On Tue Jan 17 16:43:36 2006, Barry Leiba wrote:
> >> > but also because I spent some ten minutes
> >> > looking for the LIST response
> > > A note at the beginning in the introductory prose saying where 
> the
> > LIST response is defined is all that's needed.
> 
> Dave, see if you like what I've done.  I put text in both the ABNF
> introduction AND the definition of mailbox-list.
> 
> 
That looks good.

> >> I believe that no matter what happens to ACAP,
> 
> I've reworded the ACAP text; let me know if you think that's OK.
> 
> 
Better.

> > C) "none of them is" should be "none of them are".
> 
> Nah; "none" is singular, though it's acceptable to give it plural 
> usage
> if one likes that sort of thing.  Actually, I've instead changed the
> OTHER use of "none" to be singular, to match this one.
> 
> 
Fairy nuff.

> >>> a) So far, I've not seen any server implementation supporting
> >>> multiple mailbox patterns.
> ...
> > Yes, I think it could prove useful later, certainly. At this 
> stage,
> > it makes no real difference to clients, and it's additional
> > complexity for servers - and server developers have historically
> > preferred to avoid complexity at almost any cost.
> 
> But we've had a couple of comments to leave it.  Do we have a
> resolution for this issue?
> 
> 
I've seen very little comment. My general suspicion is that those 
server implementors who expressed any opinion at all aren't entirely 
happy with it. Personally, I'd be happy to leave it in, but I'll 
defer to the server folk.

> Dave has responded adequately to Arnaud's comments, so I'll refer to
> Dave's note on it:

> >>    * Page 14, paragraph \HasChildren, I think I disagree with the
> >>      security perspective
> > > Rereading this section, I note that "the server MUST return 
> these
> > attributes", but "a server MAY exclude both the [...] attributes".
> 
> I presume, Arnaud, that you're referring to the bit about returning
> \HasNoChildren if there are no children that the requester has 
> access
> to.  That statement represents established consensus here, so unless
> there are others who want to change it, it'll stay.
> 
> Dave, you're right that there's an unintended conflict there.  I 
> did a
> little rewording; let me know what you think of it.
> 
> 
Right. You're saying that in the case where some architectural issue 
means that the server simply cannot detirmine whether a mailbox has 
children or not, then it can omit both attributes.

I understand what you're trying to say, I'm just not clear on how 
that can arise. Specifically, if a mailbox A exists, but the server 
finds it impossible to provide either CHILDREN attribute, then surely 
it also cannot handle a subsequent LIST of A's inferior mailboxes?

I can certainly follow that it may be expensive to find the 
information, that it may be equivalent to performing the second LIST 
internally, etc, but if it were impossible, then the subsequent LIST 
would also be impossible.

If by impossible you mean "*really* difficult", then you're 
essentially licensing servers to omit both flags when they feel like 
it - this is actually acceptable to me in this case, I'd just like to 
understand this issue a little better.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 17 Jan 2006 15:15:23 -0500
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
From: "Dave Cridland" <[email-masked]>
Cc: <[email-masked]>
To: <[email-masked]>
Content-Class: urn:content-classes:message
Importance: normal
Status:   
Sender: [email-masked]

On Tue Jan 17 16:43:36 2006, Barry Leiba wrote:
> >> > but also because I spent some ten minutes
> >> > looking for the LIST response
> > > A note at the beginning in the introductory prose saying where 
> the
> > LIST response is defined is all that's needed.
> 
> Dave, see if you like what I've done.  I put text in both the ABNF
> introduction AND the definition of mailbox-list.
> 
> 
That looks good.

> >> I believe that no matter what happens to ACAP,
> 
> I've reworded the ACAP text; let me know if you think that's OK.
> 
> 
Better.

> > C) "none of them is" should be "none of them are".
> 
> Nah; "none" is singular, though it's acceptable to give it plural 
> usage
> if one likes that sort of thing.  Actually, I've instead changed the
> OTHER use of "none" to be singular, to match this one.
> 
> 
Fairy nuff.

> >>> a) So far, I've not seen any server implementation supporting
> >>> multiple mailbox patterns.
> ...
> > Yes, I think it could prove useful later, certainly. At this 
> stage,
> > it makes no real difference to clients, and it's additional
> > complexity for servers - and server developers have historically
> > preferred to avoid complexity at almost any cost.
> 
> But we've had a couple of comments to leave it.  Do we have a
> resolution for this issue?
> 
> 
I've seen very little comment. My general suspicion is that those 
server implementors who expressed any opinion at all aren't entirely 
happy with it. Personally, I'd be happy to leave it in, but I'll 
defer to the server folk.

> Dave has responded adequately to Arnaud's comments, so I'll refer to
> Dave's note on it:

> >>    * Page 14, paragraph \HasChildren, I think I disagree with the
> >>      security perspective
> > > Rereading this section, I note that "the server MUST return 
> these
> > attributes", but "a server MAY exclude both the [...] attributes".
> 
> I presume, Arnaud, that you're referring to the bit about returning
> \HasNoChildren if there are no children that the requester has 
> access
> to.  That statement represents established consensus here, so unless
> there are others who want to change it, it'll stay.
> 
> Dave, you're right that there's an unintended conflict there.  I 
> did a
> little rewording; let me know what you think of it.
> 
> 
Right. You're saying that in the case where some architectural issue 
means that the server simply cannot detirmine whether a mailbox has 
children or not, then it can omit both attributes.

I understand what you're trying to say, I'm just not clear on how 
that can arise. Specifically, if a mailbox A exists, but the server 
finds it impossible to provide either CHILDREN attribute, then surely 
it also cannot handle a subsequent LIST of A's inferior mailboxes?

I can certainly follow that it may be expensive to find the 
information, that it may be equivalent to performing the second LIST 
internally, etc, but if it were impossible, then the subsequent LIST 
would also be impossible.

If by impossible you mean "*really* difficult", then you're 
essentially licensing servers to omit both flags when they feel like 
it - this is actually acceptable to me in this case, I'd just like to 
understand this issue a little better.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 17 Jan 2006 15:01:02 -0500
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
From: "Dave Cridland" <[email-masked]>
Cc: <[email-masked]>
To: <[email-masked]>
Content-Class: urn:content-classes:message
Importance: normal
Status:   
Sender: [email-masked]

On Tue Jan 17 16:43:36 2006, Barry Leiba wrote:
> >> > but also because I spent some ten minutes
> >> > looking for the LIST response
> > > A note at the beginning in the introductory prose saying where 
> the
> > LIST response is defined is all that's needed.
> 
> Dave, see if you like what I've done.  I put text in both the ABNF
> introduction AND the definition of mailbox-list.
> 
> 
That looks good.

> >> I believe that no matter what happens to ACAP,
> 
> I've reworded the ACAP text; let me know if you think that's OK.
> 
> 
Better.

> > C) "none of them is" should be "none of them are".
> 
> Nah; "none" is singular, though it's acceptable to give it plural 
> usage
> if one likes that sort of thing.  Actually, I've instead changed the
> OTHER use of "none" to be singular, to match this one.
> 
> 
Fairy nuff.

> >>> a) So far, I've not seen any server implementation supporting
> >>> multiple mailbox patterns.
> ...
> > Yes, I think it could prove useful later, certainly. At this 
> stage,
> > it makes no real difference to clients, and it's additional
> > complexity for servers - and server developers have historically
> > preferred to avoid complexity at almost any cost.
> 
> But we've had a couple of comments to leave it.  Do we have a
> resolution for this issue?
> 
> 
I've seen very little comment. My general suspicion is that those 
server implementors who expressed any opinion at all aren't entirely 
happy with it. Personally, I'd be happy to leave it in, but I'll 
defer to the server folk.

> Dave has responded adequately to Arnaud's comments, so I'll refer to
> Dave's note on it:

> >>    * Page 14, paragraph \HasChildren, I think I disagree with the
> >>      security perspective
> > > Rereading this section, I note that "the server MUST return 
> these
> > attributes", but "a server MAY exclude both the [...] attributes".
> 
> I presume, Arnaud, that you're referring to the bit about returning
> \HasNoChildren if there are no children that the requester has 
> access
> to.  That statement represents established consensus here, so unless
> there are others who want to change it, it'll stay.
> 
> Dave, you're right that there's an unintended conflict there.  I 
> did a
> little rewording; let me know what you think of it.
> 
> 
Right. You're saying that in the case where some architectural issue 
means that the server simply cannot detirmine whether a mailbox has 
children or not, then it can omit both attributes.

I understand what you're trying to say, I'm just not clear on how 
that can arise. Specifically, if a mailbox A exists, but the server 
finds it impossible to provide either CHILDREN attribute, then surely 
it also cannot handle a subsequent LIST of A's inferior mailboxes?

I can certainly follow that it may be expensive to find the 
information, that it may be equivalent to performing the second LIST 
internally, etc, but if it were impossible, then the subsequent LIST 
would also be impossible.

If by impossible you mean "*really* difficult", then you're 
essentially licensing servers to omit both flags when they feel like 
it - this is actually acceptable to me in this case, I'd just like to 
understand this issue a little better.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 17 Jan 2006 14:45:40 -0500
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
From: "Dave Cridland" <[email-masked]>
Cc: <[email-masked]>
To: <[email-masked]>
Content-class: urn:content-classes:message
Importance: normal
Status:   
Sender: [email-masked]

On Tue Jan 17 16:43:36 2006, Barry Leiba wrote:
> >> > but also because I spent some ten minutes
> >> > looking for the LIST response
> > > A note at the beginning in the introductory prose saying where 
> the
> > LIST response is defined is all that's needed.
> 
> Dave, see if you like what I've done.  I put text in both the ABNF
> introduction AND the definition of mailbox-list.
> 
> 
That looks good.

> >> I believe that no matter what happens to ACAP,
> 
> I've reworded the ACAP text; let me know if you think that's OK.
> 
> 
Better.

> > C) "none of them is" should be "none of them are".
> 
> Nah; "none" is singular, though it's acceptable to give it plural 
> usage
> if one likes that sort of thing.  Actually, I've instead changed the
> OTHER use of "none" to be singular, to match this one.
> 
> 
Fairy nuff.

> >>> a) So far, I've not seen any server implementation supporting
> >>> multiple mailbox patterns.
> ...
> > Yes, I think it could prove useful later, certainly. At this 
> stage,
> > it makes no real difference to clients, and it's additional
> > complexity for servers - and server developers have historically
> > preferred to avoid complexity at almost any cost.
> 
> But we've had a couple of comments to leave it.  Do we have a
> resolution for this issue?
> 
> 
I've seen very little comment. My general suspicion is that those 
server implementors who expressed any opinion at all aren't entirely 
happy with it. Personally, I'd be happy to leave it in, but I'll 
defer to the server folk.

> Dave has responded adequately to Arnaud's comments, so I'll refer to
> Dave's note on it:

> >>    * Page 14, paragraph \HasChildren, I think I disagree with the
> >>      security perspective
> > > Rereading this section, I note that "the server MUST return 
> these
> > attributes", but "a server MAY exclude both the [...] attributes".
> 
> I presume, Arnaud, that you're referring to the bit about returning
> \HasNoChildren if there are no children that the requester has 
> access
> to.  That statement represents established consensus here, so unless
> there are others who want to change it, it'll stay.
> 
> Dave, you're right that there's an unintended conflict there.  I 
> did a
> little rewording; let me know what you think of it.
> 
> 
Right. You're saying that in the case where some architectural issue 
means that the server simply cannot detirmine whether a mailbox has 
children or not, then it can omit both attributes.

I understand what you're trying to say, I'm just not clear on how 
that can arise. Specifically, if a mailbox A exists, but the server 
finds it impossible to provide either CHILDREN attribute, then surely 
it also cannot handle a subsequent LIST of A's inferior mailboxes?

I can certainly follow that it may be expensive to find the 
information, that it may be equivalent to performing the second LIST 
internally, etc, but if it were impossible, then the subsequent LIST 
would also be impossible.

If by impossible you mean "*really* difficult", then you're 
essentially licensing servers to omit both flags when they feel like 
it - this is actually acceptable to me in this case, I'd just like to 
understand this issue a little better.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 17 Jan 2006 14:30:29 -0500
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
From: "Dave Cridland" <[email-masked]>
Cc: <[email-masked]>
To: <[email-masked]>
Content-Class: urn:content-classes:message
Importance: normal
Status:   
Sender: [email-masked]

On Tue Jan 17 16:43:36 2006, Barry Leiba wrote:
> >> > but also because I spent some ten minutes
> >> > looking for the LIST response
> > > A note at the beginning in the introductory prose saying where 
> the
> > LIST response is defined is all that's needed.
> 
> Dave, see if you like what I've done.  I put text in both the ABNF
> introduction AND the definition of mailbox-list.
> 
> 
That looks good.

> >> I believe that no matter what happens to ACAP,
> 
> I've reworded the ACAP text; let me know if you think that's OK.
> 
> 
Better.

> > C) "none of them is" should be "none of them are".
> 
> Nah; "none" is singular, though it's acceptable to give it plural 
> usage
> if one likes that sort of thing.  Actually, I've instead changed the
> OTHER use of "none" to be singular, to match this one.
> 
> 
Fairy nuff.

> >>> a) So far, I've not seen any server implementation supporting
> >>> multiple mailbox patterns.
> ...
> > Yes, I think it could prove useful later, certainly. At this 
> stage,
> > it makes no real difference to clients, and it's additional
> > complexity for servers - and server developers have historically
> > preferred to avoid complexity at almost any cost.
> 
> But we've had a couple of comments to leave it.  Do we have a
> resolution for this issue?
> 
> 
I've seen very little comment. My general suspicion is that those 
server implementors who expressed any opinion at all aren't entirely 
happy with it. Personally, I'd be happy to leave it in, but I'll 
defer to the server folk.

> Dave has responded adequately to Arnaud's comments, so I'll refer to
> Dave's note on it:

> >>    * Page 14, paragraph \HasChildren, I think I disagree with the
> >>      security perspective
> > > Rereading this section, I note that "the server MUST return 
> these
> > attributes", but "a server MAY exclude both the [...] attributes".
> 
> I presume, Arnaud, that you're referring to the bit about returning
> \HasNoChildren if there are no children that the requester has 
> access
> to.  That statement represents established consensus here, so unless
> there are others who want to change it, it'll stay.
> 
> Dave, you're right that there's an unintended conflict there.  I 
> did a
> little rewording; let me know what you think of it.
> 
> 
Right. You're saying that in the case where some architectural issue 
means that the server simply cannot detirmine whether a mailbox has 
children or not, then it can omit both attributes.

I understand what you're trying to say, I'm just not clear on how 
that can arise. Specifically, if a mailbox A exists, but the server 
finds it impossible to provide either CHILDREN attribute, then surely 
it also cannot handle a subsequent LIST of A's inferior mailboxes?

I can certainly follow that it may be expensive to find the 
information, that it may be equivalent to performing the second LIST 
internally, etc, but if it were impossible, then the subsequent LIST 
would also be impossible.

If by impossible you mean "*really* difficult", then you're 
essentially licensing servers to omit both flags when they feel like 
it - this is actually acceptable to me in this case, I'd just like to 
understand this issue a little better.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 17 Jan 2006 14:15:36 -0500
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
From: "Dave Cridland" <[email-masked]>
Cc: <[email-masked]>
To: <[email-masked]>
Content-Class: urn:content-classes:message
Importance: normal
Status:   
Sender: [email-masked]

On Tue Jan 17 16:43:36 2006, Barry Leiba wrote:
> >> > but also because I spent some ten minutes
> >> > looking for the LIST response
> > > A note at the beginning in the introductory prose saying where 
> the
> > LIST response is defined is all that's needed.
> 
> Dave, see if you like what I've done.  I put text in both the ABNF
> introduction AND the definition of mailbox-list.
> 
> 
That looks good.

> >> I believe that no matter what happens to ACAP,
> 
> I've reworded the ACAP text; let me know if you think that's OK.
> 
> 
Better.

> > C) "none of them is" should be "none of them are".
> 
> Nah; "none" is singular, though it's acceptable to give it plural 
> usage
> if one likes that sort of thing.  Actually, I've instead changed the
> OTHER use of "none" to be singular, to match this one.
> 
> 
Fairy nuff.

> >>> a) So far, I've not seen any server implementation supporting
> >>> multiple mailbox patterns.
> ...
> > Yes, I think it could prove useful later, certainly. At this 
> stage,
> > it makes no real difference to clients, and it's additional
> > complexity for servers - and server developers have historically
> > preferred to avoid complexity at almost any cost.
> 
> But we've had a couple of comments to leave it.  Do we have a
> resolution for this issue?
> 
> 
I've seen very little comment. My general suspicion is that those 
server implementors who expressed any opinion at all aren't entirely 
happy with it. Personally, I'd be happy to leave it in, but I'll 
defer to the server folk.

> Dave has responded adequately to Arnaud's comments, so I'll refer to
> Dave's note on it:

> >>    * Page 14, paragraph \HasChildren, I think I disagree with the
> >>      security perspective
> > > Rereading this section, I note that "the server MUST return 
> these
> > attributes", but "a server MAY exclude both the [...] attributes".
> 
> I presume, Arnaud, that you're referring to the bit about returning
> \HasNoChildren if there are no children that the requester has 
> access
> to.  That statement represents established consensus here, so unless
> there are others who want to change it, it'll stay.
> 
> Dave, you're right that there's an unintended conflict there.  I 
> did a
> little rewording; let me know what you think of it.
> 
> 
Right. You're saying that in the case where some architectural issue 
means that the server simply cannot detirmine whether a mailbox has 
children or not, then it can omit both attributes.

I understand what you're trying to say, I'm just not clear on how 
that can arise. Specifically, if a mailbox A exists, but the server 
finds it impossible to provide either CHILDREN attribute, then surely 
it also cannot handle a subsequent LIST of A's inferior mailboxes?

I can certainly follow that it may be expensive to find the 
information, that it may be equivalent to performing the second LIST 
internally, etc, but if it were impossible, then the subsequent LIST 
would also be impossible.

If by impossible you mean "*really* difficult", then you're 
essentially licensing servers to omit both flags when they feel like 
it - this is actually acceptable to me in this case, I'd just like to 
understand this issue a little better.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 17 Jan 2006 14:00:15 -0500
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
From: "Dave Cridland" <[email-masked]>
Cc: <[email-masked]>
To: <[email-masked]>
Content-Class: urn:content-classes:message
Importance: normal
Status:   
Sender: [email-masked]

On Tue Jan 17 16:43:36 2006, Barry Leiba wrote:
> >> > but also because I spent some ten minutes
> >> > looking for the LIST response
> > > A note at the beginning in the introductory prose saying where 
> the
> > LIST response is defined is all that's needed.
> 
> Dave, see if you like what I've done.  I put text in both the ABNF
> introduction AND the definition of mailbox-list.
> 
> 
That looks good.

> >> I believe that no matter what happens to ACAP,
> 
> I've reworded the ACAP text; let me know if you think that's OK.
> 
> 
Better.

> > C) "none of them is" should be "none of them are".
> 
> Nah; "none" is singular, though it's acceptable to give it plural 
> usage
> if one likes that sort of thing.  Actually, I've instead changed the
> OTHER use of "none" to be singular, to match this one.
> 
> 
Fairy nuff.

> >>> a) So far, I've not seen any server implementation supporting
> >>> multiple mailbox patterns.
> ...
> > Yes, I think it could prove useful later, certainly. At this 
> stage,
> > it makes no real difference to clients, and it's additional
> > complexity for servers - and server developers have historically
> > preferred to avoid complexity at almost any cost.
> 
> But we've had a couple of comments to leave it.  Do we have a
> resolution for this issue?
> 
> 
I've seen very little comment. My general suspicion is that those 
server implementors who expressed any opinion at all aren't entirely 
happy with it. Personally, I'd be happy to leave it in, but I'll 
defer to the server folk.

> Dave has responded adequately to Arnaud's comments, so I'll refer to
> Dave's note on it:

> >>    * Page 14, paragraph \HasChildren, I think I disagree with the
> >>      security perspective
> > > Rereading this section, I note that "the server MUST return 
> these
> > attributes", but "a server MAY exclude both the [...] attributes".
> 
> I presume, Arnaud, that you're referring to the bit about returning
> \HasNoChildren if there are no children that the requester has 
> access
> to.  That statement represents established consensus here, so unless
> there are others who want to change it, it'll stay.
> 
> Dave, you're right that there's an unintended conflict there.  I 
> did a
> little rewording; let me know what you think of it.
> 
> 
Right. You're saying that in the case where some architectural issue 
means that the server simply cannot detirmine whether a mailbox has 
children or not, then it can omit both attributes.

I understand what you're trying to say, I'm just not clear on how 
that can arise. Specifically, if a mailbox A exists, but the server 
finds it impossible to provide either CHILDREN attribute, then surely 
it also cannot handle a subsequent LIST of A's inferior mailboxes?

I can certainly follow that it may be expensive to find the 
information, that it may be equivalent to performing the second LIST 
internally, etc, but if it were impossible, then the subsequent LIST 
would also be impossible.

If by impossible you mean "*really* difficult", then you're 
essentially licensing servers to omit both flags when they feel like 
it - this is actually acceptable to me in this case, I'd just like to 
understand this issue a little better.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 17 Jan 2006 13:46:04 -0500
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
From: "Dave Cridland" <[email-masked]>
Cc: <[email-masked]>
To: <[email-masked]>
Content-Class: urn:content-classes:message
Importance: normal
Status:   
Sender: [email-masked]

On Tue Jan 17 16:43:36 2006, Barry Leiba wrote:
> >> > but also because I spent some ten minutes
> >> > looking for the LIST response
> > > A note at the beginning in the introductory prose saying where 
> the
> > LIST response is defined is all that's needed.
> 
> Dave, see if you like what I've done.  I put text in both the ABNF
> introduction AND the definition of mailbox-list.
> 
> 
That looks good.

> >> I believe that no matter what happens to ACAP,
> 
> I've reworded the ACAP text; let me know if you think that's OK.
> 
> 
Better.

> > C) "none of them is" should be "none of them are".
> 
> Nah; "none" is singular, though it's acceptable to give it plural 
> usage
> if one likes that sort of thing.  Actually, I've instead changed the
> OTHER use of "none" to be singular, to match this one.
> 
> 
Fairy nuff.

> >>> a) So far, I've not seen any server implementation supporting
> >>> multiple mailbox patterns.
> ...
> > Yes, I think it could prove useful later, certainly. At this 
> stage,
> > it makes no real difference to clients, and it's additional
> > complexity for servers - and server developers have historically
> > preferred to avoid complexity at almost any cost.
> 
> But we've had a couple of comments to leave it.  Do we have a
> resolution for this issue?
> 
> 
I've seen very little comment. My general suspicion is that those 
server implementors who expressed any opinion at all aren't entirely 
happy with it. Personally, I'd be happy to leave it in, but I'll 
defer to the server folk.

> Dave has responded adequately to Arnaud's comments, so I'll refer to
> Dave's note on it:

> >>    * Page 14, paragraph \HasChildren, I think I disagree with the
> >>      security perspective
> > > Rereading this section, I note that "the server MUST return 
> these
> > attributes", but "a server MAY exclude both the [...] attributes".
> 
> I presume, Arnaud, that you're referring to the bit about returning
> \HasNoChildren if there are no children that the requester has 
> access
> to.  That statement represents established consensus here, so unless
> there are others who want to change it, it'll stay.
> 
> Dave, you're right that there's an unintended conflict there.  I 
> did a
> little rewording; let me know what you think of it.
> 
> 
Right. You're saying that in the case where some architectural issue 
means that the server simply cannot detirmine whether a mailbox has 
children or not, then it can omit both attributes.

I understand what you're trying to say, I'm just not clear on how 
that can arise. Specifically, if a mailbox A exists, but the server 
finds it impossible to provide either CHILDREN attribute, then surely 
it also cannot handle a subsequent LIST of A's inferior mailboxes?

I can certainly follow that it may be expensive to find the 
information, that it may be equivalent to performing the second LIST 
internally, etc, but if it were impossible, then the subsequent LIST 
would also be impossible.

If by impossible you mean "*really* difficult", then you're 
essentially licensing servers to omit both flags when they feel like 
it - this is actually acceptable to me in this case, I'd just like to 
understand this issue a little better.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 17 Jan 2006 13:30:42 -0500
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
From: "Dave Cridland" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Content-Class: urn:content-classes:message
Importance: normal
Status:   
Sender: [email-masked]

On Tue Jan 17 16:43:36 2006, Barry Leiba wrote:
> >> > but also because I spent some ten minutes
> >> > looking for the LIST response
> > > A note at the beginning in the introductory prose saying where 
> the
> > LIST response is defined is all that's needed.
> 
> Dave, see if you like what I've done.  I put text in both the ABNF
> introduction AND the definition of mailbox-list.
> 
> 
That looks good.

> >> I believe that no matter what happens to ACAP,
> 
> I've reworded the ACAP text; let me know if you think that's OK.
> 
> 
Better.

> > C) "none of them is" should be "none of them are".
> 
> Nah; "none" is singular, though it's acceptable to give it plural 
> usage
> if one likes that sort of thing.  Actually, I've instead changed the
> OTHER use of "none" to be singular, to match this one.
> 
> 
Fairy nuff.

> >>> a) So far, I've not seen any server implementation supporting
> >>> multiple mailbox patterns.
> ...
> > Yes, I think it could prove useful later, certainly. At this 
> stage,
> > it makes no real difference to clients, and it's additional
> > complexity for servers - and server developers have historically
> > preferred to avoid complexity at almost any cost.
> 
> But we've had a couple of comments to leave it.  Do we have a
> resolution for this issue?
> 
> 
I've seen very little comment. My general suspicion is that those 
server implementors who expressed any opinion at all aren't entirely 
happy with it. Personally, I'd be happy to leave it in, but I'll 
defer to the server folk.

> Dave has responded adequately to Arnaud's comments, so I'll refer to
> Dave's note on it:

> >>    * Page 14, paragraph \HasChildren, I think I disagree with the
> >>      security perspective
> > > Rereading this section, I note that "the server MUST return 
> these
> > attributes", but "a server MAY exclude both the [...] attributes".
> 
> I presume, Arnaud, that you're referring to the bit about returning
> \HasNoChildren if there are no children that the requester has 
> access
> to.  That statement represents established consensus here, so unless
> there are others who want to change it, it'll stay.
> 
> Dave, you're right that there's an unintended conflict there.  I 
> did a
> little rewording; let me know what you think of it.
> 
> 
Right. You're saying that in the case where some architectural issue 
means that the server simply cannot detirmine whether a mailbox has 
children or not, then it can omit both attributes.

I understand what you're trying to say, I'm just not clear on how 
that can arise. Specifically, if a mailbox A exists, but the server 
finds it impossible to provide either CHILDREN attribute, then surely 
it also cannot handle a subsequent LIST of A's inferior mailboxes?

I can certainly follow that it may be expensive to find the 
information, that it may be equivalent to performing the second LIST 
internally, etc, but if it were impossible, then the subsequent LIST 
would also be impossible.

If by impossible you mean "*really* difficult", then you're 
essentially licensing servers to omit both flags when they feel like 
it - this is actually acceptable to me in this case, I'd just like to 
understand this issue a little better.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 17 Jan 2006 13:15:30 -0500
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
From: "Dave Cridland" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Content-Class: urn:content-classes:message
Importance: normal
Status:   
Sender: [email-masked]

On Tue Jan 17 16:43:36 2006, Barry Leiba wrote:
> >> > but also because I spent some ten minutes
> >> > looking for the LIST response
> > > A note at the beginning in the introductory prose saying where 
> the
> > LIST response is defined is all that's needed.
> 
> Dave, see if you like what I've done.  I put text in both the ABNF
> introduction AND the definition of mailbox-list.
> 
> 
That looks good.

> >> I believe that no matter what happens to ACAP,
> 
> I've reworded the ACAP text; let me know if you think that's OK.
> 
> 
Better.

> > C) "none of them is" should be "none of them are".
> 
> Nah; "none" is singular, though it's acceptable to give it plural 
> usage
> if one likes that sort of thing.  Actually, I've instead changed the
> OTHER use of "none" to be singular, to match this one.
> 
> 
Fairy nuff.

> >>> a) So far, I've not seen any server implementation supporting
> >>> multiple mailbox patterns.
> ...
> > Yes, I think it could prove useful later, certainly. At this 
> stage,
> > it makes no real difference to clients, and it's additional
> > complexity for servers - and server developers have historically
> > preferred to avoid complexity at almost any cost.
> 
> But we've had a couple of comments to leave it.  Do we have a
> resolution for this issue?
> 
> 
I've seen very little comment. My general suspicion is that those 
server implementors who expressed any opinion at all aren't entirely 
happy with it. Personally, I'd be happy to leave it in, but I'll 
defer to the server folk.

> Dave has responded adequately to Arnaud's comments, so I'll refer to
> Dave's note on it:

> >>    * Page 14, paragraph \HasChildren, I think I disagree with the
> >>      security perspective
> > > Rereading this section, I note that "the server MUST return 
> these
> > attributes", but "a server MAY exclude both the [...] attributes".
> 
> I presume, Arnaud, that you're referring to the bit about returning
> \HasNoChildren if there are no children that the requester has 
> access
> to.  That statement represents established consensus here, so unless
> there are others who want to change it, it'll stay.
> 
> Dave, you're right that there's an unintended conflict there.  I 
> did a
> little rewording; let me know what you think of it.
> 
> 
Right. You're saying that in the case where some architectural issue 
means that the server simply cannot detirmine whether a mailbox has 
children or not, then it can omit both attributes.

I understand what you're trying to say, I'm just not clear on how 
that can arise. Specifically, if a mailbox A exists, but the server 
finds it impossible to provide either CHILDREN attribute, then surely 
it also cannot handle a subsequent LIST of A's inferior mailboxes?

I can certainly follow that it may be expensive to find the 
information, that it may be equivalent to performing the second LIST 
internally, etc, but if it were impossible, then the subsequent LIST 
would also be impossible.

If by impossible you mean "*really* difficult", then you're 
essentially licensing servers to omit both flags when they feel like 
it - this is actually acceptable to me in this case, I'd just like to 
understand this issue a little better.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 17 Jan 2006 13:00:18 -0500
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
From: "Dave Cridland" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Content-Class: urn:content-classes:message
Importance: normal
Status:   
Sender: [email-masked]

On Tue Jan 17 16:43:36 2006, Barry Leiba wrote:
> >> > but also because I spent some ten minutes
> >> > looking for the LIST response
> > > A note at the beginning in the introductory prose saying where 
> the
> > LIST response is defined is all that's needed.
> 
> Dave, see if you like what I've done.  I put text in both the ABNF
> introduction AND the definition of mailbox-list.
> 
> 
That looks good.

> >> I believe that no matter what happens to ACAP,
> 
> I've reworded the ACAP text; let me know if you think that's OK.
> 
> 
Better.

> > C) "none of them is" should be "none of them are".
> 
> Nah; "none" is singular, though it's acceptable to give it plural 
> usage
> if one likes that sort of thing.  Actually, I've instead changed the
> OTHER use of "none" to be singular, to match this one.
> 
> 
Fairy nuff.

> >>> a) So far, I've not seen any server implementation supporting
> >>> multiple mailbox patterns.
> ...
> > Yes, I think it could prove useful later, certainly. At this 
> stage,
> > it makes no real difference to clients, and it's additional
> > complexity for servers - and server developers have historically
> > preferred to avoid complexity at almost any cost.
> 
> But we've had a couple of comments to leave it.  Do we have a
> resolution for this issue?
> 
> 
I've seen very little comment. My general suspicion is that those 
server implementors who expressed any opinion at all aren't entirely 
happy with it. Personally, I'd be happy to leave it in, but I'll 
defer to the server folk.

> Dave has responded adequately to Arnaud's comments, so I'll refer to
> Dave's note on it:

> >>    * Page 14, paragraph \HasChildren, I think I disagree with the
> >>      security perspective
> > > Rereading this section, I note that "the server MUST return 
> these
> > attributes", but "a server MAY exclude both the [...] attributes".
> 
> I presume, Arnaud, that you're referring to the bit about returning
> \HasNoChildren if there are no children that the requester has 
> access
> to.  That statement represents established consensus here, so unless
> there are others who want to change it, it'll stay.
> 
> Dave, you're right that there's an unintended conflict there.  I 
> did a
> little rewording; let me know what you think of it.
> 
> 
Right. You're saying that in the case where some architectural issue 
means that the server simply cannot detirmine whether a mailbox has 
children or not, then it can omit both attributes.

I understand what you're trying to say, I'm just not clear on how 
that can arise. Specifically, if a mailbox A exists, but the server 
finds it impossible to provide either CHILDREN attribute, then surely 
it also cannot handle a subsequent LIST of A's inferior mailboxes?

I can certainly follow that it may be expensive to find the 
information, that it may be equivalent to performing the second LIST 
internally, etc, but if it were impossible, then the subsequent LIST 
would also be impossible.

If by impossible you mean "*really* difficult", then you're 
essentially licensing servers to omit both flags when they feel like 
it - this is actually acceptable to me in this case, I'd just like to 
understand this issue a little better.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 17 Jan 2006 12:46:06 -0500
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
From: "Dave Cridland" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Content-Class: urn:content-classes:message
Importance: normal
Status:   
Sender: [email-masked]

On Tue Jan 17 16:43:36 2006, Barry Leiba wrote:
> >> > but also because I spent some ten minutes
> >> > looking for the LIST response
> > > A note at the beginning in the introductory prose saying where 
> the
> > LIST response is defined is all that's needed.
> 
> Dave, see if you like what I've done.  I put text in both the ABNF
> introduction AND the definition of mailbox-list.
> 
> 
That looks good.

> >> I believe that no matter what happens to ACAP,
> 
> I've reworded the ACAP text; let me know if you think that's OK.
> 
> 
Better.

> > C) "none of them is" should be "none of them are".
> 
> Nah; "none" is singular, though it's acceptable to give it plural 
> usage
> if one likes that sort of thing.  Actually, I've instead changed the
> OTHER use of "none" to be singular, to match this one.
> 
> 
Fairy nuff.

> >>> a) So far, I've not seen any server implementation supporting
> >>> multiple mailbox patterns.
> ...
> > Yes, I think it could prove useful later, certainly. At this 
> stage,
> > it makes no real difference to clients, and it's additional
> > complexity for servers - and server developers have historically
> > preferred to avoid complexity at almost any cost.
> 
> But we've had a couple of comments to leave it.  Do we have a
> resolution for this issue?
> 
> 
I've seen very little comment. My general suspicion is that those 
server implementors who expressed any opinion at all aren't entirely 
happy with it. Personally, I'd be happy to leave it in, but I'll 
defer to the server folk.

> Dave has responded adequately to Arnaud's comments, so I'll refer to
> Dave's note on it:

> >>    * Page 14, paragraph \HasChildren, I think I disagree with the
> >>      security perspective
> > > Rereading this section, I note that "the server MUST return 
> these
> > attributes", but "a server MAY exclude both the [...] attributes".
> 
> I presume, Arnaud, that you're referring to the bit about returning
> \HasNoChildren if there are no children that the requester has 
> access
> to.  That statement represents established consensus here, so unless
> there are others who want to change it, it'll stay.
> 
> Dave, you're right that there's an unintended conflict there.  I 
> did a
> little rewording; let me know what you think of it.
> 
> 
Right. You're saying that in the case where some architectural issue 
means that the server simply cannot detirmine whether a mailbox has 
children or not, then it can omit both attributes.

I understand what you're trying to say, I'm just not clear on how 
that can arise. Specifically, if a mailbox A exists, but the server 
finds it impossible to provide either CHILDREN attribute, then surely 
it also cannot handle a subsequent LIST of A's inferior mailboxes?

I can certainly follow that it may be expensive to find the 
information, that it may be equivalent to performing the second LIST 
internally, etc, but if it were impossible, then the subsequent LIST 
would also be impossible.

If by impossible you mean "*really* difficult", then you're 
essentially licensing servers to omit both flags when they feel like 
it - this is actually acceptable to me in this case, I'd just like to 
understand this issue a little better.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 17 Jan 2006 12:31:44 -0500
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
From: "Dave Cridland" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Content-Class: urn:content-classes:message
Importance: normal
Status:   
Sender: [email-masked]

On Tue Jan 17 16:43:36 2006, Barry Leiba wrote:
> >> > but also because I spent some ten minutes
> >> > looking for the LIST response
> > > A note at the beginning in the introductory prose saying where 
> the
> > LIST response is defined is all that's needed.
> 
> Dave, see if you like what I've done.  I put text in both the ABNF
> introduction AND the definition of mailbox-list.
> 
> 
That looks good.

> >> I believe that no matter what happens to ACAP,
> 
> I've reworded the ACAP text; let me know if you think that's OK.
> 
> 
Better.

> > C) "none of them is" should be "none of them are".
> 
> Nah; "none" is singular, though it's acceptable to give it plural 
> usage
> if one likes that sort of thing.  Actually, I've instead changed the
> OTHER use of "none" to be singular, to match this one.
> 
> 
Fairy nuff.

> >>> a) So far, I've not seen any server implementation supporting
> >>> multiple mailbox patterns.
> ...
> > Yes, I think it could prove useful later, certainly. At this 
> stage,
> > it makes no real difference to clients, and it's additional
> > complexity for servers - and server developers have historically
> > preferred to avoid complexity at almost any cost.
> 
> But we've had a couple of comments to leave it.  Do we have a
> resolution for this issue?
> 
> 
I've seen very little comment. My general suspicion is that those 
server implementors who expressed any opinion at all aren't entirely 
happy with it. Personally, I'd be happy to leave it in, but I'll 
defer to the server folk.

> Dave has responded adequately to Arnaud's comments, so I'll refer to
> Dave's note on it:

> >>    * Page 14, paragraph \HasChildren, I think I disagree with the
> >>      security perspective
> > > Rereading this section, I note that "the server MUST return 
> these
> > attributes", but "a server MAY exclude both the [...] attributes".
> 
> I presume, Arnaud, that you're referring to the bit about returning
> \HasNoChildren if there are no children that the requester has 
> access
> to.  That statement represents established consensus here, so unless
> there are others who want to change it, it'll stay.
> 
> Dave, you're right that there's an unintended conflict there.  I 
> did a
> little rewording; let me know what you think of it.
> 
> 
Right. You're saying that in the case where some architectural issue 
means that the server simply cannot detirmine whether a mailbox has 
children or not, then it can omit both attributes.

I understand what you're trying to say, I'm just not clear on how 
that can arise. Specifically, if a mailbox A exists, but the server 
finds it impossible to provide either CHILDREN attribute, then surely 
it also cannot handle a subsequent LIST of A's inferior mailboxes?

I can certainly follow that it may be expensive to find the 
information, that it may be equivalent to performing the second LIST 
internally, etc, but if it were impossible, then the subsequent LIST 
would also be impossible.

If by impossible you mean "*really* difficult", then you're 
essentially licensing servers to omit both flags when they feel like 
it - this is actually acceptable to me in this case, I'd just like to 
understand this issue a little better.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 17 Jan 2006 17:19:16 +0000
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
From: Dave Cridland <[email-masked]>
To: Barry Leiba <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Tue Jan 17 16:43:36 2006, Barry Leiba wrote:
> >> > but also because I spent some ten minutes
> >> > looking for the LIST response
> > > A note at the beginning in the introductory prose saying where 
> the
> > LIST response is defined is all that's needed.
> 
> Dave, see if you like what I've done.  I put text in both the ABNF
> introduction AND the definition of mailbox-list.
> 
> 
That looks good.

> >> I believe that no matter what happens to ACAP,
> 
> I've reworded the ACAP text; let me know if you think that's OK.
> 
> 
Better.

> > C) "none of them is" should be "none of them are".
> 
> Nah; "none" is singular, though it's acceptable to give it plural 
> usage
> if one likes that sort of thing.  Actually, I've instead changed the
> OTHER use of "none" to be singular, to match this one.
> 
> 
Fairy nuff.

> >>> a) So far, I've not seen any server implementation supporting
> >>> multiple mailbox patterns.
> ...
> > Yes, I think it could prove useful later, certainly. At this 
> stage,
> > it makes no real difference to clients, and it's additional
> > complexity for servers - and server developers have historically
> > preferred to avoid complexity at almost any cost.
> 
> But we've had a couple of comments to leave it.  Do we have a
> resolution for this issue?
> 
> 
I've seen very little comment. My general suspicion is that those 
server implementors who expressed any opinion at all aren't entirely 
happy with it. Personally, I'd be happy to leave it in, but I'll 
defer to the server folk.

> Dave has responded adequately to Arnaud's comments, so I'll refer to
> Dave's note on it:

> >>    * Page 14, paragraph \HasChildren, I think I disagree with the
> >>      security perspective
> > > Rereading this section, I note that "the server MUST return 
> these
> > attributes", but "a server MAY exclude both the [...] attributes".
> 
> I presume, Arnaud, that you're referring to the bit about returning
> \HasNoChildren if there are no children that the requester has 
> access
> to.  That statement represents established consensus here, so unless
> there are others who want to change it, it'll stay.
> 
> Dave, you're right that there's an unintended conflict there.  I 
> did a
> little rewording; let me know what you think of it.
> 
> 
Right. You're saying that in the case where some architectural issue 
means that the server simply cannot detirmine whether a mailbox has 
children or not, then it can omit both attributes.

I understand what you're trying to say, I'm just not clear on how 
that can arise. Specifically, if a mailbox A exists, but the server 
finds it impossible to provide either CHILDREN attribute, then surely 
it also cannot handle a subsequent LIST of A's inferior mailboxes?

I can certainly follow that it may be expensive to find the 
information, that it may be equivalent to performing the second LIST 
internally, etc, but if it were impossible, then the subsequent LIST 
would also be impossible.

If by impossible you mean "*really* difficult", then you're 
essentially licensing servers to omit both flags when they feel like 
it - this is actually acceptable to me in this case, I'd just like to 
understand this issue a little better.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 17 Jan 2006 11:43:36 -0500
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
Sender: [email-masked]

--==========F13281BD76B984D2F1FF==========
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I've attached an edited diff of the changes I've made based on comments
so far.  They're minor -- mostly typo corrections and minor rewordings
and clarifications.  I've also changed the markup for the examples so
that the client/server exchanges are not double-spaced.

My specific responses to comments are below.

>> > but also because I spent some ten minutes
>> > looking for the LIST response
>=20
> A note at the beginning in the introductory prose saying where the
> LIST response is defined is all that's needed.

Dave, see if you like what I've done.  I put text in both the ABNF
introduction AND the definition of mailbox-list.

>> I believe that no matter what happens to ACAP,

I've reworded the ACAP text; let me know if you think that's OK.

> Page 7. Both examples appear to be missing spaces between the closing
> of one parenthesized list and the opening of the next.

Fixed.

> 5) "[...] similar to the command <RLSUB "" "%">." - Should be "*",
> not "%".
> Extraneous comma in "mailboxes, which".
> 6) Extraneous comma.
> 8) "demonstates" typo.
> A1) "instead" should be "as well", surely? The "or even this" clause
> and example doesn't make sense to me - it's simply added
> \HasChildren, but the client didn't request it.

Fixed all.

> C) "none of them is" should be "none of them are".

Nah; "none" is singular, though it's acceptable to give it plural usage
if one likes that sort of thing.  Actually, I've instead changed the
OTHER use of "none" to be singular, to match this one.

>>> a) So far, I've not seen any server implementation supporting
>>> multiple mailbox patterns.
...
> Yes, I think it could prove useful later, certainly. At this stage,
> it makes no real difference to clients, and it's additional
> complexity for servers - and server developers have historically
> preferred to avoid complexity at almost any cost.

But we've had a couple of comments to leave it.  Do we have a
resolution for this issue?

Dave has responded adequately to Arnaud's comments, so I'll refer to
Dave's note on it:

>   =E2=80=A2 I have a problem (which is surely my Frenglish) to =
understand
> 'or any combination of therof', I don't scan the word therof.=20
>   =E2=80=A2 Page 9 on the paragraph for REMOTE, the 3 last lines are =
really
> some byzantinism that is really a pain to explain operationally.
> Could we favor eliminating exceptions and enhancing protocol
> readability?=20
>   =E2=80=A2 Page 14, paragraph \HasChildren, I think I disagree with =
the
> security perspective=20
>   =E2=80=A2 Page 16, I am not familiar with the \Marked in example 2. =
What
> does this attribute mean? Where is it defined?=20
>   =E2=80=A2 Page 17, I think Example 6 requires much more =
explanations=20
>   =E2=80=A2 Page 19, Example 8: typo: it should be demonstrate and =
not
> demonstate, there is a missing r=20
>   =E2=80=A2 Page 26, I am not comfortable with the comment on ACAP at =
the
> beginning of section 6=20
>   =E2=80=A2 Page 30, at the end I dsiagree with the Security =
statement here=20
>   =E2=80=A2 Page 32, first paragrapha very small typo: there is a =
space
> between options/ extended, it should be options/extended to be
> consistent with the others after=20
>   =E2=80=A2 Page 34, the registration number 3 is almost a duplicate =
of
> registration number 1, you want to remove one or the other.=20

>>    * I disagree in the abstract on the Mailbox Referrals mention. No
>>      one implements it even not Microsoft correct? I think there are
>>      much more important issues to be covered in the abstract
>=20
> I implement Mailbox Referrals in my client, and Cyrus IMAP implements
> it in the server. I think Mulberry implements it client-side too. In
> any case, the mention here is illustrating that its addition forces
> additional duplicate commands such as RLIST, RLSUB, etc, and I think
> that's justified.

Agreed; it's staying.

> That's page 6 section 3 paragraph two. Should be "any combination
> thereof".

Fixed typo.

>>    * Page 9 on the paragraph for REMOTE, the 3 last lines are really
>>      some byzantinism that is really a pain to explain=20
>> operationally.
>>      Could we favor eliminating exceptions and enhancing protocol
>>      readability?
>=20
> It was tricky to explain at all. The nature of what's wrong with
> REMOTE RECURSIVEMATCH isn't echoed fully in the subsection on
> RECURSIVEMATCH, incidentally.

I've added a phrase to the RECURSIVEMATCH subsection to deal with that.
Arnaud, if you have a better suggestion for how to explain the
interaction of REMOTE, give me text (Franglish is OK; I can cope).
What you see there is the best we could come up with (and, really, I
don't think it's that confusing).

>>    * Page 14, paragraph \HasChildren, I think I disagree with the
>>      security perspective
>=20
> Rereading this section, I note that "the server MUST return these
> attributes", but "a server MAY exclude both the [...] attributes".

I presume, Arnaud, that you're referring to the bit about returning
\HasNoChildren if there are no children that the requester has access
to.  That statement represents established consensus here, so unless
there are others who want to change it, it'll stay.

Dave, you're right that there's an unintended conflict there.  I did a
little rewording; let me know what you think of it.

>>    * Page 17, I think Example 6 requires much more explanations
>=20
> I think I see why. Could you suggest some alternate text for
> explaining both example 5 and example 6? (I should think both would
> need to be changed to express the difference more clearly).

Yes, text.
I'm afraid that at this point in the process I have to insist that
comments that say that text is needed MUST come with suggested text.
I'll accept suggestions for minor tweaks, of course, but if you think
something needs to be written at this point... please write it.

>>    * Page 30, at the end I dsiagree with the Security statement here
>=20
> No, this is a security concern, and should be addressed by
> implementors.

Agreed; this is an exposure of a "covert channel" -- a back door to
retrieve information that you couldn't normally retrieve.  It has to be
documented.

Further comments?  Is -15a ready to go to the IESG as -16?

Barry

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

--==========F13281BD76B984D2F1FF==========
Content-Type: text/plain; charset=utf-8;
 name="draft-ietf-imapext-list-extensions-15to15adiff.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="draft-ietf-imapext-list-extensions-15to15adiff.txt"; size=5663

<           therof) MUST NOT treat the empty mailbox name as such =
special request
---
>           thereof) MUST NOT treat the empty mailbox name as such =
special request

[I had to make extra changes to this because I wanted each to fit on =
one line.]
<             ((tablecloth (("fringe" "lacy")("color" =
"white")))(X-Sample "text"))
<          =20
<           or...
<          =20
<             ((tablecloth ("fringe" "lacy"))(X-Sample "text" "and even =
more text"))
---
>             ((tablecloth (("edge" "lacy") ("color" "red"))) (X-Sample =
"text"))
>          =20
>           or...
>          =20
>             ((tablecloth ("edge" "lacy")) (X-Sample "text" "more =
text"))

<           option, as it only makes sense when other selection options =
are
---
>           option (nor only with REMOTE),
>           as it only makes sense when other selection options are

<           option is present, the server MUST return these attributes =
even
<           if their computation is expensive.
---
>           option is present, the server MUST return these attributes =
if it
>           is able to determine them, even if their computation is =
expensive
>           (see below about exception conditions).

<           example it may have difficulty determining whether there =
are child
---
>           example it might be impossible to determine whether there =
are child

<           if both are requested. It is an error for the server to =
return both a
<           \HasChildren and a \HasNoChildren attribute in a LIST =
response.
---
>           if both are requested.  It is an error for the server to =
return both a
>           \HasChildren and a \HasNoChildren attribute for the same =
mailbox.

<           In the next example, we'll see the subscribed mailboxes.  =
This is
---
>           In the next example we'll see the subscribed mailboxes.  =
This is

<           In this example we see more mailboxes, which reside on =
another server
---
>           In this example we see more mailboxes that reside on =
another server

<           The following example also requests the server to include =
mailboxes,
<           which reside on another server. The server returns =
information about
<           all mailboxes which are subscribed. This is similar to the =
command
<           <RLSUB "" "%">.  We also see the use of two selection =
options.
---
>           The following example also requests the server to include =
mailboxes
>           that reside on another server.  The server returns =
information about
>           all mailboxes which are subscribed.  This is similar to the =
command
>           <RLSUB "" "*">.  We also see the use of two selection =
options.

<           The following example requests the server to include =
mailboxes,
<           which reside on another server. The server is requested to =
return
<           subscription information for all returned mailboxes. This =
is different
<           from the example above.
---
>           The following example requests the server to include =
mailboxes
>           that reside on another server.  The server is asked to =
return
>           subscription information for all returned mailboxes.
>           This is different from the example above.

<           The following example demonstates the difference between
<           \HasChildren attribute and CHILDINFO extended data item.
---
>           The following example demonstrates the difference between =
the
>           \HasChildren attribute and the CHILDINFO extended data =
item.

<           A1) If the mailbox "Foo" had been subscribed instead, the =
last
---
>           A1) If the mailbox "Foo" had also been subscribed, the last

<           subscribed children match the pattern.
---
>           subscribed children matches the pattern.

<           The following syntax specification uses the augmented =
Backus-Naur
<           Form (BNF) as described in <xref target=3D"ABNF"/>.
<           Terms not defined here are taken from <xref =
target=3D"IMAP4"/>.
<
<           "vendor-token" is defined in <xref target=3D"ACAP"/>.
<           Note that this normative reference to ACAP is an issue in
<           moving this spec forward, since ACAP will never move to
<           Draft Standard.
<           The definitions of "vendor-token" and of the IANA registry =
must
<           eventually go somewhere else, in a document that can be =
moved
<           forward on the standards track.
---
>           The following syntax specification uses the augmented =
Backus-Naur
>           Form (BNF) as described in <xref target=3D"ABNF"/>.
>           Terms not defined here are taken from <xref =
target=3D"IMAP4"/>.
>           In particular, note that the version of "mailbox-list" =
below,
>           which defines the payload of the LIST response,
>           updates the version defined in the IMAP specification.
>           It is pointed to by "mailbox-data", which is defined in =
<xref target=3D"IMAP4"/>.
>
>           "vendor-token" is defined in <xref target=3D"ACAP"/>.
>           Note that this normative reference to ACAP is an issue in
>           moving this spec forward, since it introduces a dependency =
on ACAP.
>           The definitions of "vendor-token" and of the IANA registry =
must
>           eventually go somewhere else, in a document that can be =
moved
>           forward on the standards track independently of ACAP.

[inserted into the definition of "mailbox-list"]
>           ;   This is the list information pointed to by the ABNF =
item
>           ;   "mailbox-data", which is defined in <xref =
target=3D"IMAP4"/>

--==========F13281BD76B984D2F1FF==========
Content-Type: text/plain; charset=utf-8;
 name="draft-ietf-imapext-list-extensions-15a.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="draft-ietf-imapext-list-extensions-15a.txt"; size=67952

IMAP Extensions Working Group                                   B. =
Leiba
Internet-Draft                           IBM T.J. Watson Research =
Center
Updates: 2193 (if approved)                                  A. =
Melnikov
Obsoletes: 3348 (if approved)                              Isode =
Limited
Expires: July 21, 2006                                  January 17, =
2006

                     IMAP4 LIST Command Extensions
                 draft-ietf-imapext-list-extensions-16

Status of this Memo

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

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

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

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

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on July 21, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

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

Leiba & Melnikov          Expires July 21, 2006                 [Page =
1]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

   with each new extension.  This document describes an extension to =
the
   base LIST command that will allow these additions to be done with
   mutually compatible options to the LIST command, avoiding the
   exponential increase in specialized list commands.

Note

   A revised version of this draft document will be submitted to the =
RFC
   editor as a Proposed Standard for the Internet Community.  =
Discussion
   and suggestions for improvement are requested, and should be sent to
   [email-masked].

   This document obsoletes RFC 3348 and updates RFC 2193.

Table of Contents

   1.    Conventions used in this document  . . . . . . . . . . . . .  =
4

   2.    Introduction and overview  . . . . . . . . . . . . . . . . .  =
5

   3.    Extended LIST Command  . . . . . . . . . . . . . . . . . . .  =
7
   3.1.  General principles for returning LIST responses  . . . . . . =
11
   3.2.  Additional requirements on LIST-EXTENDED clients . . . . . . =
12
   3.3.  CHILDINFO extended data item . . . . . . . . . . . . . . . . =
12

   4.    The CHILDREN return Option . . . . . . . . . . . . . . . . . =
15

   5.    Examples . . . . . . . . . . . . . . . . . . . . . . . . . . =
17

   6.    Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . . =
24

   7.    Security Considerations  . . . . . . . . . . . . . . . . . . =
28

   8.    IANA Considerations  . . . . . . . . . . . . . . . . . . . . =
29
   8.1.  Guidelines for IANA  . . . . . . . . . . . . . . . . . . . . =
29
   8.2.  Registration procedure and Change control  . . . . . . . . . =
29
   8.3.  Registration template for LIST-EXTENDED options  . . . . . . =
30
   8.4.  Initial LIST-EXTENDED option registrations . . . . . . . . . =
31
   8.5.  Registration template for LIST-EXTENDED extended data
         item . . . . . . . . . . . . . . . . . . . . . . . . . . . . =
33
   8.6.  Initial LIST-EXTENDED extended data item registrations . . . =
34

   9.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . =
35

   10.   Normative References . . . . . . . . . . . . . . . . . . . . =
36

         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . =
37

Leiba & Melnikov          Expires July 21, 2006                 [Page =
2]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

         Intellectual Property and Copyright Statements . . . . . . . =
38

Leiba & Melnikov          Expires July 21, 2006                 [Page =
3]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

1.  Conventions used in this document

   In examples, "C:" indicates lines sent by a client that is connected
   to a server.  "S:" indicates lines sent by the server to the client.

   The words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are
   used in this document as specified in RFC 2119 [Kwds].

   The term "canonical LIST pattern" refers to the canonical pattern
   constructed internally by the server from the reference and mailbox
   name arguments (Section 6.3.8 of [IMAP4]).  The [IMAP4] LIST command
   returns only mailboxes that match the canonical LIST pattern.

   Other terms are introduced where they are referenced for the first
   time.

Leiba & Melnikov          Expires July 21, 2006                 [Page =
4]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

2.  Introduction and overview

   The LIST command is extended by amending the syntax to allow options
   and multiple patterns to be specified.  The list of options replaces
   the several commands that are currently used to mix and match the
   information requested.  The new syntax is backward- compatible, with
   no ambiguity: the new syntax is being used if one of the following
   conditions is true:

   1.  if the first word after the command name begins with a
       parenthesis ("LIST selection options");

   2.  if the second word after the command name begins with a
       parenthesis ("multiple mailbox patterns");

   3.  if the LIST command has more than 2 parameters ("LIST return
       options");

   Otherwise the original syntax is used.

   By adding options to the LIST command, we are announcing the intent
   to phase out and eventually to deprecate the RLIST and RLSUB =
commands
   described in [MBRef].  We are also defining the mechanism to request
   extended mailbox information, such as is described in the "Child
   Mailbox Extension" [CMbox].  The base LSUB command is not deprecated
   by this extension; rather, this extension adds a way to obtain
   subscription information with more options, with those server
   implementations that support it.  Clients that simply need a list of
   subscribed mailboxes, as provided by the LSUB command, SHOULD
   continue to use that command.

   This document defines an IMAP4 extension that is identified by the
   capability string "LIST-EXTENDED".  The LIST-EXTENDED extension =
makes
   the following changes to the IMAP4 protocol, which are described in
   more detail in Section 3 and Section 4:

   a.  defines new syntax for LIST command options.

   b.  extends LIST to allow for multiple mailbox patterns.

   c.  adds LIST command selection options: SUBSCRIBED, REMOTE and
       RECURSIVEMATCH.

   d.  adds LIST command return options: SUBSCRIBED and CHILDREN.

   e.  adds new mailbox attributes: "\NonExistent", "\Subscribed",
       "\Remote", "\HasChildren" and "\HasNoChildren".

Leiba & Melnikov          Expires July 21, 2006                 [Page =
5]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

   f.  adds CHILDINFO extended data item.

Leiba & Melnikov          Expires July 21, 2006                 [Page =
6]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

3.  Extended LIST Command

   This extension updates the syntax of the LIST command to allow for
   multiple mailbox patterns to be specified, if they are enclosed in
   parentheses.  A mailbox name matches a list of mailbox patterns if =
it
   matches at least one mailbox pattern.  If a mailbox name matches
   multiple mailbox patterns from the list, the server SHOULD return
   only a single LIST response.

   Note that the non-extended LIST command is required to treat an =
empty
   ("" string) mailbox name argument as a special request to return the
   hierarchy delimiter and the root name of the name given in the
   reference parameter (as per [IMAP4]).  However ANY extended LIST
   command (extended in any of 3 ways specified in Section 2, or any
   combination of thereof) MUST NOT treat the empty mailbox name as =
such
   special request and any regular processing described in this =
document
   applies.  In particular, if an extended LIST command has multiple
   mailbox names and one (or more) of them is the empty string, the
   empty string MUST be ignored for the purpose of matching.

   Some servers might restrict which patterns are allowed in a LIST
   command.  If a server doesn't accept a particular pattern, it MUST
   silently ignore it.

   The LIST command syntax is also extended in two additional ways: by
   adding a parenthesized list of command options between the command
   name and the reference name (LIST selection options) and an optional
   list of options at the end that control what kind of information
   should be returned (LIST return options).  See the formal syntax in
   Section 6 for specific details.

   A LIST selection option tells the server which mailbox names should
   be selected by the LIST operation.  The server should return
   information about all mailbox names that match any of the "canonical
   LIST pattern" (as described above) and satisfy additional selection
   criteria (if any) specified by the LIST selection options.  Let's
   call any such mailbox name a "matched mailbox name".  When multiple
   selection options are specified, the server MUST return information
   about mailbox names that satisfy every selection option, unless a
   description of a particular specified option prescribes special
   rules.  An example of an option prescribing special rules is the
   RECURSIVEMATCH selection option described later in this section.  We
   will use the term "selection criteria" when referring collectively =
to
   all selection options specified in a LIST command.

   A LIST return option controls which information is returned for each
   matched mailbox name.  Note that return options MUST NOT cause the
   server to report information about additional mailbox names.  If the

Leiba & Melnikov          Expires July 21, 2006                 [Page =
7]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

   client has not specified any return option, only information about
   attributes should be returned by the server.  (Of course the server
   is allowed to include any other information at will.)

   Both selection and return command options will be defined in this
   document and in approved extension documents; each option will be
   enabled by a capability string (one capability may enable multiple
   options), and a client MUST NOT send an option for which the server
   has not advertised support.  A server MUST respond to options it =
does
   not recognize with a BAD response.  The client SHOULD NOT specify =
any
   option more than once, however if the client does this, the server
   MUST act as if it received the option only once.  The order in which
   options are specified by the client is not significant.

   In general, each selection option except for RECURSIVEMATCH will =
have
   a corresponding return option.  The REMOTE selection option is an
   anomaly in this regard, and does not have a corresponding return
   option.  That is because it expands, rather than restricts, the set
   of mailboxes that are returned.  Future extensions to this
   specification should keep parallelism in mind, and define a pair of
   corresponding options.

   This extension is identified by the capability string "LIST-
   EXTENDED", and support for it is a prerequisite for any future
   extensions that require specialized forms of the LIST command.  Such
   extensions MUST refer to this document and MUST add their function
   through command options as described herein.  Note that extensions
   that don't require support for an extended LIST command, but use
   extended LIST responses (see below), don't need to advertise the
   "LIST-EXTENDED" capability string.

   This extension also defines extensions to the LIST response, =
allowing
   a series of extended fields at the end, a parenthesized list of
   tagged data (also referred to as "extended data item").  The first
   element of an extended field is a tag, which identifies type of the
   data.  Tags MUST be registered with IANA, as described in Section =
8.5
   of this document.  An example of such extended set might be

   tablecloth (("edge" "lacy") ("color" "red"))) (X-Sample "text"))

   or...

   tablecloth ("edge" "lacy")) (X-Sample "text" "more text"))

   See the formal syntax, in Section 6, for the full syntactic details.
   The server MUST NOT return any extended data item, unless the client
   has expressed its ability to support extended LIST responses, for
   example by using an extended LIST command.  The server MAY return

Leiba & Melnikov          Expires July 21, 2006                 [Page =
8]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

   data in the extended fields that was not solicited by the client.
   The client MUST ignore all extended fields it doesn't recognize.

   The LIST-EXTENDED capability also defines several new mailbox
   attributes.

   The "\NonExistent" attribute indicates that a mailbox does not
   actually exist.  Note that this attribute is not meaningful by
   itself, as mailboxes that match the canonical LIST pattern but don't
   exist must not be returned unless one of the two conditions listed
   below is also satisfied:

   a.  the mailbox also satisfies the selection criteria (for example,
       its name is subscribed and the "SUBSCRIBED" selection option has
       been specified)

   b.  "RECURSIVEMATCH" has been specified, and the mailbox has at =
least
       one descendant mailbox that does not match the LIST pattern and
       does match the selection criteria.

   In practice this means that the "\NonExistent" attribute is usually
   returned with one or more of "\Subscribed", "\Remote" or the
   CHILDINFO extended data item (see their description below).

   The "\NonExistent" attribute implies "\NoSelect".  The =
"\NonExistent"
   attribute MUST be supported and MUST be accurately computed.

   The selection options defined in this specification are

   SUBSCRIBED -  causes the LIST command to list subscribed names,
      rather than the existing mailboxes.  This will often be a subset
      of the actual mailboxes.  It's also possible for this list to
      contain the names of mailboxes that don't exist.  In any case, =
the
      list MUST include exactly those mailbox names that match the
      canonical list pattern and are subscribed to.  This option is
      intended to supplement the LSUB command.  Of particular note are
      the mailbox attributes as returned by this option, compared with
      what is returned by LSUB.  With the latter, the attributes
      returned may not reflect the actual attribute status on the
      mailbox name, and the \NoSelect attribute has a special meaning
      (it indicates that this mailbox is not, itself, subscribed, but
      that it has descendant mailboxes that are).  With the SUBSCRIBED
      selection option described here, the attributes are accurate,
      complete, and have no special meanings.  "LSUB" and "LIST
      (SUBSCRIBED)" are, thus, not the same thing, and some servers =
must
      do significant extra work to respond to "LIST (SUBSCRIBED)".
      Because of this, clients SHOULD continue to use "LSUB" unless =
they

Leiba & Melnikov          Expires July 21, 2006                 [Page =
9]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

      specifically want the additional information offered by "LIST
      (SUBSCRIBED)".

      This option defines a new mailbox attribute, "\Subscribed", that
      indicates that a mailbox name is subscribed to.  The =
"\Subscribed"
      attribute MUST be supported and MUST be accurately computed when
      the SUBSCRIBED selection option is specified.

      Note that the SUBSCRIBED selection option implies the SUBSCRIBED
      return option (see below).

   REMOTE -  causes the LIST command to show remote mailboxes as well =
as
      local ones, as described in [MBRef].  This option is intended to
      replace the RLIST command and, in conjunction with the SUBSCRIBED
      selection option, the RLSUB command.

      This option defines a new mailbox attribute, "\Remote", that
      indicates that a mailbox is a remote mailbox.  The "\Remote"
      attribute MUST be accurately computed when the REMOTE option is
      specified.

      The REMOTE selection option has no interaction with other =
options.
      Its effect is to tell the server to apply the other options, if
      any, to remote mailboxes, in addition to local ones.  In
      particular, it has no interaction with RECURSIVEMATCH (see =
below).
      A request for (REMOTE RECURSIVEMATCH) is invalid, because a
      request for (RECURSIVEMATCH) is.  A request for (REMOTE
      RECURSIVEMATCH SUBSCRIBED) is asking for all subscribed =
mailboxes,
      both local and remote.

   RECURSIVEMATCH -  this option forces the server to return =
information
      about parent mailboxes that don't match other selection options,
      but have some submailboxes that do.  Information about children =
is
      returned in the CHILDINFO extended data item, as described in
      Section 3.3.

      Note 1: In order for a parent mailbox to be returned, it still =
has
      to match the canonical LIST pattern.

      Note 2: When returning the CHILDINFO extended data item, it
      doesn't matter if the submailbox matches the canonical LIST
      pattern or not.  See also example 9 in Section 5.

      The RECURSIVEMATCH option MUST NOT occur as the only selection
      option (nor only with REMOTE), as it only makes sense when other
      selection options are also used.  The server MUST return BAD

Leiba & Melnikov          Expires July 21, 2006                [Page =
10]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

      tagged response in such case.

      Note that even if RECURSIVEMATCH option is specified, the client
      MUST still be able to handle a case when a CHILDINFO extended =
data
      item is returned and there are no submailboxes that meet the
      selection criteria of the given LIST command, as they can be
      deleted/renamed after the LIST response was sent, but before the
      client had a chance to access them.

   The return options defined in this specification are

   SUBSCRIBED -  causes the LIST command to return subscription state
      for all matching mailbox names.  The "\Subscribed" attribute MUST
      be supported and MUST be accurately computed when the SUBSCRIBED
      return option is specified.  Further, all mailbox flags MUST be
      accurately computed (this differs from the behaviour of the LSUB
      command).

   CHILDREN -  Requests mailbox child information as originally =
proposed
      in [CMbox].  See Section 4, below, for details.  This option MUST
      be supported by all servers.

3.1.  General principles for returning LIST responses

   This section outlines several principles that can be used by server
   implementations of this document to decide if a LIST response should
   be returned, as well as how many responses and what kind of
   information they may contain.

   1.  Exactly one LIST response should be returned for each mailbox
       name which matches the canonical LIST pattern.  Server
       implementors must not assume that clients will be able to
       assemble mailbox attributes and other information returned in
       multiple LIST responses.

   2.  There are only two reasons for including a matching mailbox name
       in the responses to the LIST command (Note that the server is
       allowed to return unsolicited responses at any time.  Such
       responses are not governed by this rule):

       A.  the mailbox name also satisfies the selection criteria;

       B.  the mailbox name doesn't satisfy the selection criteria, but
           it has at least one descendant mailbox name that satisfies

Leiba & Melnikov          Expires July 21, 2006                [Page =
11]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

           the selection criteria and that doesn't match the canonical
           LIST pattern.
           For more information on this case see the CHILDINFO extended
           data item described in Section 3.3.  Note that the CHILDINFO
           extended data item can only be returned when the
           RECURSIVEMATCH selection option is specified.

   3.  Attributes returned in the same LIST response must be treated
       additively.  For example the following response

          S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"

       means that the "Fruit/Peach" mailbox doesn't exist, but it is
       subscribed.

3.2.  Additional requirements on LIST-EXTENDED clients

   All clients that support this extension MUST treat an attribute with
   a stronger meaning, as implying any attribute that can be inferred
   from it.  For example, the client must treat presence of the
   \NoInferiors attribute as if the \HasNoChildren attribute was also
   sent by the server.

        The following table summarizes inference rules described in
                                Section 3.

                +--------------------+-------------------+
                | returned attribute | implied attribute |
                +--------------------+-------------------+
                |    \NoInferiors    |   \HasNoChildren  |
                |                    |                   |
                |    \NonExistent    |     \NoSelect     |
                +--------------------+-------------------+

3.3.  CHILDINFO extended data item

   The CHILDINFO extended data item MUST only be returned when the
   client has specified the RECURSIVEMATCH selection option.

   The CHILDINFO extended data item in a LIST response describes the
   selection criteria that has caused it to be returned and indicates
   that the mailbox has at least one descendant mailbox that matches =
the
   selection criteria.

   The LSUB command indicates this condition by using the "\NoSelect"

Leiba & Melnikov          Expires July 21, 2006                [Page =
12]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

   attribute, but the LIST (SUBSCRIBED) command MUST NOT do that, since
   "\NoSelect" retains its original meaning here.  Further, the
   CHILDINFO extended data item is more general, in that it can be used
   with any extended set of selection criteria.

   The returned selection criteria allow the client to distinguish a
   solicited response from an unsolicited one, as well as to =
distinguish
   among solicited responses caused by multiple pipelined LIST commands
   that specify different criteria.

   Servers SHOULD ONLY return a non-matching mailbox name along with
   CHILDINFO if at least one matching child is not also being returned.
   That is, servers SHOULD suppress redundant CHILDINFO responses.

   Examples 8 and 10 in Section 5 demonstrate the difference between
   present CHILDINFO extended data item and the "\HasChildren"
   attribute.

   The following table summarizes interaction between the =
"\NonExistent"
    attribute and CHILDINFO (the first collumn describes if the parent
                             mailbox exists):

   =
+--------+--------------+--------------------+----------------------+
   | exists |   meets the  |  has a child that  |       returned       =
|
   |        |   selection  |      meets the     |     LIST-EXTENDED    =
|
   |        |   criteria   | selection criteria |    attributes and    =
|
   |        |              |                    |       CHILDINFO      =
|
   =
+--------+--------------+--------------------+----------------------+
   |   no   |      no      |         no         |   no LIST response   =
|
   |        |              |                    |       returned       =
|
   |        |              |                    |                      =
|
   |   yes  |      no      |         no         |   no LIST response   =
|
   |        |              |                    |       returned       =
|
   |        |              |                    |                      =
|
   |   no   |      yes     |         no         |     (\NonExistent    =
|
   |        |              |                    |        <attr>)       =
|
   |        |              |                    |                      =
|
   |   yes  |      yes     |         no         |       (<attr>)       =
|
   |        |              |                    |                      =
|
   |   no   |      no      |         yes        |   (\NonExistent) +   =
|
   |        |              |                    |       CHILDINFO      =
|
   |        |              |                    |                      =
|
   |   yes  |      no      |         yes        |    () + CHILDINFO    =
|
   |        |              |                    |                      =
|
   |   no   |      yes     |         yes        |     (\NonExistent    =
|
   |        |              |                    |  <attr>) + CHILDINFO =
|
   |        |              |                    |                      =
|

Leiba & Melnikov          Expires July 21, 2006                [Page =
13]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

   |   yes  |      yes     |         yes        | (<attr>) + CHILDINFO =
|
   =
+--------+--------------+--------------------+----------------------+

       where <attr> is one or more attributes that correspond to the
   selection criteria, for example for the SUBSCRIBED option the <attr>
                              is \Subscribed.

Leiba & Melnikov          Expires July 21, 2006                [Page =
14]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

4.  The CHILDREN return Option

   The CHILDREN return option implements the Child Mailbox Extension,
   originally proposed by Mike Gahrns and Raymond Cheng, of Microsoft
   Corporation.  Most of the information in this section is taken
   directly from their original specification [CMbox].  The CHILDREN
   return option is simply an indication that the client wants this
   information; a server MAY provide it even if the option is not
   specified.

   Many IMAP4 [IMAP4] clients present to the user a hierarchical view =
of
   the mailboxes that a user has access to.  Rather than initially
   presenting to the user the entire mailbox hierarchy, it is often
   preferable to show to the user a collapsed outline list of the
   mailbox hierarchy (particularly if there is a large number of
   mailboxes).  The user can then expand the collapsed outline =
hierarchy
   as needed.  It is common to include within the collapsed hierarchy a
   visual clue (such as a ''+'') to indicate that there are child
   mailboxes under a particular mailbox.  When the visual clue is
   clicked the hierarchy list is expanded to show the child mailboxes.
   The CHILDREN return option provides a mechanism for a client to
   efficiently determine if a particular mailbox has children, without
   issuing a LIST "" * or a LIST "" % for each mailbox name.  The
   CHILDREN return option defines two new attributes that MAY be
   returned within a LIST response: \HasChildren and \HasNoChildren.
   While these attributes MAY be returned in response to any LIST
   command, the CHILDREN return option is provided to indicate that the
   client particularly wants this information.  If the CHILDREN return
   option is present, the server MUST return these attributes if it is
   able to determine them, even if their computation is expensive (see
   below about exception conditions).

   \HasChildren

        The presence of this attribute indicates that the mailbox has
        child mailboxes.  A server SHOULD NOT set this attribute if
        there are child mailboxes, and the user does not have
        permissions to access any of them.  In this case, =
\HasNoChildren
        SHOULD be used.  In many cases, however, a server may not be
        able to efficiently compute whether a user has access to all
        child mailboxes.  As such a client MUST be prepared to accept
        the \HasChildren attribute as a hint.  That is, a mailbox MAY =
be
        flagged with the \HasChildren attribute, but no child mailboxes
        will appear in the LIST response.

   \HasNoChildren

Leiba & Melnikov          Expires July 21, 2006                [Page =
15]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

        The presence of this attribute indicates that the mailbox has =
NO
        child mailboxes that are accessible to the currently
        authenticated user.

   In some instances a server that supports the LIST-EXTENDED extension
   might not be able to determine whether a mailbox has children.  For
   example it might be impossible to determine whether there are child
   mailboxes when LISTing mailboxes while operating in a particular
   namespace.  In these cases, a server MAY exclude both the
   \HasChildren and \HasNoChildren attributes in the LIST response.  As
   such, a client can not make any assumptions about whether a mailbox
   has children based upon the absence of a single attribute.  In
   particular, some servers may not be able to combine the SUBSCRIBED
   selection option and CHILDREN return option.  Such servers MUST
   honour the SUBSCRIBED selection option, and they will simply ignore
   the CHILDREN return option if both are requested.  It is an error =
for
   the server to return both a \HasChildren and a \HasNoChildren
   attribute for the same mailbox.

   Note: the \HasNoChildren attribute should not be confused with the
   IMAP4 [IMAP4] defined attribute \NoInferiors which indicates that no
   child mailboxes exist now and none can be created in the future.

Leiba & Melnikov          Expires July 21, 2006                [Page =
16]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

5.  Examples

   1:   The first example shows the complete local hierarchy that will
        be used for the other examples.

      C: A01 LIST "" "*"
      S: * LIST (\Marked \NoInferiors) "/" "inbox"
      S: * LIST () "/" "Fruit"
      S: * LIST () "/" "Fruit/Apple"
      S: * LIST () "/" "Fruit/Banana"
      S: * LIST () "/" "Tofu"
      S: * LIST () "/" "Vegetable"
      S: * LIST () "/" "Vegetable/Broccoli"
      S: * LIST () "/" "Vegetable/Corn"
      S: A01 OK done

   2:   In the next example we'll see the subscribed mailboxes.  This =
is
        similar to, but not equivalent with, <LSUB "" "*">.  Note that
        the mailbox called "Fruit/Peach" is subscribed to, but does not
        actually exist (perhaps it was deleted while still subscribed).
        The "Fruit" mailbox is not subscribed to, but it has two
        subscribed children.  The "Vegetable" mailbox is subscribed and
        has two children, one of them is subscribed as well.

      C: A02 LIST (SUBSCRIBED) "" "*"
      S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"
      S: * LIST (\Subscribed) "/" "Fruit/Banana"
      S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"
      S: * LIST (\Subscribed) "/" "Vegetable"
      S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"
      S: A02 OK done

   3:   The next example shows the use of the CHILDREN option.  The
        client, without having to list the second level of hierarchy,
        now knows which of the top-level mailboxes have submailboxes
        (children) and which do not.  Note that it's not necessary for
        the server to return the \HasNoChildren attribute for the =
inbox,
        because the \NoInferiors attribute already implies that, and =
has
        a stronger meaning.

      C: A03 LIST () "" "%" RETURN (CHILDREN)
      S: * LIST (\Marked \NoInferiors) "/" "inbox"
      S: * LIST (\HasChildren) "/" "Fruit"
      S: * LIST (\HasNoChildren) "/" "Tofu"
      S: * LIST (\HasChildren) "/" "Vegetable"
      S: A03 OK done

Leiba & Melnikov          Expires July 21, 2006                [Page =
17]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

   4:   In this example we see more mailboxes that reside on another
        server to which we may obtain referrals.  This is similar to =
the
        command <RLIST "" "%">.  Note that in the case of the remote
        mailboxes, the server might or might not be able to include
        CHILDREN information; it includes it if it can, and omits it if
        it can't.

      C: A04 LIST (REMOTE) "" "%" RETURN (CHILDREN)
      S: * LIST (\Marked \NoInferiors) "/" "inbox"
      S: * LIST (\HasChildren) "/" "Fruit"
      S: * LIST (\HasNoChildren) "/" "Tofu"
      S: * LIST (\HasChildren) "/" "Vegetable"
      S: * LIST (\Remote) "/" "Bread"
      S: * LIST (\HasChildren \Remote) "/" "Meat"
      S: A04 OK done

   5:   The following example also requests the server to include
        mailboxes that reside on another server.  The server returns
        information about all mailboxes which are subscribed.  This is
        similar to the command <RLSUB "" "*">.  We also see the use of
        two selection options.

      C: A05 LIST (REMOTE SUBSCRIBED) "" "*"
      S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"
      S: * LIST (\Subscribed) "/" "Fruit/Banana"
      S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"
      S: * LIST (\Subscribed) "/" "Vegetable"
      S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"
      S: * LIST (\Remote \Subscribed) "/" "Bread"
      S: A05 OK done

   6:   The following example requests the server to include mailboxes
        that reside on another server.  The server is asked to return
        subscription information for all returned mailboxes.  This is
        different from the example above.

        Note that the output of this command is not a superset of the
        output in the previous example, as it doesn't include LIST
        response for the non-existent "Fruit/Peach".

Leiba & Melnikov          Expires July 21, 2006                [Page =
18]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

      C: A06 LIST (REMOTE) "" "*" RETURN (SUBSCRIBED)
      S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"
      S: * LIST () "/" "Fruit"
      S: * LIST () "/" "Fruit/Apple"
      S: * LIST (\Subscribed) "/" "Fruit/Banana"
      S: * LIST () "/" "Tofu"
      S: * LIST (\Subscribed) "/" "Vegetable"
      S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"
      S: * LIST () "/" "Vegetable/Corn"
      S: * LIST (\Remote \Subscribed) "/" "Bread"
      S: * LIST (\Remote) "/" "Meat"
      S: A06 OK done

   7:   In the following example the client has specified multiple
        mailbox patterns.  Note that this example does not use the
        mailbox hierarchy used in the previous examples.

      C: BBB LIST "" ("INBOX" "Drafts" "Sent/%")
      S: * LIST () "/" "INBOX"
      S: * LIST (\NoInferiors) "/" "Drafts"
      S: * LIST () "/" "Sent/March2004"
      S: * LIST (\Marked) "/" "Sent/December2003"
      S: * LIST () "/" "Sent/August2004"
      S: BBB OK done

   8:   The following example demonstrates the difference between the
        \HasChildren attribute and the CHILDINFO extended data item.

        Let's assume there is the following hierarchy:

      C: C01 LIST "" "*"
      S: * LIST (\Marked \NoInferiors) "/" "inbox"
      S: * LIST () "/" "Foo"
      S: * LIST () "/" "Foo/Bar"
      S: * LIST () "/" "Foo/Baz"
      S: * LIST () "/" "Moo"
      S: C01 OK done

        If the client asks RETURN (CHILDREN) it will get this:

      C: CA3 LIST "" "%" RETURN (CHILDREN)
      S: * LIST (\Marked \NoInferiors) "/" "inbox"
      S: * LIST (\HasChildren) "/" "Foo"
      S: * LIST (\HasNoChildren) "/" "Moo"
      S: CA3 OK done

Leiba & Melnikov          Expires July 21, 2006                [Page =
19]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

        A) Let's also assume that the mailbox "Foo/Baz" is the only
        subscribed mailbox.  Then we get this result:

      C: C02 LIST (SUBSCRIBED) "" "*"
      S: * LIST (\Subscribed) "/" "Foo/Baz"
      S: C02 OK done

        Now, if the client issues <LIST (SUBSCRIBED) "" "%">, the =
server
        will return no mailboxes (as the mailboxes "Moo", "Foo" and
        "Inbox" are NOT subscribed).  However, if the client issues
        this:

      C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
      S: * LIST () "/" "Foo" (("CHILDINFO" ("SUBSCRIBED")))
      S: C04 OK done

        i.e. the mailbox "Foo" is not subscribed, but it has a child
        that is.

        A1) If the mailbox "Foo" had also been subscribed, the last
        command would return this:

      C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
      S: * LIST (\Subscribed) "/" "Foo" (("CHILDINFO" ("SUBSCRIBED")))
      S: C04 OK done

        or even this:

      C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
      S: * LIST (\Subscribed \HasChildren) "/" "Foo" (("CHILDINFO"
         ("SUBSCRIBED")))
      S: C04 OK done

        A2) If we assume instead that the mailbox "Foo" is not part of
        the original hierarchy and is not subscribed, the last command
        will give this result:

      C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
      S: * LIST (\NonExistent) "/" "Foo" (("CHILDINFO" ("SUBSCRIBED")))
      S: C04 OK done

        B) Now, let's assume that no mailbox is subscribed.  In this
        case the command <LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"> will
        return no responses, as there are no subscribed children (even
        though "Foo" has children).

        C) And finally, suppose that only the mailboxes "Foo" and "Moo"
        are subscribed.  In that case we see this result:

Leiba & Melnikov          Expires July 21, 2006                [Page =
20]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

      C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" RETURN (CHILDREN)
      S: * LIST (\HasChildren \Subscribed) "/" "Foo"
      S: * LIST (\HasNoChildren \Subscribed) "/" "Moo"
      S: C04 OK done

        (which means that the mailbox "Foo" has children, but none of
        them is subscribed).

   9:   The following example demonstrates that the CHILDINFO extended
        data item is returned whether children mailboxes match the
        canonical LIST pattern or not.

        Let's assume there is the following hierarchy:

      C: D01 LIST "" "*"
      S: * LIST (\Marked \NoInferiors) "/" "inbox"
      S: * LIST () "/" "foo2"
      S: * LIST () "/" "foo2/bar1"
      S: * LIST () "/" "foo2/bar2"
      S: * LIST () "/" "baz2"
      S: * LIST () "/" "baz2/bar2"
      S: * LIST () "/" "baz2/bar22"
      S: * LIST () "/" "baz2/bar222"
      S: * LIST () "/" "eps2"
      S: * LIST () "/" "eps2/mamba"
      S: * LIST () "/" "qux2/bar2"
      S: D01 OK done

        And that the following mailboxes are subscribed:

      C: D02 LIST (SUBSCRIBED) "" "*"
      S: * LIST (\Subscribed) "/" "foo2/bar1"
      S: * LIST (\Subscribed) "/" "foo2/bar2"
      S: * LIST (\Subscribed) "/" "baz2/bar2"
      S: * LIST (\Subscribed) "/" "baz2/bar22"
      S: * LIST (\Subscribed) "/" "baz2/bar222"
      S: * LIST (\Subscribed) "/" "eps2"
      S: * LIST (\Subscribed) "/" "eps2/mamba"
      S: * LIST (\Subscribed) "/" "qux2/bar2"
      S: D02 OK done

        The client issues the following command first:

Leiba & Melnikov          Expires July 21, 2006                [Page =
21]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

      C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*2"
      S: * LIST () "/" "foo2" (("CHILDINFO" ("SUBSCRIBED")))
      S: * LIST (\Subscribed) "/" "foo2/bar2"
      S: * LIST () "/" "baz2" (("CHILDINFO" ("SUBSCRIBED")))
      S: * LIST (\Subscribed) "/" "baz2/bar2"
      S: * LIST (\Subscribed) "/" "baz2/bar22"
      S: * LIST (\Subscribed) "/" "baz2/bar222"
      S: * LIST (\Subscribed) "/" "eps2" (("CHILDINFO" ("SUBSCRIBED")))
      S: * LIST (\Subscribed) "/" "qux2/bar2"
      S: D03 OK done

        and the server may also include

      S: * LIST (\NonExistent) "/" "qux2" (("CHILDINFO" =
("SUBSCRIBED")))

        The CHILDINFO extended data item is returned for mailboxes
        "foo2", "baz2" and "eps2", because all of them have subscribed
        children, even though for the mailbox "foo2" only one of the =
two
        subscribed children match the pattern, for the mailbox "baz2"
        all the subscribed children match the pattern and for the
        mailbox "eps2" none of the subscribed children matches the
        pattern.

        Note that if the client issues

      C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*"
      S: * LIST () "/" "foo2" (("CHILDINFO" ("SUBSCRIBED")))
      S: * LIST (\Subscribed) "/" "foo2/bar1"
      S: * LIST (\Subscribed) "/" "foo2/bar2"
      S: * LIST () "/" "baz2" (("CHILDINFO" ("SUBSCRIBED")))
      S: * LIST (\Subscribed) "/" "baz2/bar2"
      S: * LIST (\Subscribed) "/" "baz2/bar22"
      S: * LIST (\Subscribed) "/" "baz2/bar222"
      S: * LIST (\Subscribed) "/" "eps2" (("CHILDINFO" ("SUBSCRIBED")))
      S: * LIST (\Subscribed) "/" "eps2/mamba"
      S: * LIST (\Subscribed) "/" "qux2/bar2"
      S: D03 OK done

        the LIST responses for mailboxes "foo2", "baz2" and "eps2" =
still
        have the CHILDINFO extended data item, even though this
        information is redundant and the client can determine it by
        itself.

   10:  The following example shows usage of multiple mailbox patterns.
        It also demonstrates that the presence of the CHILDINFO =
extended
        data item doesn't necessarily imply \HasChildren.

Leiba & Melnikov          Expires July 21, 2006                [Page =
22]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

      C: a1 LIST "" ("foo" "foo/*")
      S: * LIST () "/" foo
      S: a1 OK done

      C: a2 LIST (SUBSCRIBED) "" "foo/*"
      S: * LIST (\Subscribed \NonExistent) "/" foo/bar
      S: a2 OK done

      C: a3 LIST (SUBSCRIBED RECURSIVEMATCH) "" foo RETURN (CHILDREN)
      S: * LIST (\HasNoChildren) "/" foo (("CHILDINFO" ("SUBSCRIBED")))
      S: a3 OK done

Leiba & Melnikov          Expires July 21, 2006                [Page =
23]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

6.  Formal Syntax

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) as described in [ABNF].  Terms not defined here are taken
   from [IMAP4].  In particular, note that the version of =
"mailbox-list"
   below, which defines the payload of the LIST response, updates the
   version defined in the IMAP specification.  It is pointed to by
   "mailbox-data", which is defined in [IMAP4].

   "vendor-token" is defined in [ACAP].  Note that this normative
   reference to ACAP is an issue in moving this spec forward, since it
   introduces a dependency on ACAP.  The definitions of "vendor-token"
   and of the IANA registry must eventually go somewhere else, in a
   document that can be moved forward on the standards track
   independently of ACAP.

   childinfo-extended-item =3D  "CHILDINFO" SP "("
               list-select-base-opt-quoted
               *(SP list-select-base-opt-quoted) ")"
               ; Extended data item returned when the RECURSIVEMATCH
               ; selection option is specified.
               ; Note 1: the CHILDINFO tag can be returned
               ; with and without surrounding quotes, as per
               ; mbox-list-extended-item-tag production.
               ; Note 2: The selection options are returned quoted,
               ; unlike their specification in the extended LIST
               ; command.

   child-mbox-flag =3D  "\HasChildren" / "\HasNoChildren"
               ; attributes for CHILDREN return option, at most one
               ; possible per LIST response

   eitem-standard-tag =3D  atom
               ; a tag for extended list data defined in a Standard
               ; Track or Experimental RFC.

   eitem-vendor-tag =3D  vendor-tag
               ; a vendor specific tag for extended list data

   list =3D      "LIST" [SP list-select-opts] SP mailbox SP mbox-or-pat
               [SP list-return-opts]

Leiba & Melnikov          Expires July 21, 2006                [Page =
24]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

   list-return-opts =3D  "RETURN" SP
               "(" [return-option *(SP return-option)] ")"
               ; list return options, e.g.  CHILDREN

   list-select-base-opt =3D  "SUBSCRIBED" / option-extension
               ; options that can be used by themselves

   list-select-base-opt-quoted =3D  <"> list-select-base-opt <">

   list-select-independent-opt =3D  "REMOTE" / option-extension
               ; options that do not syntactically interact with
               ; other options

   list-select-mod-opt =3D  "RECURSIVEMATCH" / option-extension
               ; options that require a list-select-base-opt
               ; to also be present

   list-select-opt =3D  list-select-base-opt / =
list-select-independent-opt
               / list-select-mod-opt
               ; An option registration template is described in
               ; Section 8.3 of this document.

   list-select-opts =3D  "(" [
                 (*(list-select-opt SP) list-select-base-opt
                  *(SP list-select-opt))
               / (list-select-independent-opt
                  *(SP list-select-independent-opt))
               ] ")"
               ; Any number of options may be in any order.
               ; If a list-select-mod-opt appears, then a
               ; list-select-base-opt must also appear.
               ; This allows these:
               ; ()
               ; (REMOTE)
               ; (SUBSCRIBED)
               ; (SUBSCRIBED REMOTE)
               ; (SUBSCRIBED RECURSIVEMATCH)
               ; (SUBSCRIBED REMOTE RECURSIVEMATCH)
               ; But does NOT allow these:
               ; (RECURSIVEMATCH)
               ; (REMOTE RECURSIVEMATCH)

Leiba & Melnikov          Expires July 21, 2006                [Page =
25]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

   mailbox-list =3D  "(" [mbx-list-flags] ")" SP
               (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox
               [SP mbox-list-extended]
               ; This is the list information pointed to by the ABNF
               item ; "mailbox-data", which is defined in [IMAP4]

   mbox-list-extended =3D  "(" [mbox-list-extended-item
               *(SP mbox-list-extended-item)] ")"

   mbox-list-extended-item =3D  "(" mbox-list-extended-item-data ")"

   mbox-list-extended-item-data =3D  mbox-list-extended-item-tag SP
               nstring-list

   mbox-list-extended-item-tag =3D  astring
               ; The content MUST conform to either "eitem-vendor-tag"
               ; or "eitem-standard-tag" ABNF productions.
               ; A tag registration template is described in this
               ; document in Section 8.5.

   mbox-list-oflag =3D  child-mbox-flag / "\NonExistent" / =
"\Subscribed" /
               "\Remote"

   mbox-or-pat =3D  list-mailbox / patterns

   nstring-list =3D  nstring /
               "(" [nstring-list *(SP nstring-list)] ")"
               ; a recursive list definition

   option-extension =3D  (option-standard-tag / option-vendor-tag)
               [SP option-value]

   option-standard-tag =3D  atom
               ; an option defined in a Standards Track or
               ; Experimental RFC

Leiba & Melnikov          Expires July 21, 2006                [Page =
26]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

   option-val-comp =3D  astring /
               option-val-comp *(SP option-val-comp) /
               "(" option-val-comp ")"

   option-value =3D  "(" option-val-comp ")"

   option-vendor-tag =3D  vendor-token "-" atom
               ; a vendor specific option, non-standard

   patterns =3D  "(" list-mailbox *(SP list-mailbox) ")"

   return-option =3D  "SUBSCRIBED" / "CHILDREN" / option-extension

Leiba & Melnikov          Expires July 21, 2006                [Page =
27]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

7.  Security Considerations

   This document describes syntactic changes to the specification of =
the
   IMAP4 commands LIST, LSUB, RLIST, and RLSUB, and the modified LIST
   command has the same security considerations as those commands.  =
They
   are described in [IMAP4] and [MBRef].

   The Child Mailbox Extension provides a client a more efficient means
   of determining whether a particular mailbox has children.  If a
   mailbox has children, but the currently authenticated user does not
   have access to any of them, the server SHOULD respond with a
   \HasNoChildren attribute.  In many cases, however, a server may not
   be able to efficiently compute whether a user has access to all =
child
   mailboxes.  If such a server responds with a \HasChildren attribute,
   when in fact the currently authenticated user does not have access =
to
   any child mailboxes, potentially more information is conveyed about
   the mailbox than intended.  In most situations this will not be a
   security concern, because if information regarding whether a mailbox
   has children is considered sensitive, a user would not be granted
   access to that mailbox in the first place.

   The CHILDINFO extended data item has the same security =
considerations
   as the \HasChildren attribute described above.

Leiba & Melnikov          Expires July 21, 2006                [Page =
28]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

8.  IANA Considerations

8.1.  Guidelines for IANA

   It is requested that IANA creates two new registries for LIST-
   EXTENDED options and LIST-EXTENDED response data.  The templates and
   the initial registrations are detailed below.

8.2.  Registration procedure and Change control

   Registration of a LIST-EXTENDED option is done by filling in the
   template in Section 8.3 and sending it via electronic mail to
   [email-masked].  Registration of a LIST-EXTENDED extended data item =
is
   done by filling in the template in Section 8.5 and sending it via
   electronic mail to [email-masked].  IANA has the right to reject
   obviously bogus registrations, but will perform no review of claims
   made in the registration form.

   A LIST-EXTENDED option/extended data item name that starts with "V-"
   is reserved for vendor specific options/extended data items.  All
   options, whether they are vendor specific or global, should be
   registered with IANA.  If a LIST-EXTENDED extended data item is
   returned as a result of requesting a particular LIST-EXTENDED =
option,
   the name of the option SHOULD be used as the name of the LIST-
   EXTENDED extended data item.

   Each vendor specific options/extended data item MUST start with =
their
   vendor-token ("vendor prefix").  The vendor-token MUST be registered
   with IANA, using the [ACAP] vendor subtree registry.

   Standard LIST-EXTENDED option/extended data item names are case
   insensitive.  If the vendor prefix is omitted from a vendor specific
   LIST-EXTENDED option/extended data item name, the rest is case
   insensitive.  The vendor prefix itself is not case-sensitive, as it
   might contain non-ASCII characters.

   While the registration procedures do not require it, authors of =
LIST-
   EXTENDED options/extended data items are encouraged to seek =
community
   review and comment whenever that is feasible.  Authors may seek
   community review by posting a specification of their proposed
   mechanism as an Internet- Draft.  LIST-EXTENDED options/extended =
data
   items intended for widespread use should be standardized through the
   normal IETF process, when appropriate.

   Comments on registered LIST-EXTENDED options/extended response data
   should first be sent to the "owner" of the mechanism and/or to the
   IMAPEXT WG mailing list.  Submitters of comments may, after a
   reasonable attempt to contact the owner, request IANA to attach =
their

Leiba & Melnikov          Expires July 21, 2006                [Page =
29]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

   comment to the registration itself.  If IANA approves of this, the
   comment will be made accessible in conjunction with the registration
   LIST-EXTENDED options/ extended response data itself.

   Once a LIST-EXTENDED registration has been published by IANA, the
   author may request a change to its definition.  The change request
   follows the same procedure as the registration request.

   The owner of a LIST-EXTENDED registration may pass responsibility =
for
   the registered option/extended data item to another person or agency
   by informing IANA; this can be done without discussion or review.

   The IESG may reassign responsibility for a LIST-EXTENDED option/
   extended data item.  The most common case of this will be to enable
   changes to be made to mechanisms where the author of the =
registration
   has died, moved out of contact or is otherwise unable to make =
changes
   that are important to the community.

   LIST-EXTENDED registrations may not be deleted; mechanisms which are
   no longer believed appropriate for use can be declared OBSOLETE by a
   change to their "intended use" field; such LIST-EXTENDED options/
   extended data items will be clearly marked in the lists published by
   IANA.

   The IESG is considered to be the owner of all LIST-EXTENDED options/
   extended data items which are on the IETF standards track.

8.3.  Registration template for LIST-EXTENDED options

   To: [email-masked]
   Subject: Registration of LIST-EXTENDED option X

   LIST-EXTENDED option name:

   LIST-EXTENDED option type: (One of SELECTION or RETURN)

   Implied return options(s), if the option type is SELECTION: (zero or
   more)

   LIST-EXTENDED option description:

   Published specification (optional, recommended):

   Security considerations:

   Intended usage:
   (One of COMMON, LIMITED USE or OBSOLETE)

Leiba & Melnikov          Expires July 21, 2006                [Page =
30]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

   Person and email address to contact for further information:

   Owner/Change controller:

   (Any other information that the author deems interesting may be =
added
   below this line.)

8.4.  Initial LIST-EXTENDED option registrations

   It is requested that the LIST-EXTENDED option registry be populated
   with the following entries:

   1.  To: [email-masked]
       Subject: Registration of LIST-EXTENDED option SUBSCRIBED

       LIST-EXTENDED option name: SUBSCRIBED

       LIST-EXTENDED option type: SELECTION

       Implied return options(s): SUBSCRIBED

       LIST-EXTENDED option description: Causes the LIST command to =
list
       subscribed mailboxes, rather than the actual mailboxes.

       Published specification : XXXX, Section 3.

       Security considerations: XXXX, Section 7.

       Intended usage: COMMON

       Person and email address to contact for further information:
       Alexey Melnikov <[email-masked]>

       Owner/Change controller: [email-masked]

   2.  To: [email-masked]
       Subject: Registration of LIST-EXTENDED option REMOTE

       LIST-EXTENDED option name: REMOTE

       LIST-EXTENDED option type: SELECTION

       Implied return options(s): (none)

       LIST-EXTENDED option description: causes the LIST command to
       return remote mailboxes as well as local ones, as described in

Leiba & Melnikov          Expires July 21, 2006                [Page =
31]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

       RFC 2193.

       Published specification : XXXX, Section 3.

       Security considerations: XXXX, Section 7.

       Intended usage: COMMON

       Person and email address to contact for further information:
       Alexey Melnikov <[email-masked]>

       Owner/Change controller: [email-masked]

   3.  To: [email-masked]
       Subject: Registration of LIST-EXTENDED option SUBSCRIBED

       LIST-EXTENDED option name: SUBSCRIBED

       LIST-EXTENDED option type: RETURN

       LIST-EXTENDED option description: Causes the LIST command to
       return subscription state.

       Published specification : XXXX, Section 3.

       Security considerations: XXXX, Section 7.

       Intended usage: COMMON

       Person and email address to contact for further information:
       Alexey Melnikov <[email-masked]>

       Owner/Change controller: [email-masked]

   4.  To: [email-masked]
       Subject: Registration of LIST-EXTENDED option RECURSIVEMATCH

       LIST-EXTENDED option name: RECURSIVEMATCH

       LIST-EXTENDED option type: SELECTION

       Implied return options(s): (none)

       LIST-EXTENDED option description: Requests that CHILDINFO

Leiba & Melnikov          Expires July 21, 2006                [Page =
32]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

       extended data item is to be returned.

       Published specification : XXXX, Section 3.

       Security considerations: XXXX, Section 7.

       Intended usage: COMMON

       Person and email address to contact for further information:
       Alexey Melnikov <[email-masked]>

       Owner/Change controller: [email-masked]

   5.  To: [email-masked]
       Subject: Registration of LIST-EXTENDED option CHILDREN

       LIST-EXTENDED option name: CHILDREN

       LIST-EXTENDED option type: RETURN

       LIST-EXTENDED option description: Requests mailbox child
       information.

       Published specification : XXXX, Section 3 and Section 4.

       Security considerations: XXXX, Section 7.

       Intended usage: COMMON

       Person and email address to contact for further information:
       Alexey Melnikov <[email-masked]>

       Owner/Change controller: [email-masked]

8.5.  Registration template for LIST-EXTENDED extended data item

   To: [email-masked]
   Subject: Registration of X LIST-EXTENDED extended data item

   LIST-EXTENDED extended data item tag:

   LIST-EXTENDED extended data item description:

   Which LIST-EXTENDED option(s) (and their types) causes this extended
   data item to be returned (if any):

Leiba & Melnikov          Expires July 21, 2006                [Page =
33]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

   Published specification (optional, recommended):

   Security considerations:

   Intended usage:
   (One of COMMON, LIMITED USE or OBSOLETE)

   Person and email address to contact for further information:

   Owner/Change controller:

   (Any other information that the author deems interesting may be =
added
   below this line.)

8.6.  Initial LIST-EXTENDED extended data item registrations

   It is requested that the LIST-EXTENDED extended data item registry =
be
   populated with the following entries:

   1.  To: [email-masked]
       Subject: Registration of CHILDINFO LIST-EXTENDED extended data
       item

       LIST-EXTENDED extended data item tag: CHILDINFO

       LIST-EXTENDED extended data item description: The CHILDINFO
       extended data item describes the selection criteria that has
       caused it to be returned and indicates that the mailbox has one
       or more child mailbox that match the selection criteria.

       Which LIST-EXTENDED option(s) (and their types) causes this
       extended data item to be returned (if any): RECURSIVEMATCH
       selection option

       Published specification : XXXX, Section 3.3.

       Security considerations: XXXX, Section 7.

       Intended usage: COMMON

       Person and email address to contact for further information:
       Alexey Melnikov <[email-masked]>

       Owner/Change controller: [email-masked]

Leiba & Melnikov          Expires July 21, 2006                [Page =
34]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

9.  Acknowledgements

   Mike Gahrns and Raymond Cheng of Microsoft Corporation originally
   devised the Child Mailbox Extension and proposed it in 1997; the
   idea, as well as most of the text in Section 4, is theirs.

   This document is the result of discussions on the IMAP4 and IMAPEXT
   mailing lists and is meant to reflect consensus of those groups.  In
   particular, Mark Crispin, Philip Guenther, Cyrus Daboo, Timo
   Sirainen, Ken Murchison, Rob Siemborski, Steve Hole, Arnt
   Gulbrandsen, Larry Greenfield, Dave Cridland and Pete Maclean were
   active participants in those discussions or made suggestions to this
   document.

Leiba & Melnikov          Expires July 21, 2006                [Page =
35]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

10.  Normative References

   [ABNF]   Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
            Specifications: ABNF", RFC 4234, October 2005.

   [ACAP]   Newman, C. and J. Myers, "ACAP -- Application Configuration
            Access Protocol", RFC 2244, November 1997.

   [CMbox]  Gahrns, M. and R. Cheng, "", RFC 3348, July 2002.

   [IMAP4]  Crispin, M., "Internet Message Access Protocol - Version
            4rev1", RFC 3501, March 2003.

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

   [MBRef]  Gahrns, M., "IMAP4 Mailbox Referrals", RFC 2193,
            September 1997.

Leiba & Melnikov          Expires July 21, 2006                [Page =
36]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

Authors' Addresses

   Barry Leiba
   IBM T.J. Watson Research Center
   19 Skyline Drive
   Hawthorne, NY  10532
   US

   Phone: +1 914 784 7941
   Email: [email-masked]

   Alexey Melnikov
   Isode Limited
   5 Castle Business Village
   36 Station Road
   Hampton, Middlesex  TW12 2BX
   UK

   Email: [email-masked]
   URI:   http://www.melnikov.ca/

Leiba & Melnikov          Expires July 21, 2006                [Page =
37]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

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

Intellectual Property

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

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

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

Acknowledgment

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

Leiba & Melnikov          Expires July 21, 2006                [Page =
38]
=0C

--==========F13281BD76B984D2F1FF==========--

Date: Mon, 16 Jan 2006 16:51:04 -0500
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: Re: Blather about \Marked
Sender: [email-masked]

Folks, folks, folks...

PLEASE...

STOP arguing about \Marked (and other things) with the subject line
"Re: WG Last Call of LISTEXT draft 14".  Change the subject line (hey,
here's a good one right on this message; feel free to use it).

I'm trying to sort out the things that people are suggesting in
response to the last call on LISTEXT.  Let's please use the "WG Last
Call of LISTEXT" subject for that only, and change the subject when the
discussion strays.

Thank you.  I now return you to the pointless discussion already in
progress.

Barry

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

Date: Wed, 11 Jan 2006 17:13:32 +0000
From: Alexey Melnikov <[email-masked]>
To: Ken Murchison <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-condstore-08.txt
Sender: [email-masked]

Ken Murchison wrote:

> [email-masked] wrote:
>
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Internet Message Access Protocol 
>> Extension Working Group of the IETF.
>>
>>     Title        : IMAP Extension for Conditional STORE operation
>>     Author(s)    : A. Melnikov, S. Hole
>>     Filename    : draft-ietf-imapext-condstore-08.txt
>>     Pages        : 0
>>     Date        : 2006-1-3
>
> What changed?

Dave is right, I've moved SORT stuff to a separate draft, so that the 
document can [finally] be published.

Date: Tue, 10 Jan 2006 11:26:03 +0100
From: Arnaud Taddei <[email-masked]>
Subject: Re: Need a template to start a draft
To: "Burger, Eric" <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_neWLDE2h82ra5ouLLJ7JbA)
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT

Burger, Eric wrote:

>You really, really, really want to use the XML stuff.  
>
Yes I am building my XML document.

>It has a little
>learning curve, but it will make the total publication process much
>easier for you and your chairs in the long run.
>  
>
I understand this indeed and it makes sense if this helps others, then 
that cannot be a wrong approach though my selfish natural approach would 
have been to use roff :-)

A++

>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]] On Behalf Of Lisa Dusseault
>Sent: Friday, January 06, 2006 1:25 PM
>To: Mark Crispin
>Cc: Arnaud Taddei; IMAP Extensions WG
>Subject: Re: Need a template to start a draft
>
>
>I use the XML stuff described at http://xml.resource.org, myself.  If 
>you browse http://ietf.webdav.org for XML files, you can see a number 
>of examples.
>
>Lisa
>
>On Jan 6, 2006, at 9:30 AM, Mark Crispin wrote:
>
>  
>
>>On Fri, 6 Jan 2006, Arnaud Taddei wrote:
>>    
>>
>>>Where can I find a template to start a draft? What are you guys
>>>      
>>>
>using?
>  
>
>>Start with http://www.ietf.org/ID-Checklist.html
>>
>>-- Mark --
>>
>>http://panda.com/mrc
>>Democracy is two wolves and a sheep deciding what to eat for lunch.
>>Liberty is a well-armed sheep contesting the vote.
>>
>>    
>>

--Boundary_(ID_neWLDE2h82ra5ouLLJ7JbA)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Burger, Eric wrote:
<blockquote
 cite="[email-masked]"
 type="cite">
  <pre wrap="">You really, really, really want to use the XML stuff.  </pre>
</blockquote>
Yes I am building my XML document.<br>
<blockquote
 cite="[email-masked]"
 type="cite">
  <pre wrap="">It has a little
learning curve, but it will make the total publication process much
easier for you and your chairs in the long run.
  </pre>
</blockquote>
I understand this indeed and it makes sense if this helps others, then
that cannot be a wrong approach though my selfish natural approach
would have been to use roff :-)<br>
<br>
A++<br>
<blockquote
 cite="[email-masked]"
 type="cite">
  <pre wrap="">
-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
[<a class="moz-txt-link-freetext" href="mailto:[email-masked]">mailto:[email-masked]</a>] On Behalf Of Lisa Dusseault
Sent: Friday, January 06, 2006 1:25 PM
To: Mark Crispin
Cc: Arnaud Taddei; IMAP Extensions WG
Subject: Re: Need a template to start a draft

I use the XML stuff described at <a class="moz-txt-link-freetext" href="http://xml.resource.org">http://xml.resource.org</a>, myself.  If 
you browse <a class="moz-txt-link-freetext" href="http://ietf.webdav.org">http://ietf.webdav.org</a> for XML files, you can see a number 
of examples.

Lisa

On Jan 6, 2006, at 9:30 AM, Mark Crispin wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap="">On Fri, 6 Jan 2006, Arnaud Taddei wrote:
    </pre>
    <blockquote type="cite">
      <pre wrap="">Where can I find a template to start a draft? What are you guys
      </pre>
    </blockquote>
  </blockquote>
  <pre wrap=""><!---->using?
  </pre>
  <blockquote type="cite">
    <pre wrap="">Start with <a class="moz-txt-link-freetext" href="http://www.ietf.org/ID-Checklist.html">http://www.ietf.org/ID-Checklist.html</a>

-- Mark --

<a class="moz-txt-link-freetext" href="http://panda.com/mrc">http://panda.com/mrc</a>
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

    </pre>
  </blockquote>
</blockquote>
<br>
</body>
</html>

--Boundary_(ID_neWLDE2h82ra5ouLLJ7JbA)--

Content-class: urn:content-classes:message
Subject: RE: Need a template to start a draft
Date: Tue, 10 Jan 2006 02:10:33 -0500
From: "Burger, Eric" <[email-masked]>
To: "Arnaud Taddei" <[email-masked]>
Cc: "IMAP Extensions WG" <[email-masked]>
Sender: [email-masked]

You really, really, really want to use the XML stuff.  It has a little
learning curve, but it will make the total publication process much
easier for you and your chairs in the long run.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Lisa Dusseault
Sent: Friday, January 06, 2006 1:25 PM
To: Mark Crispin
Cc: Arnaud Taddei; IMAP Extensions WG
Subject: Re: Need a template to start a draft

I use the XML stuff described at http://xml.resource.org, myself.  If 
you browse http://ietf.webdav.org for XML files, you can see a number 
of examples.

Lisa

On Jan 6, 2006, at 9:30 AM, Mark Crispin wrote:

>
> On Fri, 6 Jan 2006, Arnaud Taddei wrote:
>> Where can I find a template to start a draft? What are you guys
using?
>
> Start with http://www.ietf.org/ID-Checklist.html
>
> -- Mark --
>
> http://panda.com/mrc
> Democracy is two wolves and a sheep deciding what to eat for lunch.
> Liberty is a well-armed sheep contesting the vote.
>

Subject: Re: WG Last Call of LISTEXT draft 14
From: Timo Sirainen <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: [email-masked]
Date: Mon, 09 Jan 2006 23:24:38 +0200
Sender: [email-masked]

--=-HeSULr90xmx/ViOWGApp
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Mon, 2006-01-09 at 13:01 -0800, Cyrus Daboo wrote:
> Hi Timo,
>=20
> --On January 9, 2006 8:06:16 PM +0200 Timo Sirainen <[email-masked]> wrote:
>=20
> >> I certainly feel that it's less work for you to use the "Q" command th=
an
> >> it is for everybody else to deal with the wreckage caused by
> >> implementations that do not support recent and marking properly.
> >
> > I'm not suggesting that (well, not anymore nowadays). But perhaps some
> > new \Noticed flag, which works in many ways like recent, but instead of
> > being removed whenever a client notices the mail, it's removed only whe=
n
> > a MARK-NOTICED command is given. The client could send that whenever it
> > figures out that user has actually been reading the mailbox (eg. opened
> > some mail). Although I suppose that could be implemented as a keyword
> > too..
>=20
> Alternatively use \Seen (which the client should handle automatically for=
=20
> you) with a $FOLLOWUP-NEEDED keyword (or simply \Flagged) when you need t=
o=20
> do more with the message after viewing it.

That would be a nice feature also, but it's not exactly what I meant.
With \Noticed / $Noticed I meant the client thought I at least noticed
the mails' presence, not that I necessarily opened them.

For example with some mailing lists I don't really want to keep marking
all the mails as \Seen constantly, but I'd still like to know when new
mail arrives to them (then a quick look into the mailbox and out of it
would be enough to set $Noticed to all the mails).

One way would be to set this flag for *all* mails in the mailbox
whenever I open any mail them. Or maybe if the mail window becomes
visible for more than few seconds. Something like that.

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

--=-HeSULr90xmx/ViOWGApp--

Date: Mon, 09 Jan 2006 13:01:54 -0800
From: Cyrus Daboo <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: [email-masked]
Subject: Re: WG Last Call of LISTEXT draft 14
Sender: [email-masked]

Hi Timo,

--On January 9, 2006 8:06:16 PM +0200 Timo Sirainen <[email-masked]> wrote:

>> I certainly feel that it's less work for you to use the "Q" command than
>> it is for everybody else to deal with the wreckage caused by
>> implementations that do not support recent and marking properly.
>
> I'm not suggesting that (well, not anymore nowadays). But perhaps some
> new \Noticed flag, which works in many ways like recent, but instead of
> being removed whenever a client notices the mail, it's removed only when
> a MARK-NOTICED command is given. The client could send that whenever it
> figures out that user has actually been reading the mailbox (eg. opened
> some mail). Although I suppose that could be implemented as a keyword
> too..

Alternatively use \Seen (which the client should handle automatically for 
you) with a $FOLLOWUP-NEEDED keyword (or simply \Flagged) when you need to 
do more with the message after viewing it.

-- 
Cyrus Daboo

Subject: Re: WG Last Call of LISTEXT draft 14
From: Timo Sirainen <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: Dave Cridland <[email-masked]>, Arnaud Taddei <[email-masked]>, [email-masked]
Date: Mon, 09 Jan 2006 20:06:16 +0200
Sender: [email-masked]

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

On Mon, 2006-01-09 at 09:09 -0800, Mark Crispin wrote:
> On Mon, 9 Jan 2006, Timo Sirainen wrote:
> >>> Unfortunately this works only as long as you're using only one IMAP
> >>> client at a time.
> >> s/at a time./selected on the same mailbox at a time./
> > No, not the same mailbox. Just having selected any mailboxes.
>=20
> Say what?
>=20
> That doesn't make any sense.  A client selected on another mailbox is not=
=20
> going to affect the \Recent messages in the (different) mailbox you have=20
> selected.

No, but it affects the status of the other mailbox (the \Marked status)
in a mailbox list showing which boxes contain new mail.

> > You seem to suggest that the mailbox should be unselected whenever you
> > leave from the client. Is there any practical way to do that? Manually
> > it's too troublesome.
>=20
> No, I'm not suggesting that.  As I said, most people here only leave=20
> clients open on INBOX, and visit other mailboxes.
>=20
> I don't know what to tell you if a "Q" command is too much work for you.=20

Yes, it's too much :) I often start working based on some mail I read in
a mailing list, so the mailing list mailbox gets easily left open.

> I certainly feel that it's less work for you to use the "Q" command than=20
> it is for everybody else to deal with the wreckage caused by=20
> implementations that do not support recent and marking properly.

I'm not suggesting that (well, not anymore nowadays). But perhaps some
new \Noticed flag, which works in many ways like recent, but instead of
being removed whenever a client notices the mail, it's removed only when
a MARK-NOTICED command is given. The client could send that whenever it
figures out that user has actually been reading the mailbox (eg. opened
some mail). Although I suppose that could be implemented as a keyword
too..

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

--=-h5lfjY3w0ojNAf212UOu--

Date: Mon, 9 Jan 2006 09:09:02 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: Dave Cridland <[email-masked]>, Arnaud Taddei <[email-masked]>, [email-masked]
Subject: Re: WG Last Call of LISTEXT draft 14
Sender: [email-masked]

On Mon, 9 Jan 2006, Timo Sirainen wrote:
>>> Unfortunately this works only as long as you're using only one IMAP
>>> client at a time.
>> s/at a time./selected on the same mailbox at a time./
> No, not the same mailbox. Just having selected any mailboxes.

Say what?

That doesn't make any sense.  A client selected on another mailbox is not 
going to affect the \Recent messages in the (different) mailbox you have 
selected.

> But that's the problem. I always have _some_ mailbox selected in each
> client, and that client keeps eating the recent messages even though I
> haven't even looked at the client for days. It doesn't help me at all if
> my computer at office keeps telling me about new messages when I'm at
> home.

So your actual complaint is based upon your usage patterns.

My usage patterns are very different.  I leave clients selected on INBOX, 
open INBOX by default, and scan marking on the non-INBOX mailboxes that 
get direct delivery (we've had user+mailbox address syntax for a long 
time, just not as long as CMU).

Most people here do the same thing; and that's what drove the way that 
marking works.

> You seem to suggest that the mailbox should be unselected whenever you
> leave from the client. Is there any practical way to do that? Manually
> it's too troublesome.

No, I'm not suggesting that.  As I said, most people here only leave 
clients open on INBOX, and visit other mailboxes.

I don't know what to tell you if a "Q" command is too much work for you. 
I certainly feel that it's less work for you to use the "Q" command than 
it is for everybody else to deal with the wreckage caused by 
implementations that do not support recent and marking properly.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Mon, 09 Jan 2006 11:39:22 +0100
From: Arnaud Taddei <[email-masked]>
Subject: Re: WG Last Call of LISTEXT draft 14
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked], Philip Guenther <[email-masked]>, Chris Newman <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Arnaud Taddei writes:
>
>> I am not sure how many of you are dealing with operational, 
>> deployment and architectural issues in real customer sites but be 
>> aware that the IETF stack of protocol, while it allows 
>> interoperability of solutions, somehow, it too created an operational 
>> monster to implement and debug if it is not just to explain to people 
>> in the field. With the level of troops that exists today in the 
>> field, this leads me to say that I am not sure that this point of 
>> view was kept in mind when writing these extensions.
>
>
> I don't entirely agree, but, yes, I can't say I disagree...
>
> IETF standards are written for the people who show up at the meetings, 
> as they say. In the case of IMAP (and not only in that case), I do 
> wish the crowd were more diverse. (I prefer not to elaborate in email. 
> Too easy too offend people.) More people like you would help.

Well, ok I don't know IETF enough that is for sure, I never came myself 
to a session, not that I don't want to come but I was not allowed to 
come. Be aware that to just spend a few hours per week to review and 
comment and prepare myself some new drafts, I have to hide myself and I 
do that somehow on my spare time. I have to make sure my manager Waymon 
Whiting at work is ok with it (which he is because he allowed me to 
visit Mark and Terry Gray in november at Seattle) but I have to make 
sure this is ok as well with my managers at home (my wife and my two 
daughters who are 7 and 9!).

So it may be possible that my manager allows me to come to the next IETF 
but it is not clear yet. In the past it was a real challenge for me to 
do what I wanted in the past 7 years.

> Regarding LISTEXT specifically, what you have in mind seems like a 
> valuable command, but it's not one I would describe as "an extension 
> of LIST". More like a complete new command, e.g. one called 
> FOLDERSEARCH by analogy with LDAP.

Well, again, I read that statement but at the same time I have a 
different perspective on it.

> When I reviewed LISTEXT, I did so on the assumption that what was 
> needed were extensions to LIST as it stands. LISTEXT seems sensible as 
> such, and I've implemented it. Whether a completely different command 
> would be more valuable is a question I didn't contemplate, and which I 
> would prefer not to discuss now - please, let's get LISTEXT out the door.

Again I am afraid I disagree with this one here.

I will write a second round with my ideas in it.

A++

>
> Arnt

Date: Mon, 09 Jan 2006 11:24:33 +0100
From: Arnaud Taddei <[email-masked]>
Subject: Re: WG Last Call of LISTEXT draft 14
To: Mark Crispin <[email-masked]>
Cc: Dave Cridland <[email-masked]>, [email-masked]
Sender: [email-masked]

Mark Crispin wrote:

> Arnaud has his own agenda, 

in addition I have my limits, my constraints, my naivety and my biases :-)

> but I've talked with him quite a bit offline over the years.  I don't 
> always agree with him.  However, I share his dismay over some of the 
> directions taken in this WG.

> My silence on certain matters should not be taken as agreement.  It is 
> not necessary to do anything to kill something that is so byzantine 
> that it will die on its own.
>
> Put another way, if marking is too difficult to do right, so are 
> CONDSTORE and LISTEXT.  If keywords are too difficult to do right, so 
> is ANNOTATE.
>
> I object to hearing base specification functionality get badmouthed in 
> the same WG that's talking about much more complex functionality.  
> When I hear "nobody uses recent", "nobody uses marking", etc. this 
> tells me that we should not add ANY new extensions to IMAP until such 
> time as those statements cease to be made.

Ok I start to see where the problem is and I will make a second round.

A++

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

Subject: Re: WG Last Call of LISTEXT draft 14
From: Timo Sirainen <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: Dave Cridland <[email-masked]>, Arnaud Taddei <[email-masked]>, [email-masked]
Date: Mon, 09 Jan 2006 11:43:51 +0200
Sender: [email-masked]

--=-WdrYTey+vrXNs2f1qcBK
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Sun, 2006-01-08 at 14:58 -0800, Mark Crispin wrote:
> On Mon, 9 Jan 2006, Timo Sirainen wrote:
> > Unfortunately this works only as long as you're using only one IMAP
> > client at a time.
>=20
> s/at a time./selected on the same mailbox at a time./

No, not the same mailbox. Just having selected any mailboxes.

> > I wouldn't want to rely on a client that only notifies me of recent
> > messages or \Marked mailboxes, since I always have at least two IMAP
> > clients open and each one having selected whatever mailbox I happened t=
o
> > last look at.
>=20
> *Both* clients will see \Marked status until one or the other selects the=
=20
> mailbox.  At that point, the user has been alerted to the new messages.

But that's the problem. I always have _some_ mailbox selected in each
client, and that client keeps eating the recent messages even though I
haven't even looked at the client for days. It doesn't help me at all if
my computer at office keeps telling me about new messages when I'm at
home.

You seem to suggest that the mailbox should be unselected whenever you
leave from the client. Is there any practical way to do that? Manually
it's too troublesome.

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

--=-WdrYTey+vrXNs2f1qcBK--

Date: Mon, 09 Jan 2006 06:52:50 +0100
From: Arnaud Taddei <[email-masked]>
Subject: Re: WG Last Call of LISTEXT draft 14
To: Dave Cridland <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

>>    * Page 17, I think Example 6 requires much more explanations
>
>
> I think I see why. Could you suggest some alternate text for 
> explaining both example 5 and example 6? (I should think both would 
> need to be changed to express the difference more clearly).

Yes I will, let me understand all the comments on this thread first. I 
am feeling guilty now.

A++

Date: Mon, 09 Jan 2006 06:36:55 +0100
From: Arnaud Taddei <[email-masked]>
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked], Barry Leiba <[email-masked]>
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Arnaud Taddei writes:
>
>> The multiple mailbox patterns is extremely important for when you 
>> need to keep 2 IMAP servers synchronizing a selection of their 
>> (shared/public) folders so I vote for keeping this by all means.
>
>
> Could you elaborate?
>
> I don't see any difference at all between these two at the moment:
>
> C: a LIST "" a*
> C: b LIST "" *b
>
> and
>
> C: a LIST "" (a* *b)

Technically there is no difference but I consider counter intuitive that 
I have to ask 2 questions when semantically I have only one in mind.

A++

>
> There used to be a difference in previous version of the draft, namely 
> that folder 'adverb' was listed twice in the first case and only once 
> in the second.
>
> Arnt

Date: Sun, 8 Jan 2006 14:58:13 -0800
From: Mark Crispin <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: Dave Cridland <[email-masked]>, Arnaud Taddei <[email-masked]>, [email-masked]
Subject: Re: WG Last Call of LISTEXT draft 14
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Mon, 9 Jan 2006, Timo Sirainen wrote:
> Unfortunately this works only as long as you're using only one IMAP
> client at a time.

s/at a time./selected on the same mailbox at a time./

> Otherwise the new mail may be picked up first by
> another client which has the mailbox selected, but the client you're
> currently using sees the mailbox as \UnMarked and with 0 recent
> messages.

And why is this a problem?

If I am running two clients (which I routinely do), why on earth would I 
want one nagging me to open a mailbox when I've already opened it in the 
other?

I only want to be nagged about about *unopened* mailboxes with recent 
messages.  Once it's opened, I'm taking care of it; and any other client 
session should leave it alone.

> I wouldn't want to rely on a client that only notifies me of recent
> messages or \Marked mailboxes, since I always have at least two IMAP
> clients open and each one having selected whatever mailbox I happened to
> last look at.

*Both* clients will see \Marked status until one or the other selects the 
mailbox.  At that point, the user has been alerted to the new messages.

That's how it was designed to work.  At least one person feels that this 
is exactly how it should work.  Maybe I'm unique on this planet, but I 
suspect not.

After all, this is how mail worked in the 15 years prior to IMAP, and how 
most mail worked in the next 10-15 years after IMAP came about.

> \Recent may be useful for some things, but I wish there was a new
> similar flag that works properly with multiple clients open.

\Recent may not do what you prefer, but that is not the same as "does not 
work properly."

-- Mark --

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

Subject: Re: WG Last Call of LISTEXT draft 14
From: Timo Sirainen <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: Dave Cridland <[email-masked]>, Arnaud Taddei <[email-masked]>, [email-masked]
Date: Mon, 09 Jan 2006 00:06:06 +0200
Sender: [email-masked]

--=-M5DzPVaeK1o9/p0ar09H
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Sat, 2006-01-07 at 12:02 -0800, Mark Crispin wrote:
> On Sat, 7 Jan 2006, Dave Cridland wrote:
> > And my point is that even if \Marked *is* specified, client authors sti=
ll=20
> > can't make any assumptions.
>=20
> If \Marked is specified, then the mailbox definitely needs to be inspecte=
d=20
> closer.  If \UnMarked is not specified, then the mailbox definitely does=20
> NOT need to be inspected closer.

Unfortunately this works only as long as you're using only one IMAP
client at a time. Otherwise the new mail may be picked up first by
another client which has the mailbox selected, but the client you're
currently using sees the mailbox as \UnMarked and with 0 recent
messages.

I wouldn't want to rely on a client that only notifies me of recent
messages or \Marked mailboxes, since I always have at least two IMAP
clients open and each one having selected whatever mailbox I happened to
last look at.

\Recent may be useful for some things, but I wish there was a new
similar flag that works properly with multiple clients open.

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

--=-M5DzPVaeK1o9/p0ar09H--

Date: Sun, 8 Jan 2006 22:14:55 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: listext extended data
Sender: [email-masked]

I'm not sure, but it seems to me that somewhere, perhaps in the IANA 
registration for RECURSIVEMATCH, there should be a sentence which 
mentions both childinfo-extended-item and mbox-list-extended-item by 
name.

Or maybe in a comment for for childinfo-extended-item, that would be 
similar to how many other extensions extend other productions, e.g. 
annotate and search-key, condstore and fetch-att, 2177bis and 
command-auth, search-res and sequence-set, and so on and so forth.

As it stands, connecting the two required intelligent thought. Painful.

Arnt

Date: Sun, 8 Jan 2006 16:44:00 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: WG Last Call of LISTEXT draft 14
Cc: Philip Guenther <[email-masked]>, Arnaud Taddei <[email-masked]>, Chris Newman <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

Arnaud Taddei writes:
> I am not sure how many of you are dealing with operational, deployment 
> and architectural issues in real customer sites but be aware that the 
> IETF stack of protocol, while it allows interoperability of 
> solutions, somehow, it too created an operational monster to 
> implement and debug if it is not just to explain to people in the 
> field. With the level of troops that exists today in the field, this 
> leads me to say that I am not sure that this point of view was kept 
> in mind when writing these extensions.

I don't entirely agree, but, yes, I can't say I disagree...

IETF standards are written for the people who show up at the meetings, 
as they say. In the case of IMAP (and not only in that case), I do wish 
the crowd were more diverse. (I prefer not to elaborate in email. Too 
easy too offend people.) More people like you would help.

Regarding LISTEXT specifically, what you have in mind seems like a 
valuable command, but it's not one I would describe as "an extension of 
LIST". More like a complete new command, e.g. one called FOLDERSEARCH 
by analogy with LDAP.

When I reviewed LISTEXT, I did so on the assumption that what was needed 
were extensions to LIST as it stands. LISTEXT seems sensible as such, 
and I've implemented it. Whether a completely different command would 
be more valuable is a question I didn't contemplate, and which I would 
prefer not to discuss now - please, let's get LISTEXT out the door.

Arnt

Date: Sun, 8 Jan 2006 16:33:21 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
Cc: Arnaud Taddei <[email-masked]>, Barry Leiba <[email-masked]>
Sender: [email-masked]

Arnaud Taddei writes:
> The multiple mailbox patterns is extremely important for when you need 
> to keep 2 IMAP servers synchronizing a selection of their 
> (shared/public) folders so I vote for keeping this by all means.

Could you elaborate?

I don't see any difference at all between these two at the moment:

C: a LIST "" a*
C: b LIST "" *b

and

C: a LIST "" (a* *b)

There used to be a difference in previous version of the draft, namely 
that folder 'adverb' was listed twice in the first case and only once 
in the second.

Arnt

Date: Sat, 7 Jan 2006 12:02:50 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: Arnaud Taddei <[email-masked]>, [email-masked]
Subject: Re: WG Last Call of LISTEXT draft 14
Sender: [email-masked]

On Sat, 7 Jan 2006, Dave Cridland wrote:
> And my point is that even if \Marked *is* specified, client authors still 
> can't make any assumptions.

If \Marked is specified, then the mailbox definitely needs to be inspected 
closer.  If \UnMarked is not specified, then the mailbox definitely does 
NOT need to be inspected closer.

It's only in the case that there is no marking that there is a question of 
what to do.  In the case of trying to find new messages, false positives 
are better, so you treat it as if it is \Marked.  But there are cases 
where false negatives are better.  All that is avoided if the server 
follows the specification and implements marking, instead of listening to 
people who suggest that there's no point to doing so.

> Absolutely, and I'm sure you realise I'm not advocating that a server 
> implementor should do this. I'm merely pointing out that from a client's 
> perspective, it's impossible to tell if that's what the server is doing. Just 
> as servers should be striving to fully implement IMAP and all extensions, 
> clients have to be prepared to deal with the most contrary of servers.

Clients should be written to deal optimally with working servers.  It may 
be necessary to deal with broken servers, but clients should not treat a 
working server as a broken server.

In the extreme example of Courier, you have to use a special switch in 
Pine which switches off almost all IMAP functionalities and basically 
makes Pine act like Outlook (and be quite a bit slower).  The author of 
Courier may think that all clients should act like Outlook all the time. 
I disagree.

>>> In any case, many clients do not care about recent messages at all, only 
>>> about unseen messages, or simply messages they've not downloaded, causing 
>>> many server implementors to completely ignore \Marked and \UnMarked.
>> So, there are broken clients out there.
> No. These clients are not broken, they're simply not interested in that 
> information - that's a different thing.

No, clients which do not use the full capabilities of the IMAP base are 
broken.  Every piece of it is there for a reason; there is no surplusage.

A client which does not pay attention to recent status can not distinguish 
between a new message and one which arrived in a previous session but the 
user choose to defer reading it.  The latter are not new messages; and 
alerting the user to "new" messages when there are no recent messages is 
wrong.

> My client, for instance, does not care *if* a mailbox contains recent 
> messages, nor even how many there are once the mailbox is selected. It does 
> mark recent messages visually, and it does care about where the first recent 
> message is.

This is a contradiction.  At most, you are saying that your client doesn't 
do much with the recent count (which is mostly useful in a heading display 
such as "5329 messages, 23 recent").  Otherwise, your client very much 
cares about recent messages; it goes to considerable length to communicate 
the status to the user and (a non-obvious but important to any quality 
client) it makes note of where the first message is.

Let's get on the same page here.  Your client *does* care if a mailbox 
contains recent messages.

> The vast majority of clients ignore all non-system keywords that they didn't 
> define. I'd think we both agree this is misguided, but it is not broken.

It *is* broken, and I say this having fought this battle long and hard 
with my colleagues in Pine.  I'm still not particularly happy with what we 
have now, but at least it's better than what there was before which was 
nothing.  At best, Pine only gets a C+ for keywords.

> Pine, on the other hand, uses IMAP mailboxes to store addressbook and 
> configuration information, instead of using a protocol purpose-built for that 
> task. I don't consider that broken, however misguided I personally believe it 
> to be.

This is a legitimate sore spot.

We really, *really* wanted ACAP.  We instigated for ACAP because IMSP was, 
well, let's just say that IMSP was not satisfactory.  Sadly, ACAP did not 
learn from the experience.

Pine did what it did not out of ignorance or misguidance, but because we 
saw the ACAP train wreck coming early on and got off the train.

It is true that ACAP is a "failure" instead of a "miserable failure" 
because some people (such as you) have been able to use it.  But I think 
that even the small ACAP community can conceed that it has not been a 
success.

I really don't want to say too much more.  There's no sense in reopening 
old wounds.  Rather, we should look to the future.

Consider this:

IMAP mailboxes have proven to be completely satisfactory for remote 
addressbook and configuration information.  The *only* deficiency has been 
in sharing addressbooks with other MUAs.  For remote Pine configuration, 
there is no need to share that data with anything else; although one could 
imagine sharing some parts of Pine's configuration (e.g., an IMAP URL for 
the user's INBOX, submission server, NNTP server, etc.) with other MUAs.

Suppose you were to build a protocol that would be a natural upgrade to 
using IMAP mailboxes; one that solves those deficiencies *without* 
orthogonal functionality.  Would you come up with ACAP?  I suspect not.

There is a danger to doing more than is needed.  The simple and 
inexpensive solution that does what is necessary will always defeat the 
more complex and elegant solution.  VHS beat Beta.  For a long time, POP3 
beat IMAP and there are still substantial holdouts for POP3-only.  I'll 
wager that HD-DVD will beat Blu-Ray.

Sadly, it's worse than that.  A simple kludge that results in great 
complexity, but only complexity is already there and "paid for", will 
*also* beat the elegant solution that "isn't there yet".  Windows beat 
Mac.

My crystal ball says that the next train wreck is going to be personal 
address books in LDAP; only this time we are all going to be on that 
train.  What's more, we'll keep on jumping on to the train as it wrecks. 
This is a controversial prediction, and many good people are fighting hard 
to stop it from happening.  But my money is on it.  I don't take any 
pleasure in it.  I'd *love* to lose this bet.

>> I hope that you're not saying that, because there are broken clients, no 
>> client or server should ever attempt to do the right thing?
> No, but I am saying that when clients do not use information that is optional 
> to provide, there is little benefit to server implementors to go to any 
> effort to transmit it, and at least in my experience, the majority of server 
> implementors are satisfied with a minimalist conformancy.

I on the other hand believe that this is something which must be fought 
against tooth and nail.  It creates a vicious cycle in which deficient 
implementation spawns deficient implementation, back and forth between 
clients and servers.

This is what Courier does; it implements IMAP enough to satisfy Outlook 
and Netscape, and calls that "good enough".

>> Or worse, that it's alright for servers to be broken because most clients 
>> do not care?  That's basically what the author of Courier claims...
> I'm not claiming that. I am, however, claiming that servers might well elide 
> parts of the specification that are optional if there is little or no demand 
> for them, and whether or not that's a good thing isn't the issue under 
> discussion here.

There is little in the base specification that is truly optional.  I do 
not consider marking to be optional.

I might go so far as to say that a server implementation can say NO to any 
CREATE/DELETE/RENAME command; NO to any SELECT/EXAMINE command that does 
not have INBOX as an argument; and only return INBOX in LIST/LSUB, yet 
still be a quality server implementation if it otherwise fully implements 
IMAP.

Strange to say, non-INBOX mailboxes are the one part of IMAP that most 
people don't consider to be optional...

>>  . clients should be able to use the full specification
> I would argue "clients should be able to take full advantage of any 
> applicable parts of the specification and any applicable extensions to 
> achieve their goals in the most efficient manner possible", which is more or 
> less the same thing, but not quite: the distinction is that a client which 
> does not gain benefit from a particular feature obviously need not implement 
> it.

As an extreme example, the following is completely in line with what you 
just said:
 	1 select inbox
 	2 fetch 1:* rfc822
 	3 store 1:* flags (\deleted)
 	4 close

I take a harder line.  I don't consider that to be an IMAP client.  It's a 
POP client that babbles IMAP protocol.

Message metadata, envelopes, body structures, selective fetching, 
searching, sorting, threading,... all are necessary for a true IMAP 
client.  You can't declare one to be optional without imperiling it all.

> My issue with \Marked, which appears to have been blown out of all 
> proportion, is simply that the specification is, in this particular instance, 
> sufficiently vague as to make \Marked not yield any reliable information.

Not at all.

\Marked reliably states that "this mailbox definitely needs to be 
inspected for something that the user may not know about."

\UnMarked reliably states that "nothing has happened in this mailbox that 
the user does not know about."

That's very different from "no reliable information."  Rather, it's 
reliably telling you something that you may not recognize as useful.

Read below to see why it is useful.

> I've never said marking is difficult for servers to do right. Merely that 
> it's impossible for clients to rely on the information it yields, whether or 
> not it's done right.

I can't agree.  Marking is quite reliable if it is used for the intended 
purpose.

> Moreover, I have not said "nobody uses recent", nor "nobody uses marking". I 
> *have* said that if I had a use for marking, I would be concerned with 
> depending on the behaviour of \Marked, because it is not fully defined.

I contend that it is defined, but maybe you didn't understand the 
definition.

A SELECT/EXAMINE, even a STATUS, may be slow; especially when you have 
many folders.  Marking is a first-order triage that saves an enormous 
amount of time.  We have users with many hundreds of mailboxes, and some 
of these non-INBOX mailboxes get direct delivery of new mail.  A client 
which does not use marking is unusable for these folks.

In this case, the \UnMarked flag is the more important one; the triage 
separates the \UnMarked mailboxes from all others.  Even before this, the 
client triaged the \NoSelect mailboxes.

Put another way; your client may be wonderful in all other ways, but if it 
doesn't use marking, it won't work well for us.  Either it forces the user 
to manually inspect every mailbox that may have new messages, or it does 
an exhaustive scan of all mailboxes.

Please consider this.  I would like to see more clients which are useful 
in our environment.  Sadly, most clients never get far beyond starting up 
before they fail.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Sat, 07 Jan 2006 14:39:47 +0000
Subject: Re: WG Last Call of LISTEXT draft 14
From: Dave Cridland <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: Arnaud Taddei <[email-masked]>, <[email-masked]>
Sender: [email-masked]

On Fri Jan  6 22:29:51 2006, Mark Crispin wrote:
> On Fri, 6 Jan 2006, Dave Cridland wrote:

> The caution to client authors is that, depending upon what you are 
> looking for, you can't make any assumptions about mailboxes that 
> lack marking status and therefore have to go to extra (and perhaps 
> very costly) work.
> 
> 
And my point is that even if \Marked *is* specified, client authors 
still can't make any assumptions.

>> Thus, if a server implemented \Marked and \UnMarked support by 
>> never sending \UnMarked, and sending \Marked every second Tuesday 
>> of months with an 'r' in them, it would still be compliant even 
>> then.
> 
> Yes, there are many bad things that an IMAP server can do without 
> being in strict violation of the specification.  That doesn't mean 
> that it's alright for IMAP servers to do them.  This isn't unique 
> to IMAP by the way.
> 
> IMHO, it is NEVER alright to spit in the face of a specification or 
> even its spirit.
> 
> 
Absolutely, and I'm sure you realise I'm not advocating that a server 
implementor should do this. I'm merely pointing out that from a 
client's perspective, it's impossible to tell if that's what the 
server is doing. Just as servers should be striving to fully 
implement IMAP and all extensions, clients have to be prepared to 
deal with the most contrary of servers.

>> In any case, many clients do not care about recent messages at 
>> all, only about unseen messages, or simply messages they've not 
>> downloaded, causing many server implementors to completely ignore 
>> \Marked and \UnMarked.
> 
> So, there are broken clients out there.
> 
> 
No. These clients are not broken, they're simply not interested in 
that information - that's a different thing.

My client, for instance, does not care *if* a mailbox contains recent 
messages, nor even how many there are once the mailbox is selected. 
It does mark recent messages visually, and it does care about where 
the first recent message is. That is not broken, although you're free 
to consider it misguided.

The vast majority of clients ignore all non-system keywords that they 
didn't define. I'd think we both agree this is misguided, but it is 
not broken.

Pine, on the other hand, uses IMAP mailboxes to store addressbook and 
configuration information, instead of using a protocol purpose-built 
for that task. I don't consider that broken, however misguided I 
personally believe it to be.

> I hope that you're not saying that, because there are broken 
> clients, no client or server should ever attempt to do the right 
> thing?
> 
> 
No, but I am saying that when clients do not use information that is 
optional to provide, there is little benefit to server implementors 
to go to any effort to transmit it, and at least in my experience, 
the majority of server implementors are satisfied with a minimalist 
conformancy.

> Or worse, that it's alright for servers to be broken because most 
> clients do not care?  That's basically what the author of Courier 
> claims...
> 
> 
I'm not claiming that. I am, however, claiming that servers might 
well elide parts of the specification that are optional if there is 
little or no demand for them, and whether or not that's a good thing 
isn't the issue under discussion here.

Eliding parts of the specification that are not optional (not sending 
UIDNEXT during SELECT is quite popular, for instance) is not alright 
under any circumstances.

> If you're not claiming that, then you should accept on principle my 
> contentions that:
>  . servers should fully support the specification

That goes without saying. Servers must fully support the 
specification, and should conform to as many optional parts as 
possible, whether those optional parts are in the base specification 
or extensions.

>  . clients should be able to use the full specification

I would argue "clients should be able to take full advantage of any 
applicable parts of the specification and any applicable extensions 
to achieve their goals in the most efficient manner possible", which 
is more or less the same thing, but not quite: the distinction is 
that a client which does not gain benefit from a particular feature 
obviously need not implement it. Many clients don't use the 
information which the \Recent flag provides, for instance, simply 
because they have no use for this information in their model. This 
does not mean that servers needn't implement it correctly, obviously. 
Similarly, I don't use the conditional STORE, or modseq SEARCH, in 
CONDSTORE, so obviously I've not implemented those.

>  . it is WRONG to give advice of the form "nobody uses it"
> 
> 
Given the fact that I've been the recipient of this advice over ACAP 
for the past few years, you really ought to know by now that I ignore 
all such advice, and tend to consider the inverse argument of "if 
people used this" with much more weight. Besides which, almost 
invariably this kind of advice is wrong.

My issue with \Marked, which appears to have been blown out of all 
proportion, is simply that the specification is, in this particular 
instance, sufficiently vague as to make \Marked not yield any 
reliable information.

> Put another way, if marking is too difficult to do right, so are 
> CONDSTORE and LISTEXT.  If keywords are too difficult to do right, 
> so is ANNOTATE.
> 
> 
I've never said marking is difficult for servers to do right. Merely 
that it's impossible for clients to rely on the information it 
yields, whether or not it's done right.

> I object to hearing base specification functionality get badmouthed 
> in the same WG that's talking about much more complex 
> functionality.  When I hear "nobody uses recent", "nobody uses 
> marking", etc. this tells me that we should not add ANY new 
> extensions to IMAP until such time as those statements cease to be 
> made.

You make it sound like I'm slandering the entire base specification, 
which I'm not. Having features in the base specification which are 
not used by many clients isn't a problem to me at all - they still 
need to be done right by servers, or, if optional, possibly not at 
all.

Moreover, I have not said "nobody uses recent", nor "nobody uses 
marking". I *have* said that if I had a use for marking, I would be 
concerned with depending on the behaviour of \Marked, because it is 
not fully defined. As for recent, I use this to a degree myself, and 
very useful it is, too, but I completely understand the decision of 
many client implementors to ignore the information it provides.

I merely stated - accurately, I believe - that the description of 
\Marked is sufficiently vague in RFC3501 as to be unreliable. I'm 
sorry if you take this personally, it's not intended as an assignment 
of blame, merely a statement of fact.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Sat, 07 Jan 2006 11:08:19 +0100
From: Arnaud Taddei <[email-masked]>
Subject: Re: Need a template to start a draft
To: Lisa Dusseault <[email-masked]>
Cc: Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

Thanks Mark, Arnt and Lisa, I am proceeding

A++

Lisa Dusseault wrote:

> I use the XML stuff described at http://xml.resource.org, myself.  If 
> you browse http://ietf.webdav.org for XML files, you can see a number 
> of examples.
>
> Lisa
>
> On Jan 6, 2006, at 9:30 AM, Mark Crispin wrote:
>
>>
>> On Fri, 6 Jan 2006, Arnaud Taddei wrote:
>>
>>> Where can I find a template to start a draft? What are you guys using?
>>
>>
>> Start with http://www.ietf.org/ID-Checklist.html
>>
>> -- Mark --
>>
>> http://panda.com/mrc
>> Democracy is two wolves and a sheep deciding what to eat for lunch.
>> Liberty is a well-armed sheep contesting the vote.
>>
>

Date: Fri, 6 Jan 2006 14:40:55 -0800
From: Mark Crispin <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: Dave Cridland <[email-masked]>, Arnaud Taddei <[email-masked]>, [email-masked]
Subject: Re: WG Last Call of LISTEXT draft 14
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Fri, 6 Jan 2006, Timo Sirainen wrote:
> Luckily there are only very few clients that care about the \Marked
> state. I wouldn't be surprised if Pine was the only one :)

As Pawel said, you're mistaken...

> There are many other problems with maildir. The worst is that it's
> trying to be lockless without current filesystems properly supporting it
> that way, which is causing mails to be temporarily lost with heavy
> concurrent mailbox access.

Golly gee, this is what I said years ago, and I got called all sorts of 
names by members of the Maildir church (not you) over it.

> I mean here if the MUA doesn't add "Status: O" header to mails. I don't
> know how many MUAs don't do that, but at least if you quit mutt with
> ctrl-c instead of "q", the mbox isn't updated.

Basically, what you are saying is that the other MUA correctly clears 
\Marked status on the mailbox but fails to clear \Recent status on the 
messages.  This isn't a bug in UW imapd; it's a bug in the other MUA.

The other MUA's session was "the first session to have been notified about 
this mailbox"; being read-write (since it cleared \Marked status) it was 
required to clear the \Recent status as well.  If it was a read-only 
session, it would not be permitted to make "changes to the permanent state 
of the mailbox."

So what you have in this case is a damaged mailbox.  I'm surprised to hear 
that mutt causes such damage; traditional tools did the right thing.  But 
you can't blame UW imapd for that.

-- Mark --

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

Date: Fri, 6 Jan 2006 14:29:51 -0800
From: Mark Crispin <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: Arnaud Taddei <[email-masked]>, [email-masked]
Subject: Re: WG Last Call of LISTEXT draft 14
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Fri, 6 Jan 2006, Dave Cridland wrote:
>    \Marked
>        The mailbox has been marked "interesting" by the server; the
>        mailbox probably contains messages that have been added since
>        the last time the mailbox was selected.
> Doncha just love that "probably"?

This simply means that \Marked status can also mean something else, such 
as a flag change or UIDVALIDITY change.  That probably was not a good 
idea, but at the time it was thought to be.

In the most primitive form, marking exports the result of a comparison of 
file dates from stat().  In the real world, this is actually useful.

>> If a mailbox has recent messages, and the mailbox does not have \Marked 
>> status, then it's a bug in the server.
> Nope, it's absolutely not a bug in the server, that behaviour is specified 
> here:
>     If it is not feasible for the server to determine whether or not
>     the mailbox is "interesting", or if the name is a \Noselect name,
>     the server SHOULD NOT send either \Marked or \Unmarked.

You've misunderstood the purpose of that text.

That text stipulates behavior for deficient mail stores (much like 
UIDNOTSTICKY in UIDPLUS).  That's different from blessing such behavior.

> The converse is not true either - if a mailbox *is* \Marked, it may not 
> contain messages flagged \Recent, and still be delightfully compliant with 
> RFC3501, thanks to that "probably".

Nobody ever made that claim.

The caution to client authors is that, depending upon what you are looking 
for, you can't make any assumptions about mailboxes that lack marking 
status and therefore have to go to extra (and perhaps very costly) work.

> Thus, if a server implemented \Marked and \UnMarked support by never sending 
> \UnMarked, and sending \Marked every second Tuesday of months with an 'r' in 
> them, it would still be compliant even then.

Yes, there are many bad things that an IMAP server can do without being in 
strict violation of the specification.  That doesn't mean that it's 
alright for IMAP servers to do them.  This isn't unique to IMAP by the 
way.

IMHO, it is NEVER alright to spit in the face of a specification or even 
its spirit.

> In any case, many clients do not care about recent messages at all, only 
> about unseen messages, or simply messages they've not downloaded, causing 
> many server implementors to completely ignore \Marked and \UnMarked.

So, there are broken clients out there.

I hope that you're not saying that, because there are broken clients, no 
client or server should ever attempt to do the right thing?

Or worse, that it's alright for servers to be broken because most clients 
do not care?  That's basically what the author of Courier claims...

If you're not claiming that, then you should accept on principle my 
contentions that:
  . servers should fully support the specification
  . clients should be able to use the full specification
  . it is WRONG to give advice of the form "nobody uses it"

>> I am, by the way, as a matter of principle opposed to protocol extensions 
>> that attempt to amend broken servers.  A server that can't do the base 
>> protocol right is not going to do the extensions right either.
> Apropos what, Mark? I've not suggested any such thing, as far as I can 
> recall. If you mean Arnaud's suggestion to simplify IMAP by importing LDAP's 
> searching model (and if that doesn't give you a wry grin, nothing will), then 
> I don't think that's what he's suggesting either.

Arnaud has his own agenda, but I've talked with him quite a bit offline 
over the years.  I don't always agree with him.  However, I share his 
dismay over some of the directions taken in this WG.

My silence on certain matters should not be taken as agreement.  It is not 
necessary to do anything to kill something that is so byzantine that it 
will die on its own.

Put another way, if marking is too difficult to do right, so are CONDSTORE 
and LISTEXT.  If keywords are too difficult to do right, so is ANNOTATE.

I object to hearing base specification functionality get badmouthed in the 
same WG that's talking about much more complex functionality.  When I hear 
"nobody uses recent", "nobody uses marking", etc. this tells me that we 
should not add ANY new extensions to IMAP until such time as those 
statements cease to be made.

-- Mark --

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

Date: Fri, 06 Jan 2006 23:06:11 +0100
From: Pawel Salek <[email-masked]>
Subject: Re: WG Last Call of LISTEXT draft 14
To: [email-masked]
Sender: [email-masked]

On 01/06/2006 08:56:46 PM, Timo Sirainen wrote:
> On Fri, 2006-01-06 at 10:58 -0800, Mark Crispin wrote:
> > > Calculating \Marked and \UnMarked is too expensive to do with
> maildir,
> > > so I'm not returning either with it.
> >
> > That's better than reporting false marked status.  But what this
> > effectively means is that a client that is looking for mailboxes
> with
> > recent messages will have to probe every mailbox (effectively
> treating no
> > marked status as equivalent to \Marked).  This is not behavior that
> you
> > really want the clients to be doing.
> 
> Luckily there are only very few clients that care about the \Marked
> state. I wouldn't be surprised if Pine was the only one :)

It definetely isn't.

Pawel

Date: Fri, 06 Jan 2006 21:12:36 +0000
Subject: Re: WG Last Call of LISTEXT draft 14
From: Dave Cridland <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: Arnaud Taddei <[email-masked]>, <[email-masked]>
Sender: [email-masked]

On Fri Jan  6 17:27:34 2006, Mark Crispin wrote:
> On Fri, 6 Jan 2006, Dave Cridland wrote:
>> It's defined, or rather isn't, in RFC3501. Its meaning is that the 
>> mailbox has been marked in some way by the server because it is, 
>> in some way, interesting. In practise, this can mean that there 
>> are recent messages, but its absence doesn't mean there are no 
>> recent messages, making it fairly useless.
> 
> Say what???
> 
> 
RFC3501, Section 7.2.2:

     \Marked
         The mailbox has been marked "interesting" by the server; the
         mailbox probably contains messages that have been added since
         the last time the mailbox was selected.

Doncha just love that "probably"?

> If a mailbox has recent messages, and the mailbox does not have 
> \Marked status, then it's a bug in the server.
> 
> 
Nope, it's absolutely not a bug in the server, that behaviour is 
specified here:

      If it is not feasible for the server to determine whether or not
      the mailbox is "interesting", or if the name is a \Noselect 
name,
      the server SHOULD NOT send either \Marked or \Unmarked.

The converse is not true either - if a mailbox *is* \Marked, it may 
not contain messages flagged \Recent, and still be delightfully 
compliant with RFC3501, thanks to that "probably".

Thus, if a server implemented \Marked and \UnMarked support by never 
sending \UnMarked, and sending \Marked every second Tuesday of months 
with an 'r' in them, it would still be compliant even then.

In any case, many clients do not care about recent messages at all, 
only about unseen messages, or simply messages they've not 
downloaded, causing many server implementors to completely ignore 
\Marked and \UnMarked.

> I am, by the way, as a matter of principle opposed to protocol 
> extensions that attempt to amend broken servers.  A server that 
> can't do the base protocol right is not going to do the extensions 
> right either.
> 
> 
Apropos what, Mark? I've not suggested any such thing, as far as I 
can recall. If you mean Arnaud's suggestion to simplify IMAP by 
importing LDAP's searching model (and if that doesn't give you a wry 
grin, nothing will), then I don't think that's what he's suggesting 
either.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Subject: Re: WG Last Call of LISTEXT draft 14
From: Timo Sirainen <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: Dave Cridland <[email-masked]>, Arnaud Taddei <[email-masked]>, [email-masked]
Date: Fri, 06 Jan 2006 21:56:46 +0200
Sender: [email-masked]

--=-4Quss4MY9xuxws9Q4s5C
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Fri, 2006-01-06 at 10:58 -0800, Mark Crispin wrote:
> > Calculating \Marked and \UnMarked is too expensive to do with maildir,
> > so I'm not returning either with it.
>=20
> That's better than reporting false marked status.  But what this=20
> effectively means is that a client that is looking for mailboxes with=20
> recent messages will have to probe every mailbox (effectively treating no=
=20
> marked status as equivalent to \Marked).  This is not behavior that you=20
> really want the clients to be doing.

Luckily there are only very few clients that care about the \Marked
state. I wouldn't be surprised if Pine was the only one :)

> By the way, thank you for acknowledging that Maildir has problems too.=20
> Some of the more fanatic members of the Maildir church haven't grasped=20
> that yet.

There are many other problems with maildir. The worst is that it's
trying to be lockless without current filesystems properly supporting it
that way, which is causing mails to be temporarily lost with heavy
concurrent mailbox access.

> > Also the way UW-IMAP handles this with mboxes breaks immediately once
> > non-c-client based MUA opens the mailbox. Does this mean UW-IMAP is als=
o
> > buggy since the exact behavior you described can happen with it?
>=20
> I read this as a claim by you that UW imapd reports a traditional UNIX=20
> format mailbox as \Marked after it has been opened by a non-c-client base=
d=20
> MUA.
>=20
> This is a rather serious charge.  I would like to see the evidence.

I mean here if the MUA doesn't add "Status: O" header to mails. I don't
know how many MUAs don't do that, but at least if you quit mutt with
ctrl-c instead of "q", the mbox isn't updated. In that case MUA acts the
same way as "touch -a", and this happens (imap-2004g):

x copy 1 test
x OK COPY completed
x list "" test
* LIST (\NoInferiors \Marked) "/" test

"touch -a test", or open with some MUA that doesn't modify mbox.

x list "" test
* LIST (\NoInferiors \UnMarked) "/" test
x OK LIST completed
x status test (recent)
* STATUS test (RECENT 1)
x OK STATUS completed

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

--=-4Quss4MY9xuxws9Q4s5C--

Date: Fri, 6 Jan 2006 10:58:09 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: Dave Cridland <[email-masked]>, Arnaud Taddei <[email-masked]>, [email-masked]
Subject: Re: WG Last Call of LISTEXT draft 14
Sender: [email-masked]

On Fri, 6 Jan 2006, Timo Sirainen wrote:
>> If a mailbox has recent messages, and the mailbox does not have \Marked
>> status, then it's a bug in the server.
> Isn't this rather ".., and the mailbox has \UnMarked status, .."?

No and yes.

If a not-selected mailbox has recent messages, then it SHOULD have \Marked 
status and MUST NOT have \Unmarked status.

In general, lack of marking status in LIST results indicates a deficient 
implementation; and this should be avoided.

There *are* exceptions.  For example, marking status is inappropriate with 
\NoSelect names.  In general, though, servers should return marking 
status.  Truthful \UnMarked status is especially important.

> Calculating \Marked and \UnMarked is too expensive to do with maildir,
> so I'm not returning either with it.

That's better than reporting false marked status.  But what this 
effectively means is that a client that is looking for mailboxes with 
recent messages will have to probe every mailbox (effectively treating no 
marked status as equivalent to \Marked).  This is not behavior that you 
really want the clients to be doing.

By the way, thank you for acknowledging that Maildir has problems too. 
Some of the more fanatic members of the Maildir church haven't grasped 
that yet.

> Also the way UW-IMAP handles this with mboxes breaks immediately once
> non-c-client based MUA opens the mailbox. Does this mean UW-IMAP is also
> buggy since the exact behavior you described can happen with it?

I read this as a claim by you that UW imapd reports a traditional UNIX 
format mailbox as \Marked after it has been opened by a non-c-client based 
MUA.

This is a rather serious charge.  I would like to see the evidence.

If there is a bug, I will fix it.  The traditional UNIX driver goes to 
considerable effort to interact properly with legacy software.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Cc: Arnaud Taddei <[email-masked]>, IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Re: Need a template to start a draft
Date: Fri, 6 Jan 2006 10:24:56 -0800
To: Mark Crispin <[email-masked]>
Sender: [email-masked]

I use the XML stuff described at http://xml.resource.org, myself.  If 
you browse http://ietf.webdav.org for XML files, you can see a number 
of examples.

Lisa

On Jan 6, 2006, at 9:30 AM, Mark Crispin wrote:

>
> On Fri, 6 Jan 2006, Arnaud Taddei wrote:
>> Where can I find a template to start a draft? What are you guys using?
>
> Start with http://www.ietf.org/ID-Checklist.html
>
> -- Mark --
>
> http://panda.com/mrc
> Democracy is two wolves and a sheep deciding what to eat for lunch.
> Liberty is a well-armed sheep contesting the vote.
>

Subject: Re: WG Last Call of LISTEXT draft 14
From: Timo Sirainen <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: Dave Cridland <[email-masked]>, Arnaud Taddei <[email-masked]>, [email-masked]
Date: Fri, 06 Jan 2006 20:19:44 +0200
Sender: [email-masked]

--=-7j3T5NuLEOyW1N002O8T
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Fri, 2006-01-06 at 09:27 -0800, Mark Crispin wrote:
> > It's defined, or rather isn't, in RFC3501. Its meaning is that the mail=
box=20
> > has been marked in some way by the server because it is, in some way,=20
> > interesting. In practise, this can mean that there are recent messages,=
 but=20
> > its absence doesn't mean there are no recent messages, making it fairly=
=20
> > useless.
>=20
> Say what???
>=20
> If a mailbox has recent messages, and the mailbox does not have \Marked=20
> status, then it's a bug in the server.

Isn't this rather ".., and the mailbox has \UnMarked status, .."?

Calculating \Marked and \UnMarked is too expensive to do with maildir,
so I'm not returning either with it.

Also the way UW-IMAP handles this with mboxes breaks immediately once
non-c-client based MUA opens the mailbox. Does this mean UW-IMAP is also
buggy since the exact behavior you described can happen with it?

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

--=-7j3T5NuLEOyW1N002O8T--

Date: Fri, 6 Jan 2006 09:30:18 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Arnaud Taddei <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Need a template to start a draft
Sender: [email-masked]

On Fri, 6 Jan 2006, Arnaud Taddei wrote:
> Where can I find a template to start a draft? What are you guys using?

Start with http://www.ietf.org/ID-Checklist.html

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Fri, 6 Jan 2006 09:27:34 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: Arnaud Taddei <[email-masked]>, [email-masked]
Subject: Re: WG Last Call of LISTEXT draft 14
Sender: [email-masked]

On Fri, 6 Jan 2006, Dave Cridland wrote:
> I implement Mailbox Referrals in my client, and Cyrus IMAP implements it in 
> the server. I think Mulberry implements it client-side too.

Pine implements it client-side, and UW imapd implements it server side.

> It's defined, or rather isn't, in RFC3501. Its meaning is that the mailbox 
> has been marked in some way by the server because it is, in some way, 
> interesting. In practise, this can mean that there are recent messages, but 
> its absence doesn't mean there are no recent messages, making it fairly 
> useless.

Say what???

If a mailbox has recent messages, and the mailbox does not have \Marked 
status, then it's a bug in the server.

I am, by the way, as a matter of principle opposed to protocol extensions 
that attempt to amend broken servers.  A server that can't do the base 
protocol right is not going to do the extensions right either.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Fri, 06 Jan 2006 16:39:18 +0100
From: Arnaud Taddei <[email-masked]>
Subject: Re: Support for IMAP LOGIN referrals (RFC2221)
To: Edward Hibbert <[email-masked]>
Cc: Mark Crispin <[email-masked]>, [email-masked]
Sender: [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_m22D77q3V1AmHUIMXnNLVQ)
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT

Edward Hibbert wrote:

> From my point of view, the most interesting IMAP clients are those 
> which are most widely deployed :-).
>
> The following link from Microsoft contains a claim that most IMAP 
> clients don't support referrals:
>
> http://tinyurl.com/9yyf3
>
> Which I think I'll take as indicating that Microsoft clients don't. 
>
> Shame, I was hoping to use referrals.  But if Microsoft clients don't 
> support it, that's not an option.
>
Some IMAP servers do support distributed shared/public folders without 
the need for the login/mailbox referrals.

A direction I would hope would be considered more widely to help keeping 
the protocol simple.

A++

>
> Regards,
>
> Edward.
>
> -----Original Message-----
> From: [email-masked] on behalf of Mark Crispin
> Sent: Fri 16/12/2005 16:46
> To: Edward Hibbert
> Cc: [email-masked]
> Subject: RE: Support for IMAP LOGIN referrals (RFC2221)
>
> On Fri, 16 Dec 2005, Edward Hibbert wrote:
> > What about common clients like Thunderbird, Outlook, Outlook Express?
>
> For understandable reasons, Microsoft never uses open source software
> (other than open source software that it developed) as a matter of policy.
> Outlook and OE *may* support login referrals, though, as Microsoft was one
> of the instigators for referrals.
>
> I don't know what Thunderbird uses, but I doubt that it uses c-client.
>
> I don't consider any of these three to be particularly interesting as IMAP
> clients.  There are much better IMAP clients out there, and most of those
> are open source.
>
> -- Mark --
>
> http://panda.com/mrc
> Democracy is two wolves and a sheep deciding what to eat for lunch.
> Liberty is a well-armed sheep contesting the vote.
>

--Boundary_(ID_m22D77q3V1AmHUIMXnNLVQ)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Edward Hibbert wrote:
<blockquote
 cite="[email-masked]"
 type="cite">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta name="Generator" content="MS Exchange Server version 6.5.7638.1">
  <title>RE: Support for IMAP LOGIN referrals (RFC2221)</title>
<!-- Converted from text/plain format -->
  <p><font size="2">From my point of view, the most interesting IMAP
clients are those which are most widely deployed :-).<br>
  <br>
The following link from Microsoft contains a claim that most IMAP
clients don't support referrals:<br>
  <br>
  <a href="http://tinyurl.com/9yyf3">http://tinyurl.com/9yyf3</a><br>
  <br>
Which I think I'll take as indicating that Microsoft clients don't.&nbsp;<br>
  <br>
Shame, I was hoping to use referrals.&nbsp; But if Microsoft clients don't
support it, that's not an option.<br>
  </font></p>
</blockquote>
Some IMAP servers do support distributed shared/public folders without
the need for the login/mailbox referrals. <br>
<br>
A direction I would hope would be considered more widely to help
keeping the protocol simple.<br>
<br>
A++<br>
<blockquote
 cite="[email-masked]"
 type="cite">
  <p><font size="2"><br>
Regards,<br>
  <br>
Edward.<br>
  <br>
-----Original Message-----<br>
From: <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a> on behalf of Mark Crispin<br>
Sent: Fri 16/12/2005 16:46<br>
To: Edward Hibbert<br>
Cc: <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a><br>
Subject: RE: Support for IMAP LOGIN referrals (RFC2221)<br>
  <br>
On Fri, 16 Dec 2005, Edward Hibbert wrote:<br>
&gt; What about common clients like Thunderbird, Outlook, Outlook
Express?<br>
  <br>
For understandable reasons, Microsoft never uses open source software<br>
(other than open source software that it developed) as a matter of
policy.<br>
Outlook and OE *may* support login referrals, though, as Microsoft was
one<br>
of the instigators for referrals.<br>
  <br>
I don't know what Thunderbird uses, but I doubt that it uses c-client.<br>
  <br>
I don't consider any of these three to be particularly interesting as
IMAP<br>
clients.&nbsp; There are much better IMAP clients out there, and most of
those<br>
are open source.<br>
  <br>
-- Mark --<br>
  <br>
  <a href="http://panda.com/mrc">http://panda.com/mrc</a><br>
Democracy is two wolves and a sheep deciding what to eat for lunch.<br>
Liberty is a well-armed sheep contesting the vote.<br>
  <br>
  </font>
  </p>
</blockquote>
<br>
</body>
</html>

--Boundary_(ID_m22D77q3V1AmHUIMXnNLVQ)--

Date: Fri, 06 Jan 2006 14:26:50 +0000
Subject: Re: I-D ACTION:draft-ietf-imapext-condstore-08.txt
From: Dave Cridland <[email-masked]>
To: Alexandros Vellis <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Fri Jan  6 14:19:27 2006, Alexandros Vellis wrote:
> 
> Ken Murchison wrote:
> 
> > > 	Filename	: draft-ietf-imapext-condstore-08.txt
> > What changed?
> 
> I like the ISOC site for diffs:
> 
> http://ietfreport.isoc.org/idref/draft-ietf-imapext-condstore/
> 
> Click on 'diff' next to draft-ietf-imapext-condstore-07.txt.

Or there's the tool site, which I think is nicer.

http://tools.ietf.org/wg/imapext/draft-ietf-imapext-condstore/draft-ietf-imapext-condstore-08-from-07.diff.html

This shows me that SORT has been dropped, presumably to get to RFC 
status faster.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Subject: Re: I-D ACTION:draft-ietf-imapext-condstore-08.txt
From: Alexandros Vellis <[email-masked]>
To: [email-masked]
Organization: National & Kapodistrian University of Athens
Date: Fri, 06 Jan 2006 16:19:27 +0200
Sender: [email-masked]

Ken Murchison wrote:

> > 	Filename	: draft-ietf-imapext-condstore-08.txt
> What changed?

I like the ISOC site for diffs:

http://ietfreport.isoc.org/idref/draft-ietf-imapext-condstore/

Click on 'diff' next to draft-ietf-imapext-condstore-07.txt.

Cheers,
Alexandros

Date: Fri, 06 Jan 2006 15:05:36 +0100
From: Arnaud Taddei <[email-masked]>
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
To: Barry Leiba <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

>We put in multiple mailbox patterns because we wanted the flexibility,
>and we wanted consistent syntax with other commands, such as an
>extended SEARCH, which could certainly want to use that (and consider
>that someone had suggested using extended LIST itself as an extended
>SEARCH).  If consensus is that it's unnecessary and too complicated, we
>can pull out the multiple patterns for LIST, at the expense of not
>having the consistent syntax.
>  
>
The multiple mailbox patterns is extremely important for when you need 
to keep 2 IMAP servers synchronizing a selection of their 
(shared/public) folders so I vote for keeping this by all means.

A++

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

Date: Fri, 06 Jan 2006 14:03:06 +0000
Subject: Re: WG Last Call of LISTEXT draft 14
From: Dave Cridland <[email-masked]>
To: Arnaud Taddei <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Fri Jan  6 10:20:55 2006, Arnaud Taddei wrote:
> In addition to this different approach I see the following issues 
> in the document:
> 
>    * I disagree in the abstract on the Mailbox Referrals mention. No
>      one implements it even not Microsoft correct? I think there are
>      much more important issues to be covered in the abstract

I implement Mailbox Referrals in my client, and Cyrus IMAP implements 
it in the server. I think Mulberry implements it client-side too. 
In any case, the mention here is illustrating that its addition 
forces additional duplicate commands such as RLIST, RLSUB, etc, and I 
think that's justified.

>    * I have a problem (which is surely my Frenglish) to understand 
> 'or
>      any combination of therof', I don't scan the word therof.

That's page 6 section 3 paragraph two. Should be "any combination 
thereof".

>    * Page 9 on the paragraph for REMOTE, the 3 last lines are really
>      some byzantinism that is really a pain to explain 
> operationally.
>      Could we favor eliminating exceptions and enhancing protocol
>      readability?

It was tricky to explain at all. The nature of what's wrong with 
REMOTE RECURSIVEMATCH isn't echoed fully in the subsection on 
RECURSIVEMATCH, incidentally.

>    * Page 14, paragraph \HasChildren, I think I disagree with the
>      security perspective

Rereading this section, I note that "the server MUST return these 
attributes", but "a server MAY exclude both the [...] attributes".

>    * Page 16, I am not familiar with the \Marked in example 2. What
>      does this attribute mean? Where is it defined?

It's defined, or rather isn't, in RFC3501. Its meaning is that the 
mailbox has been marked in some way by the server because it is, in 
some way, interesting. In practise, this can mean that there are 
recent messages, but its absence doesn't mean there are no recent 
messages, making it fairly useless.

>    * Page 17, I think Example 6 requires much more explanations

I think I see why. Could you suggest some alternate text for 
explaining both example 5 and example 6? (I should think both would 
need to be changed to express the difference more clearly).

>    * Page 26, I am not comfortable with the comment on ACAP at the
>      beginning of section 6

If you'd like to implement both client and server fully, then we can 
move it to draft. :-)

>    * Page 30, at the end I dsiagree with the Security statement here

No, this is a security concern, and should be addressed by 
implementors.

>    * Page 34, the registration number 3 is almost a duplicate of
>      registration number 1, you want to remove one or the other.
> 
> 
No, one is selection, one is return. They're different things, but 
have the same name.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Fri, 06 Jan 2006 12:55:49 +0100
From: Arnaud Taddei <[email-masked]>
Subject: Need a template to start a draft
To: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

Where can I find a template to start a draft? What are you guys using?

I need to put the mapping of ACLs between MS Exchange proprietary 
authorization model and IMAP ACLs. This is important for coexistence 
situations and others. This document will allow as well to review the 
semantics we have and we don't have.

All the content was developed I just need to 'translate' it into the 
appropriate IETF format.

A++

Date: Fri, 06 Jan 2006 12:52:33 +0100
From: Arnaud Taddei <[email-masked]>
Subject: Re: WG Last Call of LISTEXT draft 14
To: Arnaud Taddei <[email-masked]>
Cc: Lisa Dusseault <[email-masked]>, Chris Newman <[email-masked]>, Philip Guenther <[email-masked]>, Dave Cridland <[email-masked]>, IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_iGAP5wAIo/IFwTBbRYYfNg)
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT

Arnaud Taddei wrote:

> I reviewed ACL, LISTEXT, ANNOTATEMORE and CONDSTORE. While I got 
> delayed several times in the past 4 weeks I accumulated hand written 
> remarks that I am going to share in several mail messages.
>
> Before I zoom on LISTEXT, I am generally having a very strange feeling 
> about these 4 extensions and I reallize that unfortunately I am coming 
> too late in the discussions.
>
> Sorry this mail will be long
>
> I am not sure how many of you are dealing with operational, deployment 
> and architectural issues in real customer sites but be aware that the 
> IETF stack of protocol, while it allows interoperability of solutions, 
> somehow, it too created an operational monster to implement and debug 
> if it is not just to explain to people in the field. With the level of 
> troops that exists today in the field, this leads me to say that I am 
> not sure that this point of view was kept in mind when writing these 
> extensions.
>
> My general impression is that somehow too many compromises were made 
> and some times not enough. Anyway I will elaborate step by step.
>
> Now zooming on LISTEXT, well well well. The model I had in mind for 
> LISTEXT is that:  what are folder collections: they are just a 'name 
> space' to organize data. This 'name space' is a static name space 
> (versus a VIEW) created by:
>
>     * System model, limits and constraints (for example for some
>       systems INBOX is a name space that doesn't have children, for
>       example shared and public folder name spaces)
>     * End users (end users create their own name space of folders)
>     * System administrators could create specific folder collections
>
> What is that LISTEXT say is that it wants to treat the properties of 
> the folders in this name space (remote, subscribed, exists, has kids, 
> has no kids, etc.).
>
> What is that ANNOTATEMORE say is that folders (and even the server) 
> can have more properties than those ones, for example comment, motd, 
> content-language, etc.)
>
> What I have in mind is that a name-space can be represented exactly 
> like the DIT of an LDAP server.
>
>     * you have root folders
>     * they have or not a tree below them
>     * nodes (in our case folders) are represented by a distinguished
>       name that we call the MUTF-7 folder name
>     * nodes contain properties that are called attribute that have
>       meta properties (Single-valued, multi-valued, are present or
>       not, etc.)
>     * and attributes for our folders are remote, subscribed, exists,
>       has kids, has ACLs, is sharing flags or not, has customisable
>       permanent flags or not, and the NAME itself, etc. etc. etc.
>
>
> So what is LISTEXT if I  make an analogy with LDAP, LISTEXT is the 
> LDAPSEARCH.
>
> When we had to work on the co-existence of heterogeneous solutions we 
> had to deal with how to keep the synchronization of public and shared 
> folders between two systems. As a typical alien server for a site of 
> say 3000 users would already have 10'000 public folders, with as well 
> the idea that 15% of the total users folders are shared we faced a big 
> issue in migrations if we were not capable to keep communities of end 
> users seeing the same view of their data wether they were migrated or 
> not so we were asked to build a program to synchronize any folder 
> specified by customers.
>
> When performing this task it became obvious that we would need a model 
> to 'select' the folders for examples as sub branches in the tree of 
> folders. This lead us to design what we called the Folder Global 
> Specification (FGS) and to define a listing model like an LDAP search 
> which is composed of the following sequence of items in the search
>
> Search folders:
>
>     * which NAMESPACE:
>           o in which name space (i.e. in which NAMESPACE) should we
>             list the folders, in Private? In Shared? In Public? In
>             Usenet Newsgroups? Others? a Combination?
>     * which BASE:
>           o under which folder base (i.e. under which branch)
>           o For example should I want to search only those folders
>             below "Foo/Bar/Toto"
>           o The notion of search base exists already today obviously
>     * which SCOPE:
>           o Scope 0: should we stop at the node itself (just the branch),
>           o Scope 1: one level below the node
>           o Scope 2: all the branch below the specified folder base
>             which is equivalent to Recursive
>     * which FILTER:
>           o which question in terms of a boolean combination of
>             pattern match on attributes.
>           o Usually the filter is the name but there could be others
>             attributes in the filter, this is what you put with
>             LISTEXT with the options in the LIST command, in fact
>             these are part of a filter but the syntax is not unified
>     * and what do you want to RETURN:
>           o a list of attributes you want to return
>
> With this in mind a LIST command would look like:
>
> a1 LIST NAMESPACE=private BASE=("INBOX" "Fruit" "Sent") SCOPE=2  
> FILTER=(&(\Remote=1)(\Subsribed=1)(\Exists=1) )

And if you want to retrieve only the names and the subsribed you add:

a1 LIST NAMESPACE=private BASE=("INBOX" "Fruit" "Sent") SCOPE=2  
FILTER=(&(\Remote=1)(\Subsribed=1)(\Exists=1) ) ATTRS=(name subscribed)

A++

>
> And then we can unify and simplify the syntax in a model that too me 
> is proven and comes from an area where searching a 'name space' is the 
> basics.
>
> Not only that but it would allow to unify this command with 
> ANNOTATEMORE in a very simple manner because the filter would add 
> those attributes that GETANNOTATION is giving so we would have only 
> one command to:
>
>     * consider the folder space as a name space
>     * folders do have 'attributes'
>     * 'attributes' have meta properties such as single value, mutli
>       value, presence, etc.  and including attributes ACLs (which
>       eliminates the explicit .priv and .share model)
>     * we have a unified model to search folders
>
> I will come back on the CAPABILITY vs ANNOTATEMORE story later
>
> In addition to this different approach I see the following issues in 
> the document:
>
>     * I disagree in the abstract on the Mailbox Referrals mention. No
>       one implements it even not Microsoft correct? I think there are
>       much more important issues to be covered in the abstract
>     * I have a problem (which is surely my Frenglish) to understand
>       'or any combination of therof', I don't scan the word therof.
>     * Page 9 on the paragraph for REMOTE, the 3 last lines are really
>       some byzantinism that is really a pain to explain operationally.
>       Could we favor eliminating exceptions and enhancing protocol
>       readability?
>     * Page 14, paragraph \HasChildren, I think I disagree with the
>       security perspective
>     * Page 16, I am not familiar with the \Marked in example 2. What
>       does this attribute mean? Where is it defined?
>     * Page 17, I think Example 6 requires much more explanations
>     * Page 19, Example 8: typo: it should be demonstrate and not
>       demonstate, there is a missing r
>     * Page 26, I am not comfortable with the comment on ACAP at the
>       beginning of section 6
>     * Page 30, at the end I dsiagree with the Security statement here
>     * Page 32, first paragrapha very small typo: there is a space
>       between options/ extended, it should be options/extended to be
>       consistent with the others after
>     * Page 34, the registration number 3 is almost a duplicate of
>       registration number 1, you want to remove one or the other.
>
> Hope this helps anyway
>
> A++
>
> Lisa Dusseault wrote:
>
>>
>> We still haven't gotten enough review of LISTEXT during last call to  
>> finish it off.  Chris, Philip, Dave, you still need to review at 
>> least  the changes from the last time you reviewed or we'll need to 
>> find  another couple reviewers.  Arnt was the only one who posted his 
>> review  to the Last Call.
>>
>> Here's the -15 draft:  
>> <http://www.ietf.org/internet-drafts/draft-ietf-imapext-list- 
>> extensions-15.txt>
>>
>> And to make it really easy, here's the diff from -14
>> <http://tools.ietf.org/wg/imapext/draft-ietf-imapext-list-extensions/ 
>> draft-ietf-imapext-list-extensions-15-from-14.diff.html>
>>
>> Lisa
>>
>> On Nov 27, 2005, at 7:56 AM, Lisa Dusseault wrote:
>>
>>> "I love deadlines. I like the whooshing sound they make as they fly  
>>> by."
>>>     Douglas Adams
>>>
>>> Nobody commented during this last call period.  There were good  
>>> reviews when this was previously last-called, but I'd like to know  
>>> that the changes were reviewed. Chris Newman, Philip Guenther and 
>>> Dave  Cridland volunteered to look it over, so you guys need to get 
>>> back to  me.  Anybody else who reviewed the changes in LISTEXT since 
>>> draft -13,  let me know.
>>>
>>> Lisa
>>>
>>> On Oct 27, 2005, at 4:25 PM, Lisa Dusseault wrote:
>>>
>>>>
>>>> I call your attention to this draft:
>>>>
>>>> http://www.ietf.org/internet-drafts/draft-ietf-imapext-list- 
>>>> extensions-14.txt
>>>>
>>>> We previously did a WG last call in May 2005 but we decided for a  
>>>> "do-over" since there were a few significant changes.
>>>>
>>>> This document is the framework for much of the syntax we're doing 
>>>> in  other IMAPEXT tasks and is being referenced by other documents  
>>>> already, so it's important that it gets a good review.
>>>>
>>>> If you review it at all, or plan to implement, or have any opinion  
>>>> about standardizing this document, send mail to the WG list or at  
>>>> least to me.  Send me email even if you reviewed draft 13 and  
>>>> previously sent me email about that, to let me know if you have  
>>>> reviewed the changes in draft 14 and are OK with them.
>>>>
>>>> Because of the IETF meeting in a little over a week, let's do this  
>>>> last call until EOD Nov 17 (three weeks).  If you have any chance 
>>>> to  bring up issues before IMAPEXT meets on Tuesday Nov 8, that 
>>>> would be  much appreciated because it would give us an extra forum 
>>>> for  discussion.
>>>>
>>>> Thanks,
>>>>
>>>> Lisa
>>>>
>>>
>>
>

--Boundary_(ID_iGAP5wAIo/IFwTBbRYYfNg)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Arnaud Taddei wrote:
<blockquote cite="[email-masked]" type="cite">
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
I reviewed ACL, LISTEXT, ANNOTATEMORE and CONDSTORE. While I got
delayed several times in the past 4 weeks I accumulated hand written
remarks that I am going to share in several mail messages.<br>
  <br>
Before I zoom on LISTEXT, I am generally having a very strange feeling
about these 4 extensions and I reallize that unfortunately I am coming
too late in the discussions. <br>
  <br>
Sorry this mail will be long<br>
  <br>
I am not sure how many of you are dealing with operational, deployment
and architectural issues in real customer sites but be aware that the
IETF stack of protocol, while it allows interoperability of solutions,
somehow, it too created an operational monster to implement and debug
if it is not just to explain to people in the field. With the level of
troops that exists today in the field, this leads me to say that I am
not sure that this point of view was kept in mind when writing these
extensions. <br>
  <br>
My general impression is that somehow too many compromises were made
and some times not enough. Anyway I will elaborate step by step.<br>
  <br>
Now zooming on LISTEXT, well well well. The model I had in mind for
LISTEXT is that:&nbsp; what are folder collections: they are just a 'name
space' to organize data. This 'name space' is a static name space
(versus a VIEW) created by:<br>
  <ul>
    <li>System model, limits and constraints (for example for some
systems INBOX is a name space that doesn't have children, for example
shared and public folder name spaces)</li>
    <li>End users (end users create their own name space of folders)</li>
    <li>System administrators could create specific folder collections <br>
    </li>
  </ul>
What is that LISTEXT say is that it wants to treat the properties of
the folders in this name space (remote, subscribed, exists, has kids,
has no kids, etc.). <br>
  <br>
What is that ANNOTATEMORE say is that folders (and even the server) can
have more properties than those ones, for example comment, motd,
content-language, etc.)<br>
  <br>
What I have in mind is that a name-space can be represented exactly
like the DIT of an LDAP server. <br>
  <ul>
    <li>you have root folders</li>
    <li>they have or not a tree below them</li>
    <li>nodes (in our case folders) are represented by a distinguished
name that we call the MUTF-7 folder name</li>
    <li>nodes contain properties that are called attribute that have
meta
properties (Single-valued, multi-valued, are present or not, etc.) </li>
    <li>and attributes for our folders are remote, subscribed, exists,
has kids, has ACLs, is sharing flags or not, has customisable permanent
flags or not, and the NAME itself, etc. etc. etc.</li>
  </ul>
  <br>
So what is LISTEXT if I&nbsp; make an analogy with LDAP, LISTEXT is the
LDAPSEARCH.<br>
  <br>
When we had to work on the co-existence of heterogeneous solutions we
had to deal with how to keep the synchronization of public and shared
folders between two systems. As a typical alien server for a site of
say 3000 users would already have 10'000 public folders, with as well
the idea that 15% of the total users folders are shared we faced a big
issue in migrations if we were not capable to keep communities of end
users seeing the same view of their data wether they were migrated or
not so we were asked to build a program to synchronize any folder
specified by customers. <br>
  <br>
When performing this task it became obvious that we would need a model
to 'select' the folders for examples as sub branches in the tree of
folders. This lead us to design what we called the Folder Global
Specification (FGS) and to define a listing model like an LDAP search
which is composed of the following sequence of items in the search<br>
  <br>
Search folders:<br>
  <ul>
    <li>which NAMESPACE: <br>
    </li>
    <ul>
      <li>in which name space (i.e. in which NAMESPACE) should we list
the folders, in Private? In Shared? In Public? In Usenet Newsgroups?
Others? a Combination?<br>
      </li>
    </ul>
    <li>which BASE: <br>
    </li>
    <ul>
      <li>under which folder base (i.e. under which branch)</li>
      <li>For example should I want to search only those folders below
"Foo/Bar/Toto"</li>
      <li>The notion of search base exists already today obviously<br>
      </li>
    </ul>
    <li>which SCOPE: <br>
    </li>
    <ul>
      <li>Scope 0: should we stop at the node itself (just the branch),
        <br>
      </li>
      <li>Scope 1: one level below the node</li>
      <li>Scope 2: all the branch below the specified folder base which
is equivalent to Recursive<br>
      </li>
    </ul>
    <li>which FILTER: <br>
    </li>
    <ul>
      <li>which question in terms of a boolean combination of pattern
match on attributes. <br>
      </li>
      <li>Usually the filter is the name but there could be others
attributes in the filter, this is what you put with LISTEXT with the
options in the LIST command, in fact these are part of a filter but the
syntax is not unified<br>
      </li>
    </ul>
    <li>and what do you want to RETURN:</li>
    <ul>
      <li>a list of attributes you want to return</li>
    </ul>
  </ul>
With this in mind a LIST command would look like:<br>
  <br>
a1 LIST NAMESPACE=private BASE=("INBOX" "Fruit" "Sent") SCOPE=2&nbsp;
FILTER=(&amp;(\Remote=1)(\Subsribed=1)(\Exists=1) )<br>
</blockquote>
And if you want to retrieve only the names and the subsribed you add:<br>
<br>
a1 LIST NAMESPACE=private BASE=("INBOX" "Fruit" "Sent") SCOPE=2&nbsp;
FILTER=(&amp;(\Remote=1)(\Subsribed=1)(\Exists=1) ) ATTRS=(name
subscribed)<br>
<br>
A++<br>
<br>
<blockquote cite="[email-masked]" type="cite"><br>
And then we can unify and simplify the syntax in a model that too me is
proven and comes from an area where searching a 'name space' is the
basics. <br>
  <br>
Not only that but it would allow to unify this command with
ANNOTATEMORE in a very simple manner because the filter would add those
attributes that GETANNOTATION is giving so we would have only one
command to:<br>
  <ul>
    <li>consider the folder space as a name space</li>
    <li>folders do have 'attributes'</li>
    <li>'attributes' have meta properties such as single value, mutli
value, presence, etc.&nbsp; and including attributes ACLs (which eliminates
the explicit .priv and .share model)</li>
    <li>we have a unified model to search folders</li>
  </ul>
I will come back on the CAPABILITY vs ANNOTATEMORE story later<br>
  <br>
In addition to this different approach I see the following issues in
the document:<br>
  <ul>
    <li>I disagree in the abstract on the Mailbox Referrals mention. No
one implements it even not Microsoft correct? I think there are much
more important issues to be covered in the abstract</li>
    <li>I have a problem (which is surely my Frenglish) to understand
'or
any combination of therof', I don't scan the word therof.</li>
    <li>Page 9 on the paragraph for REMOTE, the 3 last lines are really
some byzantinism that is really a pain to explain operationally. Could
we favor eliminating exceptions and enhancing protocol readability?</li>
    <li>Page 14, paragraph \HasChildren, I think I disagree with the
security perspective</li>
    <li>Page 16, I am not familiar with the \Marked in example 2. What
does this attribute mean? Where is it defined?</li>
    <li>Page 17, I think Example 6 requires much more explanations</li>
    <li>Page 19, Example 8: typo: it should be demonstrate and not
demonstate, there is a missing r</li>
    <li>Page 26, I am not comfortable with the comment on ACAP at the
beginning of section 6</li>
    <li>Page 30, at the end I dsiagree with the Security statement here</li>
    <li>Page 32, first paragrapha very small typo: there is a space
between options/ extended, it should be options/extended to be
consistent with the others after</li>
    <li>Page 34, the registration number 3 is almost a duplicate of
registration number 1, you want to remove one or the other.</li>
  </ul>
Hope this helps anyway<br>
  <br>
A++<br>
  <br>
Lisa Dusseault wrote:
  <blockquote
 cite="[email-masked]"
 type="cite"><br>
We still haven't gotten enough review of LISTEXT during last call to&nbsp;
finish it off.&nbsp; Chris, Philip, Dave, you still need to review at least&nbsp;
the changes from the last time you reviewed or we'll need to find&nbsp;
another couple reviewers.&nbsp; Arnt was the only one who posted his review&nbsp;
to the Last Call. <br>
    <br>
Here's the -15 draft:&nbsp;
    <a class="moz-txt-link-rfc2396E"
 href="http://www.ietf.org/internet-drafts/draft-ietf-imapext-list-extensions-15.txt">&lt;http://www.ietf.org/internet-drafts/draft-ietf-imapext-list-
extensions-15.txt&gt;</a> <br>
    <br>
And to make it really easy, here's the diff from -14 <br>
    <a class="moz-txt-link-rfc2396E"
 href="http://tools.ietf.org/wg/imapext/draft-ietf-imapext-list-extensions/draft-ietf-imapext-list-extensions-15-from-14.diff.html">&lt;http://tools.ietf.org/wg/imapext/draft-ietf-imapext-list-extensions/
draft-ietf-imapext-list-extensions-15-from-14.diff.html&gt;</a> <br>
    <br>
Lisa <br>
    <br>
On Nov 27, 2005, at 7:56 AM, Lisa Dusseault wrote: <br>
    <br>
    <blockquote type="cite">"I love deadlines. I like the whooshing
sound
they make as they fly&nbsp; by." <br>
&nbsp;&nbsp;&nbsp; Douglas Adams <br>
      <br>
Nobody commented during this last call period.&nbsp; There were good&nbsp;
reviews when this was previously last-called, but I'd like to know&nbsp;
that the changes were reviewed. Chris Newman, Philip Guenther and Dave&nbsp;
Cridland volunteered to look it over, so you guys need to get back to&nbsp;
me.&nbsp; Anybody else who reviewed the changes in LISTEXT since draft -13,&nbsp;
let me know. <br>
      <br>
Lisa <br>
      <br>
On Oct 27, 2005, at 4:25 PM, Lisa Dusseault wrote: <br>
      <br>
      <blockquote type="cite"><br>
I call your attention to this draft: <br>
        <br>
        <a class="moz-txt-link-freetext"
 href="http://www.ietf.org/internet-drafts/draft-ietf-imapext-list">http://www.ietf.org/internet-drafts/draft-ietf-imapext-list</a>-
extensions-14.txt <br>
        <br>
We previously did a WG last call in May 2005 but we decided for a&nbsp;
"do-over" since there were a few significant changes. <br>
        <br>
This document is the framework for much of the syntax we're doing in&nbsp;
other IMAPEXT tasks and is being referenced by other documents&nbsp;
already, so it's important that it gets a good review. <br>
        <br>
If you review it at all, or plan to implement, or have any opinion&nbsp;
about standardizing this document, send mail to the WG list or at&nbsp;
least to me.&nbsp; Send me email even if you reviewed draft 13 and&nbsp;
previously sent me email about that, to let me know if you have&nbsp;
reviewed the changes in draft 14 and are OK with them. <br>
        <br>
Because of the IETF meeting in a little over a week, let's do this&nbsp;
last call until EOD Nov 17 (three weeks).&nbsp; If you have any chance to&nbsp;
bring up issues before IMAPEXT meets on Tuesday Nov 8, that would be&nbsp;
much appreciated because it would give us an extra forum for&nbsp;
discussion. <br>
        <br>
Thanks, <br>
        <br>
Lisa <br>
        <br>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </blockquote>
  <br>
</blockquote>
<br>
</body>
</html>

--Boundary_(ID_iGAP5wAIo/IFwTBbRYYfNg)--

Date: Fri, 06 Jan 2006 11:20:55 +0100
From: Arnaud Taddei <[email-masked]>
Subject: Re: WG Last Call of LISTEXT draft 14
To: Lisa Dusseault <[email-masked]>
Cc: Chris Newman <[email-masked]>, Philip Guenther <[email-masked]>, Dave Cridland <[email-masked]>, IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_nYat8m/V8fsv+U1bIIQs/A)
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT

I reviewed ACL, LISTEXT, ANNOTATEMORE and CONDSTORE. While I got delayed 
several times in the past 4 weeks I accumulated hand written remarks 
that I am going to share in several mail messages.

Before I zoom on LISTEXT, I am generally having a very strange feeling 
about these 4 extensions and I reallize that unfortunately I am coming 
too late in the discussions.

Sorry this mail will be long

I am not sure how many of you are dealing with operational, deployment 
and architectural issues in real customer sites but be aware that the 
IETF stack of protocol, while it allows interoperability of solutions, 
somehow, it too created an operational monster to implement and debug if 
it is not just to explain to people in the field. With the level of 
troops that exists today in the field, this leads me to say that I am 
not sure that this point of view was kept in mind when writing these 
extensions.

My general impression is that somehow too many compromises were made and 
some times not enough. Anyway I will elaborate step by step.

Now zooming on LISTEXT, well well well. The model I had in mind for 
LISTEXT is that:  what are folder collections: they are just a 'name 
space' to organize data. This 'name space' is a static name space 
(versus a VIEW) created by:

    * System model, limits and constraints (for example for some systems
      INBOX is a name space that doesn't have children, for example
      shared and public folder name spaces)
    * End users (end users create their own name space of folders)
    * System administrators could create specific folder collections

What is that LISTEXT say is that it wants to treat the properties of the 
folders in this name space (remote, subscribed, exists, has kids, has no 
kids, etc.).

What is that ANNOTATEMORE say is that folders (and even the server) can 
have more properties than those ones, for example comment, motd, 
content-language, etc.)

What I have in mind is that a name-space can be represented exactly like 
the DIT of an LDAP server.

    * you have root folders
    * they have or not a tree below them
    * nodes (in our case folders) are represented by a distinguished
      name that we call the MUTF-7 folder name
    * nodes contain properties that are called attribute that have meta
      properties (Single-valued, multi-valued, are present or not, etc.)
    * and attributes for our folders are remote, subscribed, exists, has
      kids, has ACLs, is sharing flags or not, has customisable
      permanent flags or not, and the NAME itself, etc. etc. etc.

So what is LISTEXT if I  make an analogy with LDAP, LISTEXT is the 
LDAPSEARCH.

When we had to work on the co-existence of heterogeneous solutions we 
had to deal with how to keep the synchronization of public and shared 
folders between two systems. As a typical alien server for a site of say 
3000 users would already have 10'000 public folders, with as well the 
idea that 15% of the total users folders are shared we faced a big issue 
in migrations if we were not capable to keep communities of end users 
seeing the same view of their data wether they were migrated or not so 
we were asked to build a program to synchronize any folder specified by 
customers.

When performing this task it became obvious that we would need a model 
to 'select' the folders for examples as sub branches in the tree of 
folders. This lead us to design what we called the Folder Global 
Specification (FGS) and to define a listing model like an LDAP search 
which is composed of the following sequence of items in the search

Search folders:

    * which NAMESPACE:
          o in which name space (i.e. in which NAMESPACE) should we list
            the folders, in Private? In Shared? In Public? In Usenet
            Newsgroups? Others? a Combination?
    * which BASE:
          o under which folder base (i.e. under which branch)
          o For example should I want to search only those folders below
            "Foo/Bar/Toto"
          o The notion of search base exists already today obviously
    * which SCOPE:
          o Scope 0: should we stop at the node itself (just the branch),
          o Scope 1: one level below the node
          o Scope 2: all the branch below the specified folder base
            which is equivalent to Recursive
    * which FILTER:
          o which question in terms of a boolean combination of pattern
            match on attributes.
          o Usually the filter is the name but there could be others
            attributes in the filter, this is what you put with LISTEXT
            with the options in the LIST command, in fact these are part
            of a filter but the syntax is not unified
    * and what do you want to RETURN:
          o a list of attributes you want to return

With this in mind a LIST command would look like:

a1 LIST NAMESPACE=private BASE=("INBOX" "Fruit" "Sent") SCOPE=2  
FILTER=(&(\Remote=1)(\Subsribed=1)(\Exists=1) )

And then we can unify and simplify the syntax in a model that too me is 
proven and comes from an area where searching a 'name space' is the basics.

Not only that but it would allow to unify this command with ANNOTATEMORE 
in a very simple manner because the filter would add those attributes 
that GETANNOTATION is giving so we would have only one command to:

    * consider the folder space as a name space
    * folders do have 'attributes'
    * 'attributes' have meta properties such as single value, mutli
      value, presence, etc.  and including attributes ACLs (which
      eliminates the explicit .priv and .share model)
    * we have a unified model to search folders

I will come back on the CAPABILITY vs ANNOTATEMORE story later

In addition to this different approach I see the following issues in the 
document:

    * I disagree in the abstract on the Mailbox Referrals mention. No
      one implements it even not Microsoft correct? I think there are
      much more important issues to be covered in the abstract
    * I have a problem (which is surely my Frenglish) to understand 'or
      any combination of therof', I don't scan the word therof.
    * Page 9 on the paragraph for REMOTE, the 3 last lines are really
      some byzantinism that is really a pain to explain operationally.
      Could we favor eliminating exceptions and enhancing protocol
      readability?
    * Page 14, paragraph \HasChildren, I think I disagree with the
      security perspective
    * Page 16, I am not familiar with the \Marked in example 2. What
      does this attribute mean? Where is it defined?
    * Page 17, I think Example 6 requires much more explanations
    * Page 19, Example 8: typo: it should be demonstrate and not
      demonstate, there is a missing r
    * Page 26, I am not comfortable with the comment on ACAP at the
      beginning of section 6
    * Page 30, at the end I dsiagree with the Security statement here
    * Page 32, first paragrapha very small typo: there is a space
      between options/ extended, it should be options/extended to be
      consistent with the others after
    * Page 34, the registration number 3 is almost a duplicate of
      registration number 1, you want to remove one or the other.

Hope this helps anyway

A++

Lisa Dusseault wrote:

>
> We still haven't gotten enough review of LISTEXT during last call to  
> finish it off.  Chris, Philip, Dave, you still need to review at 
> least  the changes from the last time you reviewed or we'll need to 
> find  another couple reviewers.  Arnt was the only one who posted his 
> review  to the Last Call.
>
> Here's the -15 draft:  
> <http://www.ietf.org/internet-drafts/draft-ietf-imapext-list- 
> extensions-15.txt>
>
> And to make it really easy, here's the diff from -14
> <http://tools.ietf.org/wg/imapext/draft-ietf-imapext-list-extensions/ 
> draft-ietf-imapext-list-extensions-15-from-14.diff.html>
>
> Lisa
>
> On Nov 27, 2005, at 7:56 AM, Lisa Dusseault wrote:
>
>> "I love deadlines. I like the whooshing sound they make as they fly  
>> by."
>>     Douglas Adams
>>
>> Nobody commented during this last call period.  There were good  
>> reviews when this was previously last-called, but I'd like to know  
>> that the changes were reviewed. Chris Newman, Philip Guenther and 
>> Dave  Cridland volunteered to look it over, so you guys need to get 
>> back to  me.  Anybody else who reviewed the changes in LISTEXT since 
>> draft -13,  let me know.
>>
>> Lisa
>>
>> On Oct 27, 2005, at 4:25 PM, Lisa Dusseault wrote:
>>
>>>
>>> I call your attention to this draft:
>>>
>>> http://www.ietf.org/internet-drafts/draft-ietf-imapext-list- 
>>> extensions-14.txt
>>>
>>> We previously did a WG last call in May 2005 but we decided for a  
>>> "do-over" since there were a few significant changes.
>>>
>>> This document is the framework for much of the syntax we're doing 
>>> in  other IMAPEXT tasks and is being referenced by other documents  
>>> already, so it's important that it gets a good review.
>>>
>>> If you review it at all, or plan to implement, or have any opinion  
>>> about standardizing this document, send mail to the WG list or at  
>>> least to me.  Send me email even if you reviewed draft 13 and  
>>> previously sent me email about that, to let me know if you have  
>>> reviewed the changes in draft 14 and are OK with them.
>>>
>>> Because of the IETF meeting in a little over a week, let's do this  
>>> last call until EOD Nov 17 (three weeks).  If you have any chance 
>>> to  bring up issues before IMAPEXT meets on Tuesday Nov 8, that 
>>> would be  much appreciated because it would give us an extra forum 
>>> for  discussion.
>>>
>>> Thanks,
>>>
>>> Lisa
>>>
>>
>

--Boundary_(ID_nYat8m/V8fsv+U1bIIQs/A)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
I reviewed ACL, LISTEXT, ANNOTATEMORE and CONDSTORE. While I got
delayed several times in the past 4 weeks I accumulated hand written
remarks that I am going to share in several mail messages.<br>
<br>
Before I zoom on LISTEXT, I am generally having a very strange feeling
about these 4 extensions and I reallize that unfortunately I am coming
too late in the discussions. <br>
<br>
Sorry this mail will be long<br>
<br>
I am not sure how many of you are dealing with operational, deployment
and architectural issues in real customer sites but be aware that the
IETF stack of protocol, while it allows interoperability of solutions,
somehow, it too created an operational monster to implement and debug
if it is not just to explain to people in the field. With the level of
troops that exists today in the field, this leads me to say that I am
not sure that this point of view was kept in mind when writing these
extensions. <br>
<br>
My general impression is that somehow too many compromises were made
and some times not enough. Anyway I will elaborate step by step.<br>
<br>
Now zooming on LISTEXT, well well well. The model I had in mind for
LISTEXT is that:&nbsp; what are folder collections: they are just a 'name
space' to organize data. This 'name space' is a static name space
(versus a VIEW) created by:<br>
<ul>
  <li>System model, limits and constraints (for example for some
systems INBOX is a name space that doesn't have children, for example
shared and public folder name spaces)</li>
  <li>End users (end users create their own name space of folders)</li>
  <li>System administrators could create specific folder collections <br>
  </li>
</ul>
What is that LISTEXT say is that it wants to treat the properties of
the folders in this name space (remote, subscribed, exists, has kids,
has no kids, etc.). <br>
<br>
What is that ANNOTATEMORE say is that folders (and even the server) can
have more properties than those ones, for example comment, motd,
content-language, etc.)<br>
<br>
What I have in mind is that a name-space can be represented exactly
like the DIT of an LDAP server. <br>
<ul>
  <li>you have root folders</li>
  <li>they have or not a tree below them</li>
  <li>nodes (in our case folders) are represented by a distinguished
name that we call the MUTF-7 folder name</li>
  <li>nodes contain properties that are called attribute that have meta
properties (Single-valued, multi-valued, are present or not, etc.) </li>
  <li>and attributes for our folders are remote, subscribed, exists,
has kids, has ACLs, is sharing flags or not, has customisable permanent
flags or not, and the NAME itself, etc. etc. etc.</li>
</ul>
<br>
So what is LISTEXT if I&nbsp; make an analogy with LDAP, LISTEXT is the
LDAPSEARCH.<br>
<br>
When we had to work on the co-existence of heterogeneous solutions we
had to deal with how to keep the synchronization of public and shared
folders between two systems. As a typical alien server for a site of
say 3000 users would already have 10'000 public folders, with as well
the idea that 15% of the total users folders are shared we faced a big
issue in migrations if we were not capable to keep communities of end
users seeing the same view of their data wether they were migrated or
not so we were asked to build a program to synchronize any folder
specified by customers. <br>
<br>
When performing this task it became obvious that we would need a model
to 'select' the folders for examples as sub branches in the tree of
folders. This lead us to design what we called the Folder Global
Specification (FGS) and to define a listing model like an LDAP search
which is composed of the following sequence of items in the search<br>
<br>
Search folders:<br>
<ul>
  <li>which NAMESPACE: <br>
  </li>
  <ul>
    <li>in which name space (i.e. in which NAMESPACE) should we list
the folders, in Private? In Shared? In Public? In Usenet Newsgroups?
Others? a Combination?<br>
    </li>
  </ul>
  <li>which BASE: <br>
  </li>
  <ul>
    <li>under which folder base (i.e. under which branch)</li>
    <li>For example should I want to search only those folders below
"Foo/Bar/Toto"</li>
    <li>The notion of search base exists already today obviously<br>
    </li>
  </ul>
  <li>which SCOPE: <br>
  </li>
  <ul>
    <li>Scope 0: should we stop at the node itself (just the branch), <br>
    </li>
    <li>Scope 1: one level below the node</li>
    <li>Scope 2: all the branch below the specified folder base which
is equivalent to Recursive<br>
    </li>
  </ul>
  <li>which FILTER: <br>
  </li>
  <ul>
    <li>which question in terms of a boolean combination of pattern
match on attributes. <br>
    </li>
    <li>Usually the filter is the name but there could be others
attributes in the filter, this is what you put with LISTEXT with the
options in the LIST command, in fact these are part of a filter but the
syntax is not unified<br>
    </li>
  </ul>
  <li>and what do you want to RETURN:</li>
  <ul>
    <li>a list of attributes you want to return</li>
  </ul>
</ul>
With this in mind a LIST command would look like:<br>
<br>
a1 LIST NAMESPACE=private BASE=("INBOX" "Fruit" "Sent") SCOPE=2&nbsp;
FILTER=(&amp;(\Remote=1)(\Subsribed=1)(\Exists=1) )<br>
<br>
And then we can unify and simplify the syntax in a model that too me is
proven and comes from an area where searching a 'name space' is the
basics. <br>
<br>
Not only that but it would allow to unify this command with
ANNOTATEMORE in a very simple manner because the filter would add those
attributes that GETANNOTATION is giving so we would have only one
command to:<br>
<ul>
  <li>consider the folder space as a name space</li>
  <li>folders do have 'attributes'</li>
  <li>'attributes' have meta properties such as single value, mutli
value, presence, etc.&nbsp; and including attributes ACLs (which eliminates
the explicit .priv and .share model)</li>
  <li>we have a unified model to search folders</li>
</ul>
I will come back on the CAPABILITY vs ANNOTATEMORE story later<br>
<br>
In addition to this different approach I see the following issues in
the document:<br>
<ul>
  <li>I disagree in the abstract on the Mailbox Referrals mention. No
one implements it even not Microsoft correct? I think there are much
more important issues to be covered in the abstract</li>
  <li>I have a problem (which is surely my Frenglish) to understand 'or
any combination of therof', I don't scan the word therof.</li>
  <li>Page 9 on the paragraph for REMOTE, the 3 last lines are really
some byzantinism that is really a pain to explain operationally. Could
we favor eliminating exceptions and enhancing protocol readability?</li>
  <li>Page 14, paragraph \HasChildren, I think I disagree with the
security perspective</li>
  <li>Page 16, I am not familiar with the \Marked in example 2. What
does this attribute mean? Where is it defined?</li>
  <li>Page 17, I think Example 6 requires much more explanations</li>
  <li>Page 19, Example 8: typo: it should be demonstrate and not
demonstate, there is a missing r</li>
  <li>Page 26, I am not comfortable with the comment on ACAP at the
beginning of section 6</li>
  <li>Page 30, at the end I dsiagree with the Security statement here</li>
  <li>Page 32, first paragrapha very small typo: there is a space
between options/ extended, it should be options/extended to be
consistent with the others after</li>
  <li>Page 34, the registration number 3 is almost a duplicate of
registration number 1, you want to remove one or the other.</li>
</ul>
Hope this helps anyway<br>
<br>
A++<br>
<br>
Lisa Dusseault wrote:
<blockquote cite="[email-masked]"
 type="cite"><br>
We still haven't gotten enough review of LISTEXT during last call to&nbsp;
finish it off.&nbsp; Chris, Philip, Dave, you still need to review at least&nbsp;
the changes from the last time you reviewed or we'll need to find&nbsp;
another couple reviewers.&nbsp; Arnt was the only one who posted his review&nbsp;
to the Last Call.
  <br>
  <br>
Here's the -15 draft:&nbsp;
<a class="moz-txt-link-rfc2396E" href="http://www.ietf.org/internet-drafts/draft-ietf-imapext-list-extensions-15.txt">&lt;http://www.ietf.org/internet-drafts/draft-ietf-imapext-list-
extensions-15.txt&gt;</a>
  <br>
  <br>
And to make it really easy, here's the diff from -14
  <br>
<a class="moz-txt-link-rfc2396E" href="http://tools.ietf.org/wg/imapext/draft-ietf-imapext-list-extensions/draft-ietf-imapext-list-extensions-15-from-14.diff.html">&lt;http://tools.ietf.org/wg/imapext/draft-ietf-imapext-list-extensions/
draft-ietf-imapext-list-extensions-15-from-14.diff.html&gt;</a>
  <br>
  <br>
Lisa
  <br>
  <br>
On Nov 27, 2005, at 7:56 AM, Lisa Dusseault wrote:
  <br>
  <br>
  <blockquote type="cite">"I love deadlines. I like the whooshing sound
they make as they fly&nbsp; by."
    <br>
&nbsp;&nbsp;&nbsp; Douglas Adams
    <br>
    <br>
Nobody commented during this last call period.&nbsp; There were good&nbsp;
reviews when this was previously last-called, but I'd like to know&nbsp;
that the changes were reviewed. Chris Newman, Philip Guenther and Dave&nbsp;
Cridland volunteered to look it over, so you guys need to get back to&nbsp;
me.&nbsp; Anybody else who reviewed the changes in LISTEXT since draft -13,&nbsp;
let me know.
    <br>
    <br>
Lisa
    <br>
    <br>
On Oct 27, 2005, at 4:25 PM, Lisa Dusseault wrote:
    <br>
    <br>
    <blockquote type="cite"><br>
I call your attention to this draft:
      <br>
      <br>
<a class="moz-txt-link-freetext" href="http://www.ietf.org/internet-drafts/draft-ietf-imapext-list">http://www.ietf.org/internet-drafts/draft-ietf-imapext-list</a>-
extensions-14.txt
      <br>
      <br>
We previously did a WG last call in May 2005 but we decided for a&nbsp;
"do-over" since there were a few significant changes.
      <br>
      <br>
This document is the framework for much of the syntax we're doing in&nbsp;
other IMAPEXT tasks and is being referenced by other documents&nbsp;
already, so it's important that it gets a good review.
      <br>
      <br>
If you review it at all, or plan to implement, or have any opinion&nbsp;
about standardizing this document, send mail to the WG list or at&nbsp;
least to me.&nbsp; Send me email even if you reviewed draft 13 and&nbsp;
previously sent me email about that, to let me know if you have&nbsp;
reviewed the changes in draft 14 and are OK with them.
      <br>
      <br>
Because of the IETF meeting in a little over a week, let's do this&nbsp;
last call until EOD Nov 17 (three weeks).&nbsp; If you have any chance to&nbsp;
bring up issues before IMAPEXT meets on Tuesday Nov 8, that would be&nbsp;
much appreciated because it would give us an extra forum for&nbsp;
discussion.
      <br>
      <br>
Thanks,
      <br>
      <br>
Lisa
      <br>
      <br>
    </blockquote>
    <br>
  </blockquote>
  <br>
</blockquote>
<br>
</body>
</html>

--Boundary_(ID_nYat8m/V8fsv+U1bIIQs/A)--

Date: Thu, 05 Jan 2006 21:18:19 +0000
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
From: Dave Cridland <[email-masked]>
To: Barry Leiba <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Thu Jan  5 13:50:43 2006, Barry Leiba wrote:
> 
> Hoo... I'm glad this came up again when Lisa put her "nag" message 
> up
> -- since I don't care about ACL, I never read the mislabelled 
> review of
> LISTEXT.
> 
> 
Yup. If I'd changed the subject line from the nag in the ACL message, 
it'd have been more clever.

> > 1) I found the ABNF strikingly difficult to follow.
> 
> Ya, I get that.  I'm not sure what to do about it, though.  It 
> started
> simply, but it complexificatalized quickly.  I'm not happy about 
> that,
> but the complexity is partly diven by the demand to have it be
> machine-parsable in as much of its detail as possible, rather than
> leaving some of that detail to human-readable explanation (take, for
> example, the bits about which combinations of options can be used).
> 
> 
Yes, hence my "this is largely because it's complex" - I agree that 
to satisfy all demands, it simply *is* complex.

> > but also because I spent some ten minutes
> > looking for the LIST response
> 
> I'm not sure what you want done here.  We do point to the IMAP 
> document
> for the rest.  The problem here is that the item "mailbox-list" is
> redefined here, but its predecessors ("mailbox-data", and
> "response-data" before that, and "response" before that) are in RFC
> 3501.  I could put a comment on the "mailbox-list" entry saying that
> it's pointed to by "mailbox-data" in [IMAP].  If that'll satisfy 
> you,
> I'll do it.  I don't know what else I can do for this.
> 
> 
A note at the beginning in the introductory prose saying where the 
LIST response is defined is all that's needed. Text like:

The LIST response is defined as part of the mailbox-data production 
in [IMAP], this ABNF replaces the mailbox-list production defining 
its payload.

I'm thinking that the first two things implementors will be looking 
for is the LIST command production and the LIST response production.

> I believe that no matter what happens to ACAP, it
> would be useful to have a separate RFC for "vendor-token" and the
> associated IANA registry, since an entity like that is needed in a
> number of places, as we see.

Yes, certainly. I'd happily argue to restrict it to ASCII 
alphanumerics, too.

> > I've not had time to verify the examples - I'll try to do so, but 
> I
> > doubt I'll have time before the new year.
> 
> And the new year it is!
> 
> 
Yes, indeed...

Page 7. Both examples appear to be missing spaces between the closing 
of one parenthesized list and the opening of the next.

Section 5...

5) "[...] similar to the command <RLSUB "" "%">." - Should be "*", 
not "%".
Extraneous comma in "mailboxes, which".
6) Extraneous comma.
8) "demonstates" typo.
A1) "instead" should be "as well", surely? The "or even this" clause 
and example doesn't make sense to me - it's simply added 
\HasChildren, but the client didn't request it.
C) "none of them is" should be "none of them are".

> > a) So far, I've not seen any server implementation supporting
> > multiple mailbox patterns. I noted that this would be relatively
> > involved to implement server-side myself, but perhaps more 
> tellingly,
> > although my API supports this, the layer above never actually 
> causes
> > multiple mailbox patterns to be used. I'm struggling to find a
> > use-case for multiple mailbox patterns.
> 
> We put in multiple mailbox patterns because we wanted the 
> flexibility,
> and we wanted consistent syntax with other commands, such as an
> extended SEARCH, which could certainly want to use that (and 
> consider
> that someone had suggested using extended LIST itself as an extended
> SEARCH).  If consensus is that it's unnecessary and too 
> complicated, we
> can pull out the multiple patterns for LIST, at the expense of not
> having the consistent syntax.
> 
> 
Yes, I think it could prove useful later, certainly. At this stage, 
it makes no real difference to clients, and it's additional 
complexity for servers - and server developers have historically 
preferred to avoid complexity at almost any cost.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Thu, 05 Jan 2006 08:50:43 -0500
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
Sender: [email-masked]

Hoo... I'm glad this came up again when Lisa put her "nag" message up
-- since I don't care about ACL, I never read the mislabelled review of
LISTEXT.

> 1) I found the ABNF strikingly difficult to follow.

Ya, I get that.  I'm not sure what to do about it, though.  It started
simply, but it complexificatalized quickly.  I'm not happy about that,
but the complexity is partly diven by the demand to have it be
machine-parsable in as much of its detail as possible, rather than
leaving some of that detail to human-readable explanation (take, for
example, the bits about which combinations of options can be used).

> but also because I spent some ten minutes
> looking for the LIST response

I'm not sure what you want done here.  We do point to the IMAP document
for the rest.  The problem here is that the item "mailbox-list" is
redefined here, but its predecessors ("mailbox-data", and
"response-data" before that, and "response" before that) are in RFC
3501.  I could put a comment on the "mailbox-list" entry saying that
it's pointed to by "mailbox-data" in [IMAP].  If that'll satisfy you,
I'll do it.  I don't know what else I can do for this.

> 2) I disagree with the statement that ACAP will never move to Draft.
> I don't think this belongs in a normative section, it's merely an
> opinion, and one which I hope to rectify.

That's in there in error anyway -- it was an editorial comment, which
actually remains as an open issue (but one that doesn't need to be
resolved until/if we go beyond Proposed Std, and ACAP hasn't by then),
and which, when I converted the doc to XML, I didn't turn into a
<cref>.  I'll fix it so it does not disparage ACAP :-), but to bring
the issue up again here (which we should follow up, if we want to do,
in another thread):  I believe that no matter what happens to ACAP, it
would be useful to have a separate RFC for "vendor-token" and the
associated IANA registry, since an entity like that is needed in a
number of places, as we see.

[Gee, that was all one sentence!]

> I've not had time to verify the examples - I'll try to do so, but I
> doubt I'll have time before the new year.

And the new year it is!

> a) So far, I've not seen any server implementation supporting
> multiple mailbox patterns. I noted that this would be relatively
> involved to implement server-side myself, but perhaps more tellingly,
> although my API supports this, the layer above never actually causes
> multiple mailbox patterns to be used. I'm struggling to find a
> use-case for multiple mailbox patterns.

We put in multiple mailbox patterns because we wanted the flexibility,
and we wanted consistent syntax with other commands, such as an
extended SEARCH, which could certainly want to use that (and consider
that someone had suggested using extended LIST itself as an extended
SEARCH).  If consensus is that it's unnecessary and too complicated, we
can pull out the multiple patterns for LIST, at the expense of not
having the consistent syntax.

Barry

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

Date: Wed, 04 Jan 2006 22:43:51 +0000
Subject: Re: WG Last Call of LISTEXT draft 14
From: Dave Cridland <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Cc: <[email-masked]>, Chris Newman <[email-masked]>, Philip Guenther <[email-masked]>
Sender: [email-masked]

On Wed Jan  4 21:44:36 2006, Lisa Dusseault wrote:
> We still haven't gotten enough review of LISTEXT during last call 
> to  finish it off.  Chris, Philip, Dave, you still need to review 
> at least  the changes from the last time you reviewed or we'll need 
> to find  another couple reviewers.  Arnt was the only one who 
> posted his review  to the Last Call.
> 
> 
I sent mine in December, in reply to your last email, without 
changing its subject line. Whoops.

At least Timo saw it, he replied.

It's here:

<imap://[email-masked]/INBOX;UIDVALIDITY=1132432829/;uid=16618;urlauth=anonymous:internal:00336e8bab1467a5ab36b990af9e5b25f4911b1147>

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Cc: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Re: WG Last Call of LISTEXT draft 14
Date: Wed, 4 Jan 2006 13:44:36 -0800
To: Chris Newman <[email-masked]>, Philip Guenther <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

We still haven't gotten enough review of LISTEXT during last call to  
finish it off.  Chris, Philip, Dave, you still need to review at least  
the changes from the last time you reviewed or we'll need to find  
another couple reviewers.  Arnt was the only one who posted his review  
to the Last Call.

Here's the -15 draft:  
<http://www.ietf.org/internet-drafts/draft-ietf-imapext-list- 
extensions-15.txt>

And to make it really easy, here's the diff from -14
<http://tools.ietf.org/wg/imapext/draft-ietf-imapext-list-extensions/ 
draft-ietf-imapext-list-extensions-15-from-14.diff.html>

Lisa

On Nov 27, 2005, at 7:56 AM, Lisa Dusseault wrote:

> "I love deadlines. I like the whooshing sound they make as they fly  
> by."
>     Douglas Adams
>
> Nobody commented during this last call period.  There were good  
> reviews when this was previously last-called, but I'd like to know  
> that the changes were reviewed. Chris Newman, Philip Guenther and Dave  
> Cridland volunteered to look it over, so you guys need to get back to  
> me.  Anybody else who reviewed the changes in LISTEXT since draft -13,  
> let me know.
>
> Lisa
>
> On Oct 27, 2005, at 4:25 PM, Lisa Dusseault wrote:
>
>>
>> I call your attention to this draft:
>>
>> http://www.ietf.org/internet-drafts/draft-ietf-imapext-list- 
>> extensions-14.txt
>>
>> We previously did a WG last call in May 2005 but we decided for a  
>> "do-over" since there were a few significant changes.
>>
>> This document is the framework for much of the syntax we're doing in  
>> other IMAPEXT tasks and is being referenced by other documents  
>> already, so it's important that it gets a good review.
>>
>> If you review it at all, or plan to implement, or have any opinion  
>> about standardizing this document, send mail to the WG list or at  
>> least to me.  Send me email even if you reviewed draft 13 and  
>> previously sent me email about that, to let me know if you have  
>> reviewed the changes in draft 14 and are OK with them.
>>
>> Because of the IETF meeting in a little over a week, let's do this  
>> last call until EOD Nov 17 (three weeks).  If you have any chance to  
>> bring up issues before IMAPEXT meets on Tuesday Nov 8, that would be  
>> much appreciated because it would give us an extra forum for  
>> discussion.
>>
>> Thanks,
>>
>> Lisa
>>
>

Date: Tue, 03 Jan 2006 20:35:40 -0500
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-condstore-08.txt
Sender: [email-masked]

[email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF.
> 
> 	Title		: IMAP Extension for Conditional STORE operation
> 	Author(s)	: A. Melnikov, S. Hole
> 	Filename	: draft-ietf-imapext-condstore-08.txt
> 	Pages		: 0
> 	Date		: 2006-1-3

What changed?

-- 
Kenneth Murchison
Project Cyrus Developer/Maintainer
Carnegie Mellon University

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-condstore-08.txt 
Date: Tue, 03 Jan 2006 10:50:01 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF.

	Title		: IMAP Extension for Conditional STORE operation
	Author(s)	: A. Melnikov, S. Hole
	Filename	: draft-ietf-imapext-condstore-08.txt
	Pages		: 0
	Date		: 2006-1-3
	
Often, multiple IMAP (RFC 3501) clients need to coordinate changes to
a common IMAP mailbox. Examples include different clients working on behalf of the same user, and multiple users accessing shared mailboxes. These clients need a mechanism to synchronize state changes for messages within the mailbox. They must be able to guarantee that only one client can change message state (e.g., message flags) at any time.  An
example of such an application is use of an IMAP mailbox as a message
queue with multiple dequeueing clients.

The Conditional Store facility provides a protected update mechanism for
message state information that can detect and resolve conflicts between
multiple writing mail clients.

This document defines an extension to IMAP (RFC 3501).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-condstore-08.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-imapext-condstore-08.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-imapext-condstore-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-imapext-condstore-08.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-imapext-condstore-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Tue, 31 Jan 2006 12:54:15 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Use of LIST-EXTENDED
Sender: [email-masked]

Alexey Melnikov writes:
> Arnt Gulbrandsen wrote:
>> I'm trying to use it, and I want to use it. My major problems have 
>> been dealt with. The extended data items trip me up, though: My data 
>> aren't easily expressed as a list of nstrings.
>
> Can you elaborate on this?

Sure. I'm trying to, but the internet-drafts editor is sitting on the 
document ;) I want to return a search. (The search has been sent to the 
server earlier.)

I can either invent some syntax that fits in nstring or use search-key. 
I can either enclose the lot on a single nstring or use some real 
syntax. That makes four possibilities.

Sending a single nstring containing (search-key 1*(SP search-key)), all 
quoted, is bad, IMO. Quoting hell, and difficult to express in ABNF.

Sending a single nstring containing some new syntax is almost as bad. 
Inventing new search syntax just because of how listext defined future 
syntax? That's the tail wagging the dog.

Etc.

Sending search-key is the right thing to do, but the extended data 
options don't allow it, since that may not be parsable as a list of 
nstrings.

Arnt

Date: Tue, 31 Jan 2006 11:01:49 +0000
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: Use of LIST-EXTENDED
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Lisa Dusseault writes:
>
>> Anybody else, would you use LIST-EXTENDED if it went forward in its  
>> *current* form?  Or only if it did hypothetical extensions such as  
>> the one outlined by Dave?
>
> I'm trying to use it, and I want to use it. My major problems have 
> been dealt with. The extended data items trip me up, though: My data 
> aren't easily expressed as a list of nstrings.

Can you elaborate on this?

Date: Tue, 31 Jan 2006 11:00:05 +0000
From: Alexey Melnikov <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
CC: [email-masked]
Subject: Re: LISTEXT to IESG?
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> The thing that gets me the extended data item syntax. That syntax 
> seems to be flexibility waiting for a task, hoping to be flexible 
> enough for whatever the task may turn out to be. In other words, a 
> solution looking for a problem.

Well, I had a similar discussion with Philip and Mark regarding generic 
syntax defined in draft-melnikov-imap-ext-abnf-08.txt and Marks position 
is that documents should provide guidance for future extensions.

The generic syntax for extensions defined in LIST-EXTENDED is the same 
as in draft-melnikov-imap-ext-abnf-08.txt. This helps to insure 
consistency between extensions to different commands and thus can 
minimize the number of different parsers people have to write.

> I'd rather let each future extension define its own syntax,

Each future extension should define own syntax which ideally should 
conform to the generic syntax specified in LIST-EXTENDED ("ideally 
should conform" because it might turn out that the generic syntax is not 
flexible enough. However I don't think this is very likely.)

> and forbid the server from adding extended data items unsolicited (ie. 
> striking the third sentence on page 8 of draft -15

Ok, let me talk about this for a bit. The sentence you are referring to 
reads:

   The server MAY return data in the extended fields that was not 
solicited by the client.

This sentence might need some clarification.

Firstly, there are 2 types of "solicited" fields: fields explicitly 
requested in the extended LIST command and fields implicitly requested 
by enabling some feature on the server (I can't think of such LIST field 
at the moment, but CONDSTORE defines a similar behavior when FETCH 
MODSEQ items are enabled on SELECT or other condstore-enabling command).

Secondly, IMAP has philosophy that any data can send by an IMAP server 
at any time and an IMAP client MUST be able to cope with that. This "MAY 
return" refers to this part. In general the server has no reason to 
return such data, unless it is explicitly or implicitly asked for it.

> ). The general syntax could be:
>
>     ... [ SP 1*(extended-data-item-name SP extended-data-item) ]
>
> The -name would be an nstring, the -item's syntax specified by the 
> IANA registration of the -name. If a client knows the name, it can 
> parse the item. If not, it can't. Full stop.
>
> I know I've muttered about this before. Sorry for sounding like a 
> broken record.

Date: Tue, 31 Jan 2006 11:35:30 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: IMAP Extensions WG <[email-masked]>
Subject: Re: Use of LIST-EXTENDED
Sender: [email-masked]

[email-masked] writes:
> Arnt's point - that the one-size-fits-all syntax for extended data 
> items is a little ugly - I've also run into, both in the hypothetical 
> RECENT extension I outlined, plus any number of other more complex 
> extensions I've outlined privately. At this stage, I can't conceive 
> of any extended data items I'd like the server to send me 
> unilaterally, so I suspect Arnt's broken record needs another spin, 
> as it were.

FYI, I don't really mind "a little ugly". I really mind "can't make it 
do what I'm trying to do".

(And I mind ugly, too. But I could live with that if it would get the 
document done.)

Arnt

Date: Mon, 30 Jan 2006 22:47:16 +0000
From: [email-masked]
To: undisclosed-recipients:;
Sender: [email-masked]

Subject: Re: Use of LIST-EXTENDED

References: <[email-masked]>

 <[email-masked]>

In-Reply-To: <[email-masked]>

MIME-Version: 1.0

Message-Id: <[email-masked]>

From: Dave Cridland <[email-masked]>

To: Lisa Dusseault <[email-masked]>

Cc:  <[email-masked]>

Content-Type: text/plain; charset="us-ascii"; format="flowed"

On Mon Jan 30 19:48:51 2006, Lisa Dusseault wrote:

> Anybody else, would you use LIST-EXTENDED if it went forward in its 

>  *current* form?  Or only if it did hypothetical extensions such as 

>  the one outlined by Dave?

The point of the hypothetical extension is mainly that RECURSIVEMATCH 

may actually be the wrong thing. The only circumstances where descent 

criteria are the same as for listing criteria (where listing criteria 

are normal selection options, I forget the correct term) are for 

"views" of the mailbox heirarchy, I think.

Currently, we have only one such view, that of Subscribed mailboxes. 

We may have more in the future, but I can easily think of various 

possibilities for cases where descent criteria differ from listing 

criteria.

Arnt's point - that the one-size-fits-all syntax for extended data 

items is a little ugly - I've also run into, both in the hypothetical 

RECENT extension I outlined, plus any number of other more complex 

extensions I've outlined privately. At this stage, I can't conceive 

of any extended data items I'd like the server to send me 

unilaterally, so I suspect Arnt's broken record needs another spin, 

as it were.

That all said, I've implemented LIST-EXTENDED and POSTADDRESS, as 

well as LISTEXT/LIST-SUBSCRIBED (because I was bored). The RECENT 

extension can be achieved by pipelining LIST commands, easily enough, 

as can every extension I've contemplated, so I'm hardly stating that 

my concerns are show-stoppers, I'm merely questioning whether they've 

been adequately reviewed.

Dave.

-- 

           You see things; and you say "Why?"

   But I dream things that never were; and I say "Why not?"

    - George Bernard Shaw

Date: Mon, 30 Jan 2006 22:37:03 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Use of LIST-EXTENDED
Sender: [email-masked]

Lisa Dusseault writes:
> Anybody else, would you use LIST-EXTENDED if it went forward in its  
> *current* form?  Or only if it did hypothetical extensions such as  
> the one outlined by Dave?

I'm trying to use it, and I want to use it. My major problems have been 
dealt with. The extended data items trip me up, though: My data aren't 
easily expressed as a list of nstrings.

Arnt

Date: Mon, 30 Jan 2006 19:59:08 +0000
From: Alexey Melnikov <[email-masked]>
To: Lisa Dusseault <[email-masked]>
CC: IMAP Extensions WG <[email-masked]>
Subject: Re: Use of LIST-EXTENDED
Sender: [email-masked]

Lisa Dusseault wrote:

> We have in the past had several documents depending on LIST- 
> EXTENDED.  Since this document has taken so long, various authors  
> have reduced those dependencies and we now have no more active drafts  
> that depend on LIST-EXTENDED.  This URL will show the drafts that  
> depend and note they're all expired:
>
> http://rtg.ietf.org/~fenner/ietf/deps/index.cgi?dep=list-extensions
>
> Alexey, Michael,

Michael is no longer with Nokia, as far as I know.

> it would be good to get a sense of what you'd be  doing with 
> LIST-EXTENDED if it did go forward -- reissue those  drafts?

I would certainly reissue mine at some points. There are some other LIST 
extensions I have in mind as well.

> Or is it no longer needed?
>
> Anybody else, would you use LIST-EXTENDED if it went forward in its  
> *current* form?  Or only if it did hypothetical extensions such as  
> the one outlined by Dave? 

I am discussing privately with Dave if some tweaks to LIST-EXTENDED are 
needed. I will let you know the outcome of our discussion.

Cc: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Use of LIST-EXTENDED
Date: Mon, 30 Jan 2006 11:48:51 -0800
To: [email-masked], Alexey Melnikov <[email-masked]>
Sender: [email-masked]

We have in the past had several documents depending on LIST- 
EXTENDED.  Since this document has taken so long, various authors  
have reduced those dependencies and we now have no more active drafts  
that depend on LIST-EXTENDED.  This URL will show the drafts that  
depend and note they're all expired:

http://rtg.ietf.org/~fenner/ietf/deps/index.cgi?dep=list-extensions

Alexey, Michael, it would be good to get a sense of what you'd be  
doing with LIST-EXTENDED if it did go forward -- reissue those  
drafts?  Or is it no longer needed?

Anybody else, would you use LIST-EXTENDED if it went forward in its  
*current* form?  Or only if it did hypothetical extensions such as  
the one outlined by Dave?

Lisa

On Jan 26, 2006, at 7:25 AM, Dave Cridland wrote:

>
> Let's define a hypothetical extension to LIST-EXTENDED:
>
> It has a return option RECENT, which returns the recent count of a  
> mailbox.
>
> It also has a "base" selection option RECENT, which restricts the  
> selection to mailboxes which have a non-zero recent message count.  
> Being a base option, it means that this may be used with  
> RECURSIVEMATCH. We'll make it imply the RECENT return option, as is  
> traditional.
>
> Now... What I'd like to do with this extension is show my GUI tree  
> control of mailboxes which are subscribed, with little expander  
> buttons for those that have subscribed children, and also highlight  
> those mailboxes which have recent messages - or subscribed children  
> which have recent messages.
>
> In other words, assuming:
>
> A01 LIST (SUBSCRIBED) "" "*" RETURN (RECENT)
> * LIST (\Subscribed \UnMarked) "/" Foo
> * LIST (\Subscribed \Marked) "/" Foo/Bar/Baz ((RECENT "24"))
> * LIST (\Subscribed \Marked) "/" Zab ((RECENT "42"))
> * LIST (\Subscribed \UnMarked) "/" Boring
> A01 OK
>
> Then I want to show Foo, Zab, and Boring. Foo and Zab will both be  
> highlighted, Boring will not be. Zab will have a recent count  
> displayed next to it.
>
> In order to do this, I need to:
>
> B01 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
> B02 LIST (SUBSCRIBED RECENT RECURSIVEMATCH) "" "%"
>
> B01 here gets the mailbox listing and the tree "expander"  
> information. B02 gets the highlighting information. The server has  
> to recusrively search twice.
>
> What I'd really like to do, though, is the imaginary syntax:
>
> C01 LIST (SUBSCRIBED RECURSIVEMATCH (SUBSCRIBED) RECURSIVEMATCH  
> (SUBSCRIBED RECENT)) "" "%" RETURN (RECENT)
>
> In other words, "Tell me all the subscribed mailboxes at the top  
> level, and also include CHILDINFO blocks for SUBSCRIBED and  
> SUBSCRIBED+RECENT".
>
> I can think of more use-cases for this than for multiple mailbox  
> patterns, incidentally.
>
> From the server's perspective, it now has to perform the recursive  
> mailbox search only once through, rather than twice, which seems  
> more efficient.
>
> Is this worth considering at this late stage?
>
> Dave.
> -- 
>           You see things; and you say "Why?"
>   But I dream things that never were; and I say "Why not?"
>    - George Bernard Shaw
>
>

To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Subject: Last Call: 'IMAP Extension for Conditional STORE operation' to  Proposed Standard 
Reply-to: [email-masked]
CC: <[email-masked]>
Date: Thu, 26 Jan 2006 12:03:34 -0500
Sender: [email-masked]

The IESG has received a request from the Internet Message Access Protocol 
Extension WG to consider the following document:

- 'IMAP Extension for Conditional STORE operation '
   <draft-ietf-imapext-condstore-08.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2006-02-09.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-imapext-condstore-08.txt

On 25 January 2006 the IMAPEXT working group chairs request sent a request
to their area advisor to ask the IESG to evaluate
draft-ietf-imapext-condstore-08.txt as a replacement for
draft-ietf-imapext-condstore-05.txt.  The IESG approved
draft-ietf-imapext-condstore-05.txt for publication as a Proposed Standard
RFC on 4 December 2003.

Changes from -05:
1. Reworded not to have a normative reference to ANNOTATE.
2. Updated ABNF to reference IMAP ABNF.
3. Clarified that STATUS (HIGHESTMODSEQ) also enables CONDSTORE notifications.
4. Fixed few typos in examples or example titles.
5. Updated boilerplate, references.

Date: Thu, 26 Jan 2006 15:25:56 +0000
Subject: A hypothetical extension
From: Dave Cridland <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Let's define a hypothetical extension to LIST-EXTENDED:

It has a return option RECENT, which returns the recent count of a 
mailbox.

It also has a "base" selection option RECENT, which restricts the 
selection to mailboxes which have a non-zero recent message count. 
Being a base option, it means that this may be used with 
RECURSIVEMATCH. We'll make it imply the RECENT return option, as is 
traditional.

Now... What I'd like to do with this extension is show my GUI tree 
control of mailboxes which are subscribed, with little expander 
buttons for those that have subscribed children, and also highlight 
those mailboxes which have recent messages - or subscribed children 
which have recent messages.

In other words, assuming:

A01 LIST (SUBSCRIBED) "" "*" RETURN (RECENT)
* LIST (\Subscribed \UnMarked) "/" Foo
* LIST (\Subscribed \Marked) "/" Foo/Bar/Baz ((RECENT "24"))
* LIST (\Subscribed \Marked) "/" Zab ((RECENT "42"))
* LIST (\Subscribed \UnMarked) "/" Boring
A01 OK

Then I want to show Foo, Zab, and Boring. Foo and Zab will both be 
highlighted, Boring will not be. Zab will have a recent count 
displayed next to it.

In order to do this, I need to:

B01 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
B02 LIST (SUBSCRIBED RECENT RECURSIVEMATCH) "" "%"

B01 here gets the mailbox listing and the tree "expander" 
information. B02 gets the highlighting information. The server has to 
recusrively search twice.

What I'd really like to do, though, is the imaginary syntax:

C01 LIST (SUBSCRIBED RECURSIVEMATCH (SUBSCRIBED) RECURSIVEMATCH 
(SUBSCRIBED RECENT)) "" "%" RETURN (RECENT)

In other words, "Tell me all the subscribed mailboxes at the top 
level, and also include CHILDINFO blocks for SUBSCRIBED and 
SUBSCRIBED+RECENT".

I can think of more use-cases for this than for multiple mailbox 
patterns, incidentally.

 From the server's perspective, it now has to perform the recursive 
mailbox search only once through, rather than twice, which seems more 
efficient.

Is this worth considering at this late stage?

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Thu, 26 Jan 2006 15:11:13 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: LISTEXT to IESG?
Cc: Barry Leiba <[email-masked]>, Ken Murchison <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

Arnt Gulbrandsen writes:
>     ... [ SP 1*(extended-data-item-name SP extended-data-item) ]

Sorry. ... [ 1* (SP extended-data-item-name SP extended-data-item) ] of course.

Date: Thu, 26 Jan 2006 15:01:35 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: LISTEXT to IESG?
Cc: Barry Leiba <[email-masked]>, Ken Murchison <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

Ken Murchison writes:
> Dave Cridland wrote:
>> 1) Are the server implementors happy, in particular with multiple 
>> mailbox patterns?
>
> I'm not thrilled about it.  I wonder if this feature is something that 
> clients really need, given the potential complexity for server 
> implementors.

What potential complexity? The ban on multiple responses was lifted, the 
rest doesn't seem too bad. Mildly pointless, not harmful or horribly 
complex.

The thing that gets me the extended data item syntax. That syntax seems 
to be flexibility waiting for a task, hoping to be flexible enough for 
whatever the task may turn out to be. In other words, a solution 
looking for a problem.

I'd rather let each future extension define its own syntax, and forbid 
the server from adding extended data items unsolicited (ie. striking 
the third sentence on page 8 of draft -15). The general syntax could 
be:

     ... [ SP 1*(extended-data-item-name SP extended-data-item) ]

The -name would be an nstring, the -item's syntax specified by the IANA 
registration of the -name. If a client knows the name, it can parse the 
item. If not, it can't. Full stop.

I know I've muttered about this before. Sorry for sounding like a broken 
record.

Arnt

Date: Thu, 26 Jan 2006 08:04:17 -0500
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: Dave Cridland <[email-masked]>
CC: Lisa Dusseault <[email-masked]>, [email-masked], Barry Leiba <[email-masked]>
Subject: Re: LISTEXT to IESG?
Sender: [email-masked]

Dave Cridland wrote:
> 
> On Wed Jan 25 20:22:35 2006, Lisa Dusseault wrote:
> 
>>
>> Dave Cridland was the only one who responded to this revision of  
>> LISTEXT, and raised no new issues.  Is anybody aware of open issues?   
>> Because I'm starting to think this is ready to go to IESG.  Speak up  
>> now.
>>
>>
> Well, I did respond to Barry's new revision, but I questioned:
> 
> 1) Are the server implementors happy, in particular with multiple 
> mailbox patterns?

I'm not thrilled about it.  I wonder if this feature is something that 
clients really need, given the potential complexity for server implementors.

-- 
Kenneth Murchison
Project Cyrus Developer/Maintainer
Carnegie Mellon University

Date: Thu, 26 Jan 2006 06:25:04 +0100
From: Arnaud Taddei <[email-masked]>
Subject: Re: LISTEXT to IESG?
To: Lisa Dusseault <[email-masked]>
Cc: Barry Leiba <[email-masked]>, [email-masked]
Sender: [email-masked]

Lisa Dusseault wrote:

>
> Dave Cridland was the only one who responded to this revision of  
> LISTEXT, and raised no new issues.  Is anybody aware of open issues?   
> Because I'm starting to think this is ready to go to IESG.  Speak up  
> now.

Am stuck since 2 weeks at 18 hours per day + too many buis trips. I have 
all my ideas in my head but need 2 hours to complete reading Dave's 
mails and making a second pass as I have several things to check but I 
think I found a way to align a proposal. Can I beg for doing this wait 
for Monday? I think I will work on it this week end.

A++

>
> Lisa
>
> On Jan 17, 2006, at 8:43 AM, Barry Leiba wrote:
>
>> I've attached an edited diff of the changes I've made based on  comments
>> so far.  They're minor -- mostly typo corrections and minor rewordings
>> and clarifications.  I've also changed the markup for the examples so
>> that the client/server exchanges are not double-spaced.
>>
>> My specific responses to comments are below.
>>
>>
>>>>> but also because I spent some ten minutes
>>>>> looking for the LIST response
>>>>>
>>>
>>> A note at the beginning in the introductory prose saying where the
>>> LIST response is defined is all that's needed.
>>>
>>
>> Dave, see if you like what I've done.  I put text in both the ABNF
>> introduction AND the definition of mailbox-list.
>>
>>
>>>> I believe that no matter what happens to ACAP,
>>>>
>>
>> I've reworded the ACAP text; let me know if you think that's OK.
>>
>>
>>> Page 7. Both examples appear to be missing spaces between the closing
>>> of one parenthesized list and the opening of the next.
>>>
>>
>> Fixed.
>>
>>
>>> 5) "[...] similar to the command <RLSUB "" "%">." - Should be "*",
>>> not "%".
>>> Extraneous comma in "mailboxes, which".
>>> 6) Extraneous comma.
>>> 8) "demonstates" typo.
>>> A1) "instead" should be "as well", surely? The "or even this" clause
>>> and example doesn't make sense to me - it's simply added
>>> \HasChildren, but the client didn't request it.
>>>
>>
>> Fixed all.
>>
>>
>>> C) "none of them is" should be "none of them are".
>>>
>>
>> Nah; "none" is singular, though it's acceptable to give it plural  usage
>> if one likes that sort of thing.  Actually, I've instead changed the
>> OTHER use of "none" to be singular, to match this one.
>>
>>
>>>>> a) So far, I've not seen any server implementation supporting
>>>>> multiple mailbox patterns.
>>>>>
>> ...
>>
>>> Yes, I think it could prove useful later, certainly. At this stage,
>>> it makes no real difference to clients, and it's additional
>>> complexity for servers - and server developers have historically
>>> preferred to avoid complexity at almost any cost.
>>>
>>
>> But we've had a couple of comments to leave it.  Do we have a
>> resolution for this issue?
>>
>> Dave has responded adequately to Arnaud's comments, so I'll refer to
>> Dave's note on it:
>>
>>
>>>   • I have a problem (which is surely my Frenglish) to understand
>>> 'or any combination of therof', I don't scan the word therof.
>>>   • Page 9 on the paragraph for REMOTE, the 3 last lines are really
>>> some byzantinism that is really a pain to explain operationally.
>>> Could we favor eliminating exceptions and enhancing protocol
>>> readability?
>>>   • Page 14, paragraph \HasChildren, I think I disagree with the
>>> security perspective
>>>   • Page 16, I am not familiar with the \Marked in example 2. What
>>> does this attribute mean? Where is it defined?
>>>   • Page 17, I think Example 6 requires much more explanations
>>>   • Page 19, Example 8: typo: it should be demonstrate and not
>>> demonstate, there is a missing r
>>>   • Page 26, I am not comfortable with the comment on ACAP at the
>>> beginning of section 6
>>>   • Page 30, at the end I dsiagree with the Security statement here
>>>   • Page 32, first paragrapha very small typo: there is a space
>>> between options/ extended, it should be options/extended to be
>>> consistent with the others after
>>>   • Page 34, the registration number 3 is almost a duplicate of
>>> registration number 1, you want to remove one or the other.
>>>
>>
>>
>>>>    * I disagree in the abstract on the Mailbox Referrals mention. No
>>>>      one implements it even not Microsoft correct? I think there are
>>>>      much more important issues to be covered in the abstract
>>>>
>>>
>>> I implement Mailbox Referrals in my client, and Cyrus IMAP implements
>>> it in the server. I think Mulberry implements it client-side too. In
>>> any case, the mention here is illustrating that its addition forces
>>> additional duplicate commands such as RLIST, RLSUB, etc, and I think
>>> that's justified.
>>>
>>
>> Agreed; it's staying.
>>
>>
>>> That's page 6 section 3 paragraph two. Should be "any combination
>>> thereof".
>>>
>>
>> Fixed typo.
>>
>>
>>>>    * Page 9 on the paragraph for REMOTE, the 3 last lines are really
>>>>      some byzantinism that is really a pain to explain
>>>> operationally.
>>>>      Could we favor eliminating exceptions and enhancing protocol
>>>>      readability?
>>>>
>>>
>>> It was tricky to explain at all. The nature of what's wrong with
>>> REMOTE RECURSIVEMATCH isn't echoed fully in the subsection on
>>> RECURSIVEMATCH, incidentally.
>>>
>>
>> I've added a phrase to the RECURSIVEMATCH subsection to deal with  that.
>> Arnaud, if you have a better suggestion for how to explain the
>> interaction of REMOTE, give me text (Franglish is OK; I can cope).
>> What you see there is the best we could come up with (and, really, I
>> don't think it's that confusing).
>>
>>
>>>>    * Page 14, paragraph \HasChildren, I think I disagree with the
>>>>      security perspective
>>>>
>>>
>>> Rereading this section, I note that "the server MUST return these
>>> attributes", but "a server MAY exclude both the [...] attributes".
>>>
>>
>> I presume, Arnaud, that you're referring to the bit about returning
>> \HasNoChildren if there are no children that the requester has access
>> to.  That statement represents established consensus here, so unless
>> there are others who want to change it, it'll stay.
>>
>> Dave, you're right that there's an unintended conflict there.  I did a
>> little rewording; let me know what you think of it.
>>
>>
>>>>    * Page 17, I think Example 6 requires much more explanations
>>>>
>>>
>>> I think I see why. Could you suggest some alternate text for
>>> explaining both example 5 and example 6? (I should think both would
>>> need to be changed to express the difference more clearly).
>>>
>>
>> Yes, text.
>> I'm afraid that at this point in the process I have to insist that
>> comments that say that text is needed MUST come with suggested text.
>> I'll accept suggestions for minor tweaks, of course, but if you think
>> something needs to be written at this point... please write it.
>>
>>
>>>>    * Page 30, at the end I dsiagree with the Security statement here
>>>>
>>>
>>> No, this is a security concern, and should be addressed by
>>> implementors.
>>>
>>
>> Agreed; this is an exposure of a "covert channel" -- a back door to
>> retrieve information that you couldn't normally retrieve.  It has  to be
>> documented.
>>
>>
>> Further comments?  Is -15a ready to go to the IESG as -16?
>>
>> Barry
>>
>> -- 
>> Barry Leiba, Pervasive Computing Technology  ([email-masked])
>> http://www.research.ibm.com/people/l/leiba
>> http://www.research.ibm.com/spam
>>
>> <draft-ietf-imapext-list-extensions-15to15adiff.txt>
>> <draft-ietf-imapext-list-extensions-15a.txt>
>>
>
>

Date: Wed, 25 Jan 2006 23:55:14 +0000
From: Alexey Melnikov <[email-masked]>
To: Dave Cridland <[email-masked]>
CC: Barry Leiba <[email-masked]>, [email-masked]
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
Sender: [email-masked]

Dave Cridland wrote:

>> >>> a) So far, I've not seen any server implementation supporting
>> >>> multiple mailbox patterns.
>> ...
>> > Yes, I think it could prove useful later, certainly. At this stage,
>> > it makes no real difference to clients, and it's additional
>> > complexity for servers - and server developers have historically
>> > preferred to avoid complexity at almost any cost.
>>
>> But we've had a couple of comments to leave it.  Do we have a
>> resolution for this issue?
>
> I've seen very little comment. My general suspicion is that those 
> server implementors who expressed any opinion at all aren't entirely 
> happy with it. Personally, I'd be happy to leave it in, but I'll defer 
> to the server folk.

Dave, if this make you happier, I am willing to fix Isode implementation 
to support multiple patterns ;-).

Date: Wed, 25 Jan 2006 22:58:02 +0000
Subject: Re: LISTEXT to IESG?
From: Dave Cridland <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: Lisa Dusseault <[email-masked]>, <[email-masked]>, Barry Leiba <[email-masked]>
Sender: [email-masked]

On Wed Jan 25 21:50:31 2006, Mark Crispin wrote:
> On Wed, 25 Jan 2006, Dave Cridland wrote:
>> 1) Are the server implementors happy, in particular with multiple 
>> mailbox patterns?
> 
> I'm not sure that I'm happy with it, but if (when I go to implement 
> it) LISTEXT proves to be impractical, I'll just punt.  I don't see 
> a clamoring market groundswell for LISTEXT.
> 
> 
I think there may be market groundswell for extensions which use 
LIST-EXTENDED as a base, so I for one would appreciate it if you 
could take the time to see whether there's anything obvious that'd 
cause you to punt.

>> 2) How is it possible for a server to be incapable of knowing 
>> whether there are child mailboxes, when a subsequent LIST of those 
>> children (if any) must be possible?
> 
> I agree that no server would be "incapable of knowing", but it may 
> be "excessively costly" depending upon how the store is designed.
> 
> 
I agree with your arguments here.

FWIW, I think based on this, Barry's changes in 15a aren't right.

What about, referencing -15:

1) Changing the last sentence of Section 4, second para, to:

	If the CHILDREN return option is present, the server SHOULD return 
these attributes even if their computation is expensive.

2) Replacing the last two sentences of the \HasChildren explanatory 
paragraph (third para) with:

	In such a case, the server MUST NOT set this attribute.

making the \HasChildren attribute definitive. I disagree with 
attributes which are not definitive.

There's also an error here - preceding sentence should read "[...] 
access to any child mailboxes."

In other words, servers say a mailbox has children or doesn't have 
children, or else they say nothing.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Wed, 25 Jan 2006 13:50:31 -0800 (Pacific Standard Time)
From: Mark Crispin <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: Lisa Dusseault <[email-masked]>, [email-masked], Barry Leiba <[email-masked]>
Subject: Re: LISTEXT to IESG?
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Wed, 25 Jan 2006, Dave Cridland wrote:
> 1) Are the server implementors happy, in particular with multiple mailbox 
> patterns?

I'm not sure that I'm happy with it, but if (when I go to implement it) 
LISTEXT proves to be impractical, I'll just punt.  I don't see a clamoring 
market groundswell for LISTEXT.

> 2) How is it possible for a server to be incapable of knowing whether there 
> are child mailboxes, when a subsequent LIST of those children (if any) must 
> be possible?

I agree that no server would be "incapable of knowing", but it may be 
"excessively costly" depending upon how the store is designed.

For example, it is a non-trivial exercise to determine whether or not a 
directory has contents that could be considered "children".  It is not 
enough to identify that it is a directory.  The directory's contents must 
also be examined.  Not all contents may qualify as "children", and some 
actions must be taken to discriminate.

For clients that do "*", it's silly for the server to calculate children; 
it already knows.  Leave aside the small matter that "*" is not good.

For clients that do "%/%", the question is answered for the upper level. 
What's more, clients have to do this anyway if the server doesn't support 
LISTEXT or CHILDREN.

So it comes down to the case of a client that does "%".  It knows (by the 
absence of \NoSelect) that it is reasonable to offer an "open messages" 
button.  It knows (by the absence of \NoInferiors) that it is reasonable 
to offer an "open inferiors" method.  The whole point of a server 
reporting children is to enable such a client to omit the "open inferiors" 
method.

This is undoubtably useful and user-friendly.  Time will tell if it wins 
on the cost/benefit question.

-- Mark --

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

Date: Wed, 25 Jan 2006 21:26:59 +0000
Subject: Re: LISTEXT to IESG?
From: Dave Cridland <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Cc: <[email-masked]>, Barry Leiba <[email-masked]>
Sender: [email-masked]

On Wed Jan 25 20:22:35 2006, Lisa Dusseault wrote:
> 
> Dave Cridland was the only one who responded to this revision of  
> LISTEXT, and raised no new issues.  Is anybody aware of open 
> issues?   Because I'm starting to think this is ready to go to 
> IESG.  Speak up  now.
> 
> 
Well, I did respond to Barry's new revision, but I questioned:

1) Are the server implementors happy, in particular with multiple 
mailbox patterns?

2) How is it possible for a server to be incapable of knowing whether 
there are child mailboxes, when a subsequent LIST of those children 
(if any) must be possible?

Everyone must have seen it. Possibly even more than once. (No, not my 
fault, as far as I'm able to detirmine.)

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Cc: [email-masked]
From: Lisa Dusseault <[email-masked]>
Subject: LISTEXT to IESG?
Date: Wed, 25 Jan 2006 12:22:35 -0800
To: Barry Leiba <[email-masked]>
Sender: [email-masked]

Dave Cridland was the only one who responded to this revision of  
LISTEXT, and raised no new issues.  Is anybody aware of open issues?   
Because I'm starting to think this is ready to go to IESG.  Speak up  
now.

Lisa

On Jan 17, 2006, at 8:43 AM, Barry Leiba wrote:

> I've attached an edited diff of the changes I've made based on  
> comments
> so far.  They're minor -- mostly typo corrections and minor rewordings
> and clarifications.  I've also changed the markup for the examples so
> that the client/server exchanges are not double-spaced.
>
> My specific responses to comments are below.
>
>
>>>> but also because I spent some ten minutes
>>>> looking for the LIST response
>>>>
>>
>> A note at the beginning in the introductory prose saying where the
>> LIST response is defined is all that's needed.
>>
>
> Dave, see if you like what I've done.  I put text in both the ABNF
> introduction AND the definition of mailbox-list.
>
>
>>> I believe that no matter what happens to ACAP,
>>>
>
> I've reworded the ACAP text; let me know if you think that's OK.
>
>
>> Page 7. Both examples appear to be missing spaces between the closing
>> of one parenthesized list and the opening of the next.
>>
>
> Fixed.
>
>
>> 5) "[...] similar to the command <RLSUB "" "%">." - Should be "*",
>> not "%".
>> Extraneous comma in "mailboxes, which".
>> 6) Extraneous comma.
>> 8) "demonstates" typo.
>> A1) "instead" should be "as well", surely? The "or even this" clause
>> and example doesn't make sense to me - it's simply added
>> \HasChildren, but the client didn't request it.
>>
>
> Fixed all.
>
>
>> C) "none of them is" should be "none of them are".
>>
>
> Nah; "none" is singular, though it's acceptable to give it plural  
> usage
> if one likes that sort of thing.  Actually, I've instead changed the
> OTHER use of "none" to be singular, to match this one.
>
>
>>>> a) So far, I've not seen any server implementation supporting
>>>> multiple mailbox patterns.
>>>>
> ...
>
>> Yes, I think it could prove useful later, certainly. At this stage,
>> it makes no real difference to clients, and it's additional
>> complexity for servers - and server developers have historically
>> preferred to avoid complexity at almost any cost.
>>
>
> But we've had a couple of comments to leave it.  Do we have a
> resolution for this issue?
>
> Dave has responded adequately to Arnaud's comments, so I'll refer to
> Dave's note on it:
>
>
>>   • I have a problem (which is surely my Frenglish) to understand
>> 'or any combination of therof', I don't scan the word therof.
>>   • Page 9 on the paragraph for REMOTE, the 3 last lines are really
>> some byzantinism that is really a pain to explain operationally.
>> Could we favor eliminating exceptions and enhancing protocol
>> readability?
>>   • Page 14, paragraph \HasChildren, I think I disagree with the
>> security perspective
>>   • Page 16, I am not familiar with the \Marked in example 2. What
>> does this attribute mean? Where is it defined?
>>   • Page 17, I think Example 6 requires much more explanations
>>   • Page 19, Example 8: typo: it should be demonstrate and not
>> demonstate, there is a missing r
>>   • Page 26, I am not comfortable with the comment on ACAP at the
>> beginning of section 6
>>   • Page 30, at the end I dsiagree with the Security statement here
>>   • Page 32, first paragrapha very small typo: there is a space
>> between options/ extended, it should be options/extended to be
>> consistent with the others after
>>   • Page 34, the registration number 3 is almost a duplicate of
>> registration number 1, you want to remove one or the other.
>>
>
>
>>>    * I disagree in the abstract on the Mailbox Referrals mention. No
>>>      one implements it even not Microsoft correct? I think there are
>>>      much more important issues to be covered in the abstract
>>>
>>
>> I implement Mailbox Referrals in my client, and Cyrus IMAP implements
>> it in the server. I think Mulberry implements it client-side too. In
>> any case, the mention here is illustrating that its addition forces
>> additional duplicate commands such as RLIST, RLSUB, etc, and I think
>> that's justified.
>>
>
> Agreed; it's staying.
>
>
>> That's page 6 section 3 paragraph two. Should be "any combination
>> thereof".
>>
>
> Fixed typo.
>
>
>>>    * Page 9 on the paragraph for REMOTE, the 3 last lines are really
>>>      some byzantinism that is really a pain to explain
>>> operationally.
>>>      Could we favor eliminating exceptions and enhancing protocol
>>>      readability?
>>>
>>
>> It was tricky to explain at all. The nature of what's wrong with
>> REMOTE RECURSIVEMATCH isn't echoed fully in the subsection on
>> RECURSIVEMATCH, incidentally.
>>
>
> I've added a phrase to the RECURSIVEMATCH subsection to deal with  
> that.
> Arnaud, if you have a better suggestion for how to explain the
> interaction of REMOTE, give me text (Franglish is OK; I can cope).
> What you see there is the best we could come up with (and, really, I
> don't think it's that confusing).
>
>
>>>    * Page 14, paragraph \HasChildren, I think I disagree with the
>>>      security perspective
>>>
>>
>> Rereading this section, I note that "the server MUST return these
>> attributes", but "a server MAY exclude both the [...] attributes".
>>
>
> I presume, Arnaud, that you're referring to the bit about returning
> \HasNoChildren if there are no children that the requester has access
> to.  That statement represents established consensus here, so unless
> there are others who want to change it, it'll stay.
>
> Dave, you're right that there's an unintended conflict there.  I did a
> little rewording; let me know what you think of it.
>
>
>>>    * Page 17, I think Example 6 requires much more explanations
>>>
>>
>> I think I see why. Could you suggest some alternate text for
>> explaining both example 5 and example 6? (I should think both would
>> need to be changed to express the difference more clearly).
>>
>
> Yes, text.
> I'm afraid that at this point in the process I have to insist that
> comments that say that text is needed MUST come with suggested text.
> I'll accept suggestions for minor tweaks, of course, but if you think
> something needs to be written at this point... please write it.
>
>
>>>    * Page 30, at the end I dsiagree with the Security statement here
>>>
>>
>> No, this is a security concern, and should be addressed by
>> implementors.
>>
>
> Agreed; this is an exposure of a "covert channel" -- a back door to
> retrieve information that you couldn't normally retrieve.  It has  
> to be
> documented.
>
>
> Further comments?  Is -15a ready to go to the IESG as -16?
>
> Barry
>
> --
> Barry Leiba, Pervasive Computing Technology  ([email-masked])
> http://www.research.ibm.com/people/l/leiba
> http://www.research.ibm.com/spam
>
> <draft-ietf-imapext-list-extensions-15to15adiff.txt>
> <draft-ietf-imapext-list-extensions-15a.txt>
>

Date: Tue, 17 Jan 2006 17:45:19 -0500
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
From: "Dave Cridland" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Content-Class: urn:content-classes:message
Importance: normal
Status:   
Sender: [email-masked]

On Tue Jan 17 16:43:36 2006, Barry Leiba wrote:
> >> > but also because I spent some ten minutes
> >> > looking for the LIST response
> > > A note at the beginning in the introductory prose saying where 
> the
> > LIST response is defined is all that's needed.
> 
> Dave, see if you like what I've done.  I put text in both the ABNF
> introduction AND the definition of mailbox-list.
> 
> 
That looks good.

> >> I believe that no matter what happens to ACAP,
> 
> I've reworded the ACAP text; let me know if you think that's OK.
> 
> 
Better.

> > C) "none of them is" should be "none of them are".
> 
> Nah; "none" is singular, though it's acceptable to give it plural 
> usage
> if one likes that sort of thing.  Actually, I've instead changed the
> OTHER use of "none" to be singular, to match this one.
> 
> 
Fairy nuff.

> >>> a) So far, I've not seen any server implementation supporting
> >>> multiple mailbox patterns.
> ...
> > Yes, I think it could prove useful later, certainly. At this 
> stage,
> > it makes no real difference to clients, and it's additional
> > complexity for servers - and server developers have historically
> > preferred to avoid complexity at almost any cost.
> 
> But we've had a couple of comments to leave it.  Do we have a
> resolution for this issue?
> 
> 
I've seen very little comment. My general suspicion is that those 
server implementors who expressed any opinion at all aren't entirely 
happy with it. Personally, I'd be happy to leave it in, but I'll 
defer to the server folk.

> Dave has responded adequately to Arnaud's comments, so I'll refer to
> Dave's note on it:

> >>    * Page 14, paragraph \HasChildren, I think I disagree with the
> >>      security perspective
> > > Rereading this section, I note that "the server MUST return 
> these
> > attributes", but "a server MAY exclude both the [...] attributes".
> 
> I presume, Arnaud, that you're referring to the bit about returning
> \HasNoChildren if there are no children that the requester has 
> access
> to.  That statement represents established consensus here, so unless
> there are others who want to change it, it'll stay.
> 
> Dave, you're right that there's an unintended conflict there.  I 
> did a
> little rewording; let me know what you think of it.
> 
> 
Right. You're saying that in the case where some architectural issue 
means that the server simply cannot detirmine whether a mailbox has 
children or not, then it can omit both attributes.

I understand what you're trying to say, I'm just not clear on how 
that can arise. Specifically, if a mailbox A exists, but the server 
finds it impossible to provide either CHILDREN attribute, then surely 
it also cannot handle a subsequent LIST of A's inferior mailboxes?

I can certainly follow that it may be expensive to find the 
information, that it may be equivalent to performing the second LIST 
internally, etc, but if it were impossible, then the subsequent LIST 
would also be impossible.

If by impossible you mean "*really* difficult", then you're 
essentially licensing servers to omit both flags when they feel like 
it - this is actually acceptable to me in this case, I'd just like to 
understand this issue a little better.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 17 Jan 2006 17:31:10 -0500
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
From: "Dave Cridland" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Content-Class: urn:content-classes:message
Importance: normal
Status:   
Sender: [email-masked]

On Tue Jan 17 16:43:36 2006, Barry Leiba wrote:
> >> > but also because I spent some ten minutes
> >> > looking for the LIST response
> > > A note at the beginning in the introductory prose saying where 
> the
> > LIST response is defined is all that's needed.
> 
> Dave, see if you like what I've done.  I put text in both the ABNF
> introduction AND the definition of mailbox-list.
> 
> 
That looks good.

> >> I believe that no matter what happens to ACAP,
> 
> I've reworded the ACAP text; let me know if you think that's OK.
> 
> 
Better.

> > C) "none of them is" should be "none of them are".
> 
> Nah; "none" is singular, though it's acceptable to give it plural 
> usage
> if one likes that sort of thing.  Actually, I've instead changed the
> OTHER use of "none" to be singular, to match this one.
> 
> 
Fairy nuff.

> >>> a) So far, I've not seen any server implementation supporting
> >>> multiple mailbox patterns.
> ...
> > Yes, I think it could prove useful later, certainly. At this 
> stage,
> > it makes no real difference to clients, and it's additional
> > complexity for servers - and server developers have historically
> > preferred to avoid complexity at almost any cost.
> 
> But we've had a couple of comments to leave it.  Do we have a
> resolution for this issue?
> 
> 
I've seen very little comment. My general suspicion is that those 
server implementors who expressed any opinion at all aren't entirely 
happy with it. Personally, I'd be happy to leave it in, but I'll 
defer to the server folk.

> Dave has responded adequately to Arnaud's comments, so I'll refer to
> Dave's note on it:

> >>    * Page 14, paragraph \HasChildren, I think I disagree with the
> >>      security perspective
> > > Rereading this section, I note that "the server MUST return 
> these
> > attributes", but "a server MAY exclude both the [...] attributes".
> 
> I presume, Arnaud, that you're referring to the bit about returning
> \HasNoChildren if there are no children that the requester has 
> access
> to.  That statement represents established consensus here, so unless
> there are others who want to change it, it'll stay.
> 
> Dave, you're right that there's an unintended conflict there.  I 
> did a
> little rewording; let me know what you think of it.
> 
> 
Right. You're saying that in the case where some architectural issue 
means that the server simply cannot detirmine whether a mailbox has 
children or not, then it can omit both attributes.

I understand what you're trying to say, I'm just not clear on how 
that can arise. Specifically, if a mailbox A exists, but the server 
finds it impossible to provide either CHILDREN attribute, then surely 
it also cannot handle a subsequent LIST of A's inferior mailboxes?

I can certainly follow that it may be expensive to find the 
information, that it may be equivalent to performing the second LIST 
internally, etc, but if it were impossible, then the subsequent LIST 
would also be impossible.

If by impossible you mean "*really* difficult", then you're 
essentially licensing servers to omit both flags when they feel like 
it - this is actually acceptable to me in this case, I'd just like to 
understand this issue a little better.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 17 Jan 2006 17:15:57 -0500
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
From: "Dave Cridland" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Content-Class: urn:content-classes:message
Importance: normal
Status:   
Sender: [email-masked]

On Tue Jan 17 16:43:36 2006, Barry Leiba wrote:
> >> > but also because I spent some ten minutes
> >> > looking for the LIST response
> > > A note at the beginning in the introductory prose saying where 
> the
> > LIST response is defined is all that's needed.
> 
> Dave, see if you like what I've done.  I put text in both the ABNF
> introduction AND the definition of mailbox-list.
> 
> 
That looks good.

> >> I believe that no matter what happens to ACAP,
> 
> I've reworded the ACAP text; let me know if you think that's OK.
> 
> 
Better.

> > C) "none of them is" should be "none of them are".
> 
> Nah; "none" is singular, though it's acceptable to give it plural 
> usage
> if one likes that sort of thing.  Actually, I've instead changed the
> OTHER use of "none" to be singular, to match this one.
> 
> 
Fairy nuff.

> >>> a) So far, I've not seen any server implementation supporting
> >>> multiple mailbox patterns.
> ...
> > Yes, I think it could prove useful later, certainly. At this 
> stage,
> > it makes no real difference to clients, and it's additional
> > complexity for servers - and server developers have historically
> > preferred to avoid complexity at almost any cost.
> 
> But we've had a couple of comments to leave it.  Do we have a
> resolution for this issue?
> 
> 
I've seen very little comment. My general suspicion is that those 
server implementors who expressed any opinion at all aren't entirely 
happy with it. Personally, I'd be happy to leave it in, but I'll 
defer to the server folk.

> Dave has responded adequately to Arnaud's comments, so I'll refer to
> Dave's note on it:

> >>    * Page 14, paragraph \HasChildren, I think I disagree with the
> >>      security perspective
> > > Rereading this section, I note that "the server MUST return 
> these
> > attributes", but "a server MAY exclude both the [...] attributes".
> 
> I presume, Arnaud, that you're referring to the bit about returning
> \HasNoChildren if there are no children that the requester has 
> access
> to.  That statement represents established consensus here, so unless
> there are others who want to change it, it'll stay.
> 
> Dave, you're right that there's an unintended conflict there.  I 
> did a
> little rewording; let me know what you think of it.
> 
> 
Right. You're saying that in the case where some architectural issue 
means that the server simply cannot detirmine whether a mailbox has 
children or not, then it can omit both attributes.

I understand what you're trying to say, I'm just not clear on how 
that can arise. Specifically, if a mailbox A exists, but the server 
finds it impossible to provide either CHILDREN attribute, then surely 
it also cannot handle a subsequent LIST of A's inferior mailboxes?

I can certainly follow that it may be expensive to find the 
information, that it may be equivalent to performing the second LIST 
internally, etc, but if it were impossible, then the subsequent LIST 
would also be impossible.

If by impossible you mean "*really* difficult", then you're 
essentially licensing servers to omit both flags when they feel like 
it - this is actually acceptable to me in this case, I'd just like to 
understand this issue a little better.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 17 Jan 2006 17:00:38 -0500
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
From: "Dave Cridland" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Content-Class: urn:content-classes:message
Importance: normal
Status:   
Sender: [email-masked]

On Tue Jan 17 16:43:36 2006, Barry Leiba wrote:
> >> > but also because I spent some ten minutes
> >> > looking for the LIST response
> > > A note at the beginning in the introductory prose saying where 
> the
> > LIST response is defined is all that's needed.
> 
> Dave, see if you like what I've done.  I put text in both the ABNF
> introduction AND the definition of mailbox-list.
> 
> 
That looks good.

> >> I believe that no matter what happens to ACAP,
> 
> I've reworded the ACAP text; let me know if you think that's OK.
> 
> 
Better.

> > C) "none of them is" should be "none of them are".
> 
> Nah; "none" is singular, though it's acceptable to give it plural 
> usage
> if one likes that sort of thing.  Actually, I've instead changed the
> OTHER use of "none" to be singular, to match this one.
> 
> 
Fairy nuff.

> >>> a) So far, I've not seen any server implementation supporting
> >>> multiple mailbox patterns.
> ...
> > Yes, I think it could prove useful later, certainly. At this 
> stage,
> > it makes no real difference to clients, and it's additional
> > complexity for servers - and server developers have historically
> > preferred to avoid complexity at almost any cost.
> 
> But we've had a couple of comments to leave it.  Do we have a
> resolution for this issue?
> 
> 
I've seen very little comment. My general suspicion is that those 
server implementors who expressed any opinion at all aren't entirely 
happy with it. Personally, I'd be happy to leave it in, but I'll 
defer to the server folk.

> Dave has responded adequately to Arnaud's comments, so I'll refer to
> Dave's note on it:

> >>    * Page 14, paragraph \HasChildren, I think I disagree with the
> >>      security perspective
> > > Rereading this section, I note that "the server MUST return 
> these
> > attributes", but "a server MAY exclude both the [...] attributes".
> 
> I presume, Arnaud, that you're referring to the bit about returning
> \HasNoChildren if there are no children that the requester has 
> access
> to.  That statement represents established consensus here, so unless
> there are others who want to change it, it'll stay.
> 
> Dave, you're right that there's an unintended conflict there.  I 
> did a
> little rewording; let me know what you think of it.
> 
> 
Right. You're saying that in the case where some architectural issue 
means that the server simply cannot detirmine whether a mailbox has 
children or not, then it can omit both attributes.

I understand what you're trying to say, I'm just not clear on how 
that can arise. Specifically, if a mailbox A exists, but the server 
finds it impossible to provide either CHILDREN attribute, then surely 
it also cannot handle a subsequent LIST of A's inferior mailboxes?

I can certainly follow that it may be expensive to find the 
information, that it may be equivalent to performing the second LIST 
internally, etc, but if it were impossible, then the subsequent LIST 
would also be impossible.

If by impossible you mean "*really* difficult", then you're 
essentially licensing servers to omit both flags when they feel like 
it - this is actually acceptable to me in this case, I'd just like to 
understand this issue a little better.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 17 Jan 2006 16:46:26 -0500
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
From: "Dave Cridland" <[email-masked]>
Cc: <[email-masked]>
To: <[email-masked]>
Content-Class: urn:content-classes:message
Importance: normal
Status:   
Sender: [email-masked]

On Tue Jan 17 16:43:36 2006, Barry Leiba wrote:
> >> > but also because I spent some ten minutes
> >> > looking for the LIST response
> > > A note at the beginning in the introductory prose saying where 
> the
> > LIST response is defined is all that's needed.
> 
> Dave, see if you like what I've done.  I put text in both the ABNF
> introduction AND the definition of mailbox-list.
> 
> 
That looks good.

> >> I believe that no matter what happens to ACAP,
> 
> I've reworded the ACAP text; let me know if you think that's OK.
> 
> 
Better.

> > C) "none of them is" should be "none of them are".
> 
> Nah; "none" is singular, though it's acceptable to give it plural 
> usage
> if one likes that sort of thing.  Actually, I've instead changed the
> OTHER use of "none" to be singular, to match this one.
> 
> 
Fairy nuff.

> >>> a) So far, I've not seen any server implementation supporting
> >>> multiple mailbox patterns.
> ...
> > Yes, I think it could prove useful later, certainly. At this 
> stage,
> > it makes no real difference to clients, and it's additional
> > complexity for servers - and server developers have historically
> > preferred to avoid complexity at almost any cost.
> 
> But we've had a couple of comments to leave it.  Do we have a
> resolution for this issue?
> 
> 
I've seen very little comment. My general suspicion is that those 
server implementors who expressed any opinion at all aren't entirely 
happy with it. Personally, I'd be happy to leave it in, but I'll 
defer to the server folk.

> Dave has responded adequately to Arnaud's comments, so I'll refer to
> Dave's note on it:

> >>    * Page 14, paragraph \HasChildren, I think I disagree with the
> >>      security perspective
> > > Rereading this section, I note that "the server MUST return 
> these
> > attributes", but "a server MAY exclude both the [...] attributes".
> 
> I presume, Arnaud, that you're referring to the bit about returning
> \HasNoChildren if there are no children that the requester has 
> access
> to.  That statement represents established consensus here, so unless
> there are others who want to change it, it'll stay.
> 
> Dave, you're right that there's an unintended conflict there.  I 
> did a
> little rewording; let me know what you think of it.
> 
> 
Right. You're saying that in the case where some architectural issue 
means that the server simply cannot detirmine whether a mailbox has 
children or not, then it can omit both attributes.

I understand what you're trying to say, I'm just not clear on how 
that can arise. Specifically, if a mailbox A exists, but the server 
finds it impossible to provide either CHILDREN attribute, then surely 
it also cannot handle a subsequent LIST of A's inferior mailboxes?

I can certainly follow that it may be expensive to find the 
information, that it may be equivalent to performing the second LIST 
internally, etc, but if it were impossible, then the subsequent LIST 
would also be impossible.

If by impossible you mean "*really* difficult", then you're 
essentially licensing servers to omit both flags when they feel like 
it - this is actually acceptable to me in this case, I'd just like to 
understand this issue a little better.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 17 Jan 2006 16:31:24 -0500
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
From: "Dave Cridland" <[email-masked]>
Cc: <[email-masked]>
To: <[email-masked]>
Content-Class: urn:content-classes:message
Importance: normal
Status:   
Sender: [email-masked]

On Tue Jan 17 16:43:36 2006, Barry Leiba wrote:
> >> > but also because I spent some ten minutes
> >> > looking for the LIST response
> > > A note at the beginning in the introductory prose saying where 
> the
> > LIST response is defined is all that's needed.
> 
> Dave, see if you like what I've done.  I put text in both the ABNF
> introduction AND the definition of mailbox-list.
> 
> 
That looks good.

> >> I believe that no matter what happens to ACAP,
> 
> I've reworded the ACAP text; let me know if you think that's OK.
> 
> 
Better.

> > C) "none of them is" should be "none of them are".
> 
> Nah; "none" is singular, though it's acceptable to give it plural 
> usage
> if one likes that sort of thing.  Actually, I've instead changed the
> OTHER use of "none" to be singular, to match this one.
> 
> 
Fairy nuff.

> >>> a) So far, I've not seen any server implementation supporting
> >>> multiple mailbox patterns.
> ...
> > Yes, I think it could prove useful later, certainly. At this 
> stage,
> > it makes no real difference to clients, and it's additional
> > complexity for servers - and server developers have historically
> > preferred to avoid complexity at almost any cost.
> 
> But we've had a couple of comments to leave it.  Do we have a
> resolution for this issue?
> 
> 
I've seen very little comment. My general suspicion is that those 
server implementors who expressed any opinion at all aren't entirely 
happy with it. Personally, I'd be happy to leave it in, but I'll 
defer to the server folk.

> Dave has responded adequately to Arnaud's comments, so I'll refer to
> Dave's note on it:

> >>    * Page 14, paragraph \HasChildren, I think I disagree with the
> >>      security perspective
> > > Rereading this section, I note that "the server MUST return 
> these
> > attributes", but "a server MAY exclude both the [...] attributes".
> 
> I presume, Arnaud, that you're referring to the bit about returning
> \HasNoChildren if there are no children that the requester has 
> access
> to.  That statement represents established consensus here, so unless
> there are others who want to change it, it'll stay.
> 
> Dave, you're right that there's an unintended conflict there.  I 
> did a
> little rewording; let me know what you think of it.
> 
> 
Right. You're saying that in the case where some architectural issue 
means that the server simply cannot detirmine whether a mailbox has 
children or not, then it can omit both attributes.

I understand what you're trying to say, I'm just not clear on how 
that can arise. Specifically, if a mailbox A exists, but the server 
finds it impossible to provide either CHILDREN attribute, then surely 
it also cannot handle a subsequent LIST of A's inferior mailboxes?

I can certainly follow that it may be expensive to find the 
information, that it may be equivalent to performing the second LIST 
internally, etc, but if it were impossible, then the subsequent LIST 
would also be impossible.

If by impossible you mean "*really* difficult", then you're 
essentially licensing servers to omit both flags when they feel like 
it - this is actually acceptable to me in this case, I'd just like to 
understand this issue a little better.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 17 Jan 2006 16:15:41 -0500
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
From: "Dave Cridland" <[email-masked]>
Cc: <[email-masked]>
To: <[email-masked]>
Content-Class: urn:content-classes:message
Importance: normal
Status:   
Sender: [email-masked]

On Tue Jan 17 16:43:36 2006, Barry Leiba wrote:
> >> > but also because I spent some ten minutes
> >> > looking for the LIST response
> > > A note at the beginning in the introductory prose saying where 
> the
> > LIST response is defined is all that's needed.
> 
> Dave, see if you like what I've done.  I put text in both the ABNF
> introduction AND the definition of mailbox-list.
> 
> 
That looks good.

> >> I believe that no matter what happens to ACAP,
> 
> I've reworded the ACAP text; let me know if you think that's OK.
> 
> 
Better.

> > C) "none of them is" should be "none of them are".
> 
> Nah; "none" is singular, though it's acceptable to give it plural 
> usage
> if one likes that sort of thing.  Actually, I've instead changed the
> OTHER use of "none" to be singular, to match this one.
> 
> 
Fairy nuff.

> >>> a) So far, I've not seen any server implementation supporting
> >>> multiple mailbox patterns.
> ...
> > Yes, I think it could prove useful later, certainly. At this 
> stage,
> > it makes no real difference to clients, and it's additional
> > complexity for servers - and server developers have historically
> > preferred to avoid complexity at almost any cost.
> 
> But we've had a couple of comments to leave it.  Do we have a
> resolution for this issue?
> 
> 
I've seen very little comment. My general suspicion is that those 
server implementors who expressed any opinion at all aren't entirely 
happy with it. Personally, I'd be happy to leave it in, but I'll 
defer to the server folk.

> Dave has responded adequately to Arnaud's comments, so I'll refer to
> Dave's note on it:

> >>    * Page 14, paragraph \HasChildren, I think I disagree with the
> >>      security perspective
> > > Rereading this section, I note that "the server MUST return 
> these
> > attributes", but "a server MAY exclude both the [...] attributes".
> 
> I presume, Arnaud, that you're referring to the bit about returning
> \HasNoChildren if there are no children that the requester has 
> access
> to.  That statement represents established consensus here, so unless
> there are others who want to change it, it'll stay.
> 
> Dave, you're right that there's an unintended conflict there.  I 
> did a
> little rewording; let me know what you think of it.
> 
> 
Right. You're saying that in the case where some architectural issue 
means that the server simply cannot detirmine whether a mailbox has 
children or not, then it can omit both attributes.

I understand what you're trying to say, I'm just not clear on how 
that can arise. Specifically, if a mailbox A exists, but the server 
finds it impossible to provide either CHILDREN attribute, then surely 
it also cannot handle a subsequent LIST of A's inferior mailboxes?

I can certainly follow that it may be expensive to find the 
information, that it may be equivalent to performing the second LIST 
internally, etc, but if it were impossible, then the subsequent LIST 
would also be impossible.

If by impossible you mean "*really* difficult", then you're 
essentially licensing servers to omit both flags when they feel like 
it - this is actually acceptable to me in this case, I'd just like to 
understand this issue a little better.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 17 Jan 2006 16:00:19 -0500
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
From: "Dave Cridland" <[email-masked]>
Cc: <[email-masked]>
To: <[email-masked]>
Content-Class: urn:content-classes:message
Importance: normal
Status:   
Sender: [email-masked]

On Tue Jan 17 16:43:36 2006, Barry Leiba wrote:
> >> > but also because I spent some ten minutes
> >> > looking for the LIST response
> > > A note at the beginning in the introductory prose saying where 
> the
> > LIST response is defined is all that's needed.
> 
> Dave, see if you like what I've done.  I put text in both the ABNF
> introduction AND the definition of mailbox-list.
> 
> 
That looks good.

> >> I believe that no matter what happens to ACAP,
> 
> I've reworded the ACAP text; let me know if you think that's OK.
> 
> 
Better.

> > C) "none of them is" should be "none of them are".
> 
> Nah; "none" is singular, though it's acceptable to give it plural 
> usage
> if one likes that sort of thing.  Actually, I've instead changed the
> OTHER use of "none" to be singular, to match this one.
> 
> 
Fairy nuff.

> >>> a) So far, I've not seen any server implementation supporting
> >>> multiple mailbox patterns.
> ...
> > Yes, I think it could prove useful later, certainly. At this 
> stage,
> > it makes no real difference to clients, and it's additional
> > complexity for servers - and server developers have historically
> > preferred to avoid complexity at almost any cost.
> 
> But we've had a couple of comments to leave it.  Do we have a
> resolution for this issue?
> 
> 
I've seen very little comment. My general suspicion is that those 
server implementors who expressed any opinion at all aren't entirely 
happy with it. Personally, I'd be happy to leave it in, but I'll 
defer to the server folk.

> Dave has responded adequately to Arnaud's comments, so I'll refer to
> Dave's note on it:

> >>    * Page 14, paragraph \HasChildren, I think I disagree with the
> >>      security perspective
> > > Rereading this section, I note that "the server MUST return 
> these
> > attributes", but "a server MAY exclude both the [...] attributes".
> 
> I presume, Arnaud, that you're referring to the bit about returning
> \HasNoChildren if there are no children that the requester has 
> access
> to.  That statement represents established consensus here, so unless
> there are others who want to change it, it'll stay.
> 
> Dave, you're right that there's an unintended conflict there.  I 
> did a
> little rewording; let me know what you think of it.
> 
> 
Right. You're saying that in the case where some architectural issue 
means that the server simply cannot detirmine whether a mailbox has 
children or not, then it can omit both attributes.

I understand what you're trying to say, I'm just not clear on how 
that can arise. Specifically, if a mailbox A exists, but the server 
finds it impossible to provide either CHILDREN attribute, then surely 
it also cannot handle a subsequent LIST of A's inferior mailboxes?

I can certainly follow that it may be expensive to find the 
information, that it may be equivalent to performing the second LIST 
internally, etc, but if it were impossible, then the subsequent LIST 
would also be impossible.

If by impossible you mean "*really* difficult", then you're 
essentially licensing servers to omit both flags when they feel like 
it - this is actually acceptable to me in this case, I'd just like to 
understand this issue a little better.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 17 Jan 2006 15:46:08 -0500
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
From: "Dave Cridland" <[email-masked]>
Cc: <[email-masked]>
To: <[email-masked]>
Content-Class: urn:content-classes:message
Importance: normal
Status:   
Sender: [email-masked]

On Tue Jan 17 16:43:36 2006, Barry Leiba wrote:
> >> > but also because I spent some ten minutes
> >> > looking for the LIST response
> > > A note at the beginning in the introductory prose saying where 
> the
> > LIST response is defined is all that's needed.
> 
> Dave, see if you like what I've done.  I put text in both the ABNF
> introduction AND the definition of mailbox-list.
> 
> 
That looks good.

> >> I believe that no matter what happens to ACAP,
> 
> I've reworded the ACAP text; let me know if you think that's OK.
> 
> 
Better.

> > C) "none of them is" should be "none of them are".
> 
> Nah; "none" is singular, though it's acceptable to give it plural 
> usage
> if one likes that sort of thing.  Actually, I've instead changed the
> OTHER use of "none" to be singular, to match this one.
> 
> 
Fairy nuff.

> >>> a) So far, I've not seen any server implementation supporting
> >>> multiple mailbox patterns.
> ...
> > Yes, I think it could prove useful later, certainly. At this 
> stage,
> > it makes no real difference to clients, and it's additional
> > complexity for servers - and server developers have historically
> > preferred to avoid complexity at almost any cost.
> 
> But we've had a couple of comments to leave it.  Do we have a
> resolution for this issue?
> 
> 
I've seen very little comment. My general suspicion is that those 
server implementors who expressed any opinion at all aren't entirely 
happy with it. Personally, I'd be happy to leave it in, but I'll 
defer to the server folk.

> Dave has responded adequately to Arnaud's comments, so I'll refer to
> Dave's note on it:

> >>    * Page 14, paragraph \HasChildren, I think I disagree with the
> >>      security perspective
> > > Rereading this section, I note that "the server MUST return 
> these
> > attributes", but "a server MAY exclude both the [...] attributes".
> 
> I presume, Arnaud, that you're referring to the bit about returning
> \HasNoChildren if there are no children that the requester has 
> access
> to.  That statement represents established consensus here, so unless
> there are others who want to change it, it'll stay.
> 
> Dave, you're right that there's an unintended conflict there.  I 
> did a
> little rewording; let me know what you think of it.
> 
> 
Right. You're saying that in the case where some architectural issue 
means that the server simply cannot detirmine whether a mailbox has 
children or not, then it can omit both attributes.

I understand what you're trying to say, I'm just not clear on how 
that can arise. Specifically, if a mailbox A exists, but the server 
finds it impossible to provide either CHILDREN attribute, then surely 
it also cannot handle a subsequent LIST of A's inferior mailboxes?

I can certainly follow that it may be expensive to find the 
information, that it may be equivalent to performing the second LIST 
internally, etc, but if it were impossible, then the subsequent LIST 
would also be impossible.

If by impossible you mean "*really* difficult", then you're 
essentially licensing servers to omit both flags when they feel like 
it - this is actually acceptable to me in this case, I'd just like to 
understand this issue a little better.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 17 Jan 2006 15:30:57 -0500
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
From: "Dave Cridland" <[email-masked]>
Cc: <[email-masked]>
To: <[email-masked]>
Content-Class: urn:content-classes:message
Importance: normal
Status:   
Sender: [email-masked]

On Tue Jan 17 16:43:36 2006, Barry Leiba wrote:
> >> > but also because I spent some ten minutes
> >> > looking for the LIST response
> > > A note at the beginning in the introductory prose saying where 
> the
> > LIST response is defined is all that's needed.
> 
> Dave, see if you like what I've done.  I put text in both the ABNF
> introduction AND the definition of mailbox-list.
> 
> 
That looks good.

> >> I believe that no matter what happens to ACAP,
> 
> I've reworded the ACAP text; let me know if you think that's OK.
> 
> 
Better.

> > C) "none of them is" should be "none of them are".
> 
> Nah; "none" is singular, though it's acceptable to give it plural 
> usage
> if one likes that sort of thing.  Actually, I've instead changed the
> OTHER use of "none" to be singular, to match this one.
> 
> 
Fairy nuff.

> >>> a) So far, I've not seen any server implementation supporting
> >>> multiple mailbox patterns.
> ...
> > Yes, I think it could prove useful later, certainly. At this 
> stage,
> > it makes no real difference to clients, and it's additional
> > complexity for servers - and server developers have historically
> > preferred to avoid complexity at almost any cost.
> 
> But we've had a couple of comments to leave it.  Do we have a
> resolution for this issue?
> 
> 
I've seen very little comment. My general suspicion is that those 
server implementors who expressed any opinion at all aren't entirely 
happy with it. Personally, I'd be happy to leave it in, but I'll 
defer to the server folk.

> Dave has responded adequately to Arnaud's comments, so I'll refer to
> Dave's note on it:

> >>    * Page 14, paragraph \HasChildren, I think I disagree with the
> >>      security perspective
> > > Rereading this section, I note that "the server MUST return 
> these
> > attributes", but "a server MAY exclude both the [...] attributes".
> 
> I presume, Arnaud, that you're referring to the bit about returning
> \HasNoChildren if there are no children that the requester has 
> access
> to.  That statement represents established consensus here, so unless
> there are others who want to change it, it'll stay.
> 
> Dave, you're right that there's an unintended conflict there.  I 
> did a
> little rewording; let me know what you think of it.
> 
> 
Right. You're saying that in the case where some architectural issue 
means that the server simply cannot detirmine whether a mailbox has 
children or not, then it can omit both attributes.

I understand what you're trying to say, I'm just not clear on how 
that can arise. Specifically, if a mailbox A exists, but the server 
finds it impossible to provide either CHILDREN attribute, then surely 
it also cannot handle a subsequent LIST of A's inferior mailboxes?

I can certainly follow that it may be expensive to find the 
information, that it may be equivalent to performing the second LIST 
internally, etc, but if it were impossible, then the subsequent LIST 
would also be impossible.

If by impossible you mean "*really* difficult", then you're 
essentially licensing servers to omit both flags when they feel like 
it - this is actually acceptable to me in this case, I'd just like to 
understand this issue a little better.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 17 Jan 2006 15:15:23 -0500
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
From: "Dave Cridland" <[email-masked]>
Cc: <[email-masked]>
To: <[email-masked]>
Content-Class: urn:content-classes:message
Importance: normal
Status:   
Sender: [email-masked]

On Tue Jan 17 16:43:36 2006, Barry Leiba wrote:
> >> > but also because I spent some ten minutes
> >> > looking for the LIST response
> > > A note at the beginning in the introductory prose saying where 
> the
> > LIST response is defined is all that's needed.
> 
> Dave, see if you like what I've done.  I put text in both the ABNF
> introduction AND the definition of mailbox-list.
> 
> 
That looks good.

> >> I believe that no matter what happens to ACAP,
> 
> I've reworded the ACAP text; let me know if you think that's OK.
> 
> 
Better.

> > C) "none of them is" should be "none of them are".
> 
> Nah; "none" is singular, though it's acceptable to give it plural 
> usage
> if one likes that sort of thing.  Actually, I've instead changed the
> OTHER use of "none" to be singular, to match this one.
> 
> 
Fairy nuff.

> >>> a) So far, I've not seen any server implementation supporting
> >>> multiple mailbox patterns.
> ...
> > Yes, I think it could prove useful later, certainly. At this 
> stage,
> > it makes no real difference to clients, and it's additional
> > complexity for servers - and server developers have historically
> > preferred to avoid complexity at almost any cost.
> 
> But we've had a couple of comments to leave it.  Do we have a
> resolution for this issue?
> 
> 
I've seen very little comment. My general suspicion is that those 
server implementors who expressed any opinion at all aren't entirely 
happy with it. Personally, I'd be happy to leave it in, but I'll 
defer to the server folk.

> Dave has responded adequately to Arnaud's comments, so I'll refer to
> Dave's note on it:

> >>    * Page 14, paragraph \HasChildren, I think I disagree with the
> >>      security perspective
> > > Rereading this section, I note that "the server MUST return 
> these
> > attributes", but "a server MAY exclude both the [...] attributes".
> 
> I presume, Arnaud, that you're referring to the bit about returning
> \HasNoChildren if there are no children that the requester has 
> access
> to.  That statement represents established consensus here, so unless
> there are others who want to change it, it'll stay.
> 
> Dave, you're right that there's an unintended conflict there.  I 
> did a
> little rewording; let me know what you think of it.
> 
> 
Right. You're saying that in the case where some architectural issue 
means that the server simply cannot detirmine whether a mailbox has 
children or not, then it can omit both attributes.

I understand what you're trying to say, I'm just not clear on how 
that can arise. Specifically, if a mailbox A exists, but the server 
finds it impossible to provide either CHILDREN attribute, then surely 
it also cannot handle a subsequent LIST of A's inferior mailboxes?

I can certainly follow that it may be expensive to find the 
information, that it may be equivalent to performing the second LIST 
internally, etc, but if it were impossible, then the subsequent LIST 
would also be impossible.

If by impossible you mean "*really* difficult", then you're 
essentially licensing servers to omit both flags when they feel like 
it - this is actually acceptable to me in this case, I'd just like to 
understand this issue a little better.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 17 Jan 2006 15:01:02 -0500
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
From: "Dave Cridland" <[email-masked]>
Cc: <[email-masked]>
To: <[email-masked]>
Content-Class: urn:content-classes:message
Importance: normal
Status:   
Sender: [email-masked]

On Tue Jan 17 16:43:36 2006, Barry Leiba wrote:
> >> > but also because I spent some ten minutes
> >> > looking for the LIST response
> > > A note at the beginning in the introductory prose saying where 
> the
> > LIST response is defined is all that's needed.
> 
> Dave, see if you like what I've done.  I put text in both the ABNF
> introduction AND the definition of mailbox-list.
> 
> 
That looks good.

> >> I believe that no matter what happens to ACAP,
> 
> I've reworded the ACAP text; let me know if you think that's OK.
> 
> 
Better.

> > C) "none of them is" should be "none of them are".
> 
> Nah; "none" is singular, though it's acceptable to give it plural 
> usage
> if one likes that sort of thing.  Actually, I've instead changed the
> OTHER use of "none" to be singular, to match this one.
> 
> 
Fairy nuff.

> >>> a) So far, I've not seen any server implementation supporting
> >>> multiple mailbox patterns.
> ...
> > Yes, I think it could prove useful later, certainly. At this 
> stage,
> > it makes no real difference to clients, and it's additional
> > complexity for servers - and server developers have historically
> > preferred to avoid complexity at almost any cost.
> 
> But we've had a couple of comments to leave it.  Do we have a
> resolution for this issue?
> 
> 
I've seen very little comment. My general suspicion is that those 
server implementors who expressed any opinion at all aren't entirely 
happy with it. Personally, I'd be happy to leave it in, but I'll 
defer to the server folk.

> Dave has responded adequately to Arnaud's comments, so I'll refer to
> Dave's note on it:

> >>    * Page 14, paragraph \HasChildren, I think I disagree with the
> >>      security perspective
> > > Rereading this section, I note that "the server MUST return 
> these
> > attributes", but "a server MAY exclude both the [...] attributes".
> 
> I presume, Arnaud, that you're referring to the bit about returning
> \HasNoChildren if there are no children that the requester has 
> access
> to.  That statement represents established consensus here, so unless
> there are others who want to change it, it'll stay.
> 
> Dave, you're right that there's an unintended conflict there.  I 
> did a
> little rewording; let me know what you think of it.
> 
> 
Right. You're saying that in the case where some architectural issue 
means that the server simply cannot detirmine whether a mailbox has 
children or not, then it can omit both attributes.

I understand what you're trying to say, I'm just not clear on how 
that can arise. Specifically, if a mailbox A exists, but the server 
finds it impossible to provide either CHILDREN attribute, then surely 
it also cannot handle a subsequent LIST of A's inferior mailboxes?

I can certainly follow that it may be expensive to find the 
information, that it may be equivalent to performing the second LIST 
internally, etc, but if it were impossible, then the subsequent LIST 
would also be impossible.

If by impossible you mean "*really* difficult", then you're 
essentially licensing servers to omit both flags when they feel like 
it - this is actually acceptable to me in this case, I'd just like to 
understand this issue a little better.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 17 Jan 2006 14:45:40 -0500
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
From: "Dave Cridland" <[email-masked]>
Cc: <[email-masked]>
To: <[email-masked]>
Content-class: urn:content-classes:message
Importance: normal
Status:   
Sender: [email-masked]

On Tue Jan 17 16:43:36 2006, Barry Leiba wrote:
> >> > but also because I spent some ten minutes
> >> > looking for the LIST response
> > > A note at the beginning in the introductory prose saying where 
> the
> > LIST response is defined is all that's needed.
> 
> Dave, see if you like what I've done.  I put text in both the ABNF
> introduction AND the definition of mailbox-list.
> 
> 
That looks good.

> >> I believe that no matter what happens to ACAP,
> 
> I've reworded the ACAP text; let me know if you think that's OK.
> 
> 
Better.

> > C) "none of them is" should be "none of them are".
> 
> Nah; "none" is singular, though it's acceptable to give it plural 
> usage
> if one likes that sort of thing.  Actually, I've instead changed the
> OTHER use of "none" to be singular, to match this one.
> 
> 
Fairy nuff.

> >>> a) So far, I've not seen any server implementation supporting
> >>> multiple mailbox patterns.
> ...
> > Yes, I think it could prove useful later, certainly. At this 
> stage,
> > it makes no real difference to clients, and it's additional
> > complexity for servers - and server developers have historically
> > preferred to avoid complexity at almost any cost.
> 
> But we've had a couple of comments to leave it.  Do we have a
> resolution for this issue?
> 
> 
I've seen very little comment. My general suspicion is that those 
server implementors who expressed any opinion at all aren't entirely 
happy with it. Personally, I'd be happy to leave it in, but I'll 
defer to the server folk.

> Dave has responded adequately to Arnaud's comments, so I'll refer to
> Dave's note on it:

> >>    * Page 14, paragraph \HasChildren, I think I disagree with the
> >>      security perspective
> > > Rereading this section, I note that "the server MUST return 
> these
> > attributes", but "a server MAY exclude both the [...] attributes".
> 
> I presume, Arnaud, that you're referring to the bit about returning
> \HasNoChildren if there are no children that the requester has 
> access
> to.  That statement represents established consensus here, so unless
> there are others who want to change it, it'll stay.
> 
> Dave, you're right that there's an unintended conflict there.  I 
> did a
> little rewording; let me know what you think of it.
> 
> 
Right. You're saying that in the case where some architectural issue 
means that the server simply cannot detirmine whether a mailbox has 
children or not, then it can omit both attributes.

I understand what you're trying to say, I'm just not clear on how 
that can arise. Specifically, if a mailbox A exists, but the server 
finds it impossible to provide either CHILDREN attribute, then surely 
it also cannot handle a subsequent LIST of A's inferior mailboxes?

I can certainly follow that it may be expensive to find the 
information, that it may be equivalent to performing the second LIST 
internally, etc, but if it were impossible, then the subsequent LIST 
would also be impossible.

If by impossible you mean "*really* difficult", then you're 
essentially licensing servers to omit both flags when they feel like 
it - this is actually acceptable to me in this case, I'd just like to 
understand this issue a little better.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 17 Jan 2006 14:30:29 -0500
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
From: "Dave Cridland" <[email-masked]>
Cc: <[email-masked]>
To: <[email-masked]>
Content-Class: urn:content-classes:message
Importance: normal
Status:   
Sender: [email-masked]

On Tue Jan 17 16:43:36 2006, Barry Leiba wrote:
> >> > but also because I spent some ten minutes
> >> > looking for the LIST response
> > > A note at the beginning in the introductory prose saying where 
> the
> > LIST response is defined is all that's needed.
> 
> Dave, see if you like what I've done.  I put text in both the ABNF
> introduction AND the definition of mailbox-list.
> 
> 
That looks good.

> >> I believe that no matter what happens to ACAP,
> 
> I've reworded the ACAP text; let me know if you think that's OK.
> 
> 
Better.

> > C) "none of them is" should be "none of them are".
> 
> Nah; "none" is singular, though it's acceptable to give it plural 
> usage
> if one likes that sort of thing.  Actually, I've instead changed the
> OTHER use of "none" to be singular, to match this one.
> 
> 
Fairy nuff.

> >>> a) So far, I've not seen any server implementation supporting
> >>> multiple mailbox patterns.
> ...
> > Yes, I think it could prove useful later, certainly. At this 
> stage,
> > it makes no real difference to clients, and it's additional
> > complexity for servers - and server developers have historically
> > preferred to avoid complexity at almost any cost.
> 
> But we've had a couple of comments to leave it.  Do we have a
> resolution for this issue?
> 
> 
I've seen very little comment. My general suspicion is that those 
server implementors who expressed any opinion at all aren't entirely 
happy with it. Personally, I'd be happy to leave it in, but I'll 
defer to the server folk.

> Dave has responded adequately to Arnaud's comments, so I'll refer to
> Dave's note on it:

> >>    * Page 14, paragraph \HasChildren, I think I disagree with the
> >>      security perspective
> > > Rereading this section, I note that "the server MUST return 
> these
> > attributes", but "a server MAY exclude both the [...] attributes".
> 
> I presume, Arnaud, that you're referring to the bit about returning
> \HasNoChildren if there are no children that the requester has 
> access
> to.  That statement represents established consensus here, so unless
> there are others who want to change it, it'll stay.
> 
> Dave, you're right that there's an unintended conflict there.  I 
> did a
> little rewording; let me know what you think of it.
> 
> 
Right. You're saying that in the case where some architectural issue 
means that the server simply cannot detirmine whether a mailbox has 
children or not, then it can omit both attributes.

I understand what you're trying to say, I'm just not clear on how 
that can arise. Specifically, if a mailbox A exists, but the server 
finds it impossible to provide either CHILDREN attribute, then surely 
it also cannot handle a subsequent LIST of A's inferior mailboxes?

I can certainly follow that it may be expensive to find the 
information, that it may be equivalent to performing the second LIST 
internally, etc, but if it were impossible, then the subsequent LIST 
would also be impossible.

If by impossible you mean "*really* difficult", then you're 
essentially licensing servers to omit both flags when they feel like 
it - this is actually acceptable to me in this case, I'd just like to 
understand this issue a little better.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 17 Jan 2006 14:15:36 -0500
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
From: "Dave Cridland" <[email-masked]>
Cc: <[email-masked]>
To: <[email-masked]>
Content-Class: urn:content-classes:message
Importance: normal
Status:   
Sender: [email-masked]

On Tue Jan 17 16:43:36 2006, Barry Leiba wrote:
> >> > but also because I spent some ten minutes
> >> > looking for the LIST response
> > > A note at the beginning in the introductory prose saying where 
> the
> > LIST response is defined is all that's needed.
> 
> Dave, see if you like what I've done.  I put text in both the ABNF
> introduction AND the definition of mailbox-list.
> 
> 
That looks good.

> >> I believe that no matter what happens to ACAP,
> 
> I've reworded the ACAP text; let me know if you think that's OK.
> 
> 
Better.

> > C) "none of them is" should be "none of them are".
> 
> Nah; "none" is singular, though it's acceptable to give it plural 
> usage
> if one likes that sort of thing.  Actually, I've instead changed the
> OTHER use of "none" to be singular, to match this one.
> 
> 
Fairy nuff.

> >>> a) So far, I've not seen any server implementation supporting
> >>> multiple mailbox patterns.
> ...
> > Yes, I think it could prove useful later, certainly. At this 
> stage,
> > it makes no real difference to clients, and it's additional
> > complexity for servers - and server developers have historically
> > preferred to avoid complexity at almost any cost.
> 
> But we've had a couple of comments to leave it.  Do we have a
> resolution for this issue?
> 
> 
I've seen very little comment. My general suspicion is that those 
server implementors who expressed any opinion at all aren't entirely 
happy with it. Personally, I'd be happy to leave it in, but I'll 
defer to the server folk.

> Dave has responded adequately to Arnaud's comments, so I'll refer to
> Dave's note on it:

> >>    * Page 14, paragraph \HasChildren, I think I disagree with the
> >>      security perspective
> > > Rereading this section, I note that "the server MUST return 
> these
> > attributes", but "a server MAY exclude both the [...] attributes".
> 
> I presume, Arnaud, that you're referring to the bit about returning
> \HasNoChildren if there are no children that the requester has 
> access
> to.  That statement represents established consensus here, so unless
> there are others who want to change it, it'll stay.
> 
> Dave, you're right that there's an unintended conflict there.  I 
> did a
> little rewording; let me know what you think of it.
> 
> 
Right. You're saying that in the case where some architectural issue 
means that the server simply cannot detirmine whether a mailbox has 
children or not, then it can omit both attributes.

I understand what you're trying to say, I'm just not clear on how 
that can arise. Specifically, if a mailbox A exists, but the server 
finds it impossible to provide either CHILDREN attribute, then surely 
it also cannot handle a subsequent LIST of A's inferior mailboxes?

I can certainly follow that it may be expensive to find the 
information, that it may be equivalent to performing the second LIST 
internally, etc, but if it were impossible, then the subsequent LIST 
would also be impossible.

If by impossible you mean "*really* difficult", then you're 
essentially licensing servers to omit both flags when they feel like 
it - this is actually acceptable to me in this case, I'd just like to 
understand this issue a little better.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 17 Jan 2006 14:00:15 -0500
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
From: "Dave Cridland" <[email-masked]>
Cc: <[email-masked]>
To: <[email-masked]>
Content-Class: urn:content-classes:message
Importance: normal
Status:   
Sender: [email-masked]

On Tue Jan 17 16:43:36 2006, Barry Leiba wrote:
> >> > but also because I spent some ten minutes
> >> > looking for the LIST response
> > > A note at the beginning in the introductory prose saying where 
> the
> > LIST response is defined is all that's needed.
> 
> Dave, see if you like what I've done.  I put text in both the ABNF
> introduction AND the definition of mailbox-list.
> 
> 
That looks good.

> >> I believe that no matter what happens to ACAP,
> 
> I've reworded the ACAP text; let me know if you think that's OK.
> 
> 
Better.

> > C) "none of them is" should be "none of them are".
> 
> Nah; "none" is singular, though it's acceptable to give it plural 
> usage
> if one likes that sort of thing.  Actually, I've instead changed the
> OTHER use of "none" to be singular, to match this one.
> 
> 
Fairy nuff.

> >>> a) So far, I've not seen any server implementation supporting
> >>> multiple mailbox patterns.
> ...
> > Yes, I think it could prove useful later, certainly. At this 
> stage,
> > it makes no real difference to clients, and it's additional
> > complexity for servers - and server developers have historically
> > preferred to avoid complexity at almost any cost.
> 
> But we've had a couple of comments to leave it.  Do we have a
> resolution for this issue?
> 
> 
I've seen very little comment. My general suspicion is that those 
server implementors who expressed any opinion at all aren't entirely 
happy with it. Personally, I'd be happy to leave it in, but I'll 
defer to the server folk.

> Dave has responded adequately to Arnaud's comments, so I'll refer to
> Dave's note on it:

> >>    * Page 14, paragraph \HasChildren, I think I disagree with the
> >>      security perspective
> > > Rereading this section, I note that "the server MUST return 
> these
> > attributes", but "a server MAY exclude both the [...] attributes".
> 
> I presume, Arnaud, that you're referring to the bit about returning
> \HasNoChildren if there are no children that the requester has 
> access
> to.  That statement represents established consensus here, so unless
> there are others who want to change it, it'll stay.
> 
> Dave, you're right that there's an unintended conflict there.  I 
> did a
> little rewording; let me know what you think of it.
> 
> 
Right. You're saying that in the case where some architectural issue 
means that the server simply cannot detirmine whether a mailbox has 
children or not, then it can omit both attributes.

I understand what you're trying to say, I'm just not clear on how 
that can arise. Specifically, if a mailbox A exists, but the server 
finds it impossible to provide either CHILDREN attribute, then surely 
it also cannot handle a subsequent LIST of A's inferior mailboxes?

I can certainly follow that it may be expensive to find the 
information, that it may be equivalent to performing the second LIST 
internally, etc, but if it were impossible, then the subsequent LIST 
would also be impossible.

If by impossible you mean "*really* difficult", then you're 
essentially licensing servers to omit both flags when they feel like 
it - this is actually acceptable to me in this case, I'd just like to 
understand this issue a little better.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 17 Jan 2006 13:46:04 -0500
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
From: "Dave Cridland" <[email-masked]>
Cc: <[email-masked]>
To: <[email-masked]>
Content-Class: urn:content-classes:message
Importance: normal
Status:   
Sender: [email-masked]

On Tue Jan 17 16:43:36 2006, Barry Leiba wrote:
> >> > but also because I spent some ten minutes
> >> > looking for the LIST response
> > > A note at the beginning in the introductory prose saying where 
> the
> > LIST response is defined is all that's needed.
> 
> Dave, see if you like what I've done.  I put text in both the ABNF
> introduction AND the definition of mailbox-list.
> 
> 
That looks good.

> >> I believe that no matter what happens to ACAP,
> 
> I've reworded the ACAP text; let me know if you think that's OK.
> 
> 
Better.

> > C) "none of them is" should be "none of them are".
> 
> Nah; "none" is singular, though it's acceptable to give it plural 
> usage
> if one likes that sort of thing.  Actually, I've instead changed the
> OTHER use of "none" to be singular, to match this one.
> 
> 
Fairy nuff.

> >>> a) So far, I've not seen any server implementation supporting
> >>> multiple mailbox patterns.
> ...
> > Yes, I think it could prove useful later, certainly. At this 
> stage,
> > it makes no real difference to clients, and it's additional
> > complexity for servers - and server developers have historically
> > preferred to avoid complexity at almost any cost.
> 
> But we've had a couple of comments to leave it.  Do we have a
> resolution for this issue?
> 
> 
I've seen very little comment. My general suspicion is that those 
server implementors who expressed any opinion at all aren't entirely 
happy with it. Personally, I'd be happy to leave it in, but I'll 
defer to the server folk.

> Dave has responded adequately to Arnaud's comments, so I'll refer to
> Dave's note on it:

> >>    * Page 14, paragraph \HasChildren, I think I disagree with the
> >>      security perspective
> > > Rereading this section, I note that "the server MUST return 
> these
> > attributes", but "a server MAY exclude both the [...] attributes".
> 
> I presume, Arnaud, that you're referring to the bit about returning
> \HasNoChildren if there are no children that the requester has 
> access
> to.  That statement represents established consensus here, so unless
> there are others who want to change it, it'll stay.
> 
> Dave, you're right that there's an unintended conflict there.  I 
> did a
> little rewording; let me know what you think of it.
> 
> 
Right. You're saying that in the case where some architectural issue 
means that the server simply cannot detirmine whether a mailbox has 
children or not, then it can omit both attributes.

I understand what you're trying to say, I'm just not clear on how 
that can arise. Specifically, if a mailbox A exists, but the server 
finds it impossible to provide either CHILDREN attribute, then surely 
it also cannot handle a subsequent LIST of A's inferior mailboxes?

I can certainly follow that it may be expensive to find the 
information, that it may be equivalent to performing the second LIST 
internally, etc, but if it were impossible, then the subsequent LIST 
would also be impossible.

If by impossible you mean "*really* difficult", then you're 
essentially licensing servers to omit both flags when they feel like 
it - this is actually acceptable to me in this case, I'd just like to 
understand this issue a little better.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 17 Jan 2006 13:30:42 -0500
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
From: "Dave Cridland" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Content-Class: urn:content-classes:message
Importance: normal
Status:   
Sender: [email-masked]

On Tue Jan 17 16:43:36 2006, Barry Leiba wrote:
> >> > but also because I spent some ten minutes
> >> > looking for the LIST response
> > > A note at the beginning in the introductory prose saying where 
> the
> > LIST response is defined is all that's needed.
> 
> Dave, see if you like what I've done.  I put text in both the ABNF
> introduction AND the definition of mailbox-list.
> 
> 
That looks good.

> >> I believe that no matter what happens to ACAP,
> 
> I've reworded the ACAP text; let me know if you think that's OK.
> 
> 
Better.

> > C) "none of them is" should be "none of them are".
> 
> Nah; "none" is singular, though it's acceptable to give it plural 
> usage
> if one likes that sort of thing.  Actually, I've instead changed the
> OTHER use of "none" to be singular, to match this one.
> 
> 
Fairy nuff.

> >>> a) So far, I've not seen any server implementation supporting
> >>> multiple mailbox patterns.
> ...
> > Yes, I think it could prove useful later, certainly. At this 
> stage,
> > it makes no real difference to clients, and it's additional
> > complexity for servers - and server developers have historically
> > preferred to avoid complexity at almost any cost.
> 
> But we've had a couple of comments to leave it.  Do we have a
> resolution for this issue?
> 
> 
I've seen very little comment. My general suspicion is that those 
server implementors who expressed any opinion at all aren't entirely 
happy with it. Personally, I'd be happy to leave it in, but I'll 
defer to the server folk.

> Dave has responded adequately to Arnaud's comments, so I'll refer to
> Dave's note on it:

> >>    * Page 14, paragraph \HasChildren, I think I disagree with the
> >>      security perspective
> > > Rereading this section, I note that "the server MUST return 
> these
> > attributes", but "a server MAY exclude both the [...] attributes".
> 
> I presume, Arnaud, that you're referring to the bit about returning
> \HasNoChildren if there are no children that the requester has 
> access
> to.  That statement represents established consensus here, so unless
> there are others who want to change it, it'll stay.
> 
> Dave, you're right that there's an unintended conflict there.  I 
> did a
> little rewording; let me know what you think of it.
> 
> 
Right. You're saying that in the case where some architectural issue 
means that the server simply cannot detirmine whether a mailbox has 
children or not, then it can omit both attributes.

I understand what you're trying to say, I'm just not clear on how 
that can arise. Specifically, if a mailbox A exists, but the server 
finds it impossible to provide either CHILDREN attribute, then surely 
it also cannot handle a subsequent LIST of A's inferior mailboxes?

I can certainly follow that it may be expensive to find the 
information, that it may be equivalent to performing the second LIST 
internally, etc, but if it were impossible, then the subsequent LIST 
would also be impossible.

If by impossible you mean "*really* difficult", then you're 
essentially licensing servers to omit both flags when they feel like 
it - this is actually acceptable to me in this case, I'd just like to 
understand this issue a little better.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 17 Jan 2006 13:15:30 -0500
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
From: "Dave Cridland" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Content-Class: urn:content-classes:message
Importance: normal
Status:   
Sender: [email-masked]

On Tue Jan 17 16:43:36 2006, Barry Leiba wrote:
> >> > but also because I spent some ten minutes
> >> > looking for the LIST response
> > > A note at the beginning in the introductory prose saying where 
> the
> > LIST response is defined is all that's needed.
> 
> Dave, see if you like what I've done.  I put text in both the ABNF
> introduction AND the definition of mailbox-list.
> 
> 
That looks good.

> >> I believe that no matter what happens to ACAP,
> 
> I've reworded the ACAP text; let me know if you think that's OK.
> 
> 
Better.

> > C) "none of them is" should be "none of them are".
> 
> Nah; "none" is singular, though it's acceptable to give it plural 
> usage
> if one likes that sort of thing.  Actually, I've instead changed the
> OTHER use of "none" to be singular, to match this one.
> 
> 
Fairy nuff.

> >>> a) So far, I've not seen any server implementation supporting
> >>> multiple mailbox patterns.
> ...
> > Yes, I think it could prove useful later, certainly. At this 
> stage,
> > it makes no real difference to clients, and it's additional
> > complexity for servers - and server developers have historically
> > preferred to avoid complexity at almost any cost.
> 
> But we've had a couple of comments to leave it.  Do we have a
> resolution for this issue?
> 
> 
I've seen very little comment. My general suspicion is that those 
server implementors who expressed any opinion at all aren't entirely 
happy with it. Personally, I'd be happy to leave it in, but I'll 
defer to the server folk.

> Dave has responded adequately to Arnaud's comments, so I'll refer to
> Dave's note on it:

> >>    * Page 14, paragraph \HasChildren, I think I disagree with the
> >>      security perspective
> > > Rereading this section, I note that "the server MUST return 
> these
> > attributes", but "a server MAY exclude both the [...] attributes".
> 
> I presume, Arnaud, that you're referring to the bit about returning
> \HasNoChildren if there are no children that the requester has 
> access
> to.  That statement represents established consensus here, so unless
> there are others who want to change it, it'll stay.
> 
> Dave, you're right that there's an unintended conflict there.  I 
> did a
> little rewording; let me know what you think of it.
> 
> 
Right. You're saying that in the case where some architectural issue 
means that the server simply cannot detirmine whether a mailbox has 
children or not, then it can omit both attributes.

I understand what you're trying to say, I'm just not clear on how 
that can arise. Specifically, if a mailbox A exists, but the server 
finds it impossible to provide either CHILDREN attribute, then surely 
it also cannot handle a subsequent LIST of A's inferior mailboxes?

I can certainly follow that it may be expensive to find the 
information, that it may be equivalent to performing the second LIST 
internally, etc, but if it were impossible, then the subsequent LIST 
would also be impossible.

If by impossible you mean "*really* difficult", then you're 
essentially licensing servers to omit both flags when they feel like 
it - this is actually acceptable to me in this case, I'd just like to 
understand this issue a little better.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 17 Jan 2006 13:00:18 -0500
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
From: "Dave Cridland" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Content-Class: urn:content-classes:message
Importance: normal
Status:   
Sender: [email-masked]

On Tue Jan 17 16:43:36 2006, Barry Leiba wrote:
> >> > but also because I spent some ten minutes
> >> > looking for the LIST response
> > > A note at the beginning in the introductory prose saying where 
> the
> > LIST response is defined is all that's needed.
> 
> Dave, see if you like what I've done.  I put text in both the ABNF
> introduction AND the definition of mailbox-list.
> 
> 
That looks good.

> >> I believe that no matter what happens to ACAP,
> 
> I've reworded the ACAP text; let me know if you think that's OK.
> 
> 
Better.

> > C) "none of them is" should be "none of them are".
> 
> Nah; "none" is singular, though it's acceptable to give it plural 
> usage
> if one likes that sort of thing.  Actually, I've instead changed the
> OTHER use of "none" to be singular, to match this one.
> 
> 
Fairy nuff.

> >>> a) So far, I've not seen any server implementation supporting
> >>> multiple mailbox patterns.
> ...
> > Yes, I think it could prove useful later, certainly. At this 
> stage,
> > it makes no real difference to clients, and it's additional
> > complexity for servers - and server developers have historically
> > preferred to avoid complexity at almost any cost.
> 
> But we've had a couple of comments to leave it.  Do we have a
> resolution for this issue?
> 
> 
I've seen very little comment. My general suspicion is that those 
server implementors who expressed any opinion at all aren't entirely 
happy with it. Personally, I'd be happy to leave it in, but I'll 
defer to the server folk.

> Dave has responded adequately to Arnaud's comments, so I'll refer to
> Dave's note on it:

> >>    * Page 14, paragraph \HasChildren, I think I disagree with the
> >>      security perspective
> > > Rereading this section, I note that "the server MUST return 
> these
> > attributes", but "a server MAY exclude both the [...] attributes".
> 
> I presume, Arnaud, that you're referring to the bit about returning
> \HasNoChildren if there are no children that the requester has 
> access
> to.  That statement represents established consensus here, so unless
> there are others who want to change it, it'll stay.
> 
> Dave, you're right that there's an unintended conflict there.  I 
> did a
> little rewording; let me know what you think of it.
> 
> 
Right. You're saying that in the case where some architectural issue 
means that the server simply cannot detirmine whether a mailbox has 
children or not, then it can omit both attributes.

I understand what you're trying to say, I'm just not clear on how 
that can arise. Specifically, if a mailbox A exists, but the server 
finds it impossible to provide either CHILDREN attribute, then surely 
it also cannot handle a subsequent LIST of A's inferior mailboxes?

I can certainly follow that it may be expensive to find the 
information, that it may be equivalent to performing the second LIST 
internally, etc, but if it were impossible, then the subsequent LIST 
would also be impossible.

If by impossible you mean "*really* difficult", then you're 
essentially licensing servers to omit both flags when they feel like 
it - this is actually acceptable to me in this case, I'd just like to 
understand this issue a little better.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 17 Jan 2006 12:46:06 -0500
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
From: "Dave Cridland" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Content-Class: urn:content-classes:message
Importance: normal
Status:   
Sender: [email-masked]

On Tue Jan 17 16:43:36 2006, Barry Leiba wrote:
> >> > but also because I spent some ten minutes
> >> > looking for the LIST response
> > > A note at the beginning in the introductory prose saying where 
> the
> > LIST response is defined is all that's needed.
> 
> Dave, see if you like what I've done.  I put text in both the ABNF
> introduction AND the definition of mailbox-list.
> 
> 
That looks good.

> >> I believe that no matter what happens to ACAP,
> 
> I've reworded the ACAP text; let me know if you think that's OK.
> 
> 
Better.

> > C) "none of them is" should be "none of them are".
> 
> Nah; "none" is singular, though it's acceptable to give it plural 
> usage
> if one likes that sort of thing.  Actually, I've instead changed the
> OTHER use of "none" to be singular, to match this one.
> 
> 
Fairy nuff.

> >>> a) So far, I've not seen any server implementation supporting
> >>> multiple mailbox patterns.
> ...
> > Yes, I think it could prove useful later, certainly. At this 
> stage,
> > it makes no real difference to clients, and it's additional
> > complexity for servers - and server developers have historically
> > preferred to avoid complexity at almost any cost.
> 
> But we've had a couple of comments to leave it.  Do we have a
> resolution for this issue?
> 
> 
I've seen very little comment. My general suspicion is that those 
server implementors who expressed any opinion at all aren't entirely 
happy with it. Personally, I'd be happy to leave it in, but I'll 
defer to the server folk.

> Dave has responded adequately to Arnaud's comments, so I'll refer to
> Dave's note on it:

> >>    * Page 14, paragraph \HasChildren, I think I disagree with the
> >>      security perspective
> > > Rereading this section, I note that "the server MUST return 
> these
> > attributes", but "a server MAY exclude both the [...] attributes".
> 
> I presume, Arnaud, that you're referring to the bit about returning
> \HasNoChildren if there are no children that the requester has 
> access
> to.  That statement represents established consensus here, so unless
> there are others who want to change it, it'll stay.
> 
> Dave, you're right that there's an unintended conflict there.  I 
> did a
> little rewording; let me know what you think of it.
> 
> 
Right. You're saying that in the case where some architectural issue 
means that the server simply cannot detirmine whether a mailbox has 
children or not, then it can omit both attributes.

I understand what you're trying to say, I'm just not clear on how 
that can arise. Specifically, if a mailbox A exists, but the server 
finds it impossible to provide either CHILDREN attribute, then surely 
it also cannot handle a subsequent LIST of A's inferior mailboxes?

I can certainly follow that it may be expensive to find the 
information, that it may be equivalent to performing the second LIST 
internally, etc, but if it were impossible, then the subsequent LIST 
would also be impossible.

If by impossible you mean "*really* difficult", then you're 
essentially licensing servers to omit both flags when they feel like 
it - this is actually acceptable to me in this case, I'd just like to 
understand this issue a little better.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 17 Jan 2006 12:31:44 -0500
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
From: "Dave Cridland" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Content-Class: urn:content-classes:message
Importance: normal
Status:   
Sender: [email-masked]

On Tue Jan 17 16:43:36 2006, Barry Leiba wrote:
> >> > but also because I spent some ten minutes
> >> > looking for the LIST response
> > > A note at the beginning in the introductory prose saying where 
> the
> > LIST response is defined is all that's needed.
> 
> Dave, see if you like what I've done.  I put text in both the ABNF
> introduction AND the definition of mailbox-list.
> 
> 
That looks good.

> >> I believe that no matter what happens to ACAP,
> 
> I've reworded the ACAP text; let me know if you think that's OK.
> 
> 
Better.

> > C) "none of them is" should be "none of them are".
> 
> Nah; "none" is singular, though it's acceptable to give it plural 
> usage
> if one likes that sort of thing.  Actually, I've instead changed the
> OTHER use of "none" to be singular, to match this one.
> 
> 
Fairy nuff.

> >>> a) So far, I've not seen any server implementation supporting
> >>> multiple mailbox patterns.
> ...
> > Yes, I think it could prove useful later, certainly. At this 
> stage,
> > it makes no real difference to clients, and it's additional
> > complexity for servers - and server developers have historically
> > preferred to avoid complexity at almost any cost.
> 
> But we've had a couple of comments to leave it.  Do we have a
> resolution for this issue?
> 
> 
I've seen very little comment. My general suspicion is that those 
server implementors who expressed any opinion at all aren't entirely 
happy with it. Personally, I'd be happy to leave it in, but I'll 
defer to the server folk.

> Dave has responded adequately to Arnaud's comments, so I'll refer to
> Dave's note on it:

> >>    * Page 14, paragraph \HasChildren, I think I disagree with the
> >>      security perspective
> > > Rereading this section, I note that "the server MUST return 
> these
> > attributes", but "a server MAY exclude both the [...] attributes".
> 
> I presume, Arnaud, that you're referring to the bit about returning
> \HasNoChildren if there are no children that the requester has 
> access
> to.  That statement represents established consensus here, so unless
> there are others who want to change it, it'll stay.
> 
> Dave, you're right that there's an unintended conflict there.  I 
> did a
> little rewording; let me know what you think of it.
> 
> 
Right. You're saying that in the case where some architectural issue 
means that the server simply cannot detirmine whether a mailbox has 
children or not, then it can omit both attributes.

I understand what you're trying to say, I'm just not clear on how 
that can arise. Specifically, if a mailbox A exists, but the server 
finds it impossible to provide either CHILDREN attribute, then surely 
it also cannot handle a subsequent LIST of A's inferior mailboxes?

I can certainly follow that it may be expensive to find the 
information, that it may be equivalent to performing the second LIST 
internally, etc, but if it were impossible, then the subsequent LIST 
would also be impossible.

If by impossible you mean "*really* difficult", then you're 
essentially licensing servers to omit both flags when they feel like 
it - this is actually acceptable to me in this case, I'd just like to 
understand this issue a little better.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 17 Jan 2006 17:19:16 +0000
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
From: Dave Cridland <[email-masked]>
To: Barry Leiba <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Tue Jan 17 16:43:36 2006, Barry Leiba wrote:
> >> > but also because I spent some ten minutes
> >> > looking for the LIST response
> > > A note at the beginning in the introductory prose saying where 
> the
> > LIST response is defined is all that's needed.
> 
> Dave, see if you like what I've done.  I put text in both the ABNF
> introduction AND the definition of mailbox-list.
> 
> 
That looks good.

> >> I believe that no matter what happens to ACAP,
> 
> I've reworded the ACAP text; let me know if you think that's OK.
> 
> 
Better.

> > C) "none of them is" should be "none of them are".
> 
> Nah; "none" is singular, though it's acceptable to give it plural 
> usage
> if one likes that sort of thing.  Actually, I've instead changed the
> OTHER use of "none" to be singular, to match this one.
> 
> 
Fairy nuff.

> >>> a) So far, I've not seen any server implementation supporting
> >>> multiple mailbox patterns.
> ...
> > Yes, I think it could prove useful later, certainly. At this 
> stage,
> > it makes no real difference to clients, and it's additional
> > complexity for servers - and server developers have historically
> > preferred to avoid complexity at almost any cost.
> 
> But we've had a couple of comments to leave it.  Do we have a
> resolution for this issue?
> 
> 
I've seen very little comment. My general suspicion is that those 
server implementors who expressed any opinion at all aren't entirely 
happy with it. Personally, I'd be happy to leave it in, but I'll 
defer to the server folk.

> Dave has responded adequately to Arnaud's comments, so I'll refer to
> Dave's note on it:

> >>    * Page 14, paragraph \HasChildren, I think I disagree with the
> >>      security perspective
> > > Rereading this section, I note that "the server MUST return 
> these
> > attributes", but "a server MAY exclude both the [...] attributes".
> 
> I presume, Arnaud, that you're referring to the bit about returning
> \HasNoChildren if there are no children that the requester has 
> access
> to.  That statement represents established consensus here, so unless
> there are others who want to change it, it'll stay.
> 
> Dave, you're right that there's an unintended conflict there.  I 
> did a
> little rewording; let me know what you think of it.
> 
> 
Right. You're saying that in the case where some architectural issue 
means that the server simply cannot detirmine whether a mailbox has 
children or not, then it can omit both attributes.

I understand what you're trying to say, I'm just not clear on how 
that can arise. Specifically, if a mailbox A exists, but the server 
finds it impossible to provide either CHILDREN attribute, then surely 
it also cannot handle a subsequent LIST of A's inferior mailboxes?

I can certainly follow that it may be expensive to find the 
information, that it may be equivalent to performing the second LIST 
internally, etc, but if it were impossible, then the subsequent LIST 
would also be impossible.

If by impossible you mean "*really* difficult", then you're 
essentially licensing servers to omit both flags when they feel like 
it - this is actually acceptable to me in this case, I'd just like to 
understand this issue a little better.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Tue, 17 Jan 2006 11:43:36 -0500
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
Sender: [email-masked]

--==========F13281BD76B984D2F1FF==========
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

I've attached an edited diff of the changes I've made based on comments
so far.  They're minor -- mostly typo corrections and minor rewordings
and clarifications.  I've also changed the markup for the examples so
that the client/server exchanges are not double-spaced.

My specific responses to comments are below.

>> > but also because I spent some ten minutes
>> > looking for the LIST response
>=20
> A note at the beginning in the introductory prose saying where the
> LIST response is defined is all that's needed.

Dave, see if you like what I've done.  I put text in both the ABNF
introduction AND the definition of mailbox-list.

>> I believe that no matter what happens to ACAP,

I've reworded the ACAP text; let me know if you think that's OK.

> Page 7. Both examples appear to be missing spaces between the closing
> of one parenthesized list and the opening of the next.

Fixed.

> 5) "[...] similar to the command <RLSUB "" "%">." - Should be "*",
> not "%".
> Extraneous comma in "mailboxes, which".
> 6) Extraneous comma.
> 8) "demonstates" typo.
> A1) "instead" should be "as well", surely? The "or even this" clause
> and example doesn't make sense to me - it's simply added
> \HasChildren, but the client didn't request it.

Fixed all.

> C) "none of them is" should be "none of them are".

Nah; "none" is singular, though it's acceptable to give it plural usage
if one likes that sort of thing.  Actually, I've instead changed the
OTHER use of "none" to be singular, to match this one.

>>> a) So far, I've not seen any server implementation supporting
>>> multiple mailbox patterns.
...
> Yes, I think it could prove useful later, certainly. At this stage,
> it makes no real difference to clients, and it's additional
> complexity for servers - and server developers have historically
> preferred to avoid complexity at almost any cost.

But we've had a couple of comments to leave it.  Do we have a
resolution for this issue?

Dave has responded adequately to Arnaud's comments, so I'll refer to
Dave's note on it:

>   =E2=80=A2 I have a problem (which is surely my Frenglish) to =
understand
> 'or any combination of therof', I don't scan the word therof.=20
>   =E2=80=A2 Page 9 on the paragraph for REMOTE, the 3 last lines are =
really
> some byzantinism that is really a pain to explain operationally.
> Could we favor eliminating exceptions and enhancing protocol
> readability?=20
>   =E2=80=A2 Page 14, paragraph \HasChildren, I think I disagree with =
the
> security perspective=20
>   =E2=80=A2 Page 16, I am not familiar with the \Marked in example 2. =
What
> does this attribute mean? Where is it defined?=20
>   =E2=80=A2 Page 17, I think Example 6 requires much more =
explanations=20
>   =E2=80=A2 Page 19, Example 8: typo: it should be demonstrate and =
not
> demonstate, there is a missing r=20
>   =E2=80=A2 Page 26, I am not comfortable with the comment on ACAP at =
the
> beginning of section 6=20
>   =E2=80=A2 Page 30, at the end I dsiagree with the Security =
statement here=20
>   =E2=80=A2 Page 32, first paragrapha very small typo: there is a =
space
> between options/ extended, it should be options/extended to be
> consistent with the others after=20
>   =E2=80=A2 Page 34, the registration number 3 is almost a duplicate =
of
> registration number 1, you want to remove one or the other.=20

>>    * I disagree in the abstract on the Mailbox Referrals mention. No
>>      one implements it even not Microsoft correct? I think there are
>>      much more important issues to be covered in the abstract
>=20
> I implement Mailbox Referrals in my client, and Cyrus IMAP implements
> it in the server. I think Mulberry implements it client-side too. In
> any case, the mention here is illustrating that its addition forces
> additional duplicate commands such as RLIST, RLSUB, etc, and I think
> that's justified.

Agreed; it's staying.

> That's page 6 section 3 paragraph two. Should be "any combination
> thereof".

Fixed typo.

>>    * Page 9 on the paragraph for REMOTE, the 3 last lines are really
>>      some byzantinism that is really a pain to explain=20
>> operationally.
>>      Could we favor eliminating exceptions and enhancing protocol
>>      readability?
>=20
> It was tricky to explain at all. The nature of what's wrong with
> REMOTE RECURSIVEMATCH isn't echoed fully in the subsection on
> RECURSIVEMATCH, incidentally.

I've added a phrase to the RECURSIVEMATCH subsection to deal with that.
Arnaud, if you have a better suggestion for how to explain the
interaction of REMOTE, give me text (Franglish is OK; I can cope).
What you see there is the best we could come up with (and, really, I
don't think it's that confusing).

>>    * Page 14, paragraph \HasChildren, I think I disagree with the
>>      security perspective
>=20
> Rereading this section, I note that "the server MUST return these
> attributes", but "a server MAY exclude both the [...] attributes".

I presume, Arnaud, that you're referring to the bit about returning
\HasNoChildren if there are no children that the requester has access
to.  That statement represents established consensus here, so unless
there are others who want to change it, it'll stay.

Dave, you're right that there's an unintended conflict there.  I did a
little rewording; let me know what you think of it.

>>    * Page 17, I think Example 6 requires much more explanations
>=20
> I think I see why. Could you suggest some alternate text for
> explaining both example 5 and example 6? (I should think both would
> need to be changed to express the difference more clearly).

Yes, text.
I'm afraid that at this point in the process I have to insist that
comments that say that text is needed MUST come with suggested text.
I'll accept suggestions for minor tweaks, of course, but if you think
something needs to be written at this point... please write it.

>>    * Page 30, at the end I dsiagree with the Security statement here
>=20
> No, this is a security concern, and should be addressed by
> implementors.

Agreed; this is an exposure of a "covert channel" -- a back door to
retrieve information that you couldn't normally retrieve.  It has to be
documented.

Further comments?  Is -15a ready to go to the IESG as -16?

Barry

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

--==========F13281BD76B984D2F1FF==========
Content-Type: text/plain; charset=utf-8;
 name="draft-ietf-imapext-list-extensions-15to15adiff.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="draft-ietf-imapext-list-extensions-15to15adiff.txt"; size=5663

<           therof) MUST NOT treat the empty mailbox name as such =
special request
---
>           thereof) MUST NOT treat the empty mailbox name as such =
special request

[I had to make extra changes to this because I wanted each to fit on =
one line.]
<             ((tablecloth (("fringe" "lacy")("color" =
"white")))(X-Sample "text"))
<          =20
<           or...
<          =20
<             ((tablecloth ("fringe" "lacy"))(X-Sample "text" "and even =
more text"))
---
>             ((tablecloth (("edge" "lacy") ("color" "red"))) (X-Sample =
"text"))
>          =20
>           or...
>          =20
>             ((tablecloth ("edge" "lacy")) (X-Sample "text" "more =
text"))

<           option, as it only makes sense when other selection options =
are
---
>           option (nor only with REMOTE),
>           as it only makes sense when other selection options are

<           option is present, the server MUST return these attributes =
even
<           if their computation is expensive.
---
>           option is present, the server MUST return these attributes =
if it
>           is able to determine them, even if their computation is =
expensive
>           (see below about exception conditions).

<           example it may have difficulty determining whether there =
are child
---
>           example it might be impossible to determine whether there =
are child

<           if both are requested. It is an error for the server to =
return both a
<           \HasChildren and a \HasNoChildren attribute in a LIST =
response.
---
>           if both are requested.  It is an error for the server to =
return both a
>           \HasChildren and a \HasNoChildren attribute for the same =
mailbox.

<           In the next example, we'll see the subscribed mailboxes.  =
This is
---
>           In the next example we'll see the subscribed mailboxes.  =
This is

<           In this example we see more mailboxes, which reside on =
another server
---
>           In this example we see more mailboxes that reside on =
another server

<           The following example also requests the server to include =
mailboxes,
<           which reside on another server. The server returns =
information about
<           all mailboxes which are subscribed. This is similar to the =
command
<           <RLSUB "" "%">.  We also see the use of two selection =
options.
---
>           The following example also requests the server to include =
mailboxes
>           that reside on another server.  The server returns =
information about
>           all mailboxes which are subscribed.  This is similar to the =
command
>           <RLSUB "" "*">.  We also see the use of two selection =
options.

<           The following example requests the server to include =
mailboxes,
<           which reside on another server. The server is requested to =
return
<           subscription information for all returned mailboxes. This =
is different
<           from the example above.
---
>           The following example requests the server to include =
mailboxes
>           that reside on another server.  The server is asked to =
return
>           subscription information for all returned mailboxes.
>           This is different from the example above.

<           The following example demonstates the difference between
<           \HasChildren attribute and CHILDINFO extended data item.
---
>           The following example demonstrates the difference between =
the
>           \HasChildren attribute and the CHILDINFO extended data =
item.

<           A1) If the mailbox "Foo" had been subscribed instead, the =
last
---
>           A1) If the mailbox "Foo" had also been subscribed, the last

<           subscribed children match the pattern.
---
>           subscribed children matches the pattern.

<           The following syntax specification uses the augmented =
Backus-Naur
<           Form (BNF) as described in <xref target=3D"ABNF"/>.
<           Terms not defined here are taken from <xref =
target=3D"IMAP4"/>.
<
<           "vendor-token" is defined in <xref target=3D"ACAP"/>.
<           Note that this normative reference to ACAP is an issue in
<           moving this spec forward, since ACAP will never move to
<           Draft Standard.
<           The definitions of "vendor-token" and of the IANA registry =
must
<           eventually go somewhere else, in a document that can be =
moved
<           forward on the standards track.
---
>           The following syntax specification uses the augmented =
Backus-Naur
>           Form (BNF) as described in <xref target=3D"ABNF"/>.
>           Terms not defined here are taken from <xref =
target=3D"IMAP4"/>.
>           In particular, note that the version of "mailbox-list" =
below,
>           which defines the payload of the LIST response,
>           updates the version defined in the IMAP specification.
>           It is pointed to by "mailbox-data", which is defined in =
<xref target=3D"IMAP4"/>.
>
>           "vendor-token" is defined in <xref target=3D"ACAP"/>.
>           Note that this normative reference to ACAP is an issue in
>           moving this spec forward, since it introduces a dependency =
on ACAP.
>           The definitions of "vendor-token" and of the IANA registry =
must
>           eventually go somewhere else, in a document that can be =
moved
>           forward on the standards track independently of ACAP.

[inserted into the definition of "mailbox-list"]
>           ;   This is the list information pointed to by the ABNF =
item
>           ;   "mailbox-data", which is defined in <xref =
target=3D"IMAP4"/>

--==========F13281BD76B984D2F1FF==========
Content-Type: text/plain; charset=utf-8;
 name="draft-ietf-imapext-list-extensions-15a.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="draft-ietf-imapext-list-extensions-15a.txt"; size=67952

IMAP Extensions Working Group                                   B. =
Leiba
Internet-Draft                           IBM T.J. Watson Research =
Center
Updates: 2193 (if approved)                                  A. =
Melnikov
Obsoletes: 3348 (if approved)                              Isode =
Limited
Expires: July 21, 2006                                  January 17, =
2006

                     IMAP4 LIST Command Extensions
                 draft-ietf-imapext-list-extensions-16

Status of this Memo

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

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

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

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

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on July 21, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

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

Leiba & Melnikov          Expires July 21, 2006                 [Page =
1]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

   with each new extension.  This document describes an extension to =
the
   base LIST command that will allow these additions to be done with
   mutually compatible options to the LIST command, avoiding the
   exponential increase in specialized list commands.

Note

   A revised version of this draft document will be submitted to the =
RFC
   editor as a Proposed Standard for the Internet Community.  =
Discussion
   and suggestions for improvement are requested, and should be sent to
   [email-masked].

   This document obsoletes RFC 3348 and updates RFC 2193.

Table of Contents

   1.    Conventions used in this document  . . . . . . . . . . . . .  =
4

   2.    Introduction and overview  . . . . . . . . . . . . . . . . .  =
5

   3.    Extended LIST Command  . . . . . . . . . . . . . . . . . . .  =
7
   3.1.  General principles for returning LIST responses  . . . . . . =
11
   3.2.  Additional requirements on LIST-EXTENDED clients . . . . . . =
12
   3.3.  CHILDINFO extended data item . . . . . . . . . . . . . . . . =
12

   4.    The CHILDREN return Option . . . . . . . . . . . . . . . . . =
15

   5.    Examples . . . . . . . . . . . . . . . . . . . . . . . . . . =
17

   6.    Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . . =
24

   7.    Security Considerations  . . . . . . . . . . . . . . . . . . =
28

   8.    IANA Considerations  . . . . . . . . . . . . . . . . . . . . =
29
   8.1.  Guidelines for IANA  . . . . . . . . . . . . . . . . . . . . =
29
   8.2.  Registration procedure and Change control  . . . . . . . . . =
29
   8.3.  Registration template for LIST-EXTENDED options  . . . . . . =
30
   8.4.  Initial LIST-EXTENDED option registrations . . . . . . . . . =
31
   8.5.  Registration template for LIST-EXTENDED extended data
         item . . . . . . . . . . . . . . . . . . . . . . . . . . . . =
33
   8.6.  Initial LIST-EXTENDED extended data item registrations . . . =
34

   9.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . =
35

   10.   Normative References . . . . . . . . . . . . . . . . . . . . =
36

         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . =
37

Leiba & Melnikov          Expires July 21, 2006                 [Page =
2]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

         Intellectual Property and Copyright Statements . . . . . . . =
38

Leiba & Melnikov          Expires July 21, 2006                 [Page =
3]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

1.  Conventions used in this document

   In examples, "C:" indicates lines sent by a client that is connected
   to a server.  "S:" indicates lines sent by the server to the client.

   The words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are
   used in this document as specified in RFC 2119 [Kwds].

   The term "canonical LIST pattern" refers to the canonical pattern
   constructed internally by the server from the reference and mailbox
   name arguments (Section 6.3.8 of [IMAP4]).  The [IMAP4] LIST command
   returns only mailboxes that match the canonical LIST pattern.

   Other terms are introduced where they are referenced for the first
   time.

Leiba & Melnikov          Expires July 21, 2006                 [Page =
4]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

2.  Introduction and overview

   The LIST command is extended by amending the syntax to allow options
   and multiple patterns to be specified.  The list of options replaces
   the several commands that are currently used to mix and match the
   information requested.  The new syntax is backward- compatible, with
   no ambiguity: the new syntax is being used if one of the following
   conditions is true:

   1.  if the first word after the command name begins with a
       parenthesis ("LIST selection options");

   2.  if the second word after the command name begins with a
       parenthesis ("multiple mailbox patterns");

   3.  if the LIST command has more than 2 parameters ("LIST return
       options");

   Otherwise the original syntax is used.

   By adding options to the LIST command, we are announcing the intent
   to phase out and eventually to deprecate the RLIST and RLSUB =
commands
   described in [MBRef].  We are also defining the mechanism to request
   extended mailbox information, such as is described in the "Child
   Mailbox Extension" [CMbox].  The base LSUB command is not deprecated
   by this extension; rather, this extension adds a way to obtain
   subscription information with more options, with those server
   implementations that support it.  Clients that simply need a list of
   subscribed mailboxes, as provided by the LSUB command, SHOULD
   continue to use that command.

   This document defines an IMAP4 extension that is identified by the
   capability string "LIST-EXTENDED".  The LIST-EXTENDED extension =
makes
   the following changes to the IMAP4 protocol, which are described in
   more detail in Section 3 and Section 4:

   a.  defines new syntax for LIST command options.

   b.  extends LIST to allow for multiple mailbox patterns.

   c.  adds LIST command selection options: SUBSCRIBED, REMOTE and
       RECURSIVEMATCH.

   d.  adds LIST command return options: SUBSCRIBED and CHILDREN.

   e.  adds new mailbox attributes: "\NonExistent", "\Subscribed",
       "\Remote", "\HasChildren" and "\HasNoChildren".

Leiba & Melnikov          Expires July 21, 2006                 [Page =
5]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

   f.  adds CHILDINFO extended data item.

Leiba & Melnikov          Expires July 21, 2006                 [Page =
6]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

3.  Extended LIST Command

   This extension updates the syntax of the LIST command to allow for
   multiple mailbox patterns to be specified, if they are enclosed in
   parentheses.  A mailbox name matches a list of mailbox patterns if =
it
   matches at least one mailbox pattern.  If a mailbox name matches
   multiple mailbox patterns from the list, the server SHOULD return
   only a single LIST response.

   Note that the non-extended LIST command is required to treat an =
empty
   ("" string) mailbox name argument as a special request to return the
   hierarchy delimiter and the root name of the name given in the
   reference parameter (as per [IMAP4]).  However ANY extended LIST
   command (extended in any of 3 ways specified in Section 2, or any
   combination of thereof) MUST NOT treat the empty mailbox name as =
such
   special request and any regular processing described in this =
document
   applies.  In particular, if an extended LIST command has multiple
   mailbox names and one (or more) of them is the empty string, the
   empty string MUST be ignored for the purpose of matching.

   Some servers might restrict which patterns are allowed in a LIST
   command.  If a server doesn't accept a particular pattern, it MUST
   silently ignore it.

   The LIST command syntax is also extended in two additional ways: by
   adding a parenthesized list of command options between the command
   name and the reference name (LIST selection options) and an optional
   list of options at the end that control what kind of information
   should be returned (LIST return options).  See the formal syntax in
   Section 6 for specific details.

   A LIST selection option tells the server which mailbox names should
   be selected by the LIST operation.  The server should return
   information about all mailbox names that match any of the "canonical
   LIST pattern" (as described above) and satisfy additional selection
   criteria (if any) specified by the LIST selection options.  Let's
   call any such mailbox name a "matched mailbox name".  When multiple
   selection options are specified, the server MUST return information
   about mailbox names that satisfy every selection option, unless a
   description of a particular specified option prescribes special
   rules.  An example of an option prescribing special rules is the
   RECURSIVEMATCH selection option described later in this section.  We
   will use the term "selection criteria" when referring collectively =
to
   all selection options specified in a LIST command.

   A LIST return option controls which information is returned for each
   matched mailbox name.  Note that return options MUST NOT cause the
   server to report information about additional mailbox names.  If the

Leiba & Melnikov          Expires July 21, 2006                 [Page =
7]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

   client has not specified any return option, only information about
   attributes should be returned by the server.  (Of course the server
   is allowed to include any other information at will.)

   Both selection and return command options will be defined in this
   document and in approved extension documents; each option will be
   enabled by a capability string (one capability may enable multiple
   options), and a client MUST NOT send an option for which the server
   has not advertised support.  A server MUST respond to options it =
does
   not recognize with a BAD response.  The client SHOULD NOT specify =
any
   option more than once, however if the client does this, the server
   MUST act as if it received the option only once.  The order in which
   options are specified by the client is not significant.

   In general, each selection option except for RECURSIVEMATCH will =
have
   a corresponding return option.  The REMOTE selection option is an
   anomaly in this regard, and does not have a corresponding return
   option.  That is because it expands, rather than restricts, the set
   of mailboxes that are returned.  Future extensions to this
   specification should keep parallelism in mind, and define a pair of
   corresponding options.

   This extension is identified by the capability string "LIST-
   EXTENDED", and support for it is a prerequisite for any future
   extensions that require specialized forms of the LIST command.  Such
   extensions MUST refer to this document and MUST add their function
   through command options as described herein.  Note that extensions
   that don't require support for an extended LIST command, but use
   extended LIST responses (see below), don't need to advertise the
   "LIST-EXTENDED" capability string.

   This extension also defines extensions to the LIST response, =
allowing
   a series of extended fields at the end, a parenthesized list of
   tagged data (also referred to as "extended data item").  The first
   element of an extended field is a tag, which identifies type of the
   data.  Tags MUST be registered with IANA, as described in Section =
8.5
   of this document.  An example of such extended set might be

   tablecloth (("edge" "lacy") ("color" "red"))) (X-Sample "text"))

   or...

   tablecloth ("edge" "lacy")) (X-Sample "text" "more text"))

   See the formal syntax, in Section 6, for the full syntactic details.
   The server MUST NOT return any extended data item, unless the client
   has expressed its ability to support extended LIST responses, for
   example by using an extended LIST command.  The server MAY return

Leiba & Melnikov          Expires July 21, 2006                 [Page =
8]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

   data in the extended fields that was not solicited by the client.
   The client MUST ignore all extended fields it doesn't recognize.

   The LIST-EXTENDED capability also defines several new mailbox
   attributes.

   The "\NonExistent" attribute indicates that a mailbox does not
   actually exist.  Note that this attribute is not meaningful by
   itself, as mailboxes that match the canonical LIST pattern but don't
   exist must not be returned unless one of the two conditions listed
   below is also satisfied:

   a.  the mailbox also satisfies the selection criteria (for example,
       its name is subscribed and the "SUBSCRIBED" selection option has
       been specified)

   b.  "RECURSIVEMATCH" has been specified, and the mailbox has at =
least
       one descendant mailbox that does not match the LIST pattern and
       does match the selection criteria.

   In practice this means that the "\NonExistent" attribute is usually
   returned with one or more of "\Subscribed", "\Remote" or the
   CHILDINFO extended data item (see their description below).

   The "\NonExistent" attribute implies "\NoSelect".  The =
"\NonExistent"
   attribute MUST be supported and MUST be accurately computed.

   The selection options defined in this specification are

   SUBSCRIBED -  causes the LIST command to list subscribed names,
      rather than the existing mailboxes.  This will often be a subset
      of the actual mailboxes.  It's also possible for this list to
      contain the names of mailboxes that don't exist.  In any case, =
the
      list MUST include exactly those mailbox names that match the
      canonical list pattern and are subscribed to.  This option is
      intended to supplement the LSUB command.  Of particular note are
      the mailbox attributes as returned by this option, compared with
      what is returned by LSUB.  With the latter, the attributes
      returned may not reflect the actual attribute status on the
      mailbox name, and the \NoSelect attribute has a special meaning
      (it indicates that this mailbox is not, itself, subscribed, but
      that it has descendant mailboxes that are).  With the SUBSCRIBED
      selection option described here, the attributes are accurate,
      complete, and have no special meanings.  "LSUB" and "LIST
      (SUBSCRIBED)" are, thus, not the same thing, and some servers =
must
      do significant extra work to respond to "LIST (SUBSCRIBED)".
      Because of this, clients SHOULD continue to use "LSUB" unless =
they

Leiba & Melnikov          Expires July 21, 2006                 [Page =
9]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

      specifically want the additional information offered by "LIST
      (SUBSCRIBED)".

      This option defines a new mailbox attribute, "\Subscribed", that
      indicates that a mailbox name is subscribed to.  The =
"\Subscribed"
      attribute MUST be supported and MUST be accurately computed when
      the SUBSCRIBED selection option is specified.

      Note that the SUBSCRIBED selection option implies the SUBSCRIBED
      return option (see below).

   REMOTE -  causes the LIST command to show remote mailboxes as well =
as
      local ones, as described in [MBRef].  This option is intended to
      replace the RLIST command and, in conjunction with the SUBSCRIBED
      selection option, the RLSUB command.

      This option defines a new mailbox attribute, "\Remote", that
      indicates that a mailbox is a remote mailbox.  The "\Remote"
      attribute MUST be accurately computed when the REMOTE option is
      specified.

      The REMOTE selection option has no interaction with other =
options.
      Its effect is to tell the server to apply the other options, if
      any, to remote mailboxes, in addition to local ones.  In
      particular, it has no interaction with RECURSIVEMATCH (see =
below).
      A request for (REMOTE RECURSIVEMATCH) is invalid, because a
      request for (RECURSIVEMATCH) is.  A request for (REMOTE
      RECURSIVEMATCH SUBSCRIBED) is asking for all subscribed =
mailboxes,
      both local and remote.

   RECURSIVEMATCH -  this option forces the server to return =
information
      about parent mailboxes that don't match other selection options,
      but have some submailboxes that do.  Information about children =
is
      returned in the CHILDINFO extended data item, as described in
      Section 3.3.

      Note 1: In order for a parent mailbox to be returned, it still =
has
      to match the canonical LIST pattern.

      Note 2: When returning the CHILDINFO extended data item, it
      doesn't matter if the submailbox matches the canonical LIST
      pattern or not.  See also example 9 in Section 5.

      The RECURSIVEMATCH option MUST NOT occur as the only selection
      option (nor only with REMOTE), as it only makes sense when other
      selection options are also used.  The server MUST return BAD

Leiba & Melnikov          Expires July 21, 2006                [Page =
10]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

      tagged response in such case.

      Note that even if RECURSIVEMATCH option is specified, the client
      MUST still be able to handle a case when a CHILDINFO extended =
data
      item is returned and there are no submailboxes that meet the
      selection criteria of the given LIST command, as they can be
      deleted/renamed after the LIST response was sent, but before the
      client had a chance to access them.

   The return options defined in this specification are

   SUBSCRIBED -  causes the LIST command to return subscription state
      for all matching mailbox names.  The "\Subscribed" attribute MUST
      be supported and MUST be accurately computed when the SUBSCRIBED
      return option is specified.  Further, all mailbox flags MUST be
      accurately computed (this differs from the behaviour of the LSUB
      command).

   CHILDREN -  Requests mailbox child information as originally =
proposed
      in [CMbox].  See Section 4, below, for details.  This option MUST
      be supported by all servers.

3.1.  General principles for returning LIST responses

   This section outlines several principles that can be used by server
   implementations of this document to decide if a LIST response should
   be returned, as well as how many responses and what kind of
   information they may contain.

   1.  Exactly one LIST response should be returned for each mailbox
       name which matches the canonical LIST pattern.  Server
       implementors must not assume that clients will be able to
       assemble mailbox attributes and other information returned in
       multiple LIST responses.

   2.  There are only two reasons for including a matching mailbox name
       in the responses to the LIST command (Note that the server is
       allowed to return unsolicited responses at any time.  Such
       responses are not governed by this rule):

       A.  the mailbox name also satisfies the selection criteria;

       B.  the mailbox name doesn't satisfy the selection criteria, but
           it has at least one descendant mailbox name that satisfies

Leiba & Melnikov          Expires July 21, 2006                [Page =
11]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

           the selection criteria and that doesn't match the canonical
           LIST pattern.
           For more information on this case see the CHILDINFO extended
           data item described in Section 3.3.  Note that the CHILDINFO
           extended data item can only be returned when the
           RECURSIVEMATCH selection option is specified.

   3.  Attributes returned in the same LIST response must be treated
       additively.  For example the following response

          S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"

       means that the "Fruit/Peach" mailbox doesn't exist, but it is
       subscribed.

3.2.  Additional requirements on LIST-EXTENDED clients

   All clients that support this extension MUST treat an attribute with
   a stronger meaning, as implying any attribute that can be inferred
   from it.  For example, the client must treat presence of the
   \NoInferiors attribute as if the \HasNoChildren attribute was also
   sent by the server.

        The following table summarizes inference rules described in
                                Section 3.

                +--------------------+-------------------+
                | returned attribute | implied attribute |
                +--------------------+-------------------+
                |    \NoInferiors    |   \HasNoChildren  |
                |                    |                   |
                |    \NonExistent    |     \NoSelect     |
                +--------------------+-------------------+

3.3.  CHILDINFO extended data item

   The CHILDINFO extended data item MUST only be returned when the
   client has specified the RECURSIVEMATCH selection option.

   The CHILDINFO extended data item in a LIST response describes the
   selection criteria that has caused it to be returned and indicates
   that the mailbox has at least one descendant mailbox that matches =
the
   selection criteria.

   The LSUB command indicates this condition by using the "\NoSelect"

Leiba & Melnikov          Expires July 21, 2006                [Page =
12]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

   attribute, but the LIST (SUBSCRIBED) command MUST NOT do that, since
   "\NoSelect" retains its original meaning here.  Further, the
   CHILDINFO extended data item is more general, in that it can be used
   with any extended set of selection criteria.

   The returned selection criteria allow the client to distinguish a
   solicited response from an unsolicited one, as well as to =
distinguish
   among solicited responses caused by multiple pipelined LIST commands
   that specify different criteria.

   Servers SHOULD ONLY return a non-matching mailbox name along with
   CHILDINFO if at least one matching child is not also being returned.
   That is, servers SHOULD suppress redundant CHILDINFO responses.

   Examples 8 and 10 in Section 5 demonstrate the difference between
   present CHILDINFO extended data item and the "\HasChildren"
   attribute.

   The following table summarizes interaction between the =
"\NonExistent"
    attribute and CHILDINFO (the first collumn describes if the parent
                             mailbox exists):

   =
+--------+--------------+--------------------+----------------------+
   | exists |   meets the  |  has a child that  |       returned       =
|
   |        |   selection  |      meets the     |     LIST-EXTENDED    =
|
   |        |   criteria   | selection criteria |    attributes and    =
|
   |        |              |                    |       CHILDINFO      =
|
   =
+--------+--------------+--------------------+----------------------+
   |   no   |      no      |         no         |   no LIST response   =
|
   |        |              |                    |       returned       =
|
   |        |              |                    |                      =
|
   |   yes  |      no      |         no         |   no LIST response   =
|
   |        |              |                    |       returned       =
|
   |        |              |                    |                      =
|
   |   no   |      yes     |         no         |     (\NonExistent    =
|
   |        |              |                    |        <attr>)       =
|
   |        |              |                    |                      =
|
   |   yes  |      yes     |         no         |       (<attr>)       =
|
   |        |              |                    |                      =
|
   |   no   |      no      |         yes        |   (\NonExistent) +   =
|
   |        |              |                    |       CHILDINFO      =
|
   |        |              |                    |                      =
|
   |   yes  |      no      |         yes        |    () + CHILDINFO    =
|
   |        |              |                    |                      =
|
   |   no   |      yes     |         yes        |     (\NonExistent    =
|
   |        |              |                    |  <attr>) + CHILDINFO =
|
   |        |              |                    |                      =
|

Leiba & Melnikov          Expires July 21, 2006                [Page =
13]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

   |   yes  |      yes     |         yes        | (<attr>) + CHILDINFO =
|
   =
+--------+--------------+--------------------+----------------------+

       where <attr> is one or more attributes that correspond to the
   selection criteria, for example for the SUBSCRIBED option the <attr>
                              is \Subscribed.

Leiba & Melnikov          Expires July 21, 2006                [Page =
14]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

4.  The CHILDREN return Option

   The CHILDREN return option implements the Child Mailbox Extension,
   originally proposed by Mike Gahrns and Raymond Cheng, of Microsoft
   Corporation.  Most of the information in this section is taken
   directly from their original specification [CMbox].  The CHILDREN
   return option is simply an indication that the client wants this
   information; a server MAY provide it even if the option is not
   specified.

   Many IMAP4 [IMAP4] clients present to the user a hierarchical view =
of
   the mailboxes that a user has access to.  Rather than initially
   presenting to the user the entire mailbox hierarchy, it is often
   preferable to show to the user a collapsed outline list of the
   mailbox hierarchy (particularly if there is a large number of
   mailboxes).  The user can then expand the collapsed outline =
hierarchy
   as needed.  It is common to include within the collapsed hierarchy a
   visual clue (such as a ''+'') to indicate that there are child
   mailboxes under a particular mailbox.  When the visual clue is
   clicked the hierarchy list is expanded to show the child mailboxes.
   The CHILDREN return option provides a mechanism for a client to
   efficiently determine if a particular mailbox has children, without
   issuing a LIST "" * or a LIST "" % for each mailbox name.  The
   CHILDREN return option defines two new attributes that MAY be
   returned within a LIST response: \HasChildren and \HasNoChildren.
   While these attributes MAY be returned in response to any LIST
   command, the CHILDREN return option is provided to indicate that the
   client particularly wants this information.  If the CHILDREN return
   option is present, the server MUST return these attributes if it is
   able to determine them, even if their computation is expensive (see
   below about exception conditions).

   \HasChildren

        The presence of this attribute indicates that the mailbox has
        child mailboxes.  A server SHOULD NOT set this attribute if
        there are child mailboxes, and the user does not have
        permissions to access any of them.  In this case, =
\HasNoChildren
        SHOULD be used.  In many cases, however, a server may not be
        able to efficiently compute whether a user has access to all
        child mailboxes.  As such a client MUST be prepared to accept
        the \HasChildren attribute as a hint.  That is, a mailbox MAY =
be
        flagged with the \HasChildren attribute, but no child mailboxes
        will appear in the LIST response.

   \HasNoChildren

Leiba & Melnikov          Expires July 21, 2006                [Page =
15]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

        The presence of this attribute indicates that the mailbox has =
NO
        child mailboxes that are accessible to the currently
        authenticated user.

   In some instances a server that supports the LIST-EXTENDED extension
   might not be able to determine whether a mailbox has children.  For
   example it might be impossible to determine whether there are child
   mailboxes when LISTing mailboxes while operating in a particular
   namespace.  In these cases, a server MAY exclude both the
   \HasChildren and \HasNoChildren attributes in the LIST response.  As
   such, a client can not make any assumptions about whether a mailbox
   has children based upon the absence of a single attribute.  In
   particular, some servers may not be able to combine the SUBSCRIBED
   selection option and CHILDREN return option.  Such servers MUST
   honour the SUBSCRIBED selection option, and they will simply ignore
   the CHILDREN return option if both are requested.  It is an error =
for
   the server to return both a \HasChildren and a \HasNoChildren
   attribute for the same mailbox.

   Note: the \HasNoChildren attribute should not be confused with the
   IMAP4 [IMAP4] defined attribute \NoInferiors which indicates that no
   child mailboxes exist now and none can be created in the future.

Leiba & Melnikov          Expires July 21, 2006                [Page =
16]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

5.  Examples

   1:   The first example shows the complete local hierarchy that will
        be used for the other examples.

      C: A01 LIST "" "*"
      S: * LIST (\Marked \NoInferiors) "/" "inbox"
      S: * LIST () "/" "Fruit"
      S: * LIST () "/" "Fruit/Apple"
      S: * LIST () "/" "Fruit/Banana"
      S: * LIST () "/" "Tofu"
      S: * LIST () "/" "Vegetable"
      S: * LIST () "/" "Vegetable/Broccoli"
      S: * LIST () "/" "Vegetable/Corn"
      S: A01 OK done

   2:   In the next example we'll see the subscribed mailboxes.  This =
is
        similar to, but not equivalent with, <LSUB "" "*">.  Note that
        the mailbox called "Fruit/Peach" is subscribed to, but does not
        actually exist (perhaps it was deleted while still subscribed).
        The "Fruit" mailbox is not subscribed to, but it has two
        subscribed children.  The "Vegetable" mailbox is subscribed and
        has two children, one of them is subscribed as well.

      C: A02 LIST (SUBSCRIBED) "" "*"
      S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"
      S: * LIST (\Subscribed) "/" "Fruit/Banana"
      S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"
      S: * LIST (\Subscribed) "/" "Vegetable"
      S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"
      S: A02 OK done

   3:   The next example shows the use of the CHILDREN option.  The
        client, without having to list the second level of hierarchy,
        now knows which of the top-level mailboxes have submailboxes
        (children) and which do not.  Note that it's not necessary for
        the server to return the \HasNoChildren attribute for the =
inbox,
        because the \NoInferiors attribute already implies that, and =
has
        a stronger meaning.

      C: A03 LIST () "" "%" RETURN (CHILDREN)
      S: * LIST (\Marked \NoInferiors) "/" "inbox"
      S: * LIST (\HasChildren) "/" "Fruit"
      S: * LIST (\HasNoChildren) "/" "Tofu"
      S: * LIST (\HasChildren) "/" "Vegetable"
      S: A03 OK done

Leiba & Melnikov          Expires July 21, 2006                [Page =
17]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

   4:   In this example we see more mailboxes that reside on another
        server to which we may obtain referrals.  This is similar to =
the
        command <RLIST "" "%">.  Note that in the case of the remote
        mailboxes, the server might or might not be able to include
        CHILDREN information; it includes it if it can, and omits it if
        it can't.

      C: A04 LIST (REMOTE) "" "%" RETURN (CHILDREN)
      S: * LIST (\Marked \NoInferiors) "/" "inbox"
      S: * LIST (\HasChildren) "/" "Fruit"
      S: * LIST (\HasNoChildren) "/" "Tofu"
      S: * LIST (\HasChildren) "/" "Vegetable"
      S: * LIST (\Remote) "/" "Bread"
      S: * LIST (\HasChildren \Remote) "/" "Meat"
      S: A04 OK done

   5:   The following example also requests the server to include
        mailboxes that reside on another server.  The server returns
        information about all mailboxes which are subscribed.  This is
        similar to the command <RLSUB "" "*">.  We also see the use of
        two selection options.

      C: A05 LIST (REMOTE SUBSCRIBED) "" "*"
      S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"
      S: * LIST (\Subscribed) "/" "Fruit/Banana"
      S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"
      S: * LIST (\Subscribed) "/" "Vegetable"
      S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"
      S: * LIST (\Remote \Subscribed) "/" "Bread"
      S: A05 OK done

   6:   The following example requests the server to include mailboxes
        that reside on another server.  The server is asked to return
        subscription information for all returned mailboxes.  This is
        different from the example above.

        Note that the output of this command is not a superset of the
        output in the previous example, as it doesn't include LIST
        response for the non-existent "Fruit/Peach".

Leiba & Melnikov          Expires July 21, 2006                [Page =
18]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

      C: A06 LIST (REMOTE) "" "*" RETURN (SUBSCRIBED)
      S: * LIST (\Marked \NoInferiors \Subscribed) "/" "inbox"
      S: * LIST () "/" "Fruit"
      S: * LIST () "/" "Fruit/Apple"
      S: * LIST (\Subscribed) "/" "Fruit/Banana"
      S: * LIST () "/" "Tofu"
      S: * LIST (\Subscribed) "/" "Vegetable"
      S: * LIST (\Subscribed) "/" "Vegetable/Broccoli"
      S: * LIST () "/" "Vegetable/Corn"
      S: * LIST (\Remote \Subscribed) "/" "Bread"
      S: * LIST (\Remote) "/" "Meat"
      S: A06 OK done

   7:   In the following example the client has specified multiple
        mailbox patterns.  Note that this example does not use the
        mailbox hierarchy used in the previous examples.

      C: BBB LIST "" ("INBOX" "Drafts" "Sent/%")
      S: * LIST () "/" "INBOX"
      S: * LIST (\NoInferiors) "/" "Drafts"
      S: * LIST () "/" "Sent/March2004"
      S: * LIST (\Marked) "/" "Sent/December2003"
      S: * LIST () "/" "Sent/August2004"
      S: BBB OK done

   8:   The following example demonstrates the difference between the
        \HasChildren attribute and the CHILDINFO extended data item.

        Let's assume there is the following hierarchy:

      C: C01 LIST "" "*"
      S: * LIST (\Marked \NoInferiors) "/" "inbox"
      S: * LIST () "/" "Foo"
      S: * LIST () "/" "Foo/Bar"
      S: * LIST () "/" "Foo/Baz"
      S: * LIST () "/" "Moo"
      S: C01 OK done

        If the client asks RETURN (CHILDREN) it will get this:

      C: CA3 LIST "" "%" RETURN (CHILDREN)
      S: * LIST (\Marked \NoInferiors) "/" "inbox"
      S: * LIST (\HasChildren) "/" "Foo"
      S: * LIST (\HasNoChildren) "/" "Moo"
      S: CA3 OK done

Leiba & Melnikov          Expires July 21, 2006                [Page =
19]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

        A) Let's also assume that the mailbox "Foo/Baz" is the only
        subscribed mailbox.  Then we get this result:

      C: C02 LIST (SUBSCRIBED) "" "*"
      S: * LIST (\Subscribed) "/" "Foo/Baz"
      S: C02 OK done

        Now, if the client issues <LIST (SUBSCRIBED) "" "%">, the =
server
        will return no mailboxes (as the mailboxes "Moo", "Foo" and
        "Inbox" are NOT subscribed).  However, if the client issues
        this:

      C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
      S: * LIST () "/" "Foo" (("CHILDINFO" ("SUBSCRIBED")))
      S: C04 OK done

        i.e. the mailbox "Foo" is not subscribed, but it has a child
        that is.

        A1) If the mailbox "Foo" had also been subscribed, the last
        command would return this:

      C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
      S: * LIST (\Subscribed) "/" "Foo" (("CHILDINFO" ("SUBSCRIBED")))
      S: C04 OK done

        or even this:

      C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
      S: * LIST (\Subscribed \HasChildren) "/" "Foo" (("CHILDINFO"
         ("SUBSCRIBED")))
      S: C04 OK done

        A2) If we assume instead that the mailbox "Foo" is not part of
        the original hierarchy and is not subscribed, the last command
        will give this result:

      C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
      S: * LIST (\NonExistent) "/" "Foo" (("CHILDINFO" ("SUBSCRIBED")))
      S: C04 OK done

        B) Now, let's assume that no mailbox is subscribed.  In this
        case the command <LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"> will
        return no responses, as there are no subscribed children (even
        though "Foo" has children).

        C) And finally, suppose that only the mailboxes "Foo" and "Moo"
        are subscribed.  In that case we see this result:

Leiba & Melnikov          Expires July 21, 2006                [Page =
20]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

      C: C04 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%" RETURN (CHILDREN)
      S: * LIST (\HasChildren \Subscribed) "/" "Foo"
      S: * LIST (\HasNoChildren \Subscribed) "/" "Moo"
      S: C04 OK done

        (which means that the mailbox "Foo" has children, but none of
        them is subscribed).

   9:   The following example demonstrates that the CHILDINFO extended
        data item is returned whether children mailboxes match the
        canonical LIST pattern or not.

        Let's assume there is the following hierarchy:

      C: D01 LIST "" "*"
      S: * LIST (\Marked \NoInferiors) "/" "inbox"
      S: * LIST () "/" "foo2"
      S: * LIST () "/" "foo2/bar1"
      S: * LIST () "/" "foo2/bar2"
      S: * LIST () "/" "baz2"
      S: * LIST () "/" "baz2/bar2"
      S: * LIST () "/" "baz2/bar22"
      S: * LIST () "/" "baz2/bar222"
      S: * LIST () "/" "eps2"
      S: * LIST () "/" "eps2/mamba"
      S: * LIST () "/" "qux2/bar2"
      S: D01 OK done

        And that the following mailboxes are subscribed:

      C: D02 LIST (SUBSCRIBED) "" "*"
      S: * LIST (\Subscribed) "/" "foo2/bar1"
      S: * LIST (\Subscribed) "/" "foo2/bar2"
      S: * LIST (\Subscribed) "/" "baz2/bar2"
      S: * LIST (\Subscribed) "/" "baz2/bar22"
      S: * LIST (\Subscribed) "/" "baz2/bar222"
      S: * LIST (\Subscribed) "/" "eps2"
      S: * LIST (\Subscribed) "/" "eps2/mamba"
      S: * LIST (\Subscribed) "/" "qux2/bar2"
      S: D02 OK done

        The client issues the following command first:

Leiba & Melnikov          Expires July 21, 2006                [Page =
21]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

      C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*2"
      S: * LIST () "/" "foo2" (("CHILDINFO" ("SUBSCRIBED")))
      S: * LIST (\Subscribed) "/" "foo2/bar2"
      S: * LIST () "/" "baz2" (("CHILDINFO" ("SUBSCRIBED")))
      S: * LIST (\Subscribed) "/" "baz2/bar2"
      S: * LIST (\Subscribed) "/" "baz2/bar22"
      S: * LIST (\Subscribed) "/" "baz2/bar222"
      S: * LIST (\Subscribed) "/" "eps2" (("CHILDINFO" ("SUBSCRIBED")))
      S: * LIST (\Subscribed) "/" "qux2/bar2"
      S: D03 OK done

        and the server may also include

      S: * LIST (\NonExistent) "/" "qux2" (("CHILDINFO" =
("SUBSCRIBED")))

        The CHILDINFO extended data item is returned for mailboxes
        "foo2", "baz2" and "eps2", because all of them have subscribed
        children, even though for the mailbox "foo2" only one of the =
two
        subscribed children match the pattern, for the mailbox "baz2"
        all the subscribed children match the pattern and for the
        mailbox "eps2" none of the subscribed children matches the
        pattern.

        Note that if the client issues

      C: D03 LIST (RECURSIVEMATCH SUBSCRIBED) "" "*"
      S: * LIST () "/" "foo2" (("CHILDINFO" ("SUBSCRIBED")))
      S: * LIST (\Subscribed) "/" "foo2/bar1"
      S: * LIST (\Subscribed) "/" "foo2/bar2"
      S: * LIST () "/" "baz2" (("CHILDINFO" ("SUBSCRIBED")))
      S: * LIST (\Subscribed) "/" "baz2/bar2"
      S: * LIST (\Subscribed) "/" "baz2/bar22"
      S: * LIST (\Subscribed) "/" "baz2/bar222"
      S: * LIST (\Subscribed) "/" "eps2" (("CHILDINFO" ("SUBSCRIBED")))
      S: * LIST (\Subscribed) "/" "eps2/mamba"
      S: * LIST (\Subscribed) "/" "qux2/bar2"
      S: D03 OK done

        the LIST responses for mailboxes "foo2", "baz2" and "eps2" =
still
        have the CHILDINFO extended data item, even though this
        information is redundant and the client can determine it by
        itself.

   10:  The following example shows usage of multiple mailbox patterns.
        It also demonstrates that the presence of the CHILDINFO =
extended
        data item doesn't necessarily imply \HasChildren.

Leiba & Melnikov          Expires July 21, 2006                [Page =
22]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

      C: a1 LIST "" ("foo" "foo/*")
      S: * LIST () "/" foo
      S: a1 OK done

      C: a2 LIST (SUBSCRIBED) "" "foo/*"
      S: * LIST (\Subscribed \NonExistent) "/" foo/bar
      S: a2 OK done

      C: a3 LIST (SUBSCRIBED RECURSIVEMATCH) "" foo RETURN (CHILDREN)
      S: * LIST (\HasNoChildren) "/" foo (("CHILDINFO" ("SUBSCRIBED")))
      S: a3 OK done

Leiba & Melnikov          Expires July 21, 2006                [Page =
23]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

6.  Formal Syntax

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) as described in [ABNF].  Terms not defined here are taken
   from [IMAP4].  In particular, note that the version of =
"mailbox-list"
   below, which defines the payload of the LIST response, updates the
   version defined in the IMAP specification.  It is pointed to by
   "mailbox-data", which is defined in [IMAP4].

   "vendor-token" is defined in [ACAP].  Note that this normative
   reference to ACAP is an issue in moving this spec forward, since it
   introduces a dependency on ACAP.  The definitions of "vendor-token"
   and of the IANA registry must eventually go somewhere else, in a
   document that can be moved forward on the standards track
   independently of ACAP.

   childinfo-extended-item =3D  "CHILDINFO" SP "("
               list-select-base-opt-quoted
               *(SP list-select-base-opt-quoted) ")"
               ; Extended data item returned when the RECURSIVEMATCH
               ; selection option is specified.
               ; Note 1: the CHILDINFO tag can be returned
               ; with and without surrounding quotes, as per
               ; mbox-list-extended-item-tag production.
               ; Note 2: The selection options are returned quoted,
               ; unlike their specification in the extended LIST
               ; command.

   child-mbox-flag =3D  "\HasChildren" / "\HasNoChildren"
               ; attributes for CHILDREN return option, at most one
               ; possible per LIST response

   eitem-standard-tag =3D  atom
               ; a tag for extended list data defined in a Standard
               ; Track or Experimental RFC.

   eitem-vendor-tag =3D  vendor-tag
               ; a vendor specific tag for extended list data

   list =3D      "LIST" [SP list-select-opts] SP mailbox SP mbox-or-pat
               [SP list-return-opts]

Leiba & Melnikov          Expires July 21, 2006                [Page =
24]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

   list-return-opts =3D  "RETURN" SP
               "(" [return-option *(SP return-option)] ")"
               ; list return options, e.g.  CHILDREN

   list-select-base-opt =3D  "SUBSCRIBED" / option-extension
               ; options that can be used by themselves

   list-select-base-opt-quoted =3D  <"> list-select-base-opt <">

   list-select-independent-opt =3D  "REMOTE" / option-extension
               ; options that do not syntactically interact with
               ; other options

   list-select-mod-opt =3D  "RECURSIVEMATCH" / option-extension
               ; options that require a list-select-base-opt
               ; to also be present

   list-select-opt =3D  list-select-base-opt / =
list-select-independent-opt
               / list-select-mod-opt
               ; An option registration template is described in
               ; Section 8.3 of this document.

   list-select-opts =3D  "(" [
                 (*(list-select-opt SP) list-select-base-opt
                  *(SP list-select-opt))
               / (list-select-independent-opt
                  *(SP list-select-independent-opt))
               ] ")"
               ; Any number of options may be in any order.
               ; If a list-select-mod-opt appears, then a
               ; list-select-base-opt must also appear.
               ; This allows these:
               ; ()
               ; (REMOTE)
               ; (SUBSCRIBED)
               ; (SUBSCRIBED REMOTE)
               ; (SUBSCRIBED RECURSIVEMATCH)
               ; (SUBSCRIBED REMOTE RECURSIVEMATCH)
               ; But does NOT allow these:
               ; (RECURSIVEMATCH)
               ; (REMOTE RECURSIVEMATCH)

Leiba & Melnikov          Expires July 21, 2006                [Page =
25]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

   mailbox-list =3D  "(" [mbx-list-flags] ")" SP
               (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox
               [SP mbox-list-extended]
               ; This is the list information pointed to by the ABNF
               item ; "mailbox-data", which is defined in [IMAP4]

   mbox-list-extended =3D  "(" [mbox-list-extended-item
               *(SP mbox-list-extended-item)] ")"

   mbox-list-extended-item =3D  "(" mbox-list-extended-item-data ")"

   mbox-list-extended-item-data =3D  mbox-list-extended-item-tag SP
               nstring-list

   mbox-list-extended-item-tag =3D  astring
               ; The content MUST conform to either "eitem-vendor-tag"
               ; or "eitem-standard-tag" ABNF productions.
               ; A tag registration template is described in this
               ; document in Section 8.5.

   mbox-list-oflag =3D  child-mbox-flag / "\NonExistent" / =
"\Subscribed" /
               "\Remote"

   mbox-or-pat =3D  list-mailbox / patterns

   nstring-list =3D  nstring /
               "(" [nstring-list *(SP nstring-list)] ")"
               ; a recursive list definition

   option-extension =3D  (option-standard-tag / option-vendor-tag)
               [SP option-value]

   option-standard-tag =3D  atom
               ; an option defined in a Standards Track or
               ; Experimental RFC

Leiba & Melnikov          Expires July 21, 2006                [Page =
26]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

   option-val-comp =3D  astring /
               option-val-comp *(SP option-val-comp) /
               "(" option-val-comp ")"

   option-value =3D  "(" option-val-comp ")"

   option-vendor-tag =3D  vendor-token "-" atom
               ; a vendor specific option, non-standard

   patterns =3D  "(" list-mailbox *(SP list-mailbox) ")"

   return-option =3D  "SUBSCRIBED" / "CHILDREN" / option-extension

Leiba & Melnikov          Expires July 21, 2006                [Page =
27]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

7.  Security Considerations

   This document describes syntactic changes to the specification of =
the
   IMAP4 commands LIST, LSUB, RLIST, and RLSUB, and the modified LIST
   command has the same security considerations as those commands.  =
They
   are described in [IMAP4] and [MBRef].

   The Child Mailbox Extension provides a client a more efficient means
   of determining whether a particular mailbox has children.  If a
   mailbox has children, but the currently authenticated user does not
   have access to any of them, the server SHOULD respond with a
   \HasNoChildren attribute.  In many cases, however, a server may not
   be able to efficiently compute whether a user has access to all =
child
   mailboxes.  If such a server responds with a \HasChildren attribute,
   when in fact the currently authenticated user does not have access =
to
   any child mailboxes, potentially more information is conveyed about
   the mailbox than intended.  In most situations this will not be a
   security concern, because if information regarding whether a mailbox
   has children is considered sensitive, a user would not be granted
   access to that mailbox in the first place.

   The CHILDINFO extended data item has the same security =
considerations
   as the \HasChildren attribute described above.

Leiba & Melnikov          Expires July 21, 2006                [Page =
28]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

8.  IANA Considerations

8.1.  Guidelines for IANA

   It is requested that IANA creates two new registries for LIST-
   EXTENDED options and LIST-EXTENDED response data.  The templates and
   the initial registrations are detailed below.

8.2.  Registration procedure and Change control

   Registration of a LIST-EXTENDED option is done by filling in the
   template in Section 8.3 and sending it via electronic mail to
   [email-masked].  Registration of a LIST-EXTENDED extended data item =
is
   done by filling in the template in Section 8.5 and sending it via
   electronic mail to [email-masked].  IANA has the right to reject
   obviously bogus registrations, but will perform no review of claims
   made in the registration form.

   A LIST-EXTENDED option/extended data item name that starts with "V-"
   is reserved for vendor specific options/extended data items.  All
   options, whether they are vendor specific or global, should be
   registered with IANA.  If a LIST-EXTENDED extended data item is
   returned as a result of requesting a particular LIST-EXTENDED =
option,
   the name of the option SHOULD be used as the name of the LIST-
   EXTENDED extended data item.

   Each vendor specific options/extended data item MUST start with =
their
   vendor-token ("vendor prefix").  The vendor-token MUST be registered
   with IANA, using the [ACAP] vendor subtree registry.

   Standard LIST-EXTENDED option/extended data item names are case
   insensitive.  If the vendor prefix is omitted from a vendor specific
   LIST-EXTENDED option/extended data item name, the rest is case
   insensitive.  The vendor prefix itself is not case-sensitive, as it
   might contain non-ASCII characters.

   While the registration procedures do not require it, authors of =
LIST-
   EXTENDED options/extended data items are encouraged to seek =
community
   review and comment whenever that is feasible.  Authors may seek
   community review by posting a specification of their proposed
   mechanism as an Internet- Draft.  LIST-EXTENDED options/extended =
data
   items intended for widespread use should be standardized through the
   normal IETF process, when appropriate.

   Comments on registered LIST-EXTENDED options/extended response data
   should first be sent to the "owner" of the mechanism and/or to the
   IMAPEXT WG mailing list.  Submitters of comments may, after a
   reasonable attempt to contact the owner, request IANA to attach =
their

Leiba & Melnikov          Expires July 21, 2006                [Page =
29]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

   comment to the registration itself.  If IANA approves of this, the
   comment will be made accessible in conjunction with the registration
   LIST-EXTENDED options/ extended response data itself.

   Once a LIST-EXTENDED registration has been published by IANA, the
   author may request a change to its definition.  The change request
   follows the same procedure as the registration request.

   The owner of a LIST-EXTENDED registration may pass responsibility =
for
   the registered option/extended data item to another person or agency
   by informing IANA; this can be done without discussion or review.

   The IESG may reassign responsibility for a LIST-EXTENDED option/
   extended data item.  The most common case of this will be to enable
   changes to be made to mechanisms where the author of the =
registration
   has died, moved out of contact or is otherwise unable to make =
changes
   that are important to the community.

   LIST-EXTENDED registrations may not be deleted; mechanisms which are
   no longer believed appropriate for use can be declared OBSOLETE by a
   change to their "intended use" field; such LIST-EXTENDED options/
   extended data items will be clearly marked in the lists published by
   IANA.

   The IESG is considered to be the owner of all LIST-EXTENDED options/
   extended data items which are on the IETF standards track.

8.3.  Registration template for LIST-EXTENDED options

   To: [email-masked]
   Subject: Registration of LIST-EXTENDED option X

   LIST-EXTENDED option name:

   LIST-EXTENDED option type: (One of SELECTION or RETURN)

   Implied return options(s), if the option type is SELECTION: (zero or
   more)

   LIST-EXTENDED option description:

   Published specification (optional, recommended):

   Security considerations:

   Intended usage:
   (One of COMMON, LIMITED USE or OBSOLETE)

Leiba & Melnikov          Expires July 21, 2006                [Page =
30]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

   Person and email address to contact for further information:

   Owner/Change controller:

   (Any other information that the author deems interesting may be =
added
   below this line.)

8.4.  Initial LIST-EXTENDED option registrations

   It is requested that the LIST-EXTENDED option registry be populated
   with the following entries:

   1.  To: [email-masked]
       Subject: Registration of LIST-EXTENDED option SUBSCRIBED

       LIST-EXTENDED option name: SUBSCRIBED

       LIST-EXTENDED option type: SELECTION

       Implied return options(s): SUBSCRIBED

       LIST-EXTENDED option description: Causes the LIST command to =
list
       subscribed mailboxes, rather than the actual mailboxes.

       Published specification : XXXX, Section 3.

       Security considerations: XXXX, Section 7.

       Intended usage: COMMON

       Person and email address to contact for further information:
       Alexey Melnikov <[email-masked]>

       Owner/Change controller: [email-masked]

   2.  To: [email-masked]
       Subject: Registration of LIST-EXTENDED option REMOTE

       LIST-EXTENDED option name: REMOTE

       LIST-EXTENDED option type: SELECTION

       Implied return options(s): (none)

       LIST-EXTENDED option description: causes the LIST command to
       return remote mailboxes as well as local ones, as described in

Leiba & Melnikov          Expires July 21, 2006                [Page =
31]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

       RFC 2193.

       Published specification : XXXX, Section 3.

       Security considerations: XXXX, Section 7.

       Intended usage: COMMON

       Person and email address to contact for further information:
       Alexey Melnikov <[email-masked]>

       Owner/Change controller: [email-masked]

   3.  To: [email-masked]
       Subject: Registration of LIST-EXTENDED option SUBSCRIBED

       LIST-EXTENDED option name: SUBSCRIBED

       LIST-EXTENDED option type: RETURN

       LIST-EXTENDED option description: Causes the LIST command to
       return subscription state.

       Published specification : XXXX, Section 3.

       Security considerations: XXXX, Section 7.

       Intended usage: COMMON

       Person and email address to contact for further information:
       Alexey Melnikov <[email-masked]>

       Owner/Change controller: [email-masked]

   4.  To: [email-masked]
       Subject: Registration of LIST-EXTENDED option RECURSIVEMATCH

       LIST-EXTENDED option name: RECURSIVEMATCH

       LIST-EXTENDED option type: SELECTION

       Implied return options(s): (none)

       LIST-EXTENDED option description: Requests that CHILDINFO

Leiba & Melnikov          Expires July 21, 2006                [Page =
32]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

       extended data item is to be returned.

       Published specification : XXXX, Section 3.

       Security considerations: XXXX, Section 7.

       Intended usage: COMMON

       Person and email address to contact for further information:
       Alexey Melnikov <[email-masked]>

       Owner/Change controller: [email-masked]

   5.  To: [email-masked]
       Subject: Registration of LIST-EXTENDED option CHILDREN

       LIST-EXTENDED option name: CHILDREN

       LIST-EXTENDED option type: RETURN

       LIST-EXTENDED option description: Requests mailbox child
       information.

       Published specification : XXXX, Section 3 and Section 4.

       Security considerations: XXXX, Section 7.

       Intended usage: COMMON

       Person and email address to contact for further information:
       Alexey Melnikov <[email-masked]>

       Owner/Change controller: [email-masked]

8.5.  Registration template for LIST-EXTENDED extended data item

   To: [email-masked]
   Subject: Registration of X LIST-EXTENDED extended data item

   LIST-EXTENDED extended data item tag:

   LIST-EXTENDED extended data item description:

   Which LIST-EXTENDED option(s) (and their types) causes this extended
   data item to be returned (if any):

Leiba & Melnikov          Expires July 21, 2006                [Page =
33]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

   Published specification (optional, recommended):

   Security considerations:

   Intended usage:
   (One of COMMON, LIMITED USE or OBSOLETE)

   Person and email address to contact for further information:

   Owner/Change controller:

   (Any other information that the author deems interesting may be =
added
   below this line.)

8.6.  Initial LIST-EXTENDED extended data item registrations

   It is requested that the LIST-EXTENDED extended data item registry =
be
   populated with the following entries:

   1.  To: [email-masked]
       Subject: Registration of CHILDINFO LIST-EXTENDED extended data
       item

       LIST-EXTENDED extended data item tag: CHILDINFO

       LIST-EXTENDED extended data item description: The CHILDINFO
       extended data item describes the selection criteria that has
       caused it to be returned and indicates that the mailbox has one
       or more child mailbox that match the selection criteria.

       Which LIST-EXTENDED option(s) (and their types) causes this
       extended data item to be returned (if any): RECURSIVEMATCH
       selection option

       Published specification : XXXX, Section 3.3.

       Security considerations: XXXX, Section 7.

       Intended usage: COMMON

       Person and email address to contact for further information:
       Alexey Melnikov <[email-masked]>

       Owner/Change controller: [email-masked]

Leiba & Melnikov          Expires July 21, 2006                [Page =
34]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

9.  Acknowledgements

   Mike Gahrns and Raymond Cheng of Microsoft Corporation originally
   devised the Child Mailbox Extension and proposed it in 1997; the
   idea, as well as most of the text in Section 4, is theirs.

   This document is the result of discussions on the IMAP4 and IMAPEXT
   mailing lists and is meant to reflect consensus of those groups.  In
   particular, Mark Crispin, Philip Guenther, Cyrus Daboo, Timo
   Sirainen, Ken Murchison, Rob Siemborski, Steve Hole, Arnt
   Gulbrandsen, Larry Greenfield, Dave Cridland and Pete Maclean were
   active participants in those discussions or made suggestions to this
   document.

Leiba & Melnikov          Expires July 21, 2006                [Page =
35]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

10.  Normative References

   [ABNF]   Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
            Specifications: ABNF", RFC 4234, October 2005.

   [ACAP]   Newman, C. and J. Myers, "ACAP -- Application Configuration
            Access Protocol", RFC 2244, November 1997.

   [CMbox]  Gahrns, M. and R. Cheng, "", RFC 3348, July 2002.

   [IMAP4]  Crispin, M., "Internet Message Access Protocol - Version
            4rev1", RFC 3501, March 2003.

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

   [MBRef]  Gahrns, M., "IMAP4 Mailbox Referrals", RFC 2193,
            September 1997.

Leiba & Melnikov          Expires July 21, 2006                [Page =
36]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

Authors' Addresses

   Barry Leiba
   IBM T.J. Watson Research Center
   19 Skyline Drive
   Hawthorne, NY  10532
   US

   Phone: +1 914 784 7941
   Email: [email-masked]

   Alexey Melnikov
   Isode Limited
   5 Castle Business Village
   36 Station Road
   Hampton, Middlesex  TW12 2BX
   UK

   Email: [email-masked]
   URI:   http://www.melnikov.ca/

Leiba & Melnikov          Expires July 21, 2006                [Page =
37]
=0C
Internet-Draft        IMAP4 LIST Command Extensions         January =
2006

Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

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

Intellectual Property

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

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

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

Acknowledgment

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

Leiba & Melnikov          Expires July 21, 2006                [Page =
38]
=0C

--==========F13281BD76B984D2F1FF==========--

Date: Mon, 16 Jan 2006 16:51:04 -0500
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: Re: Blather about \Marked
Sender: [email-masked]

Folks, folks, folks...

PLEASE...

STOP arguing about \Marked (and other things) with the subject line
"Re: WG Last Call of LISTEXT draft 14".  Change the subject line (hey,
here's a good one right on this message; feel free to use it).

I'm trying to sort out the things that people are suggesting in
response to the last call on LISTEXT.  Let's please use the "WG Last
Call of LISTEXT" subject for that only, and change the subject when the
discussion strays.

Thank you.  I now return you to the pointless discussion already in
progress.

Barry

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

Date: Wed, 11 Jan 2006 17:13:32 +0000
From: Alexey Melnikov <[email-masked]>
To: Ken Murchison <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-condstore-08.txt
Sender: [email-masked]

Ken Murchison wrote:

> [email-masked] wrote:
>
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Internet Message Access Protocol 
>> Extension Working Group of the IETF.
>>
>>     Title        : IMAP Extension for Conditional STORE operation
>>     Author(s)    : A. Melnikov, S. Hole
>>     Filename    : draft-ietf-imapext-condstore-08.txt
>>     Pages        : 0
>>     Date        : 2006-1-3
>
> What changed?

Dave is right, I've moved SORT stuff to a separate draft, so that the 
document can [finally] be published.

Date: Tue, 10 Jan 2006 11:26:03 +0100
From: Arnaud Taddei <[email-masked]>
Subject: Re: Need a template to start a draft
To: "Burger, Eric" <[email-masked]>
Cc: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_neWLDE2h82ra5ouLLJ7JbA)
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT

Burger, Eric wrote:

>You really, really, really want to use the XML stuff.  
>
Yes I am building my XML document.

>It has a little
>learning curve, but it will make the total publication process much
>easier for you and your chairs in the long run.
>  
>
I understand this indeed and it makes sense if this helps others, then 
that cannot be a wrong approach though my selfish natural approach would 
have been to use roff :-)

A++

>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]] On Behalf Of Lisa Dusseault
>Sent: Friday, January 06, 2006 1:25 PM
>To: Mark Crispin
>Cc: Arnaud Taddei; IMAP Extensions WG
>Subject: Re: Need a template to start a draft
>
>
>I use the XML stuff described at http://xml.resource.org, myself.  If 
>you browse http://ietf.webdav.org for XML files, you can see a number 
>of examples.
>
>Lisa
>
>On Jan 6, 2006, at 9:30 AM, Mark Crispin wrote:
>
>  
>
>>On Fri, 6 Jan 2006, Arnaud Taddei wrote:
>>    
>>
>>>Where can I find a template to start a draft? What are you guys
>>>      
>>>
>using?
>  
>
>>Start with http://www.ietf.org/ID-Checklist.html
>>
>>-- Mark --
>>
>>http://panda.com/mrc
>>Democracy is two wolves and a sheep deciding what to eat for lunch.
>>Liberty is a well-armed sheep contesting the vote.
>>
>>    
>>

--Boundary_(ID_neWLDE2h82ra5ouLLJ7JbA)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Burger, Eric wrote:
<blockquote
 cite="[email-masked]"
 type="cite">
  <pre wrap="">You really, really, really want to use the XML stuff.  </pre>
</blockquote>
Yes I am building my XML document.<br>
<blockquote
 cite="[email-masked]"
 type="cite">
  <pre wrap="">It has a little
learning curve, but it will make the total publication process much
easier for you and your chairs in the long run.
  </pre>
</blockquote>
I understand this indeed and it makes sense if this helps others, then
that cannot be a wrong approach though my selfish natural approach
would have been to use roff :-)<br>
<br>
A++<br>
<blockquote
 cite="[email-masked]"
 type="cite">
  <pre wrap="">
-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
[<a class="moz-txt-link-freetext" href="mailto:[email-masked]">mailto:[email-masked]</a>] On Behalf Of Lisa Dusseault
Sent: Friday, January 06, 2006 1:25 PM
To: Mark Crispin
Cc: Arnaud Taddei; IMAP Extensions WG
Subject: Re: Need a template to start a draft

I use the XML stuff described at <a class="moz-txt-link-freetext" href="http://xml.resource.org">http://xml.resource.org</a>, myself.  If 
you browse <a class="moz-txt-link-freetext" href="http://ietf.webdav.org">http://ietf.webdav.org</a> for XML files, you can see a number 
of examples.

Lisa

On Jan 6, 2006, at 9:30 AM, Mark Crispin wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap="">On Fri, 6 Jan 2006, Arnaud Taddei wrote:
    </pre>
    <blockquote type="cite">
      <pre wrap="">Where can I find a template to start a draft? What are you guys
      </pre>
    </blockquote>
  </blockquote>
  <pre wrap=""><!---->using?
  </pre>
  <blockquote type="cite">
    <pre wrap="">Start with <a class="moz-txt-link-freetext" href="http://www.ietf.org/ID-Checklist.html">http://www.ietf.org/ID-Checklist.html</a>

-- Mark --

<a class="moz-txt-link-freetext" href="http://panda.com/mrc">http://panda.com/mrc</a>
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

    </pre>
  </blockquote>
</blockquote>
<br>
</body>
</html>

--Boundary_(ID_neWLDE2h82ra5ouLLJ7JbA)--

Content-class: urn:content-classes:message
Subject: RE: Need a template to start a draft
Date: Tue, 10 Jan 2006 02:10:33 -0500
From: "Burger, Eric" <[email-masked]>
To: "Arnaud Taddei" <[email-masked]>
Cc: "IMAP Extensions WG" <[email-masked]>
Sender: [email-masked]

You really, really, really want to use the XML stuff.  It has a little
learning curve, but it will make the total publication process much
easier for you and your chairs in the long run.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Lisa Dusseault
Sent: Friday, January 06, 2006 1:25 PM
To: Mark Crispin
Cc: Arnaud Taddei; IMAP Extensions WG
Subject: Re: Need a template to start a draft

I use the XML stuff described at http://xml.resource.org, myself.  If 
you browse http://ietf.webdav.org for XML files, you can see a number 
of examples.

Lisa

On Jan 6, 2006, at 9:30 AM, Mark Crispin wrote:

>
> On Fri, 6 Jan 2006, Arnaud Taddei wrote:
>> Where can I find a template to start a draft? What are you guys
using?
>
> Start with http://www.ietf.org/ID-Checklist.html
>
> -- Mark --
>
> http://panda.com/mrc
> Democracy is two wolves and a sheep deciding what to eat for lunch.
> Liberty is a well-armed sheep contesting the vote.
>

Subject: Re: WG Last Call of LISTEXT draft 14
From: Timo Sirainen <[email-masked]>
To: Cyrus Daboo <[email-masked]>
Cc: [email-masked]
Date: Mon, 09 Jan 2006 23:24:38 +0200
Sender: [email-masked]

--=-HeSULr90xmx/ViOWGApp
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Mon, 2006-01-09 at 13:01 -0800, Cyrus Daboo wrote:
> Hi Timo,
>=20
> --On January 9, 2006 8:06:16 PM +0200 Timo Sirainen <[email-masked]> wrote:
>=20
> >> I certainly feel that it's less work for you to use the "Q" command th=
an
> >> it is for everybody else to deal with the wreckage caused by
> >> implementations that do not support recent and marking properly.
> >
> > I'm not suggesting that (well, not anymore nowadays). But perhaps some
> > new \Noticed flag, which works in many ways like recent, but instead of
> > being removed whenever a client notices the mail, it's removed only whe=
n
> > a MARK-NOTICED command is given. The client could send that whenever it
> > figures out that user has actually been reading the mailbox (eg. opened
> > some mail). Although I suppose that could be implemented as a keyword
> > too..
>=20
> Alternatively use \Seen (which the client should handle automatically for=
=20
> you) with a $FOLLOWUP-NEEDED keyword (or simply \Flagged) when you need t=
o=20
> do more with the message after viewing it.

That would be a nice feature also, but it's not exactly what I meant.
With \Noticed / $Noticed I meant the client thought I at least noticed
the mails' presence, not that I necessarily opened them.

For example with some mailing lists I don't really want to keep marking
all the mails as \Seen constantly, but I'd still like to know when new
mail arrives to them (then a quick look into the mailbox and out of it
would be enough to set $Noticed to all the mails).

One way would be to set this flag for *all* mails in the mailbox
whenever I open any mail them. Or maybe if the mail window becomes
visible for more than few seconds. Something like that.

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

--=-HeSULr90xmx/ViOWGApp--

Date: Mon, 09 Jan 2006 13:01:54 -0800
From: Cyrus Daboo <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: [email-masked]
Subject: Re: WG Last Call of LISTEXT draft 14
Sender: [email-masked]

Hi Timo,

--On January 9, 2006 8:06:16 PM +0200 Timo Sirainen <[email-masked]> wrote:

>> I certainly feel that it's less work for you to use the "Q" command than
>> it is for everybody else to deal with the wreckage caused by
>> implementations that do not support recent and marking properly.
>
> I'm not suggesting that (well, not anymore nowadays). But perhaps some
> new \Noticed flag, which works in many ways like recent, but instead of
> being removed whenever a client notices the mail, it's removed only when
> a MARK-NOTICED command is given. The client could send that whenever it
> figures out that user has actually been reading the mailbox (eg. opened
> some mail). Although I suppose that could be implemented as a keyword
> too..

Alternatively use \Seen (which the client should handle automatically for 
you) with a $FOLLOWUP-NEEDED keyword (or simply \Flagged) when you need to 
do more with the message after viewing it.

-- 
Cyrus Daboo

Subject: Re: WG Last Call of LISTEXT draft 14
From: Timo Sirainen <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: Dave Cridland <[email-masked]>, Arnaud Taddei <[email-masked]>, [email-masked]
Date: Mon, 09 Jan 2006 20:06:16 +0200
Sender: [email-masked]

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

On Mon, 2006-01-09 at 09:09 -0800, Mark Crispin wrote:
> On Mon, 9 Jan 2006, Timo Sirainen wrote:
> >>> Unfortunately this works only as long as you're using only one IMAP
> >>> client at a time.
> >> s/at a time./selected on the same mailbox at a time./
> > No, not the same mailbox. Just having selected any mailboxes.
>=20
> Say what?
>=20
> That doesn't make any sense.  A client selected on another mailbox is not=
=20
> going to affect the \Recent messages in the (different) mailbox you have=20
> selected.

No, but it affects the status of the other mailbox (the \Marked status)
in a mailbox list showing which boxes contain new mail.

> > You seem to suggest that the mailbox should be unselected whenever you
> > leave from the client. Is there any practical way to do that? Manually
> > it's too troublesome.
>=20
> No, I'm not suggesting that.  As I said, most people here only leave=20
> clients open on INBOX, and visit other mailboxes.
>=20
> I don't know what to tell you if a "Q" command is too much work for you.=20

Yes, it's too much :) I often start working based on some mail I read in
a mailing list, so the mailing list mailbox gets easily left open.

> I certainly feel that it's less work for you to use the "Q" command than=20
> it is for everybody else to deal with the wreckage caused by=20
> implementations that do not support recent and marking properly.

I'm not suggesting that (well, not anymore nowadays). But perhaps some
new \Noticed flag, which works in many ways like recent, but instead of
being removed whenever a client notices the mail, it's removed only when
a MARK-NOTICED command is given. The client could send that whenever it
figures out that user has actually been reading the mailbox (eg. opened
some mail). Although I suppose that could be implemented as a keyword
too..

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

--=-h5lfjY3w0ojNAf212UOu--

Date: Mon, 9 Jan 2006 09:09:02 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: Dave Cridland <[email-masked]>, Arnaud Taddei <[email-masked]>, [email-masked]
Subject: Re: WG Last Call of LISTEXT draft 14
Sender: [email-masked]

On Mon, 9 Jan 2006, Timo Sirainen wrote:
>>> Unfortunately this works only as long as you're using only one IMAP
>>> client at a time.
>> s/at a time./selected on the same mailbox at a time./
> No, not the same mailbox. Just having selected any mailboxes.

Say what?

That doesn't make any sense.  A client selected on another mailbox is not 
going to affect the \Recent messages in the (different) mailbox you have 
selected.

> But that's the problem. I always have _some_ mailbox selected in each
> client, and that client keeps eating the recent messages even though I
> haven't even looked at the client for days. It doesn't help me at all if
> my computer at office keeps telling me about new messages when I'm at
> home.

So your actual complaint is based upon your usage patterns.

My usage patterns are very different.  I leave clients selected on INBOX, 
open INBOX by default, and scan marking on the non-INBOX mailboxes that 
get direct delivery (we've had user+mailbox address syntax for a long 
time, just not as long as CMU).

Most people here do the same thing; and that's what drove the way that 
marking works.

> You seem to suggest that the mailbox should be unselected whenever you
> leave from the client. Is there any practical way to do that? Manually
> it's too troublesome.

No, I'm not suggesting that.  As I said, most people here only leave 
clients open on INBOX, and visit other mailboxes.

I don't know what to tell you if a "Q" command is too much work for you. 
I certainly feel that it's less work for you to use the "Q" command than 
it is for everybody else to deal with the wreckage caused by 
implementations that do not support recent and marking properly.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Mon, 09 Jan 2006 11:39:22 +0100
From: Arnaud Taddei <[email-masked]>
Subject: Re: WG Last Call of LISTEXT draft 14
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked], Philip Guenther <[email-masked]>, Chris Newman <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Arnaud Taddei writes:
>
>> I am not sure how many of you are dealing with operational, 
>> deployment and architectural issues in real customer sites but be 
>> aware that the IETF stack of protocol, while it allows 
>> interoperability of solutions, somehow, it too created an operational 
>> monster to implement and debug if it is not just to explain to people 
>> in the field. With the level of troops that exists today in the 
>> field, this leads me to say that I am not sure that this point of 
>> view was kept in mind when writing these extensions.
>
>
> I don't entirely agree, but, yes, I can't say I disagree...
>
> IETF standards are written for the people who show up at the meetings, 
> as they say. In the case of IMAP (and not only in that case), I do 
> wish the crowd were more diverse. (I prefer not to elaborate in email. 
> Too easy too offend people.) More people like you would help.

Well, ok I don't know IETF enough that is for sure, I never came myself 
to a session, not that I don't want to come but I was not allowed to 
come. Be aware that to just spend a few hours per week to review and 
comment and prepare myself some new drafts, I have to hide myself and I 
do that somehow on my spare time. I have to make sure my manager Waymon 
Whiting at work is ok with it (which he is because he allowed me to 
visit Mark and Terry Gray in november at Seattle) but I have to make 
sure this is ok as well with my managers at home (my wife and my two 
daughters who are 7 and 9!).

So it may be possible that my manager allows me to come to the next IETF 
but it is not clear yet. In the past it was a real challenge for me to 
do what I wanted in the past 7 years.

> Regarding LISTEXT specifically, what you have in mind seems like a 
> valuable command, but it's not one I would describe as "an extension 
> of LIST". More like a complete new command, e.g. one called 
> FOLDERSEARCH by analogy with LDAP.

Well, again, I read that statement but at the same time I have a 
different perspective on it.

> When I reviewed LISTEXT, I did so on the assumption that what was 
> needed were extensions to LIST as it stands. LISTEXT seems sensible as 
> such, and I've implemented it. Whether a completely different command 
> would be more valuable is a question I didn't contemplate, and which I 
> would prefer not to discuss now - please, let's get LISTEXT out the door.

Again I am afraid I disagree with this one here.

I will write a second round with my ideas in it.

A++

>
> Arnt

Date: Mon, 09 Jan 2006 11:24:33 +0100
From: Arnaud Taddei <[email-masked]>
Subject: Re: WG Last Call of LISTEXT draft 14
To: Mark Crispin <[email-masked]>
Cc: Dave Cridland <[email-masked]>, [email-masked]
Sender: [email-masked]

Mark Crispin wrote:

> Arnaud has his own agenda, 

in addition I have my limits, my constraints, my naivety and my biases :-)

> but I've talked with him quite a bit offline over the years.  I don't 
> always agree with him.  However, I share his dismay over some of the 
> directions taken in this WG.

> My silence on certain matters should not be taken as agreement.  It is 
> not necessary to do anything to kill something that is so byzantine 
> that it will die on its own.
>
> Put another way, if marking is too difficult to do right, so are 
> CONDSTORE and LISTEXT.  If keywords are too difficult to do right, so 
> is ANNOTATE.
>
> I object to hearing base specification functionality get badmouthed in 
> the same WG that's talking about much more complex functionality.  
> When I hear "nobody uses recent", "nobody uses marking", etc. this 
> tells me that we should not add ANY new extensions to IMAP until such 
> time as those statements cease to be made.

Ok I start to see where the problem is and I will make a second round.

A++

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

Subject: Re: WG Last Call of LISTEXT draft 14
From: Timo Sirainen <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: Dave Cridland <[email-masked]>, Arnaud Taddei <[email-masked]>, [email-masked]
Date: Mon, 09 Jan 2006 11:43:51 +0200
Sender: [email-masked]

--=-WdrYTey+vrXNs2f1qcBK
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Sun, 2006-01-08 at 14:58 -0800, Mark Crispin wrote:
> On Mon, 9 Jan 2006, Timo Sirainen wrote:
> > Unfortunately this works only as long as you're using only one IMAP
> > client at a time.
>=20
> s/at a time./selected on the same mailbox at a time./

No, not the same mailbox. Just having selected any mailboxes.

> > I wouldn't want to rely on a client that only notifies me of recent
> > messages or \Marked mailboxes, since I always have at least two IMAP
> > clients open and each one having selected whatever mailbox I happened t=
o
> > last look at.
>=20
> *Both* clients will see \Marked status until one or the other selects the=
=20
> mailbox.  At that point, the user has been alerted to the new messages.

But that's the problem. I always have _some_ mailbox selected in each
client, and that client keeps eating the recent messages even though I
haven't even looked at the client for days. It doesn't help me at all if
my computer at office keeps telling me about new messages when I'm at
home.

You seem to suggest that the mailbox should be unselected whenever you
leave from the client. Is there any practical way to do that? Manually
it's too troublesome.

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

--=-WdrYTey+vrXNs2f1qcBK--

Date: Mon, 09 Jan 2006 06:52:50 +0100
From: Arnaud Taddei <[email-masked]>
Subject: Re: WG Last Call of LISTEXT draft 14
To: Dave Cridland <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

>>    * Page 17, I think Example 6 requires much more explanations
>
>
> I think I see why. Could you suggest some alternate text for 
> explaining both example 5 and example 6? (I should think both would 
> need to be changed to express the difference more clearly).

Yes I will, let me understand all the comments on this thread first. I 
am feeling guilty now.

A++

Date: Mon, 09 Jan 2006 06:36:55 +0100
From: Arnaud Taddei <[email-masked]>
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
To: Arnt Gulbrandsen <[email-masked]>
Cc: [email-masked], Barry Leiba <[email-masked]>
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Arnaud Taddei writes:
>
>> The multiple mailbox patterns is extremely important for when you 
>> need to keep 2 IMAP servers synchronizing a selection of their 
>> (shared/public) folders so I vote for keeping this by all means.
>
>
> Could you elaborate?
>
> I don't see any difference at all between these two at the moment:
>
> C: a LIST "" a*
> C: b LIST "" *b
>
> and
>
> C: a LIST "" (a* *b)

Technically there is no difference but I consider counter intuitive that 
I have to ask 2 questions when semantically I have only one in mind.

A++

>
> There used to be a difference in previous version of the draft, namely 
> that folder 'adverb' was listed twice in the first case and only once 
> in the second.
>
> Arnt

Date: Sun, 8 Jan 2006 14:58:13 -0800
From: Mark Crispin <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: Dave Cridland <[email-masked]>, Arnaud Taddei <[email-masked]>, [email-masked]
Subject: Re: WG Last Call of LISTEXT draft 14
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Mon, 9 Jan 2006, Timo Sirainen wrote:
> Unfortunately this works only as long as you're using only one IMAP
> client at a time.

s/at a time./selected on the same mailbox at a time./

> Otherwise the new mail may be picked up first by
> another client which has the mailbox selected, but the client you're
> currently using sees the mailbox as \UnMarked and with 0 recent
> messages.

And why is this a problem?

If I am running two clients (which I routinely do), why on earth would I 
want one nagging me to open a mailbox when I've already opened it in the 
other?

I only want to be nagged about about *unopened* mailboxes with recent 
messages.  Once it's opened, I'm taking care of it; and any other client 
session should leave it alone.

> I wouldn't want to rely on a client that only notifies me of recent
> messages or \Marked mailboxes, since I always have at least two IMAP
> clients open and each one having selected whatever mailbox I happened to
> last look at.

*Both* clients will see \Marked status until one or the other selects the 
mailbox.  At that point, the user has been alerted to the new messages.

That's how it was designed to work.  At least one person feels that this 
is exactly how it should work.  Maybe I'm unique on this planet, but I 
suspect not.

After all, this is how mail worked in the 15 years prior to IMAP, and how 
most mail worked in the next 10-15 years after IMAP came about.

> \Recent may be useful for some things, but I wish there was a new
> similar flag that works properly with multiple clients open.

\Recent may not do what you prefer, but that is not the same as "does not 
work properly."

-- Mark --

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

Subject: Re: WG Last Call of LISTEXT draft 14
From: Timo Sirainen <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: Dave Cridland <[email-masked]>, Arnaud Taddei <[email-masked]>, [email-masked]
Date: Mon, 09 Jan 2006 00:06:06 +0200
Sender: [email-masked]

--=-M5DzPVaeK1o9/p0ar09H
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Sat, 2006-01-07 at 12:02 -0800, Mark Crispin wrote:
> On Sat, 7 Jan 2006, Dave Cridland wrote:
> > And my point is that even if \Marked *is* specified, client authors sti=
ll=20
> > can't make any assumptions.
>=20
> If \Marked is specified, then the mailbox definitely needs to be inspecte=
d=20
> closer.  If \UnMarked is not specified, then the mailbox definitely does=20
> NOT need to be inspected closer.

Unfortunately this works only as long as you're using only one IMAP
client at a time. Otherwise the new mail may be picked up first by
another client which has the mailbox selected, but the client you're
currently using sees the mailbox as \UnMarked and with 0 recent
messages.

I wouldn't want to rely on a client that only notifies me of recent
messages or \Marked mailboxes, since I always have at least two IMAP
clients open and each one having selected whatever mailbox I happened to
last look at.

\Recent may be useful for some things, but I wish there was a new
similar flag that works properly with multiple clients open.

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

--=-M5DzPVaeK1o9/p0ar09H--

Date: Sun, 8 Jan 2006 22:14:55 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: listext extended data
Sender: [email-masked]

I'm not sure, but it seems to me that somewhere, perhaps in the IANA 
registration for RECURSIVEMATCH, there should be a sentence which 
mentions both childinfo-extended-item and mbox-list-extended-item by 
name.

Or maybe in a comment for for childinfo-extended-item, that would be 
similar to how many other extensions extend other productions, e.g. 
annotate and search-key, condstore and fetch-att, 2177bis and 
command-auth, search-res and sequence-set, and so on and so forth.

As it stands, connecting the two required intelligent thought. Painful.

Arnt

Date: Sun, 8 Jan 2006 16:44:00 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: WG Last Call of LISTEXT draft 14
Cc: Philip Guenther <[email-masked]>, Arnaud Taddei <[email-masked]>, Chris Newman <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

Arnaud Taddei writes:
> I am not sure how many of you are dealing with operational, deployment 
> and architectural issues in real customer sites but be aware that the 
> IETF stack of protocol, while it allows interoperability of 
> solutions, somehow, it too created an operational monster to 
> implement and debug if it is not just to explain to people in the 
> field. With the level of troops that exists today in the field, this 
> leads me to say that I am not sure that this point of view was kept 
> in mind when writing these extensions.

I don't entirely agree, but, yes, I can't say I disagree...

IETF standards are written for the people who show up at the meetings, 
as they say. In the case of IMAP (and not only in that case), I do wish 
the crowd were more diverse. (I prefer not to elaborate in email. Too 
easy too offend people.) More people like you would help.

Regarding LISTEXT specifically, what you have in mind seems like a 
valuable command, but it's not one I would describe as "an extension of 
LIST". More like a complete new command, e.g. one called FOLDERSEARCH 
by analogy with LDAP.

When I reviewed LISTEXT, I did so on the assumption that what was needed 
were extensions to LIST as it stands. LISTEXT seems sensible as such, 
and I've implemented it. Whether a completely different command would 
be more valuable is a question I didn't contemplate, and which I would 
prefer not to discuss now - please, let's get LISTEXT out the door.

Arnt

Date: Sun, 8 Jan 2006 16:33:21 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
Cc: Arnaud Taddei <[email-masked]>, Barry Leiba <[email-masked]>
Sender: [email-masked]

Arnaud Taddei writes:
> The multiple mailbox patterns is extremely important for when you need 
> to keep 2 IMAP servers synchronizing a selection of their 
> (shared/public) folders so I vote for keeping this by all means.

Could you elaborate?

I don't see any difference at all between these two at the moment:

C: a LIST "" a*
C: b LIST "" *b

and

C: a LIST "" (a* *b)

There used to be a difference in previous version of the draft, namely 
that folder 'adverb' was listed twice in the first case and only once 
in the second.

Arnt

Date: Sat, 7 Jan 2006 12:02:50 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: Arnaud Taddei <[email-masked]>, [email-masked]
Subject: Re: WG Last Call of LISTEXT draft 14
Sender: [email-masked]

On Sat, 7 Jan 2006, Dave Cridland wrote:
> And my point is that even if \Marked *is* specified, client authors still 
> can't make any assumptions.

If \Marked is specified, then the mailbox definitely needs to be inspected 
closer.  If \UnMarked is not specified, then the mailbox definitely does 
NOT need to be inspected closer.

It's only in the case that there is no marking that there is a question of 
what to do.  In the case of trying to find new messages, false positives 
are better, so you treat it as if it is \Marked.  But there are cases 
where false negatives are better.  All that is avoided if the server 
follows the specification and implements marking, instead of listening to 
people who suggest that there's no point to doing so.

> Absolutely, and I'm sure you realise I'm not advocating that a server 
> implementor should do this. I'm merely pointing out that from a client's 
> perspective, it's impossible to tell if that's what the server is doing. Just 
> as servers should be striving to fully implement IMAP and all extensions, 
> clients have to be prepared to deal with the most contrary of servers.

Clients should be written to deal optimally with working servers.  It may 
be necessary to deal with broken servers, but clients should not treat a 
working server as a broken server.

In the extreme example of Courier, you have to use a special switch in 
Pine which switches off almost all IMAP functionalities and basically 
makes Pine act like Outlook (and be quite a bit slower).  The author of 
Courier may think that all clients should act like Outlook all the time. 
I disagree.

>>> In any case, many clients do not care about recent messages at all, only 
>>> about unseen messages, or simply messages they've not downloaded, causing 
>>> many server implementors to completely ignore \Marked and \UnMarked.
>> So, there are broken clients out there.
> No. These clients are not broken, they're simply not interested in that 
> information - that's a different thing.

No, clients which do not use the full capabilities of the IMAP base are 
broken.  Every piece of it is there for a reason; there is no surplusage.

A client which does not pay attention to recent status can not distinguish 
between a new message and one which arrived in a previous session but the 
user choose to defer reading it.  The latter are not new messages; and 
alerting the user to "new" messages when there are no recent messages is 
wrong.

> My client, for instance, does not care *if* a mailbox contains recent 
> messages, nor even how many there are once the mailbox is selected. It does 
> mark recent messages visually, and it does care about where the first recent 
> message is.

This is a contradiction.  At most, you are saying that your client doesn't 
do much with the recent count (which is mostly useful in a heading display 
such as "5329 messages, 23 recent").  Otherwise, your client very much 
cares about recent messages; it goes to considerable length to communicate 
the status to the user and (a non-obvious but important to any quality 
client) it makes note of where the first message is.

Let's get on the same page here.  Your client *does* care if a mailbox 
contains recent messages.

> The vast majority of clients ignore all non-system keywords that they didn't 
> define. I'd think we both agree this is misguided, but it is not broken.

It *is* broken, and I say this having fought this battle long and hard 
with my colleagues in Pine.  I'm still not particularly happy with what we 
have now, but at least it's better than what there was before which was 
nothing.  At best, Pine only gets a C+ for keywords.

> Pine, on the other hand, uses IMAP mailboxes to store addressbook and 
> configuration information, instead of using a protocol purpose-built for that 
> task. I don't consider that broken, however misguided I personally believe it 
> to be.

This is a legitimate sore spot.

We really, *really* wanted ACAP.  We instigated for ACAP because IMSP was, 
well, let's just say that IMSP was not satisfactory.  Sadly, ACAP did not 
learn from the experience.

Pine did what it did not out of ignorance or misguidance, but because we 
saw the ACAP train wreck coming early on and got off the train.

It is true that ACAP is a "failure" instead of a "miserable failure" 
because some people (such as you) have been able to use it.  But I think 
that even the small ACAP community can conceed that it has not been a 
success.

I really don't want to say too much more.  There's no sense in reopening 
old wounds.  Rather, we should look to the future.

Consider this:

IMAP mailboxes have proven to be completely satisfactory for remote 
addressbook and configuration information.  The *only* deficiency has been 
in sharing addressbooks with other MUAs.  For remote Pine configuration, 
there is no need to share that data with anything else; although one could 
imagine sharing some parts of Pine's configuration (e.g., an IMAP URL for 
the user's INBOX, submission server, NNTP server, etc.) with other MUAs.

Suppose you were to build a protocol that would be a natural upgrade to 
using IMAP mailboxes; one that solves those deficiencies *without* 
orthogonal functionality.  Would you come up with ACAP?  I suspect not.

There is a danger to doing more than is needed.  The simple and 
inexpensive solution that does what is necessary will always defeat the 
more complex and elegant solution.  VHS beat Beta.  For a long time, POP3 
beat IMAP and there are still substantial holdouts for POP3-only.  I'll 
wager that HD-DVD will beat Blu-Ray.

Sadly, it's worse than that.  A simple kludge that results in great 
complexity, but only complexity is already there and "paid for", will 
*also* beat the elegant solution that "isn't there yet".  Windows beat 
Mac.

My crystal ball says that the next train wreck is going to be personal 
address books in LDAP; only this time we are all going to be on that 
train.  What's more, we'll keep on jumping on to the train as it wrecks. 
This is a controversial prediction, and many good people are fighting hard 
to stop it from happening.  But my money is on it.  I don't take any 
pleasure in it.  I'd *love* to lose this bet.

>> I hope that you're not saying that, because there are broken clients, no 
>> client or server should ever attempt to do the right thing?
> No, but I am saying that when clients do not use information that is optional 
> to provide, there is little benefit to server implementors to go to any 
> effort to transmit it, and at least in my experience, the majority of server 
> implementors are satisfied with a minimalist conformancy.

I on the other hand believe that this is something which must be fought 
against tooth and nail.  It creates a vicious cycle in which deficient 
implementation spawns deficient implementation, back and forth between 
clients and servers.

This is what Courier does; it implements IMAP enough to satisfy Outlook 
and Netscape, and calls that "good enough".

>> Or worse, that it's alright for servers to be broken because most clients 
>> do not care?  That's basically what the author of Courier claims...
> I'm not claiming that. I am, however, claiming that servers might well elide 
> parts of the specification that are optional if there is little or no demand 
> for them, and whether or not that's a good thing isn't the issue under 
> discussion here.

There is little in the base specification that is truly optional.  I do 
not consider marking to be optional.

I might go so far as to say that a server implementation can say NO to any 
CREATE/DELETE/RENAME command; NO to any SELECT/EXAMINE command that does 
not have INBOX as an argument; and only return INBOX in LIST/LSUB, yet 
still be a quality server implementation if it otherwise fully implements 
IMAP.

Strange to say, non-INBOX mailboxes are the one part of IMAP that most 
people don't consider to be optional...

>>  . clients should be able to use the full specification
> I would argue "clients should be able to take full advantage of any 
> applicable parts of the specification and any applicable extensions to 
> achieve their goals in the most efficient manner possible", which is more or 
> less the same thing, but not quite: the distinction is that a client which 
> does not gain benefit from a particular feature obviously need not implement 
> it.

As an extreme example, the following is completely in line with what you 
just said:
 	1 select inbox
 	2 fetch 1:* rfc822
 	3 store 1:* flags (\deleted)
 	4 close

I take a harder line.  I don't consider that to be an IMAP client.  It's a 
POP client that babbles IMAP protocol.

Message metadata, envelopes, body structures, selective fetching, 
searching, sorting, threading,... all are necessary for a true IMAP 
client.  You can't declare one to be optional without imperiling it all.

> My issue with \Marked, which appears to have been blown out of all 
> proportion, is simply that the specification is, in this particular instance, 
> sufficiently vague as to make \Marked not yield any reliable information.

Not at all.

\Marked reliably states that "this mailbox definitely needs to be 
inspected for something that the user may not know about."

\UnMarked reliably states that "nothing has happened in this mailbox that 
the user does not know about."

That's very different from "no reliable information."  Rather, it's 
reliably telling you something that you may not recognize as useful.

Read below to see why it is useful.

> I've never said marking is difficult for servers to do right. Merely that 
> it's impossible for clients to rely on the information it yields, whether or 
> not it's done right.

I can't agree.  Marking is quite reliable if it is used for the intended 
purpose.

> Moreover, I have not said "nobody uses recent", nor "nobody uses marking". I 
> *have* said that if I had a use for marking, I would be concerned with 
> depending on the behaviour of \Marked, because it is not fully defined.

I contend that it is defined, but maybe you didn't understand the 
definition.

A SELECT/EXAMINE, even a STATUS, may be slow; especially when you have 
many folders.  Marking is a first-order triage that saves an enormous 
amount of time.  We have users with many hundreds of mailboxes, and some 
of these non-INBOX mailboxes get direct delivery of new mail.  A client 
which does not use marking is unusable for these folks.

In this case, the \UnMarked flag is the more important one; the triage 
separates the \UnMarked mailboxes from all others.  Even before this, the 
client triaged the \NoSelect mailboxes.

Put another way; your client may be wonderful in all other ways, but if it 
doesn't use marking, it won't work well for us.  Either it forces the user 
to manually inspect every mailbox that may have new messages, or it does 
an exhaustive scan of all mailboxes.

Please consider this.  I would like to see more clients which are useful 
in our environment.  Sadly, most clients never get far beyond starting up 
before they fail.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Sat, 07 Jan 2006 14:39:47 +0000
Subject: Re: WG Last Call of LISTEXT draft 14
From: Dave Cridland <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: Arnaud Taddei <[email-masked]>, <[email-masked]>
Sender: [email-masked]

On Fri Jan  6 22:29:51 2006, Mark Crispin wrote:
> On Fri, 6 Jan 2006, Dave Cridland wrote:

> The caution to client authors is that, depending upon what you are 
> looking for, you can't make any assumptions about mailboxes that 
> lack marking status and therefore have to go to extra (and perhaps 
> very costly) work.
> 
> 
And my point is that even if \Marked *is* specified, client authors 
still can't make any assumptions.

>> Thus, if a server implemented \Marked and \UnMarked support by 
>> never sending \UnMarked, and sending \Marked every second Tuesday 
>> of months with an 'r' in them, it would still be compliant even 
>> then.
> 
> Yes, there are many bad things that an IMAP server can do without 
> being in strict violation of the specification.  That doesn't mean 
> that it's alright for IMAP servers to do them.  This isn't unique 
> to IMAP by the way.
> 
> IMHO, it is NEVER alright to spit in the face of a specification or 
> even its spirit.
> 
> 
Absolutely, and I'm sure you realise I'm not advocating that a server 
implementor should do this. I'm merely pointing out that from a 
client's perspective, it's impossible to tell if that's what the 
server is doing. Just as servers should be striving to fully 
implement IMAP and all extensions, clients have to be prepared to 
deal with the most contrary of servers.

>> In any case, many clients do not care about recent messages at 
>> all, only about unseen messages, or simply messages they've not 
>> downloaded, causing many server implementors to completely ignore 
>> \Marked and \UnMarked.
> 
> So, there are broken clients out there.
> 
> 
No. These clients are not broken, they're simply not interested in 
that information - that's a different thing.

My client, for instance, does not care *if* a mailbox contains recent 
messages, nor even how many there are once the mailbox is selected. 
It does mark recent messages visually, and it does care about where 
the first recent message is. That is not broken, although you're free 
to consider it misguided.

The vast majority of clients ignore all non-system keywords that they 
didn't define. I'd think we both agree this is misguided, but it is 
not broken.

Pine, on the other hand, uses IMAP mailboxes to store addressbook and 
configuration information, instead of using a protocol purpose-built 
for that task. I don't consider that broken, however misguided I 
personally believe it to be.

> I hope that you're not saying that, because there are broken 
> clients, no client or server should ever attempt to do the right 
> thing?
> 
> 
No, but I am saying that when clients do not use information that is 
optional to provide, there is little benefit to server implementors 
to go to any effort to transmit it, and at least in my experience, 
the majority of server implementors are satisfied with a minimalist 
conformancy.

> Or worse, that it's alright for servers to be broken because most 
> clients do not care?  That's basically what the author of Courier 
> claims...
> 
> 
I'm not claiming that. I am, however, claiming that servers might 
well elide parts of the specification that are optional if there is 
little or no demand for them, and whether or not that's a good thing 
isn't the issue under discussion here.

Eliding parts of the specification that are not optional (not sending 
UIDNEXT during SELECT is quite popular, for instance) is not alright 
under any circumstances.

> If you're not claiming that, then you should accept on principle my 
> contentions that:
>  . servers should fully support the specification

That goes without saying. Servers must fully support the 
specification, and should conform to as many optional parts as 
possible, whether those optional parts are in the base specification 
or extensions.

>  . clients should be able to use the full specification

I would argue "clients should be able to take full advantage of any 
applicable parts of the specification and any applicable extensions 
to achieve their goals in the most efficient manner possible", which 
is more or less the same thing, but not quite: the distinction is 
that a client which does not gain benefit from a particular feature 
obviously need not implement it. Many clients don't use the 
information which the \Recent flag provides, for instance, simply 
because they have no use for this information in their model. This 
does not mean that servers needn't implement it correctly, obviously. 
Similarly, I don't use the conditional STORE, or modseq SEARCH, in 
CONDSTORE, so obviously I've not implemented those.

>  . it is WRONG to give advice of the form "nobody uses it"
> 
> 
Given the fact that I've been the recipient of this advice over ACAP 
for the past few years, you really ought to know by now that I ignore 
all such advice, and tend to consider the inverse argument of "if 
people used this" with much more weight. Besides which, almost 
invariably this kind of advice is wrong.

My issue with \Marked, which appears to have been blown out of all 
proportion, is simply that the specification is, in this particular 
instance, sufficiently vague as to make \Marked not yield any 
reliable information.

> Put another way, if marking is too difficult to do right, so are 
> CONDSTORE and LISTEXT.  If keywords are too difficult to do right, 
> so is ANNOTATE.
> 
> 
I've never said marking is difficult for servers to do right. Merely 
that it's impossible for clients to rely on the information it 
yields, whether or not it's done right.

> I object to hearing base specification functionality get badmouthed 
> in the same WG that's talking about much more complex 
> functionality.  When I hear "nobody uses recent", "nobody uses 
> marking", etc. this tells me that we should not add ANY new 
> extensions to IMAP until such time as those statements cease to be 
> made.

You make it sound like I'm slandering the entire base specification, 
which I'm not. Having features in the base specification which are 
not used by many clients isn't a problem to me at all - they still 
need to be done right by servers, or, if optional, possibly not at 
all.

Moreover, I have not said "nobody uses recent", nor "nobody uses 
marking". I *have* said that if I had a use for marking, I would be 
concerned with depending on the behaviour of \Marked, because it is 
not fully defined. As for recent, I use this to a degree myself, and 
very useful it is, too, but I completely understand the decision of 
many client implementors to ignore the information it provides.

I merely stated - accurately, I believe - that the description of 
\Marked is sufficiently vague in RFC3501 as to be unreliable. I'm 
sorry if you take this personally, it's not intended as an assignment 
of blame, merely a statement of fact.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Sat, 07 Jan 2006 11:08:19 +0100
From: Arnaud Taddei <[email-masked]>
Subject: Re: Need a template to start a draft
To: Lisa Dusseault <[email-masked]>
Cc: Mark Crispin <[email-masked]>, IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

Thanks Mark, Arnt and Lisa, I am proceeding

A++

Lisa Dusseault wrote:

> I use the XML stuff described at http://xml.resource.org, myself.  If 
> you browse http://ietf.webdav.org for XML files, you can see a number 
> of examples.
>
> Lisa
>
> On Jan 6, 2006, at 9:30 AM, Mark Crispin wrote:
>
>>
>> On Fri, 6 Jan 2006, Arnaud Taddei wrote:
>>
>>> Where can I find a template to start a draft? What are you guys using?
>>
>>
>> Start with http://www.ietf.org/ID-Checklist.html
>>
>> -- Mark --
>>
>> http://panda.com/mrc
>> Democracy is two wolves and a sheep deciding what to eat for lunch.
>> Liberty is a well-armed sheep contesting the vote.
>>
>

Date: Fri, 6 Jan 2006 14:40:55 -0800
From: Mark Crispin <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: Dave Cridland <[email-masked]>, Arnaud Taddei <[email-masked]>, [email-masked]
Subject: Re: WG Last Call of LISTEXT draft 14
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Fri, 6 Jan 2006, Timo Sirainen wrote:
> Luckily there are only very few clients that care about the \Marked
> state. I wouldn't be surprised if Pine was the only one :)

As Pawel said, you're mistaken...

> There are many other problems with maildir. The worst is that it's
> trying to be lockless without current filesystems properly supporting it
> that way, which is causing mails to be temporarily lost with heavy
> concurrent mailbox access.

Golly gee, this is what I said years ago, and I got called all sorts of 
names by members of the Maildir church (not you) over it.

> I mean here if the MUA doesn't add "Status: O" header to mails. I don't
> know how many MUAs don't do that, but at least if you quit mutt with
> ctrl-c instead of "q", the mbox isn't updated.

Basically, what you are saying is that the other MUA correctly clears 
\Marked status on the mailbox but fails to clear \Recent status on the 
messages.  This isn't a bug in UW imapd; it's a bug in the other MUA.

The other MUA's session was "the first session to have been notified about 
this mailbox"; being read-write (since it cleared \Marked status) it was 
required to clear the \Recent status as well.  If it was a read-only 
session, it would not be permitted to make "changes to the permanent state 
of the mailbox."

So what you have in this case is a damaged mailbox.  I'm surprised to hear 
that mutt causes such damage; traditional tools did the right thing.  But 
you can't blame UW imapd for that.

-- Mark --

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

Date: Fri, 6 Jan 2006 14:29:51 -0800
From: Mark Crispin <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: Arnaud Taddei <[email-masked]>, [email-masked]
Subject: Re: WG Last Call of LISTEXT draft 14
Organization: Networks & Distributed Computing
Sender: [email-masked]

On Fri, 6 Jan 2006, Dave Cridland wrote:
>    \Marked
>        The mailbox has been marked "interesting" by the server; the
>        mailbox probably contains messages that have been added since
>        the last time the mailbox was selected.
> Doncha just love that "probably"?

This simply means that \Marked status can also mean something else, such 
as a flag change or UIDVALIDITY change.  That probably was not a good 
idea, but at the time it was thought to be.

In the most primitive form, marking exports the result of a comparison of 
file dates from stat().  In the real world, this is actually useful.

>> If a mailbox has recent messages, and the mailbox does not have \Marked 
>> status, then it's a bug in the server.
> Nope, it's absolutely not a bug in the server, that behaviour is specified 
> here:
>     If it is not feasible for the server to determine whether or not
>     the mailbox is "interesting", or if the name is a \Noselect name,
>     the server SHOULD NOT send either \Marked or \Unmarked.

You've misunderstood the purpose of that text.

That text stipulates behavior for deficient mail stores (much like 
UIDNOTSTICKY in UIDPLUS).  That's different from blessing such behavior.

> The converse is not true either - if a mailbox *is* \Marked, it may not 
> contain messages flagged \Recent, and still be delightfully compliant with 
> RFC3501, thanks to that "probably".

Nobody ever made that claim.

The caution to client authors is that, depending upon what you are looking 
for, you can't make any assumptions about mailboxes that lack marking 
status and therefore have to go to extra (and perhaps very costly) work.

> Thus, if a server implemented \Marked and \UnMarked support by never sending 
> \UnMarked, and sending \Marked every second Tuesday of months with an 'r' in 
> them, it would still be compliant even then.

Yes, there are many bad things that an IMAP server can do without being in 
strict violation of the specification.  That doesn't mean that it's 
alright for IMAP servers to do them.  This isn't unique to IMAP by the 
way.

IMHO, it is NEVER alright to spit in the face of a specification or even 
its spirit.

> In any case, many clients do not care about recent messages at all, only 
> about unseen messages, or simply messages they've not downloaded, causing 
> many server implementors to completely ignore \Marked and \UnMarked.

So, there are broken clients out there.

I hope that you're not saying that, because there are broken clients, no 
client or server should ever attempt to do the right thing?

Or worse, that it's alright for servers to be broken because most clients 
do not care?  That's basically what the author of Courier claims...

If you're not claiming that, then you should accept on principle my 
contentions that:
  . servers should fully support the specification
  . clients should be able to use the full specification
  . it is WRONG to give advice of the form "nobody uses it"

>> I am, by the way, as a matter of principle opposed to protocol extensions 
>> that attempt to amend broken servers.  A server that can't do the base 
>> protocol right is not going to do the extensions right either.
> Apropos what, Mark? I've not suggested any such thing, as far as I can 
> recall. If you mean Arnaud's suggestion to simplify IMAP by importing LDAP's 
> searching model (and if that doesn't give you a wry grin, nothing will), then 
> I don't think that's what he's suggesting either.

Arnaud has his own agenda, but I've talked with him quite a bit offline 
over the years.  I don't always agree with him.  However, I share his 
dismay over some of the directions taken in this WG.

My silence on certain matters should not be taken as agreement.  It is not 
necessary to do anything to kill something that is so byzantine that it 
will die on its own.

Put another way, if marking is too difficult to do right, so are CONDSTORE 
and LISTEXT.  If keywords are too difficult to do right, so is ANNOTATE.

I object to hearing base specification functionality get badmouthed in the 
same WG that's talking about much more complex functionality.  When I hear 
"nobody uses recent", "nobody uses marking", etc. this tells me that we 
should not add ANY new extensions to IMAP until such time as those 
statements cease to be made.

-- Mark --

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

Date: Fri, 06 Jan 2006 23:06:11 +0100
From: Pawel Salek <[email-masked]>
Subject: Re: WG Last Call of LISTEXT draft 14
To: [email-masked]
Sender: [email-masked]

On 01/06/2006 08:56:46 PM, Timo Sirainen wrote:
> On Fri, 2006-01-06 at 10:58 -0800, Mark Crispin wrote:
> > > Calculating \Marked and \UnMarked is too expensive to do with
> maildir,
> > > so I'm not returning either with it.
> >
> > That's better than reporting false marked status.  But what this
> > effectively means is that a client that is looking for mailboxes
> with
> > recent messages will have to probe every mailbox (effectively
> treating no
> > marked status as equivalent to \Marked).  This is not behavior that
> you
> > really want the clients to be doing.
> 
> Luckily there are only very few clients that care about the \Marked
> state. I wouldn't be surprised if Pine was the only one :)

It definetely isn't.

Pawel

Date: Fri, 06 Jan 2006 21:12:36 +0000
Subject: Re: WG Last Call of LISTEXT draft 14
From: Dave Cridland <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: Arnaud Taddei <[email-masked]>, <[email-masked]>
Sender: [email-masked]

On Fri Jan  6 17:27:34 2006, Mark Crispin wrote:
> On Fri, 6 Jan 2006, Dave Cridland wrote:
>> It's defined, or rather isn't, in RFC3501. Its meaning is that the 
>> mailbox has been marked in some way by the server because it is, 
>> in some way, interesting. In practise, this can mean that there 
>> are recent messages, but its absence doesn't mean there are no 
>> recent messages, making it fairly useless.
> 
> Say what???
> 
> 
RFC3501, Section 7.2.2:

     \Marked
         The mailbox has been marked "interesting" by the server; the
         mailbox probably contains messages that have been added since
         the last time the mailbox was selected.

Doncha just love that "probably"?

> If a mailbox has recent messages, and the mailbox does not have 
> \Marked status, then it's a bug in the server.
> 
> 
Nope, it's absolutely not a bug in the server, that behaviour is 
specified here:

      If it is not feasible for the server to determine whether or not
      the mailbox is "interesting", or if the name is a \Noselect 
name,
      the server SHOULD NOT send either \Marked or \Unmarked.

The converse is not true either - if a mailbox *is* \Marked, it may 
not contain messages flagged \Recent, and still be delightfully 
compliant with RFC3501, thanks to that "probably".

Thus, if a server implemented \Marked and \UnMarked support by never 
sending \UnMarked, and sending \Marked every second Tuesday of months 
with an 'r' in them, it would still be compliant even then.

In any case, many clients do not care about recent messages at all, 
only about unseen messages, or simply messages they've not 
downloaded, causing many server implementors to completely ignore 
\Marked and \UnMarked.

> I am, by the way, as a matter of principle opposed to protocol 
> extensions that attempt to amend broken servers.  A server that 
> can't do the base protocol right is not going to do the extensions 
> right either.
> 
> 
Apropos what, Mark? I've not suggested any such thing, as far as I 
can recall. If you mean Arnaud's suggestion to simplify IMAP by 
importing LDAP's searching model (and if that doesn't give you a wry 
grin, nothing will), then I don't think that's what he's suggesting 
either.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Subject: Re: WG Last Call of LISTEXT draft 14
From: Timo Sirainen <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: Dave Cridland <[email-masked]>, Arnaud Taddei <[email-masked]>, [email-masked]
Date: Fri, 06 Jan 2006 21:56:46 +0200
Sender: [email-masked]

--=-4Quss4MY9xuxws9Q4s5C
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Fri, 2006-01-06 at 10:58 -0800, Mark Crispin wrote:
> > Calculating \Marked and \UnMarked is too expensive to do with maildir,
> > so I'm not returning either with it.
>=20
> That's better than reporting false marked status.  But what this=20
> effectively means is that a client that is looking for mailboxes with=20
> recent messages will have to probe every mailbox (effectively treating no=
=20
> marked status as equivalent to \Marked).  This is not behavior that you=20
> really want the clients to be doing.

Luckily there are only very few clients that care about the \Marked
state. I wouldn't be surprised if Pine was the only one :)

> By the way, thank you for acknowledging that Maildir has problems too.=20
> Some of the more fanatic members of the Maildir church haven't grasped=20
> that yet.

There are many other problems with maildir. The worst is that it's
trying to be lockless without current filesystems properly supporting it
that way, which is causing mails to be temporarily lost with heavy
concurrent mailbox access.

> > Also the way UW-IMAP handles this with mboxes breaks immediately once
> > non-c-client based MUA opens the mailbox. Does this mean UW-IMAP is als=
o
> > buggy since the exact behavior you described can happen with it?
>=20
> I read this as a claim by you that UW imapd reports a traditional UNIX=20
> format mailbox as \Marked after it has been opened by a non-c-client base=
d=20
> MUA.
>=20
> This is a rather serious charge.  I would like to see the evidence.

I mean here if the MUA doesn't add "Status: O" header to mails. I don't
know how many MUAs don't do that, but at least if you quit mutt with
ctrl-c instead of "q", the mbox isn't updated. In that case MUA acts the
same way as "touch -a", and this happens (imap-2004g):

x copy 1 test
x OK COPY completed
x list "" test
* LIST (\NoInferiors \Marked) "/" test

"touch -a test", or open with some MUA that doesn't modify mbox.

x list "" test
* LIST (\NoInferiors \UnMarked) "/" test
x OK LIST completed
x status test (recent)
* STATUS test (RECENT 1)
x OK STATUS completed

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

--=-4Quss4MY9xuxws9Q4s5C--

Date: Fri, 6 Jan 2006 10:58:09 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Timo Sirainen <[email-masked]>
cc: Dave Cridland <[email-masked]>, Arnaud Taddei <[email-masked]>, [email-masked]
Subject: Re: WG Last Call of LISTEXT draft 14
Sender: [email-masked]

On Fri, 6 Jan 2006, Timo Sirainen wrote:
>> If a mailbox has recent messages, and the mailbox does not have \Marked
>> status, then it's a bug in the server.
> Isn't this rather ".., and the mailbox has \UnMarked status, .."?

No and yes.

If a not-selected mailbox has recent messages, then it SHOULD have \Marked 
status and MUST NOT have \Unmarked status.

In general, lack of marking status in LIST results indicates a deficient 
implementation; and this should be avoided.

There *are* exceptions.  For example, marking status is inappropriate with 
\NoSelect names.  In general, though, servers should return marking 
status.  Truthful \UnMarked status is especially important.

> Calculating \Marked and \UnMarked is too expensive to do with maildir,
> so I'm not returning either with it.

That's better than reporting false marked status.  But what this 
effectively means is that a client that is looking for mailboxes with 
recent messages will have to probe every mailbox (effectively treating no 
marked status as equivalent to \Marked).  This is not behavior that you 
really want the clients to be doing.

By the way, thank you for acknowledging that Maildir has problems too. 
Some of the more fanatic members of the Maildir church haven't grasped 
that yet.

> Also the way UW-IMAP handles this with mboxes breaks immediately once
> non-c-client based MUA opens the mailbox. Does this mean UW-IMAP is also
> buggy since the exact behavior you described can happen with it?

I read this as a claim by you that UW imapd reports a traditional UNIX 
format mailbox as \Marked after it has been opened by a non-c-client based 
MUA.

This is a rather serious charge.  I would like to see the evidence.

If there is a bug, I will fix it.  The traditional UNIX driver goes to 
considerable effort to interact properly with legacy software.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Cc: Arnaud Taddei <[email-masked]>, IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Re: Need a template to start a draft
Date: Fri, 6 Jan 2006 10:24:56 -0800
To: Mark Crispin <[email-masked]>
Sender: [email-masked]

I use the XML stuff described at http://xml.resource.org, myself.  If 
you browse http://ietf.webdav.org for XML files, you can see a number 
of examples.

Lisa

On Jan 6, 2006, at 9:30 AM, Mark Crispin wrote:

>
> On Fri, 6 Jan 2006, Arnaud Taddei wrote:
>> Where can I find a template to start a draft? What are you guys using?
>
> Start with http://www.ietf.org/ID-Checklist.html
>
> -- Mark --
>
> http://panda.com/mrc
> Democracy is two wolves and a sheep deciding what to eat for lunch.
> Liberty is a well-armed sheep contesting the vote.
>

Subject: Re: WG Last Call of LISTEXT draft 14
From: Timo Sirainen <[email-masked]>
To: Mark Crispin <[email-masked]>
Cc: Dave Cridland <[email-masked]>, Arnaud Taddei <[email-masked]>, [email-masked]
Date: Fri, 06 Jan 2006 20:19:44 +0200
Sender: [email-masked]

--=-7j3T5NuLEOyW1N002O8T
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Fri, 2006-01-06 at 09:27 -0800, Mark Crispin wrote:
> > It's defined, or rather isn't, in RFC3501. Its meaning is that the mail=
box=20
> > has been marked in some way by the server because it is, in some way,=20
> > interesting. In practise, this can mean that there are recent messages,=
 but=20
> > its absence doesn't mean there are no recent messages, making it fairly=
=20
> > useless.
>=20
> Say what???
>=20
> If a mailbox has recent messages, and the mailbox does not have \Marked=20
> status, then it's a bug in the server.

Isn't this rather ".., and the mailbox has \UnMarked status, .."?

Calculating \Marked and \UnMarked is too expensive to do with maildir,
so I'm not returning either with it.

Also the way UW-IMAP handles this with mboxes breaks immediately once
non-c-client based MUA opens the mailbox. Does this mean UW-IMAP is also
buggy since the exact behavior you described can happen with it?

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

--=-7j3T5NuLEOyW1N002O8T--

Date: Fri, 6 Jan 2006 09:30:18 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Arnaud Taddei <[email-masked]>
cc: IMAP Extensions WG <[email-masked]>
Subject: Re: Need a template to start a draft
Sender: [email-masked]

On Fri, 6 Jan 2006, Arnaud Taddei wrote:
> Where can I find a template to start a draft? What are you guys using?

Start with http://www.ietf.org/ID-Checklist.html

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Fri, 6 Jan 2006 09:27:34 -0800 (PST)
From: Mark Crispin <[email-masked]>
To: Dave Cridland <[email-masked]>
cc: Arnaud Taddei <[email-masked]>, [email-masked]
Subject: Re: WG Last Call of LISTEXT draft 14
Sender: [email-masked]

On Fri, 6 Jan 2006, Dave Cridland wrote:
> I implement Mailbox Referrals in my client, and Cyrus IMAP implements it in 
> the server. I think Mulberry implements it client-side too.

Pine implements it client-side, and UW imapd implements it server side.

> It's defined, or rather isn't, in RFC3501. Its meaning is that the mailbox 
> has been marked in some way by the server because it is, in some way, 
> interesting. In practise, this can mean that there are recent messages, but 
> its absence doesn't mean there are no recent messages, making it fairly 
> useless.

Say what???

If a mailbox has recent messages, and the mailbox does not have \Marked 
status, then it's a bug in the server.

I am, by the way, as a matter of principle opposed to protocol extensions 
that attempt to amend broken servers.  A server that can't do the base 
protocol right is not going to do the extensions right either.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

Date: Fri, 06 Jan 2006 16:39:18 +0100
From: Arnaud Taddei <[email-masked]>
Subject: Re: Support for IMAP LOGIN referrals (RFC2221)
To: Edward Hibbert <[email-masked]>
Cc: Mark Crispin <[email-masked]>, [email-masked]
Sender: [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_m22D77q3V1AmHUIMXnNLVQ)
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT

Edward Hibbert wrote:

> From my point of view, the most interesting IMAP clients are those 
> which are most widely deployed :-).
>
> The following link from Microsoft contains a claim that most IMAP 
> clients don't support referrals:
>
> http://tinyurl.com/9yyf3
>
> Which I think I'll take as indicating that Microsoft clients don't. 
>
> Shame, I was hoping to use referrals.  But if Microsoft clients don't 
> support it, that's not an option.
>
Some IMAP servers do support distributed shared/public folders without 
the need for the login/mailbox referrals.

A direction I would hope would be considered more widely to help keeping 
the protocol simple.

A++

>
> Regards,
>
> Edward.
>
> -----Original Message-----
> From: [email-masked] on behalf of Mark Crispin
> Sent: Fri 16/12/2005 16:46
> To: Edward Hibbert
> Cc: [email-masked]
> Subject: RE: Support for IMAP LOGIN referrals (RFC2221)
>
> On Fri, 16 Dec 2005, Edward Hibbert wrote:
> > What about common clients like Thunderbird, Outlook, Outlook Express?
>
> For understandable reasons, Microsoft never uses open source software
> (other than open source software that it developed) as a matter of policy.
> Outlook and OE *may* support login referrals, though, as Microsoft was one
> of the instigators for referrals.
>
> I don't know what Thunderbird uses, but I doubt that it uses c-client.
>
> I don't consider any of these three to be particularly interesting as IMAP
> clients.  There are much better IMAP clients out there, and most of those
> are open source.
>
> -- Mark --
>
> http://panda.com/mrc
> Democracy is two wolves and a sheep deciding what to eat for lunch.
> Liberty is a well-armed sheep contesting the vote.
>

--Boundary_(ID_m22D77q3V1AmHUIMXnNLVQ)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Edward Hibbert wrote:
<blockquote
 cite="[email-masked]"
 type="cite">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta name="Generator" content="MS Exchange Server version 6.5.7638.1">
  <title>RE: Support for IMAP LOGIN referrals (RFC2221)</title>
<!-- Converted from text/plain format -->
  <p><font size="2">From my point of view, the most interesting IMAP
clients are those which are most widely deployed :-).<br>
  <br>
The following link from Microsoft contains a claim that most IMAP
clients don't support referrals:<br>
  <br>
  <a href="http://tinyurl.com/9yyf3">http://tinyurl.com/9yyf3</a><br>
  <br>
Which I think I'll take as indicating that Microsoft clients don't.&nbsp;<br>
  <br>
Shame, I was hoping to use referrals.&nbsp; But if Microsoft clients don't
support it, that's not an option.<br>
  </font></p>
</blockquote>
Some IMAP servers do support distributed shared/public folders without
the need for the login/mailbox referrals. <br>
<br>
A direction I would hope would be considered more widely to help
keeping the protocol simple.<br>
<br>
A++<br>
<blockquote
 cite="[email-masked]"
 type="cite">
  <p><font size="2"><br>
Regards,<br>
  <br>
Edward.<br>
  <br>
-----Original Message-----<br>
From: <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a> on behalf of Mark Crispin<br>
Sent: Fri 16/12/2005 16:46<br>
To: Edward Hibbert<br>
Cc: <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a><br>
Subject: RE: Support for IMAP LOGIN referrals (RFC2221)<br>
  <br>
On Fri, 16 Dec 2005, Edward Hibbert wrote:<br>
&gt; What about common clients like Thunderbird, Outlook, Outlook
Express?<br>
  <br>
For understandable reasons, Microsoft never uses open source software<br>
(other than open source software that it developed) as a matter of
policy.<br>
Outlook and OE *may* support login referrals, though, as Microsoft was
one<br>
of the instigators for referrals.<br>
  <br>
I don't know what Thunderbird uses, but I doubt that it uses c-client.<br>
  <br>
I don't consider any of these three to be particularly interesting as
IMAP<br>
clients.&nbsp; There are much better IMAP clients out there, and most of
those<br>
are open source.<br>
  <br>
-- Mark --<br>
  <br>
  <a href="http://panda.com/mrc">http://panda.com/mrc</a><br>
Democracy is two wolves and a sheep deciding what to eat for lunch.<br>
Liberty is a well-armed sheep contesting the vote.<br>
  <br>
  </font>
  </p>
</blockquote>
<br>
</body>
</html>

--Boundary_(ID_m22D77q3V1AmHUIMXnNLVQ)--

Date: Fri, 06 Jan 2006 14:26:50 +0000
Subject: Re: I-D ACTION:draft-ietf-imapext-condstore-08.txt
From: Dave Cridland <[email-masked]>
To: Alexandros Vellis <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Fri Jan  6 14:19:27 2006, Alexandros Vellis wrote:
> 
> Ken Murchison wrote:
> 
> > > 	Filename	: draft-ietf-imapext-condstore-08.txt
> > What changed?
> 
> I like the ISOC site for diffs:
> 
> http://ietfreport.isoc.org/idref/draft-ietf-imapext-condstore/
> 
> Click on 'diff' next to draft-ietf-imapext-condstore-07.txt.

Or there's the tool site, which I think is nicer.

http://tools.ietf.org/wg/imapext/draft-ietf-imapext-condstore/draft-ietf-imapext-condstore-08-from-07.diff.html

This shows me that SORT has been dropped, presumably to get to RFC 
status faster.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Subject: Re: I-D ACTION:draft-ietf-imapext-condstore-08.txt
From: Alexandros Vellis <[email-masked]>
To: [email-masked]
Organization: National & Kapodistrian University of Athens
Date: Fri, 06 Jan 2006 16:19:27 +0200
Sender: [email-masked]

Ken Murchison wrote:

> > 	Filename	: draft-ietf-imapext-condstore-08.txt
> What changed?

I like the ISOC site for diffs:

http://ietfreport.isoc.org/idref/draft-ietf-imapext-condstore/

Click on 'diff' next to draft-ietf-imapext-condstore-07.txt.

Cheers,
Alexandros

Date: Fri, 06 Jan 2006 15:05:36 +0100
From: Arnaud Taddei <[email-masked]>
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
To: Barry Leiba <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

>We put in multiple mailbox patterns because we wanted the flexibility,
>and we wanted consistent syntax with other commands, such as an
>extended SEARCH, which could certainly want to use that (and consider
>that someone had suggested using extended LIST itself as an extended
>SEARCH).  If consensus is that it's unnecessary and too complicated, we
>can pull out the multiple patterns for LIST, at the expense of not
>having the consistent syntax.
>  
>
The multiple mailbox patterns is extremely important for when you need 
to keep 2 IMAP servers synchronizing a selection of their 
(shared/public) folders so I vote for keeping this by all means.

A++

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

Date: Fri, 06 Jan 2006 14:03:06 +0000
Subject: Re: WG Last Call of LISTEXT draft 14
From: Dave Cridland <[email-masked]>
To: Arnaud Taddei <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Fri Jan  6 10:20:55 2006, Arnaud Taddei wrote:
> In addition to this different approach I see the following issues 
> in the document:
> 
>    * I disagree in the abstract on the Mailbox Referrals mention. No
>      one implements it even not Microsoft correct? I think there are
>      much more important issues to be covered in the abstract

I implement Mailbox Referrals in my client, and Cyrus IMAP implements 
it in the server. I think Mulberry implements it client-side too. 
In any case, the mention here is illustrating that its addition 
forces additional duplicate commands such as RLIST, RLSUB, etc, and I 
think that's justified.

>    * I have a problem (which is surely my Frenglish) to understand 
> 'or
>      any combination of therof', I don't scan the word therof.

That's page 6 section 3 paragraph two. Should be "any combination 
thereof".

>    * Page 9 on the paragraph for REMOTE, the 3 last lines are really
>      some byzantinism that is really a pain to explain 
> operationally.
>      Could we favor eliminating exceptions and enhancing protocol
>      readability?

It was tricky to explain at all. The nature of what's wrong with 
REMOTE RECURSIVEMATCH isn't echoed fully in the subsection on 
RECURSIVEMATCH, incidentally.

>    * Page 14, paragraph \HasChildren, I think I disagree with the
>      security perspective

Rereading this section, I note that "the server MUST return these 
attributes", but "a server MAY exclude both the [...] attributes".

>    * Page 16, I am not familiar with the \Marked in example 2. What
>      does this attribute mean? Where is it defined?

It's defined, or rather isn't, in RFC3501. Its meaning is that the 
mailbox has been marked in some way by the server because it is, in 
some way, interesting. In practise, this can mean that there are 
recent messages, but its absence doesn't mean there are no recent 
messages, making it fairly useless.

>    * Page 17, I think Example 6 requires much more explanations

I think I see why. Could you suggest some alternate text for 
explaining both example 5 and example 6? (I should think both would 
need to be changed to express the difference more clearly).

>    * Page 26, I am not comfortable with the comment on ACAP at the
>      beginning of section 6

If you'd like to implement both client and server fully, then we can 
move it to draft. :-)

>    * Page 30, at the end I dsiagree with the Security statement here

No, this is a security concern, and should be addressed by 
implementors.

>    * Page 34, the registration number 3 is almost a duplicate of
>      registration number 1, you want to remove one or the other.
> 
> 
No, one is selection, one is return. They're different things, but 
have the same name.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Fri, 06 Jan 2006 12:55:49 +0100
From: Arnaud Taddei <[email-masked]>
Subject: Need a template to start a draft
To: IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

Where can I find a template to start a draft? What are you guys using?

I need to put the mapping of ACLs between MS Exchange proprietary 
authorization model and IMAP ACLs. This is important for coexistence 
situations and others. This document will allow as well to review the 
semantics we have and we don't have.

All the content was developed I just need to 'translate' it into the 
appropriate IETF format.

A++

Date: Fri, 06 Jan 2006 12:52:33 +0100
From: Arnaud Taddei <[email-masked]>
Subject: Re: WG Last Call of LISTEXT draft 14
To: Arnaud Taddei <[email-masked]>
Cc: Lisa Dusseault <[email-masked]>, Chris Newman <[email-masked]>, Philip Guenther <[email-masked]>, Dave Cridland <[email-masked]>, IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_iGAP5wAIo/IFwTBbRYYfNg)
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT

Arnaud Taddei wrote:

> I reviewed ACL, LISTEXT, ANNOTATEMORE and CONDSTORE. While I got 
> delayed several times in the past 4 weeks I accumulated hand written 
> remarks that I am going to share in several mail messages.
>
> Before I zoom on LISTEXT, I am generally having a very strange feeling 
> about these 4 extensions and I reallize that unfortunately I am coming 
> too late in the discussions.
>
> Sorry this mail will be long
>
> I am not sure how many of you are dealing with operational, deployment 
> and architectural issues in real customer sites but be aware that the 
> IETF stack of protocol, while it allows interoperability of solutions, 
> somehow, it too created an operational monster to implement and debug 
> if it is not just to explain to people in the field. With the level of 
> troops that exists today in the field, this leads me to say that I am 
> not sure that this point of view was kept in mind when writing these 
> extensions.
>
> My general impression is that somehow too many compromises were made 
> and some times not enough. Anyway I will elaborate step by step.
>
> Now zooming on LISTEXT, well well well. The model I had in mind for 
> LISTEXT is that:  what are folder collections: they are just a 'name 
> space' to organize data. This 'name space' is a static name space 
> (versus a VIEW) created by:
>
>     * System model, limits and constraints (for example for some
>       systems INBOX is a name space that doesn't have children, for
>       example shared and public folder name spaces)
>     * End users (end users create their own name space of folders)
>     * System administrators could create specific folder collections
>
> What is that LISTEXT say is that it wants to treat the properties of 
> the folders in this name space (remote, subscribed, exists, has kids, 
> has no kids, etc.).
>
> What is that ANNOTATEMORE say is that folders (and even the server) 
> can have more properties than those ones, for example comment, motd, 
> content-language, etc.)
>
> What I have in mind is that a name-space can be represented exactly 
> like the DIT of an LDAP server.
>
>     * you have root folders
>     * they have or not a tree below them
>     * nodes (in our case folders) are represented by a distinguished
>       name that we call the MUTF-7 folder name
>     * nodes contain properties that are called attribute that have
>       meta properties (Single-valued, multi-valued, are present or
>       not, etc.)
>     * and attributes for our folders are remote, subscribed, exists,
>       has kids, has ACLs, is sharing flags or not, has customisable
>       permanent flags or not, and the NAME itself, etc. etc. etc.
>
>
> So what is LISTEXT if I  make an analogy with LDAP, LISTEXT is the 
> LDAPSEARCH.
>
> When we had to work on the co-existence of heterogeneous solutions we 
> had to deal with how to keep the synchronization of public and shared 
> folders between two systems. As a typical alien server for a site of 
> say 3000 users would already have 10'000 public folders, with as well 
> the idea that 15% of the total users folders are shared we faced a big 
> issue in migrations if we were not capable to keep communities of end 
> users seeing the same view of their data wether they were migrated or 
> not so we were asked to build a program to synchronize any folder 
> specified by customers.
>
> When performing this task it became obvious that we would need a model 
> to 'select' the folders for examples as sub branches in the tree of 
> folders. This lead us to design what we called the Folder Global 
> Specification (FGS) and to define a listing model like an LDAP search 
> which is composed of the following sequence of items in the search
>
> Search folders:
>
>     * which NAMESPACE:
>           o in which name space (i.e. in which NAMESPACE) should we
>             list the folders, in Private? In Shared? In Public? In
>             Usenet Newsgroups? Others? a Combination?
>     * which BASE:
>           o under which folder base (i.e. under which branch)
>           o For example should I want to search only those folders
>             below "Foo/Bar/Toto"
>           o The notion of search base exists already today obviously
>     * which SCOPE:
>           o Scope 0: should we stop at the node itself (just the branch),
>           o Scope 1: one level below the node
>           o Scope 2: all the branch below the specified folder base
>             which is equivalent to Recursive
>     * which FILTER:
>           o which question in terms of a boolean combination of
>             pattern match on attributes.
>           o Usually the filter is the name but there could be others
>             attributes in the filter, this is what you put with
>             LISTEXT with the options in the LIST command, in fact
>             these are part of a filter but the syntax is not unified
>     * and what do you want to RETURN:
>           o a list of attributes you want to return
>
> With this in mind a LIST command would look like:
>
> a1 LIST NAMESPACE=private BASE=("INBOX" "Fruit" "Sent") SCOPE=2  
> FILTER=(&(\Remote=1)(\Subsribed=1)(\Exists=1) )

And if you want to retrieve only the names and the subsribed you add:

a1 LIST NAMESPACE=private BASE=("INBOX" "Fruit" "Sent") SCOPE=2  
FILTER=(&(\Remote=1)(\Subsribed=1)(\Exists=1) ) ATTRS=(name subscribed)

A++

>
> And then we can unify and simplify the syntax in a model that too me 
> is proven and comes from an area where searching a 'name space' is the 
> basics.
>
> Not only that but it would allow to unify this command with 
> ANNOTATEMORE in a very simple manner because the filter would add 
> those attributes that GETANNOTATION is giving so we would have only 
> one command to:
>
>     * consider the folder space as a name space
>     * folders do have 'attributes'
>     * 'attributes' have meta properties such as single value, mutli
>       value, presence, etc.  and including attributes ACLs (which
>       eliminates the explicit .priv and .share model)
>     * we have a unified model to search folders
>
> I will come back on the CAPABILITY vs ANNOTATEMORE story later
>
> In addition to this different approach I see the following issues in 
> the document:
>
>     * I disagree in the abstract on the Mailbox Referrals mention. No
>       one implements it even not Microsoft correct? I think there are
>       much more important issues to be covered in the abstract
>     * I have a problem (which is surely my Frenglish) to understand
>       'or any combination of therof', I don't scan the word therof.
>     * Page 9 on the paragraph for REMOTE, the 3 last lines are really
>       some byzantinism that is really a pain to explain operationally.
>       Could we favor eliminating exceptions and enhancing protocol
>       readability?
>     * Page 14, paragraph \HasChildren, I think I disagree with the
>       security perspective
>     * Page 16, I am not familiar with the \Marked in example 2. What
>       does this attribute mean? Where is it defined?
>     * Page 17, I think Example 6 requires much more explanations
>     * Page 19, Example 8: typo: it should be demonstrate and not
>       demonstate, there is a missing r
>     * Page 26, I am not comfortable with the comment on ACAP at the
>       beginning of section 6
>     * Page 30, at the end I dsiagree with the Security statement here
>     * Page 32, first paragrapha very small typo: there is a space
>       between options/ extended, it should be options/extended to be
>       consistent with the others after
>     * Page 34, the registration number 3 is almost a duplicate of
>       registration number 1, you want to remove one or the other.
>
> Hope this helps anyway
>
> A++
>
> Lisa Dusseault wrote:
>
>>
>> We still haven't gotten enough review of LISTEXT during last call to  
>> finish it off.  Chris, Philip, Dave, you still need to review at 
>> least  the changes from the last time you reviewed or we'll need to 
>> find  another couple reviewers.  Arnt was the only one who posted his 
>> review  to the Last Call.
>>
>> Here's the -15 draft:  
>> <http://www.ietf.org/internet-drafts/draft-ietf-imapext-list- 
>> extensions-15.txt>
>>
>> And to make it really easy, here's the diff from -14
>> <http://tools.ietf.org/wg/imapext/draft-ietf-imapext-list-extensions/ 
>> draft-ietf-imapext-list-extensions-15-from-14.diff.html>
>>
>> Lisa
>>
>> On Nov 27, 2005, at 7:56 AM, Lisa Dusseault wrote:
>>
>>> "I love deadlines. I like the whooshing sound they make as they fly  
>>> by."
>>>     Douglas Adams
>>>
>>> Nobody commented during this last call period.  There were good  
>>> reviews when this was previously last-called, but I'd like to know  
>>> that the changes were reviewed. Chris Newman, Philip Guenther and 
>>> Dave  Cridland volunteered to look it over, so you guys need to get 
>>> back to  me.  Anybody else who reviewed the changes in LISTEXT since 
>>> draft -13,  let me know.
>>>
>>> Lisa
>>>
>>> On Oct 27, 2005, at 4:25 PM, Lisa Dusseault wrote:
>>>
>>>>
>>>> I call your attention to this draft:
>>>>
>>>> http://www.ietf.org/internet-drafts/draft-ietf-imapext-list- 
>>>> extensions-14.txt
>>>>
>>>> We previously did a WG last call in May 2005 but we decided for a  
>>>> "do-over" since there were a few significant changes.
>>>>
>>>> This document is the framework for much of the syntax we're doing 
>>>> in  other IMAPEXT tasks and is being referenced by other documents  
>>>> already, so it's important that it gets a good review.
>>>>
>>>> If you review it at all, or plan to implement, or have any opinion  
>>>> about standardizing this document, send mail to the WG list or at  
>>>> least to me.  Send me email even if you reviewed draft 13 and  
>>>> previously sent me email about that, to let me know if you have  
>>>> reviewed the changes in draft 14 and are OK with them.
>>>>
>>>> Because of the IETF meeting in a little over a week, let's do this  
>>>> last call until EOD Nov 17 (three weeks).  If you have any chance 
>>>> to  bring up issues before IMAPEXT meets on Tuesday Nov 8, that 
>>>> would be  much appreciated because it would give us an extra forum 
>>>> for  discussion.
>>>>
>>>> Thanks,
>>>>
>>>> Lisa
>>>>
>>>
>>
>

--Boundary_(ID_iGAP5wAIo/IFwTBbRYYfNg)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Arnaud Taddei wrote:
<blockquote cite="[email-masked]" type="cite">
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
I reviewed ACL, LISTEXT, ANNOTATEMORE and CONDSTORE. While I got
delayed several times in the past 4 weeks I accumulated hand written
remarks that I am going to share in several mail messages.<br>
  <br>
Before I zoom on LISTEXT, I am generally having a very strange feeling
about these 4 extensions and I reallize that unfortunately I am coming
too late in the discussions. <br>
  <br>
Sorry this mail will be long<br>
  <br>
I am not sure how many of you are dealing with operational, deployment
and architectural issues in real customer sites but be aware that the
IETF stack of protocol, while it allows interoperability of solutions,
somehow, it too created an operational monster to implement and debug
if it is not just to explain to people in the field. With the level of
troops that exists today in the field, this leads me to say that I am
not sure that this point of view was kept in mind when writing these
extensions. <br>
  <br>
My general impression is that somehow too many compromises were made
and some times not enough. Anyway I will elaborate step by step.<br>
  <br>
Now zooming on LISTEXT, well well well. The model I had in mind for
LISTEXT is that:&nbsp; what are folder collections: they are just a 'name
space' to organize data. This 'name space' is a static name space
(versus a VIEW) created by:<br>
  <ul>
    <li>System model, limits and constraints (for example for some
systems INBOX is a name space that doesn't have children, for example
shared and public folder name spaces)</li>
    <li>End users (end users create their own name space of folders)</li>
    <li>System administrators could create specific folder collections <br>
    </li>
  </ul>
What is that LISTEXT say is that it wants to treat the properties of
the folders in this name space (remote, subscribed, exists, has kids,
has no kids, etc.). <br>
  <br>
What is that ANNOTATEMORE say is that folders (and even the server) can
have more properties than those ones, for example comment, motd,
content-language, etc.)<br>
  <br>
What I have in mind is that a name-space can be represented exactly
like the DIT of an LDAP server. <br>
  <ul>
    <li>you have root folders</li>
    <li>they have or not a tree below them</li>
    <li>nodes (in our case folders) are represented by a distinguished
name that we call the MUTF-7 folder name</li>
    <li>nodes contain properties that are called attribute that have
meta
properties (Single-valued, multi-valued, are present or not, etc.) </li>
    <li>and attributes for our folders are remote, subscribed, exists,
has kids, has ACLs, is sharing flags or not, has customisable permanent
flags or not, and the NAME itself, etc. etc. etc.</li>
  </ul>
  <br>
So what is LISTEXT if I&nbsp; make an analogy with LDAP, LISTEXT is the
LDAPSEARCH.<br>
  <br>
When we had to work on the co-existence of heterogeneous solutions we
had to deal with how to keep the synchronization of public and shared
folders between two systems. As a typical alien server for a site of
say 3000 users would already have 10'000 public folders, with as well
the idea that 15% of the total users folders are shared we faced a big
issue in migrations if we were not capable to keep communities of end
users seeing the same view of their data wether they were migrated or
not so we were asked to build a program to synchronize any folder
specified by customers. <br>
  <br>
When performing this task it became obvious that we would need a model
to 'select' the folders for examples as sub branches in the tree of
folders. This lead us to design what we called the Folder Global
Specification (FGS) and to define a listing model like an LDAP search
which is composed of the following sequence of items in the search<br>
  <br>
Search folders:<br>
  <ul>
    <li>which NAMESPACE: <br>
    </li>
    <ul>
      <li>in which name space (i.e. in which NAMESPACE) should we list
the folders, in Private? In Shared? In Public? In Usenet Newsgroups?
Others? a Combination?<br>
      </li>
    </ul>
    <li>which BASE: <br>
    </li>
    <ul>
      <li>under which folder base (i.e. under which branch)</li>
      <li>For example should I want to search only those folders below
"Foo/Bar/Toto"</li>
      <li>The notion of search base exists already today obviously<br>
      </li>
    </ul>
    <li>which SCOPE: <br>
    </li>
    <ul>
      <li>Scope 0: should we stop at the node itself (just the branch),
        <br>
      </li>
      <li>Scope 1: one level below the node</li>
      <li>Scope 2: all the branch below the specified folder base which
is equivalent to Recursive<br>
      </li>
    </ul>
    <li>which FILTER: <br>
    </li>
    <ul>
      <li>which question in terms of a boolean combination of pattern
match on attributes. <br>
      </li>
      <li>Usually the filter is the name but there could be others
attributes in the filter, this is what you put with LISTEXT with the
options in the LIST command, in fact these are part of a filter but the
syntax is not unified<br>
      </li>
    </ul>
    <li>and what do you want to RETURN:</li>
    <ul>
      <li>a list of attributes you want to return</li>
    </ul>
  </ul>
With this in mind a LIST command would look like:<br>
  <br>
a1 LIST NAMESPACE=private BASE=("INBOX" "Fruit" "Sent") SCOPE=2&nbsp;
FILTER=(&amp;(\Remote=1)(\Subsribed=1)(\Exists=1) )<br>
</blockquote>
And if you want to retrieve only the names and the subsribed you add:<br>
<br>
a1 LIST NAMESPACE=private BASE=("INBOX" "Fruit" "Sent") SCOPE=2&nbsp;
FILTER=(&amp;(\Remote=1)(\Subsribed=1)(\Exists=1) ) ATTRS=(name
subscribed)<br>
<br>
A++<br>
<br>
<blockquote cite="[email-masked]" type="cite"><br>
And then we can unify and simplify the syntax in a model that too me is
proven and comes from an area where searching a 'name space' is the
basics. <br>
  <br>
Not only that but it would allow to unify this command with
ANNOTATEMORE in a very simple manner because the filter would add those
attributes that GETANNOTATION is giving so we would have only one
command to:<br>
  <ul>
    <li>consider the folder space as a name space</li>
    <li>folders do have 'attributes'</li>
    <li>'attributes' have meta properties such as single value, mutli
value, presence, etc.&nbsp; and including attributes ACLs (which eliminates
the explicit .priv and .share model)</li>
    <li>we have a unified model to search folders</li>
  </ul>
I will come back on the CAPABILITY vs ANNOTATEMORE story later<br>
  <br>
In addition to this different approach I see the following issues in
the document:<br>
  <ul>
    <li>I disagree in the abstract on the Mailbox Referrals mention. No
one implements it even not Microsoft correct? I think there are much
more important issues to be covered in the abstract</li>
    <li>I have a problem (which is surely my Frenglish) to understand
'or
any combination of therof', I don't scan the word therof.</li>
    <li>Page 9 on the paragraph for REMOTE, the 3 last lines are really
some byzantinism that is really a pain to explain operationally. Could
we favor eliminating exceptions and enhancing protocol readability?</li>
    <li>Page 14, paragraph \HasChildren, I think I disagree with the
security perspective</li>
    <li>Page 16, I am not familiar with the \Marked in example 2. What
does this attribute mean? Where is it defined?</li>
    <li>Page 17, I think Example 6 requires much more explanations</li>
    <li>Page 19, Example 8: typo: it should be demonstrate and not
demonstate, there is a missing r</li>
    <li>Page 26, I am not comfortable with the comment on ACAP at the
beginning of section 6</li>
    <li>Page 30, at the end I dsiagree with the Security statement here</li>
    <li>Page 32, first paragrapha very small typo: there is a space
between options/ extended, it should be options/extended to be
consistent with the others after</li>
    <li>Page 34, the registration number 3 is almost a duplicate of
registration number 1, you want to remove one or the other.</li>
  </ul>
Hope this helps anyway<br>
  <br>
A++<br>
  <br>
Lisa Dusseault wrote:
  <blockquote
 cite="[email-masked]"
 type="cite"><br>
We still haven't gotten enough review of LISTEXT during last call to&nbsp;
finish it off.&nbsp; Chris, Philip, Dave, you still need to review at least&nbsp;
the changes from the last time you reviewed or we'll need to find&nbsp;
another couple reviewers.&nbsp; Arnt was the only one who posted his review&nbsp;
to the Last Call. <br>
    <br>
Here's the -15 draft:&nbsp;
    <a class="moz-txt-link-rfc2396E"
 href="http://www.ietf.org/internet-drafts/draft-ietf-imapext-list-extensions-15.txt">&lt;http://www.ietf.org/internet-drafts/draft-ietf-imapext-list-
extensions-15.txt&gt;</a> <br>
    <br>
And to make it really easy, here's the diff from -14 <br>
    <a class="moz-txt-link-rfc2396E"
 href="http://tools.ietf.org/wg/imapext/draft-ietf-imapext-list-extensions/draft-ietf-imapext-list-extensions-15-from-14.diff.html">&lt;http://tools.ietf.org/wg/imapext/draft-ietf-imapext-list-extensions/
draft-ietf-imapext-list-extensions-15-from-14.diff.html&gt;</a> <br>
    <br>
Lisa <br>
    <br>
On Nov 27, 2005, at 7:56 AM, Lisa Dusseault wrote: <br>
    <br>
    <blockquote type="cite">"I love deadlines. I like the whooshing
sound
they make as they fly&nbsp; by." <br>
&nbsp;&nbsp;&nbsp; Douglas Adams <br>
      <br>
Nobody commented during this last call period.&nbsp; There were good&nbsp;
reviews when this was previously last-called, but I'd like to know&nbsp;
that the changes were reviewed. Chris Newman, Philip Guenther and Dave&nbsp;
Cridland volunteered to look it over, so you guys need to get back to&nbsp;
me.&nbsp; Anybody else who reviewed the changes in LISTEXT since draft -13,&nbsp;
let me know. <br>
      <br>
Lisa <br>
      <br>
On Oct 27, 2005, at 4:25 PM, Lisa Dusseault wrote: <br>
      <br>
      <blockquote type="cite"><br>
I call your attention to this draft: <br>
        <br>
        <a class="moz-txt-link-freetext"
 href="http://www.ietf.org/internet-drafts/draft-ietf-imapext-list">http://www.ietf.org/internet-drafts/draft-ietf-imapext-list</a>-
extensions-14.txt <br>
        <br>
We previously did a WG last call in May 2005 but we decided for a&nbsp;
"do-over" since there were a few significant changes. <br>
        <br>
This document is the framework for much of the syntax we're doing in&nbsp;
other IMAPEXT tasks and is being referenced by other documents&nbsp;
already, so it's important that it gets a good review. <br>
        <br>
If you review it at all, or plan to implement, or have any opinion&nbsp;
about standardizing this document, send mail to the WG list or at&nbsp;
least to me.&nbsp; Send me email even if you reviewed draft 13 and&nbsp;
previously sent me email about that, to let me know if you have&nbsp;
reviewed the changes in draft 14 and are OK with them. <br>
        <br>
Because of the IETF meeting in a little over a week, let's do this&nbsp;
last call until EOD Nov 17 (three weeks).&nbsp; If you have any chance to&nbsp;
bring up issues before IMAPEXT meets on Tuesday Nov 8, that would be&nbsp;
much appreciated because it would give us an extra forum for&nbsp;
discussion. <br>
        <br>
Thanks, <br>
        <br>
Lisa <br>
        <br>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </blockquote>
  <br>
</blockquote>
<br>
</body>
</html>

--Boundary_(ID_iGAP5wAIo/IFwTBbRYYfNg)--

Date: Fri, 06 Jan 2006 11:20:55 +0100
From: Arnaud Taddei <[email-masked]>
Subject: Re: WG Last Call of LISTEXT draft 14
To: Lisa Dusseault <[email-masked]>
Cc: Chris Newman <[email-masked]>, Philip Guenther <[email-masked]>, Dave Cridland <[email-masked]>, IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_nYat8m/V8fsv+U1bIIQs/A)
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT

I reviewed ACL, LISTEXT, ANNOTATEMORE and CONDSTORE. While I got delayed 
several times in the past 4 weeks I accumulated hand written remarks 
that I am going to share in several mail messages.

Before I zoom on LISTEXT, I am generally having a very strange feeling 
about these 4 extensions and I reallize that unfortunately I am coming 
too late in the discussions.

Sorry this mail will be long

I am not sure how many of you are dealing with operational, deployment 
and architectural issues in real customer sites but be aware that the 
IETF stack of protocol, while it allows interoperability of solutions, 
somehow, it too created an operational monster to implement and debug if 
it is not just to explain to people in the field. With the level of 
troops that exists today in the field, this leads me to say that I am 
not sure that this point of view was kept in mind when writing these 
extensions.

My general impression is that somehow too many compromises were made and 
some times not enough. Anyway I will elaborate step by step.

Now zooming on LISTEXT, well well well. The model I had in mind for 
LISTEXT is that:  what are folder collections: they are just a 'name 
space' to organize data. This 'name space' is a static name space 
(versus a VIEW) created by:

    * System model, limits and constraints (for example for some systems
      INBOX is a name space that doesn't have children, for example
      shared and public folder name spaces)
    * End users (end users create their own name space of folders)
    * System administrators could create specific folder collections

What is that LISTEXT say is that it wants to treat the properties of the 
folders in this name space (remote, subscribed, exists, has kids, has no 
kids, etc.).

What is that ANNOTATEMORE say is that folders (and even the server) can 
have more properties than those ones, for example comment, motd, 
content-language, etc.)

What I have in mind is that a name-space can be represented exactly like 
the DIT of an LDAP server.

    * you have root folders
    * they have or not a tree below them
    * nodes (in our case folders) are represented by a distinguished
      name that we call the MUTF-7 folder name
    * nodes contain properties that are called attribute that have meta
      properties (Single-valued, multi-valued, are present or not, etc.)
    * and attributes for our folders are remote, subscribed, exists, has
      kids, has ACLs, is sharing flags or not, has customisable
      permanent flags or not, and the NAME itself, etc. etc. etc.

So what is LISTEXT if I  make an analogy with LDAP, LISTEXT is the 
LDAPSEARCH.

When we had to work on the co-existence of heterogeneous solutions we 
had to deal with how to keep the synchronization of public and shared 
folders between two systems. As a typical alien server for a site of say 
3000 users would already have 10'000 public folders, with as well the 
idea that 15% of the total users folders are shared we faced a big issue 
in migrations if we were not capable to keep communities of end users 
seeing the same view of their data wether they were migrated or not so 
we were asked to build a program to synchronize any folder specified by 
customers.

When performing this task it became obvious that we would need a model 
to 'select' the folders for examples as sub branches in the tree of 
folders. This lead us to design what we called the Folder Global 
Specification (FGS) and to define a listing model like an LDAP search 
which is composed of the following sequence of items in the search

Search folders:

    * which NAMESPACE:
          o in which name space (i.e. in which NAMESPACE) should we list
            the folders, in Private? In Shared? In Public? In Usenet
            Newsgroups? Others? a Combination?
    * which BASE:
          o under which folder base (i.e. under which branch)
          o For example should I want to search only those folders below
            "Foo/Bar/Toto"
          o The notion of search base exists already today obviously
    * which SCOPE:
          o Scope 0: should we stop at the node itself (just the branch),
          o Scope 1: one level below the node
          o Scope 2: all the branch below the specified folder base
            which is equivalent to Recursive
    * which FILTER:
          o which question in terms of a boolean combination of pattern
            match on attributes.
          o Usually the filter is the name but there could be others
            attributes in the filter, this is what you put with LISTEXT
            with the options in the LIST command, in fact these are part
            of a filter but the syntax is not unified
    * and what do you want to RETURN:
          o a list of attributes you want to return

With this in mind a LIST command would look like:

a1 LIST NAMESPACE=private BASE=("INBOX" "Fruit" "Sent") SCOPE=2  
FILTER=(&(\Remote=1)(\Subsribed=1)(\Exists=1) )

And then we can unify and simplify the syntax in a model that too me is 
proven and comes from an area where searching a 'name space' is the basics.

Not only that but it would allow to unify this command with ANNOTATEMORE 
in a very simple manner because the filter would add those attributes 
that GETANNOTATION is giving so we would have only one command to:

    * consider the folder space as a name space
    * folders do have 'attributes'
    * 'attributes' have meta properties such as single value, mutli
      value, presence, etc.  and including attributes ACLs (which
      eliminates the explicit .priv and .share model)
    * we have a unified model to search folders

I will come back on the CAPABILITY vs ANNOTATEMORE story later

In addition to this different approach I see the following issues in the 
document:

    * I disagree in the abstract on the Mailbox Referrals mention. No
      one implements it even not Microsoft correct? I think there are
      much more important issues to be covered in the abstract
    * I have a problem (which is surely my Frenglish) to understand 'or
      any combination of therof', I don't scan the word therof.
    * Page 9 on the paragraph for REMOTE, the 3 last lines are really
      some byzantinism that is really a pain to explain operationally.
      Could we favor eliminating exceptions and enhancing protocol
      readability?
    * Page 14, paragraph \HasChildren, I think I disagree with the
      security perspective
    * Page 16, I am not familiar with the \Marked in example 2. What
      does this attribute mean? Where is it defined?
    * Page 17, I think Example 6 requires much more explanations
    * Page 19, Example 8: typo: it should be demonstrate and not
      demonstate, there is a missing r
    * Page 26, I am not comfortable with the comment on ACAP at the
      beginning of section 6
    * Page 30, at the end I dsiagree with the Security statement here
    * Page 32, first paragrapha very small typo: there is a space
      between options/ extended, it should be options/extended to be
      consistent with the others after
    * Page 34, the registration number 3 is almost a duplicate of
      registration number 1, you want to remove one or the other.

Hope this helps anyway

A++

Lisa Dusseault wrote:

>
> We still haven't gotten enough review of LISTEXT during last call to  
> finish it off.  Chris, Philip, Dave, you still need to review at 
> least  the changes from the last time you reviewed or we'll need to 
> find  another couple reviewers.  Arnt was the only one who posted his 
> review  to the Last Call.
>
> Here's the -15 draft:  
> <http://www.ietf.org/internet-drafts/draft-ietf-imapext-list- 
> extensions-15.txt>
>
> And to make it really easy, here's the diff from -14
> <http://tools.ietf.org/wg/imapext/draft-ietf-imapext-list-extensions/ 
> draft-ietf-imapext-list-extensions-15-from-14.diff.html>
>
> Lisa
>
> On Nov 27, 2005, at 7:56 AM, Lisa Dusseault wrote:
>
>> "I love deadlines. I like the whooshing sound they make as they fly  
>> by."
>>     Douglas Adams
>>
>> Nobody commented during this last call period.  There were good  
>> reviews when this was previously last-called, but I'd like to know  
>> that the changes were reviewed. Chris Newman, Philip Guenther and 
>> Dave  Cridland volunteered to look it over, so you guys need to get 
>> back to  me.  Anybody else who reviewed the changes in LISTEXT since 
>> draft -13,  let me know.
>>
>> Lisa
>>
>> On Oct 27, 2005, at 4:25 PM, Lisa Dusseault wrote:
>>
>>>
>>> I call your attention to this draft:
>>>
>>> http://www.ietf.org/internet-drafts/draft-ietf-imapext-list- 
>>> extensions-14.txt
>>>
>>> We previously did a WG last call in May 2005 but we decided for a  
>>> "do-over" since there were a few significant changes.
>>>
>>> This document is the framework for much of the syntax we're doing 
>>> in  other IMAPEXT tasks and is being referenced by other documents  
>>> already, so it's important that it gets a good review.
>>>
>>> If you review it at all, or plan to implement, or have any opinion  
>>> about standardizing this document, send mail to the WG list or at  
>>> least to me.  Send me email even if you reviewed draft 13 and  
>>> previously sent me email about that, to let me know if you have  
>>> reviewed the changes in draft 14 and are OK with them.
>>>
>>> Because of the IETF meeting in a little over a week, let's do this  
>>> last call until EOD Nov 17 (three weeks).  If you have any chance 
>>> to  bring up issues before IMAPEXT meets on Tuesday Nov 8, that 
>>> would be  much appreciated because it would give us an extra forum 
>>> for  discussion.
>>>
>>> Thanks,
>>>
>>> Lisa
>>>
>>
>

--Boundary_(ID_nYat8m/V8fsv+U1bIIQs/A)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
I reviewed ACL, LISTEXT, ANNOTATEMORE and CONDSTORE. While I got
delayed several times in the past 4 weeks I accumulated hand written
remarks that I am going to share in several mail messages.<br>
<br>
Before I zoom on LISTEXT, I am generally having a very strange feeling
about these 4 extensions and I reallize that unfortunately I am coming
too late in the discussions. <br>
<br>
Sorry this mail will be long<br>
<br>
I am not sure how many of you are dealing with operational, deployment
and architectural issues in real customer sites but be aware that the
IETF stack of protocol, while it allows interoperability of solutions,
somehow, it too created an operational monster to implement and debug
if it is not just to explain to people in the field. With the level of
troops that exists today in the field, this leads me to say that I am
not sure that this point of view was kept in mind when writing these
extensions. <br>
<br>
My general impression is that somehow too many compromises were made
and some times not enough. Anyway I will elaborate step by step.<br>
<br>
Now zooming on LISTEXT, well well well. The model I had in mind for
LISTEXT is that:&nbsp; what are folder collections: they are just a 'name
space' to organize data. This 'name space' is a static name space
(versus a VIEW) created by:<br>
<ul>
  <li>System model, limits and constraints (for example for some
systems INBOX is a name space that doesn't have children, for example
shared and public folder name spaces)</li>
  <li>End users (end users create their own name space of folders)</li>
  <li>System administrators could create specific folder collections <br>
  </li>
</ul>
What is that LISTEXT say is that it wants to treat the properties of
the folders in this name space (remote, subscribed, exists, has kids,
has no kids, etc.). <br>
<br>
What is that ANNOTATEMORE say is that folders (and even the server) can
have more properties than those ones, for example comment, motd,
content-language, etc.)<br>
<br>
What I have in mind is that a name-space can be represented exactly
like the DIT of an LDAP server. <br>
<ul>
  <li>you have root folders</li>
  <li>they have or not a tree below them</li>
  <li>nodes (in our case folders) are represented by a distinguished
name that we call the MUTF-7 folder name</li>
  <li>nodes contain properties that are called attribute that have meta
properties (Single-valued, multi-valued, are present or not, etc.) </li>
  <li>and attributes for our folders are remote, subscribed, exists,
has kids, has ACLs, is sharing flags or not, has customisable permanent
flags or not, and the NAME itself, etc. etc. etc.</li>
</ul>
<br>
So what is LISTEXT if I&nbsp; make an analogy with LDAP, LISTEXT is the
LDAPSEARCH.<br>
<br>
When we had to work on the co-existence of heterogeneous solutions we
had to deal with how to keep the synchronization of public and shared
folders between two systems. As a typical alien server for a site of
say 3000 users would already have 10'000 public folders, with as well
the idea that 15% of the total users folders are shared we faced a big
issue in migrations if we were not capable to keep communities of end
users seeing the same view of their data wether they were migrated or
not so we were asked to build a program to synchronize any folder
specified by customers. <br>
<br>
When performing this task it became obvious that we would need a model
to 'select' the folders for examples as sub branches in the tree of
folders. This lead us to design what we called the Folder Global
Specification (FGS) and to define a listing model like an LDAP search
which is composed of the following sequence of items in the search<br>
<br>
Search folders:<br>
<ul>
  <li>which NAMESPACE: <br>
  </li>
  <ul>
    <li>in which name space (i.e. in which NAMESPACE) should we list
the folders, in Private? In Shared? In Public? In Usenet Newsgroups?
Others? a Combination?<br>
    </li>
  </ul>
  <li>which BASE: <br>
  </li>
  <ul>
    <li>under which folder base (i.e. under which branch)</li>
    <li>For example should I want to search only those folders below
"Foo/Bar/Toto"</li>
    <li>The notion of search base exists already today obviously<br>
    </li>
  </ul>
  <li>which SCOPE: <br>
  </li>
  <ul>
    <li>Scope 0: should we stop at the node itself (just the branch), <br>
    </li>
    <li>Scope 1: one level below the node</li>
    <li>Scope 2: all the branch below the specified folder base which
is equivalent to Recursive<br>
    </li>
  </ul>
  <li>which FILTER: <br>
  </li>
  <ul>
    <li>which question in terms of a boolean combination of pattern
match on attributes. <br>
    </li>
    <li>Usually the filter is the name but there could be others
attributes in the filter, this is what you put with LISTEXT with the
options in the LIST command, in fact these are part of a filter but the
syntax is not unified<br>
    </li>
  </ul>
  <li>and what do you want to RETURN:</li>
  <ul>
    <li>a list of attributes you want to return</li>
  </ul>
</ul>
With this in mind a LIST command would look like:<br>
<br>
a1 LIST NAMESPACE=private BASE=("INBOX" "Fruit" "Sent") SCOPE=2&nbsp;
FILTER=(&amp;(\Remote=1)(\Subsribed=1)(\Exists=1) )<br>
<br>
And then we can unify and simplify the syntax in a model that too me is
proven and comes from an area where searching a 'name space' is the
basics. <br>
<br>
Not only that but it would allow to unify this command with
ANNOTATEMORE in a very simple manner because the filter would add those
attributes that GETANNOTATION is giving so we would have only one
command to:<br>
<ul>
  <li>consider the folder space as a name space</li>
  <li>folders do have 'attributes'</li>
  <li>'attributes' have meta properties such as single value, mutli
value, presence, etc.&nbsp; and including attributes ACLs (which eliminates
the explicit .priv and .share model)</li>
  <li>we have a unified model to search folders</li>
</ul>
I will come back on the CAPABILITY vs ANNOTATEMORE story later<br>
<br>
In addition to this different approach I see the following issues in
the document:<br>
<ul>
  <li>I disagree in the abstract on the Mailbox Referrals mention. No
one implements it even not Microsoft correct? I think there are much
more important issues to be covered in the abstract</li>
  <li>I have a problem (which is surely my Frenglish) to understand 'or
any combination of therof', I don't scan the word therof.</li>
  <li>Page 9 on the paragraph for REMOTE, the 3 last lines are really
some byzantinism that is really a pain to explain operationally. Could
we favor eliminating exceptions and enhancing protocol readability?</li>
  <li>Page 14, paragraph \HasChildren, I think I disagree with the
security perspective</li>
  <li>Page 16, I am not familiar with the \Marked in example 2. What
does this attribute mean? Where is it defined?</li>
  <li>Page 17, I think Example 6 requires much more explanations</li>
  <li>Page 19, Example 8: typo: it should be demonstrate and not
demonstate, there is a missing r</li>
  <li>Page 26, I am not comfortable with the comment on ACAP at the
beginning of section 6</li>
  <li>Page 30, at the end I dsiagree with the Security statement here</li>
  <li>Page 32, first paragrapha very small typo: there is a space
between options/ extended, it should be options/extended to be
consistent with the others after</li>
  <li>Page 34, the registration number 3 is almost a duplicate of
registration number 1, you want to remove one or the other.</li>
</ul>
Hope this helps anyway<br>
<br>
A++<br>
<br>
Lisa Dusseault wrote:
<blockquote cite="[email-masked]"
 type="cite"><br>
We still haven't gotten enough review of LISTEXT during last call to&nbsp;
finish it off.&nbsp; Chris, Philip, Dave, you still need to review at least&nbsp;
the changes from the last time you reviewed or we'll need to find&nbsp;
another couple reviewers.&nbsp; Arnt was the only one who posted his review&nbsp;
to the Last Call.
  <br>
  <br>
Here's the -15 draft:&nbsp;
<a class="moz-txt-link-rfc2396E" href="http://www.ietf.org/internet-drafts/draft-ietf-imapext-list-extensions-15.txt">&lt;http://www.ietf.org/internet-drafts/draft-ietf-imapext-list-
extensions-15.txt&gt;</a>
  <br>
  <br>
And to make it really easy, here's the diff from -14
  <br>
<a class="moz-txt-link-rfc2396E" href="http://tools.ietf.org/wg/imapext/draft-ietf-imapext-list-extensions/draft-ietf-imapext-list-extensions-15-from-14.diff.html">&lt;http://tools.ietf.org/wg/imapext/draft-ietf-imapext-list-extensions/
draft-ietf-imapext-list-extensions-15-from-14.diff.html&gt;</a>
  <br>
  <br>
Lisa
  <br>
  <br>
On Nov 27, 2005, at 7:56 AM, Lisa Dusseault wrote:
  <br>
  <br>
  <blockquote type="cite">"I love deadlines. I like the whooshing sound
they make as they fly&nbsp; by."
    <br>
&nbsp;&nbsp;&nbsp; Douglas Adams
    <br>
    <br>
Nobody commented during this last call period.&nbsp; There were good&nbsp;
reviews when this was previously last-called, but I'd like to know&nbsp;
that the changes were reviewed. Chris Newman, Philip Guenther and Dave&nbsp;
Cridland volunteered to look it over, so you guys need to get back to&nbsp;
me.&nbsp; Anybody else who reviewed the changes in LISTEXT since draft -13,&nbsp;
let me know.
    <br>
    <br>
Lisa
    <br>
    <br>
On Oct 27, 2005, at 4:25 PM, Lisa Dusseault wrote:
    <br>
    <br>
    <blockquote type="cite"><br>
I call your attention to this draft:
      <br>
      <br>
<a class="moz-txt-link-freetext" href="http://www.ietf.org/internet-drafts/draft-ietf-imapext-list">http://www.ietf.org/internet-drafts/draft-ietf-imapext-list</a>-
extensions-14.txt
      <br>
      <br>
We previously did a WG last call in May 2005 but we decided for a&nbsp;
"do-over" since there were a few significant changes.
      <br>
      <br>
This document is the framework for much of the syntax we're doing in&nbsp;
other IMAPEXT tasks and is being referenced by other documents&nbsp;
already, so it's important that it gets a good review.
      <br>
      <br>
If you review it at all, or plan to implement, or have any opinion&nbsp;
about standardizing this document, send mail to the WG list or at&nbsp;
least to me.&nbsp; Send me email even if you reviewed draft 13 and&nbsp;
previously sent me email about that, to let me know if you have&nbsp;
reviewed the changes in draft 14 and are OK with them.
      <br>
      <br>
Because of the IETF meeting in a little over a week, let's do this&nbsp;
last call until EOD Nov 17 (three weeks).&nbsp; If you have any chance to&nbsp;
bring up issues before IMAPEXT meets on Tuesday Nov 8, that would be&nbsp;
much appreciated because it would give us an extra forum for&nbsp;
discussion.
      <br>
      <br>
Thanks,
      <br>
      <br>
Lisa
      <br>
      <br>
    </blockquote>
    <br>
  </blockquote>
  <br>
</blockquote>
<br>
</body>
</html>

--Boundary_(ID_nYat8m/V8fsv+U1bIIQs/A)--

Date: Thu, 05 Jan 2006 21:18:19 +0000
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
From: Dave Cridland <[email-masked]>
To: Barry Leiba <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

On Thu Jan  5 13:50:43 2006, Barry Leiba wrote:
> 
> Hoo... I'm glad this came up again when Lisa put her "nag" message 
> up
> -- since I don't care about ACL, I never read the mislabelled 
> review of
> LISTEXT.
> 
> 
Yup. If I'd changed the subject line from the nag in the ACL message, 
it'd have been more clever.

> > 1) I found the ABNF strikingly difficult to follow.
> 
> Ya, I get that.  I'm not sure what to do about it, though.  It 
> started
> simply, but it complexificatalized quickly.  I'm not happy about 
> that,
> but the complexity is partly diven by the demand to have it be
> machine-parsable in as much of its detail as possible, rather than
> leaving some of that detail to human-readable explanation (take, for
> example, the bits about which combinations of options can be used).
> 
> 
Yes, hence my "this is largely because it's complex" - I agree that 
to satisfy all demands, it simply *is* complex.

> > but also because I spent some ten minutes
> > looking for the LIST response
> 
> I'm not sure what you want done here.  We do point to the IMAP 
> document
> for the rest.  The problem here is that the item "mailbox-list" is
> redefined here, but its predecessors ("mailbox-data", and
> "response-data" before that, and "response" before that) are in RFC
> 3501.  I could put a comment on the "mailbox-list" entry saying that
> it's pointed to by "mailbox-data" in [IMAP].  If that'll satisfy 
> you,
> I'll do it.  I don't know what else I can do for this.
> 
> 
A note at the beginning in the introductory prose saying where the 
LIST response is defined is all that's needed. Text like:

The LIST response is defined as part of the mailbox-data production 
in [IMAP], this ABNF replaces the mailbox-list production defining 
its payload.

I'm thinking that the first two things implementors will be looking 
for is the LIST command production and the LIST response production.

> I believe that no matter what happens to ACAP, it
> would be useful to have a separate RFC for "vendor-token" and the
> associated IANA registry, since an entity like that is needed in a
> number of places, as we see.

Yes, certainly. I'd happily argue to restrict it to ASCII 
alphanumerics, too.

> > I've not had time to verify the examples - I'll try to do so, but 
> I
> > doubt I'll have time before the new year.
> 
> And the new year it is!
> 
> 
Yes, indeed...

Page 7. Both examples appear to be missing spaces between the closing 
of one parenthesized list and the opening of the next.

Section 5...

5) "[...] similar to the command <RLSUB "" "%">." - Should be "*", 
not "%".
Extraneous comma in "mailboxes, which".
6) Extraneous comma.
8) "demonstates" typo.
A1) "instead" should be "as well", surely? The "or even this" clause 
and example doesn't make sense to me - it's simply added 
\HasChildren, but the client didn't request it.
C) "none of them is" should be "none of them are".

> > a) So far, I've not seen any server implementation supporting
> > multiple mailbox patterns. I noted that this would be relatively
> > involved to implement server-side myself, but perhaps more 
> tellingly,
> > although my API supports this, the layer above never actually 
> causes
> > multiple mailbox patterns to be used. I'm struggling to find a
> > use-case for multiple mailbox patterns.
> 
> We put in multiple mailbox patterns because we wanted the 
> flexibility,
> and we wanted consistent syntax with other commands, such as an
> extended SEARCH, which could certainly want to use that (and 
> consider
> that someone had suggested using extended LIST itself as an extended
> SEARCH).  If consensus is that it's unnecessary and too 
> complicated, we
> can pull out the multiple patterns for LIST, at the expense of not
> having the consistent syntax.
> 
> 
Yes, I think it could prove useful later, certainly. At this stage, 
it makes no real difference to clients, and it's additional 
complexity for servers - and server developers have historically 
preferred to avoid complexity at almost any cost.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Date: Thu, 05 Jan 2006 08:50:43 -0500
From: Barry Leiba <[email-masked]>
To: [email-masked]
Subject: Re: Review of draft-ietf-imapext-list-extensions-15
Sender: [email-masked]

Hoo... I'm glad this came up again when Lisa put her "nag" message up
-- since I don't care about ACL, I never read the mislabelled review of
LISTEXT.

> 1) I found the ABNF strikingly difficult to follow.

Ya, I get that.  I'm not sure what to do about it, though.  It started
simply, but it complexificatalized quickly.  I'm not happy about that,
but the complexity is partly diven by the demand to have it be
machine-parsable in as much of its detail as possible, rather than
leaving some of that detail to human-readable explanation (take, for
example, the bits about which combinations of options can be used).

> but also because I spent some ten minutes
> looking for the LIST response

I'm not sure what you want done here.  We do point to the IMAP document
for the rest.  The problem here is that the item "mailbox-list" is
redefined here, but its predecessors ("mailbox-data", and
"response-data" before that, and "response" before that) are in RFC
3501.  I could put a comment on the "mailbox-list" entry saying that
it's pointed to by "mailbox-data" in [IMAP].  If that'll satisfy you,
I'll do it.  I don't know what else I can do for this.

> 2) I disagree with the statement that ACAP will never move to Draft.
> I don't think this belongs in a normative section, it's merely an
> opinion, and one which I hope to rectify.

That's in there in error anyway -- it was an editorial comment, which
actually remains as an open issue (but one that doesn't need to be
resolved until/if we go beyond Proposed Std, and ACAP hasn't by then),
and which, when I converted the doc to XML, I didn't turn into a
<cref>.  I'll fix it so it does not disparage ACAP :-), but to bring
the issue up again here (which we should follow up, if we want to do,
in another thread):  I believe that no matter what happens to ACAP, it
would be useful to have a separate RFC for "vendor-token" and the
associated IANA registry, since an entity like that is needed in a
number of places, as we see.

[Gee, that was all one sentence!]

> I've not had time to verify the examples - I'll try to do so, but I
> doubt I'll have time before the new year.

And the new year it is!

> a) So far, I've not seen any server implementation supporting
> multiple mailbox patterns. I noted that this would be relatively
> involved to implement server-side myself, but perhaps more tellingly,
> although my API supports this, the layer above never actually causes
> multiple mailbox patterns to be used. I'm struggling to find a
> use-case for multiple mailbox patterns.

We put in multiple mailbox patterns because we wanted the flexibility,
and we wanted consistent syntax with other commands, such as an
extended SEARCH, which could certainly want to use that (and consider
that someone had suggested using extended LIST itself as an extended
SEARCH).  If consensus is that it's unnecessary and too complicated, we
can pull out the multiple patterns for LIST, at the expense of not
having the consistent syntax.

Barry

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

Date: Wed, 04 Jan 2006 22:43:51 +0000
Subject: Re: WG Last Call of LISTEXT draft 14
From: Dave Cridland <[email-masked]>
To: Lisa Dusseault <[email-masked]>
Cc: <[email-masked]>, Chris Newman <[email-masked]>, Philip Guenther <[email-masked]>
Sender: [email-masked]

On Wed Jan  4 21:44:36 2006, Lisa Dusseault wrote:
> We still haven't gotten enough review of LISTEXT during last call 
> to  finish it off.  Chris, Philip, Dave, you still need to review 
> at least  the changes from the last time you reviewed or we'll need 
> to find  another couple reviewers.  Arnt was the only one who 
> posted his review  to the Last Call.
> 
> 
I sent mine in December, in reply to your last email, without 
changing its subject line. Whoops.

At least Timo saw it, he replied.

It's here:

<imap://[email-masked]/INBOX;UIDVALIDITY=1132432829/;uid=16618;urlauth=anonymous:internal:00336e8bab1467a5ab36b990af9e5b25f4911b1147>

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

Cc: IMAP Extensions WG <[email-masked]>
From: Lisa Dusseault <[email-masked]>
Subject: Re: WG Last Call of LISTEXT draft 14
Date: Wed, 4 Jan 2006 13:44:36 -0800
To: Chris Newman <[email-masked]>, Philip Guenther <[email-masked]>, Dave Cridland <[email-masked]>
Sender: [email-masked]

We still haven't gotten enough review of LISTEXT during last call to  
finish it off.  Chris, Philip, Dave, you still need to review at least  
the changes from the last time you reviewed or we'll need to find  
another couple reviewers.  Arnt was the only one who posted his review  
to the Last Call.

Here's the -15 draft:  
<http://www.ietf.org/internet-drafts/draft-ietf-imapext-list- 
extensions-15.txt>

And to make it really easy, here's the diff from -14
<http://tools.ietf.org/wg/imapext/draft-ietf-imapext-list-extensions/ 
draft-ietf-imapext-list-extensions-15-from-14.diff.html>

Lisa

On Nov 27, 2005, at 7:56 AM, Lisa Dusseault wrote:

> "I love deadlines. I like the whooshing sound they make as they fly  
> by."
>     Douglas Adams
>
> Nobody commented during this last call period.  There were good  
> reviews when this was previously last-called, but I'd like to know  
> that the changes were reviewed. Chris Newman, Philip Guenther and Dave  
> Cridland volunteered to look it over, so you guys need to get back to  
> me.  Anybody else who reviewed the changes in LISTEXT since draft -13,  
> let me know.
>
> Lisa
>
> On Oct 27, 2005, at 4:25 PM, Lisa Dusseault wrote:
>
>>
>> I call your attention to this draft:
>>
>> http://www.ietf.org/internet-drafts/draft-ietf-imapext-list- 
>> extensions-14.txt
>>
>> We previously did a WG last call in May 2005 but we decided for a  
>> "do-over" since there were a few significant changes.
>>
>> This document is the framework for much of the syntax we're doing in  
>> other IMAPEXT tasks and is being referenced by other documents  
>> already, so it's important that it gets a good review.
>>
>> If you review it at all, or plan to implement, or have any opinion  
>> about standardizing this document, send mail to the WG list or at  
>> least to me.  Send me email even if you reviewed draft 13 and  
>> previously sent me email about that, to let me know if you have  
>> reviewed the changes in draft 14 and are OK with them.
>>
>> Because of the IETF meeting in a little over a week, let's do this  
>> last call until EOD Nov 17 (three weeks).  If you have any chance to  
>> bring up issues before IMAPEXT meets on Tuesday Nov 8, that would be  
>> much appreciated because it would give us an extra forum for  
>> discussion.
>>
>> Thanks,
>>
>> Lisa
>>
>

Date: Tue, 03 Jan 2006 20:35:40 -0500
From: Ken Murchison <[email-masked]>
Organization: Carnegie Mellon University
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-imapext-condstore-08.txt
Sender: [email-masked]

[email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF.
> 
> 	Title		: IMAP Extension for Conditional STORE operation
> 	Author(s)	: A. Melnikov, S. Hole
> 	Filename	: draft-ietf-imapext-condstore-08.txt
> 	Pages		: 0
> 	Date		: 2006-1-3

What changed?

-- 
Kenneth Murchison
Project Cyrus Developer/Maintainer
Carnegie Mellon University

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-imapext-condstore-08.txt 
Date: Tue, 03 Jan 2006 10:50:01 -0500
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Message Access Protocol Extension Working Group of the IETF.

	Title		: IMAP Extension for Conditional STORE operation
	Author(s)	: A. Melnikov, S. Hole
	Filename	: draft-ietf-imapext-condstore-08.txt
	Pages		: 0
	Date		: 2006-1-3
	
Often, multiple IMAP (RFC 3501) clients need to coordinate changes to
a common IMAP mailbox. Examples include different clients working on behalf of the same user, and multiple users accessing shared mailboxes. These clients need a mechanism to synchronize state changes for messages within the mailbox. They must be able to guarantee that only one client can change message state (e.g., message flags) at any time.  An
example of such an application is use of an IMAP mailbox as a message
queue with multiple dequeueing clients.

The Conditional Store facility provides a protected update mechanism for
message state information that can detect and resolve conflicts between
multiple writing mail clients.

This document defines an extension to IMAP (RFC 3501).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapext-condstore-08.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-imapext-condstore-08.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-imapext-condstore-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-imapext-condstore-08.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-imapext-condstore-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--