[09:45:33] --- amelnikov has joined
[14:06:26] --- lisa has joined
[14:07:06] <lisa> hi!
[14:07:25] <lisa> You're on the big screen now
[14:09:58] --- Hollenbeck has joined
[14:10:09] <lisa> quick, say something nasty about Barry
[14:10:21] <lisa> he's reading the chat room on the big screen :)
[14:11:41] <amelnikov> Barry is lazy :-)
[14:11:55] <amelnikov> Is it nasty enough?
[14:12:18] <lisa> He didn't even flinch.
[14:12:25] <lisa> he's actually still smiling
[14:12:42] <lisa> ah well, my attempts at "let's you and him fight" usually fail.
[14:12:44] <amelnikov> He probably got used to it
[14:12:52] <lisa> now thtat's mean!
[14:14:51] <amelnikov> Actually, if Larry is in the room - tell him that he is probably even lazier
[14:14:57] <lisa> Barry says you probably voted for Bush.
[14:15:17] <amelnikov> Ok, that is insulting enough :-)
[14:18:52] <amelnikov> Ok people, it is 8:20pm for me, so you have to keep me awake ;-)
[14:20:29] --- tonyhansen has joined
[14:21:10] * lisa pokes Alexey to keep him awake
[14:21:35] <tonyhansen> that's a virtual jab via jabber
[14:23:01] <lisa> that makes *me* the jabber
[14:23:54] <lisa> or the jabber-jabber, to be specific.
[14:26:09] --- randy has joined
[14:27:35] <lisa> My clock has it at 3:29, so we'll stop the jabber-jabber jabber and get started...
[14:27:54] --- corby has joined
[14:27:56] --- Glenn Parsosn has joined
[14:28:04] <lisa> Jabber scribe, anyone?
[14:28:15] --- Glenn Parsosn has left
[14:28:27] --- Glenn Parsons has joined
[14:28:49] --- Glenn Parsons has left: Disconnected
[14:30:11] <lisa> Chris is coming online to be our jabber scribe...
[14:30:17] <lisa> We're still missing Pete R in the meeting room
[14:30:23] --- cnewman has joined
[14:32:59] <cnewman> lisa: agenda bashing?
[14:34:02] <cnewman> collator/comparator draft reviews pending Martin pushed out release recently
[14:34:30] <cnewman> Pete R arrives at meeting
[14:35:42] --- resnick has joined
[14:36:09] <cnewman> List extensions draft is deemed complex, partly due to \Placeholder
[14:36:25] * resnick will be right back
[14:36:28] <cnewman> Philip proposed removing most \Placeholder text
[14:36:33] --- Sam has joined
[14:37:38] <cnewman> Barry: agrees we need to simplify listext
[14:38:04] <cnewman> Barry: need more client oriented perspective
[14:38:18] <amelnikov> A more concrete proposal is welcomed
[14:40:04] <cnewman> Cyrus: only return \Placeholder if pattern ends in %
[14:41:00] <cnewman> Philip: Problem is keeping responses stateless independent of the request
[14:41:17] * resnick returns
[14:41:43] <cnewman> Barry: does anyone do mailbox referrals besides Microsoft?
[14:42:03] <cnewman> Cyrus: CMU server makes it available to clients
[14:42:22] <lisa> Alexey, what client implementers besides Cyrus were involved in asking for features in LISTEXT?
[14:42:23] <amelnikov> MessagingDirect stores referrals internally
[14:43:11] <lisa> who wanted MatchParent?
[14:43:14] <amelnikov> Lisa: David Cridland. Mark?
[14:43:18] <cnewman> Barry: Who wanted matched parent?
[14:43:59] <amelnikov> MatchParent is evolution of LSUB code in Cyrus
[14:44:42] <cnewman> Action: Cyrus and Philip will feed concrete simplification suggestions to Barry
[14:44:44] <lisa> Any more issues with LIESTEXT?
[14:44:51] <amelnikov> To answer direct question: I don't know. Cyrus never said "no"
[14:44:55] <lisa> before we move on to antoher topic?
[14:45:38] <amelnikov> Multiple mailbox patterns?
[14:46:13] <lisa> barry's discussing that now...
[14:46:48] <cnewman> Barry: issue with multiple mailbox patterns. Barry wants to keep this feature in so this is extensible, but concern that this makes it more complex for server. Barry wants servers to do duplicate removal on mailbox which matches multiple patterns.
[14:47:31] <cnewman> Cyrus: Mulberry does lots of lists in sequence, so it would be nice to do it in one command
[14:47:46] <cnewman> Barry: Would like to get syntax in now rather than have yet another extension
[14:48:32] <resnick> (*and the political commentary degrades further and further*)
[14:49:32] <cnewman> Philip: Concerned about a bit more complexity which makes it more likely someone will screw up and get it wrong. What is value if client can just pipeline multiple lists
[14:50:01] --- resnick has left: Disconnected
[14:50:08] <cnewman> Philip: his server can perform better with all patterns up front
[14:50:18] <cnewman> Lisa: any other objections to multiple patterns?
[14:50:28] --- resnick has joined
[14:50:40] <amelnikov> If I am to choose one feature to keep between MATCHPARENT and multiple mailbox patterns - I will keep multiple mailbox patterns
[14:51:06] <amelnikov> Unfortunately Timo and Arnt are asleep now
[14:51:23] <cnewman> Nobody in room objects to multiple mailbox patterns
[14:51:47] <amelnikov> ... so they can't comment on LISTEXT
[14:52:28] <cnewman> Pete: unless objection on list go forward with multiple mailbox patterns.
[14:52:55] <amelnikov> Do we have any person who wants MATCHPARENT?
[14:54:03] <cnewman> Barry: The \Placeholder was put in for LSUB + NOSELECT vs. \Nonexistent.
[14:54:15] <cnewman> Philip: we should just combine \Placeholder and \Nonexistent
[14:54:39] <cnewman> Philip: Clients don't care about distinction
[14:55:00] <cnewman> correction: should combine \Noselect and \Nonexistent
[14:55:16] <lisa> WRT Timo and Arnt, we'll review these "consensuses" so far, on the list
[14:56:24] <cnewman> Requirement was given to server vendor to distinguish between deleted and non-deleted
[14:57:20] <amelnikov> But the client wouldn't care either way. Do we have a useful use case when \NoSelect is different from \NonExistent?
[14:57:21] --- Glenn Parsons has joined
[14:57:26] <cnewman> Request made to investigate reason for requirement
[14:58:59] <cnewman> Barry: Wording for special case of "" pattern is believed to be OK. Provide feedback if otherwise.
[14:59:17] <cnewman> Lisa: moving on to ACL spec
[14:59:24] <cnewman> Lisa: who read it?
[14:59:32] <cnewman> peanut gallery: only 4 people
[15:00:15] <cnewman> Philip: let's clarify which rights are associated with which commands and split up rights for expunge and delete mailbox
[15:01:04] <amelnikov> I think this is already done
[15:01:05] <cnewman> Philip: only open issue left is the "m" flag for private annotations
[15:01:50] <amelnikov> To be precise: usage of the "m" right for reading of the private annotations (controlling writing of priv annotations is Ok)
[15:01:52] <cnewman> Cyrus: how to get myrights response back from select
[15:02:25] <amelnikov> MYRIGHTS is sent automatically on SELECT (in both drafts)
[15:02:40] <cnewman> Philip: may need to have myrights come back as a response code when included with SELECT response
[15:03:10] <cnewman> Lisa: if anyone has bad feeling about ACL, speak up now rather than later.
[15:03:28] <lisa> Philip, Cyrus, myself and one other admitted to reading 2086 upd
[15:03:35] <resnick> comments alexey?
[15:04:19] <amelnikov> draft-ietf-imapext-acl-11.txt defines MYRIGHTS response code, but I see no point to do this in draft-ietf-imapext-2086upd-01.txt, which is "quick fix".
[15:04:59] <amelnikov> draft-ietf-imapext-2086upd-01.txt just uses MYRIGHT response, which backward compatible with ACL.
[15:05:29] <amelnikov> Philip has done a good review of draft-ietf-imapext-2086upd-00.txt, my big thanks.
[15:05:31] <cnewman> Cyrus wants to see myright response code to SELECT in 2086upd; needs response code to be backwards compatible
[15:05:55] --- kmurchison has joined
[15:06:22] <cnewman> Philip: myrights response code is backwards compatible with old clients; a myrights response to SELECT is not backwards compatible with old clients.
[15:06:44] <cnewman> moving on to message annotations
[15:06:53] <amelnikov> MYRIGHTS response is compatible with ACL.
[15:06:56] <cnewman> How many people looked at draft?
[15:07:08] <cnewman> [silence]
[15:07:15] <amelnikov> I've looked at the diff.
[15:07:24] <resnick> (a few weak hands go up)
[15:07:42] <cnewman> major change was can't set flags through annotate
[15:08:04] <cnewman> flags.shared and flags.priv map to same value you'd get from a FETCH
[15:08:48] <cnewman> Other change: proposing two new ACL bits; "m" for shared annotations, "n" for private annotations
[15:09:05] <cnewman> Any objections to new ACL bits?
[15:09:49] <lisa> There are no objections in the room, so Alexey this is your prompt if you have an objection to CYyrus' proposal
[15:09:56] <amelnikov> As I said earlier I object to using "m" for reading of private annotations ("r" is sufficient). Using "m" for writing is fine
[15:10:17] <amelnikov> And Timo has said the same thing
[15:11:18] <cnewman> Question: can we use "r" for reading annotations and "s" for writing annotations instead of "m"?
[15:11:50] <cnewman> John: READ-WRITE vs. READ-ONLY is usless once we have myrights
[15:12:15] <cnewman> John: "w" is write for public state and "s" is write for private state
[15:12:39] <cnewman> Cyrus: What if seen is shared flag, but also want to allow private annotations?
[15:12:56] <amelnikov> John Myers?
[15:13:22] <cnewman> Yes. John = John Myers
[15:13:41] <amelnikov> Say hi to him.
[15:14:34] <cnewman> Issue: do you want someone to be able to write annotations, then take write access away and still allow read? Or should read/write for private annotations be linked?
[15:14:34] <amelnikov> I am ok with redefining "w" to control shared \Seen state
[15:14:41] --- tonyhansen has left: Disconnected
[15:15:06] <amelnikov> I can see a case when the server *only* provides private annotations
[15:15:31] <amelnikov> Please, don't link reading and writing
[15:15:41] <cnewman> Pete: private annotations either exist or they don't. If they exist they are readable and writable so splitting those in two bits doesn't make sense.
[15:16:05] --- Glenn Parsons has left: Disconnected
[15:16:12] <amelnikov> Private annotations can be generated on the fly by the server
[15:16:18] <cnewman> Question: why not link reading and writing?
[15:16:45] <resnick> Generated by the server but not changeable by me?
[15:17:22] <amelnikov> Pete: yes. Same as \Recent.
[15:17:30] <cnewman> If private annotations is unmodifiable by user, what is the purpose of it?
[15:17:55] <cnewman> \Recent is bad example :-)
[15:17:58] <resnick> Uh, we want more things like recent?
[15:19:05] <cnewman> Cyrus: question about silly state where "r" is off and "m" is on if we split read/write.
[15:19:11] <resnick> Does anybody real want to implement a private annotation that is readble but not writeable?
[15:19:33] <cnewman> Philip: lots of silly states are present in ACL
[15:19:33] <resnick> Not theoretically. I want a serious example.
[15:20:00] <amelnikov> I frankly don't know. But I don't want to prevent something that might be reasonable in the future.
[15:20:26] --- corby has left: Disconnected
[15:20:31] <amelnikov> We already have a lot of silly states in ACL: "l" without "r" - visible in LIST, but not selectable.
[15:20:58] <resnick> Barry: But it's not just a single annotation. Having read-only .priv annotations means *all* .priv annotations are read-only, not just a single one.
[15:21:06] <cnewman> Chris: we want to avoid silly states whenever possible. Client is harder to implement if it has to have separate read-only and read-write displays of private annotations.
[15:23:45] <cnewman> Cyrus: no objection to having read private annotations controlled by "r" and ability to write private annotations is controlled by new "m" ACL bit.
[15:23:52] <lisa> Proposal: that the ability to read private annotations is controlled by the 'r' ACL bit, and the ability to write private annotations is controlled by the new 'm' ACL bit.
[15:24:46] <amelnikov> I obviously agree with the proposal
[15:24:48] <lisa> Corollary: This means that 'r' controls readability for both private and shared annotations.
[15:24:55] <cnewman> Chris: slight preference for "m" controls both "read" and "write", but can live with split proposal.
[15:25:04] <cnewman> Barry: agree with Chris
[15:25:15] <cnewman> No objections to split proposal in room
[15:25:43] <amelnikov> There is a consistency problem between ANNOTATE servers and ANNOTATE+ACL servers. Please read my post on the mailing list.
[15:26:11] <cnewman> Other issue: CATENATE race condition with ANNOTATE draft
[15:26:49] <amelnikov> That is the first time I hear about this. Can somebody explain
[15:27:12] <resnick> ANNOTATE changes APPEND to add annotations.
[15:27:30] <resnick> Should we add CATENATE to ANNOTATE or ANNOTATE to CATENATE?
[15:27:53] <amelnikov> Is there some syntax issue?
[15:28:29] <cnewman> Yes, it's a syntax dependency issue.
[15:28:58] <amelnikov> CONDSTORE depends on ANNOTATE depends on CATENATE and I18N. Hmmm.
[15:29:26] <cnewman> Pete: can we make ANNOTATE redefine flag-list to include annotations so CATENATE reference to flag-list will automatically be updated?
[15:30:12] <cnewman> Philip: no. used in flags fetch response.
[15:30:50] <cnewman> Pete: this becomes a race to last call. CATENATE will likely make it out the door first so Annotate will have to include section on how it interacts with CATENATE.
[15:31:24] <cnewman> Randy: race to last call is refreshing change :-)
[15:32:43] <amelnikov> I would hope it would be the other way around, although both are pretty close
[15:33:02] <amelnikov> I meant: ANNOTATE be published first.
[15:33:07] <cnewman> Cyrus: when we do annotations in append it could have body part dependencies on the MIME structure, text may be needed to clarify that server does body part parse first.
[15:33:36] <cnewman> CATENATE will be published first because it doesn't depend on i18n and will go to last call after one round of editorial/example editing.
[15:33:59] <cnewman> ANNOTATE also needs only one rev, but it will take longer to go to RFC.
[15:34:24] <amelnikov> It is one year now since CONDSTORE was approved :-(
[15:34:38] <cnewman> Lisa: wants more review for 2086 update.
[15:34:44] <cnewman> Chris: stupidly volunteers
[15:34:54] <amelnikov> Thanks Chris
[15:35:40] <cnewman> Other volunteer for 2086upd review: Scott H.
[15:35:56] <amelnikov> Thanks Scott!
[15:36:05] <cnewman> Cyrus: wants more review for annotatemore
[15:37:11] <amelnikov> I promise to review ANNOTATEMORE, as soon as ANNOTATE is approved ;-)
[15:37:17] <kmurchison> I'll review ANNOTATEMORE since I have implementation experience
[15:38:00] <Hollenbeck> Alexey: please ping when when 2086upd-01 is available, ok?
[15:38:30] <amelnikov> Scott: I can send you the version I will submit now.
[15:39:04] <cnewman> Chris: will try to find someone in Sun to review ANNOTATEMORE
[15:39:14] <cnewman> Philip: will try to find time for annotatemore review
[15:39:18] <cnewman> Lisa: any other issues?
[15:39:40] <resnick> Alexey?
[15:40:06] <amelnikov> Just a moment.
[15:40:25] * resnick curses asking
[15:40:36] --- tonyhansen has joined
[15:41:01] <amelnikov> I've asked our ADs to Last Call draft-melnikov-imap-disc-06.txt. (IMAP Disconnected Mode, dependency of RFC 3501). Please review!
[15:41:02] <tonyhansen> how do you whistle via jabber?
[15:41:13] <Hollenbeck> ted will be taking it
[15:41:24] <lisa> Please send a message to the list asking for review!
[15:41:30] <resnick> Anything else?
[15:41:36] <lisa> (but now the people in the room know too)
[15:42:09] <lisa> Ted points out that comments on disc need to be cc'ed to him as well as Scott
[15:42:19] * resnick listens for Alexey still typing....
[15:42:48] <amelnikov> No, lucky you. No more issues.
[15:43:00] <resnick> And the gavel falls!
[15:43:00] --- Hollenbeck has left
[15:43:01] <lisa> thanks everybody!
[15:43:07] --- resnick has left
[15:43:12] --- cnewman has left
[15:43:13] <amelnikov> Thanks!
[15:43:16] --- tonyhansen has left
[15:43:37] --- kmurchison has left
[15:43:43] --- lisa has left: Disconnected
[15:44:26] --- randy has left
[15:45:01] --- amelnikov has left
[16:26:24] --- Sam has left: Disconnected