Re: draft-ietf-imapext-list-extensions-01.txt

["Barry Leiba" <[e-mail]>]

> 1. The discussion of \PlaceHolder incorrectly refers to \NoSelect
> instead of \Noselect.

Atoms are case-insensitive.

> 2. The second example uses the option SUBSCRIBE instead of SUBSCRIBED.

Already fixed in my draft, along with the erroneous reference to
"SUBSCRIPTIONS" later.

> 1. Is \NonExistent ONLY intended to be used for subscribed mailboxes, or
> can/should it be used for other mailboxes in the hierarchy.  For
> example, we have a subscribed mailbox foo/bar, but mailbox foo doesn't
> exist.  Should LIST (SUBSCRIBED) "" % return
> 
> * LIST (\NonExistent \PlaceHolder) "/" "foo"
> 
> or should \Noselect be used in place of \Nonexistent?  Or, is just
> \PlaceHolder sufficient?

I'd say that \NonExistent should be used in any case where it's possible
to have an entity returned that doesn't exist.  So if "a/b/c/d/e" is 
subscribed to, and nothing in the whole hierarchy exists, then whenever
there's cause to return "a" or "a/b" or "a/b/c" or "a/b/c/d", they should
also be marked \NonExistent.  Theoretically, this would apply in cases
other than with the SUBSCRIBED option, but there aren't any other cases
where this could happen (since we don't allow truly missing hierarchy
levels; we can only mark those \Noselect).

Since the SUBSCRIBED option demands that all flags be accurate, you'd
need to return both flags... because both are true.

> 2. What should the flags be for a LIST response which returns just a
> namespace prefix?  For instance, given the namespace
> 
> * NAMESPACE (("" "/")) (("Other Users/" "/")) (("Shared Folders/" "/"))
> 
> and assuming that we have mailbox "Shared Folders/foo" which is
> subscribed and exists, should LIST (SUBSCRIBED) " % return
> 
> * LIST (\Noselect \PlaceHolder) "/" "Shared Folders"
> 
> or should it return only one or the other?  Should \NonExistent be used
> in place of \Noselect?

I think a namespace is an existent entity, so it gets marked \Noselect.

> 3. When doing a LIST (SUBSCRIBED CHILDREN), does the presence of
> \PlaceHolder imply \HasChildren, or should both flags be returned (ala
> \Noinferiors implies and supercedes \HasNoChildren)?

Clearly \PlaceHolder implies \HasChildren, but I see no reason not to send
them both.  If anyone feels strongly about it, I'm happy to say that because
\PlaceHolder implies \HasChildren, the latter SHOULD NOT be returned.  But
I won't make that change unless some people really think I should.

> 4. Are there any existing clients which implement standalone CHILDREN
> (draft-gahrns-imap-child-mailbox), and would benefit from Cyrus
> advertising it in addition to LISTEXT, or should any new CHILDREN
> implementations do so only under the LISTEXT umbrella?

As CHILDREN evolved, it was actually decided NOT to advertise a capability
string for it, because as the draft was written there was no way to ask 
for the info or not.  So a client could determine that it was supported by
the presence of the flags.

Barry Leiba, Internet Messaging Technology   ([e-mail])
http://www.research.ibm.com/people/l/leiba