[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 minutesThat looks good.
>> > looking for the LIST response
> > A note at the beginning in the introductory prose saying where
> 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,Better.
I've reworded the ACAP text; let me know if you think that's OK.
> C) "none of them is" should be "none of them are".Fairy nuff.
Nah; "none" is singular, though it's acceptable to give it plural
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 supportingI'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.
>>> multiple mailbox patterns.
> Yes, I think it could prove useful later, certainly. At this
> 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:
>> * Page 14, paragraph \HasChildren, I think I disagree with theRight. 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.
>> security perspective
> > Rereading this section, I note that "the server MUST return
> 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
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
little rewording; let me know what you think of it.
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.
You see things; and you say "Why?"
But I dream things that never were; and I say "Why not?"
- George Bernard Shaw