Re: LISTEXT to IESG?

[Arnaud Taddei <[e-mail]>]

Lisa Dusseault wrote:

>
> 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.

Am stuck since 2 weeks at 18 hours per day + too many buis trips. I have 
all my ideas in my head but need 2 hours to complete reading Dave's 
mails and making a second pass as I have several things to check but I 
think I found a way to align a proposal. Can I beg for doing this wait 
for Monday? I think I will work on it this week end.

A++

>
> 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>
>>
>
>