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 (leiba@xxxxxxxxxxxxxx)
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>