Re: Review of draft-ietf-imapext-list-extensions-15

["Dave Cridland" <[e-mail]>]

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