[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


















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