LISTEXT to IESG?

[Lisa Dusseault <[e-mail]>]

Dave Cridland was the only one who responded to this revision of  
LISTEXT, and raised no new issues.  Is anybody aware of open issues?   
Because I'm starting to think this is ready to go to IESG.  Speak up  
now.

Lisa

On Jan 17, 2006, at 8:43 AM, Barry Leiba wrote:

> 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  ([e-mail])
> 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>
>