[05:12:53] --- alexeymelnikov has joined
[07:24:57] --- alexeymelnikov has left
[07:25:35] --- alexeymelnikov has joined
[07:31:31] --- alexeymelnikov has left
[07:48:57] --- alexeymelnikov has joined
[08:26:02] --- hardie has joined
[08:39:18] --- rjs3 has joined
[08:39:49] <alexeymelnikov> Hi Ted
[08:40:21] --- kmurchison has joined
[08:40:24] <alexeymelnikov> Ted: Have you received my response regarding IMAP CONDSTORE extension?
[08:40:53] <hardie> What date was it sent?
[08:42:33] <alexeymelnikov> October 30th. I've replied to Ned and CC'd to you
[08:43:00] <hardie> I'll check for it.
[08:45:03] <alexeymelnikov> I've just forwared it to you. Subject line is "[Fwd: Re: IESG review of draft-ietf-imapext-condstore-04.txt]"
[08:50:44] <alexeymelnikov> Ted: My question regarding CONDSTORE is as follows: Based on information in my reply, do you think that a new Last Call be required?
[08:51:43] --- resnick has joined
[08:55:12] --- lisaDusseault has joined
[08:57:40] <rjs3> test
[08:58:01] <rjs3> looks like we're about get started
[08:58:38] --- lisaDusseault has left: Disconnected
[09:00:13] <rjs3> going to start with a document status check
[09:00:19] <rjs3> what is ready/not for last call
[09:00:34] <rjs3> then we'll do a review of documents/discuss open issues for those who want
[09:00:40] <rjs3> cyrus: ANNOTATE
[09:00:49] <hardie> A new last call should not be required; adjusting the text in the document is required. I re-read the explanation in your message, and I think I get it. We'd need more "drafty" language for me to be sure.
[09:01:07] <rjs3> last one was posted a while ago, no comments so far. we should do a WG last call
[09:01:35] <alexeymelnikov> Ted: Thanks. I will try to publish a new revision by the end of the month
[09:01:56] <rjs3> ANNOTATEMORE: looking at issues with partial failures for SETANNOTATION
[09:02:10] <rjs3> 3 options: total failure, partial failure, or no multimailbox setannotation
[09:02:27] <rjs3> we'll address that later
[09:03:10] <rjs3> crispin: SORT - it should be in the IESG queue by now
[09:03:28] <rjs3> pete: we may have been sitting on last call until chris's document was ready
[09:04:03] <rjs3> chris: currently draft is in ID-exists state, we need to make sure someone pokes it
[09:04:17] <rjs3> ted takes care of it
[09:05:12] <rjs3> LISTEXT - pete owes a note to barry, alexey is willing to help if it is stuck
[09:05:32] <rjs3> ACL -
[09:06:00] <alexeymelnikov> I haven't done much on ACL2 since the last round of comments
[09:06:03] --- leg has joined
[09:06:06] <rjs3> there are still open issues that haven't folded into the document
[09:06:17] <rjs3> CONDSTORE -
[09:06:44] <rjs3> alexey to send in new version of draft then ready to go
[09:07:26] <rjs3> lemonade stuff - COMPOSE, URLAUTH, CHANNEL
[09:07:35] <rjs3> compose isn't written yet
[09:07:54] <rjs3> urlauth is stabalizing, but needs a bit more work before its ready
[09:08:10] <rjs3> mark: this is great but it could be greater, implementation by the end of the year
[09:09:00] <rjs3> pete: there was some yelping about channel at some point
[09:09:13] <rjs3> chris: the editors went AWOL
[09:09:23] <rjs3> pete: my feeling is to let them figure it out...
[09:10:16] <rjs3> cyrus: IEA?
[09:10:27] <rjs3> pete: I'm uninclined to go there until we know what they are doing
[09:10:45] --- randy has joined
[09:11:04] <rjs3> mark: proposed way of dealing: big switch to change all of IMAP to UTF-8
[09:11:17] <rjs3> details to be discussed later, but we should keep this in mind
[09:11:18] --- leg has left: Lost connection
[09:11:57] --- alexeymelnikov has left: Replaced by new connection
[09:12:39] --- NFreed has joined
[09:12:40] --- lisaDusseault has joined
[09:12:45] <rjs3> leg: lets move on
[09:12:55] --- alexeymelnikov has joined
[09:14:22] <rjs3> SASL-IR: please review, new version after the respository opens
[09:14:36] <rjs3> current known implementations: Cyrus, UW, Squirrelmail
[09:14:55] <NFreed> Alexey: I see no need to redo the last call on CONDSTORE unless you
[09:14:56] <rjs3> ANNOTATEMORE: discussion of the failure mode
[09:15:01] <NFreed> make really major changes.
[09:15:20] <NFreed> I also don't think major changes are needed at this point.
[09:15:38] <rjs3> review of alexey's comments: total failure is impractical, partial failure is consistant with ACL2
[09:16:26] <rjs3> mark: concerns about legacy mailstores
[09:17:11] <rjs3> mark: it would be nice for there to be implementation recommendations
[09:18:26] <alexeymelnikov> Ned: I don't expect to do any major changes to CONDSTORE.
[09:18:57] <rjs3> cyrus: there is a need to set an entire mailboxes to a certain thread/sort view
[09:19:27] <rjs3> cyrus: we could provide a suggested mechanism of inheretance simulation
[09:20:01] <rjs3> no one seems to want to implement inheretance "for real" in the spec
[09:20:32] <rjs3> leg: since clients can simulate it, it seems to be an argument for not allowing multi-mailbox setannotatioon
[09:20:58] <rjs3> leg: can you show an example where multimailbox is significantly more useful than just pipelining commands?
[09:21:24] <rjs3> cyrus: ACL does have inheretance, should a created mailbox inheret the settings of its parent?
[09:21:49] <alexeymelnikov> Question about ANNOTATEMORE: are annotations inherited when a submailbox is created?
[09:22:17] <rjs3> not currently, thats under discussion.
[09:22:30] --- leg has joined
[09:22:38] <rjs3> to me, it seems dangerous for the /vendor namespace atleast
[09:23:16] <rjs3> rough consensus on denying multiple mailbox lookups and giving clients a suggested mechanism to implement inheretence if they wanted
[09:24:45] <kmurchison> deny multiple mailbox GETANNOTATION and/or SETANNOTATION?
[09:24:59] --- lisaDusseault has left: Disconnected
[09:25:27] <leg> multiple mailbox SETANNOTATION is out is what i got
[09:25:37] <rjs3> just deny setannotation
[09:25:48] <kmurchison> ok
[09:25:58] <rjs3> getannotation multiple mailbox is fine
[09:26:36] <alexeymelnikov> This seems consistent with LIST/SUBSCRIBE/UNSUBSCRIBE
[09:26:36] <rjs3> discussing ACL2 briefly
[09:27:34] <kmurchison> is GETANNOTATION going to be deprecated in favor of a LISTEXT option?
[09:28:24] <alexeymelnikov> Ken: I think we had no agreement on this before
[09:28:38] <kmurchison> reason?
[09:28:53] <alexeymelnikov> Suggestion was to have both and the market will decide (or something like this)
[09:29:36] <rjs3> brief review of webdav acl (and its troubles) by lisa
[09:30:03] <alexeymelnikov> I frankly don't care about LISTEXT vs GETANNOTATION, both just use different syntax for doing the same
[09:30:20] <resnick> Alexey: Open ACL2 issues you want discussed?
[09:30:55] <alexeymelnikov> Can somebody summarize recently proposed change :-)?
[09:31:14] <rjs3> I think we really need to see the new document after all the comments are incoproated into it
[09:31:35] <alexeymelnikov> I agree.
[09:32:04] <alexeymelnikov> So, what were the issues with WebDav ACLs?
[09:33:15] <rjs3> more discussion of legacy systems in acl.
[09:33:50] --- LOGGING STARTED
[09:34:47] --- LOGGING STARTED
[09:35:17] --- alexeymelnikov has joined
[09:35:29] --- alexeymelnikov has left
[09:35:59] --- alexeymelnikov has joined
[09:36:07] --- alexeymelnikov has left
[09:37:27] --- rjs3 has joined
[09:38:28] --- rjs3 has left: Logged out
[09:38:28] --- rjs3 has joined
[09:38:28] --- rjs3 has left: Logged out
[09:38:45] --- rjs3 has joined
[09:38:48] <rjs3> test
[09:39:05] <rjs3> hmmm, I wonder where everyone went.
[09:39:13] --- leg has joined
[09:39:19] <rjs3> Anyway, we're putting the ACL issue on hold until we see a new document
[09:39:25] <leg> there was massive jabber suck.
[09:39:33] <leg> and as always, we avoided the underlying issue.
[09:39:48] --- kmurchison has joined
[09:40:38] <rjs3> chris is now about to talk about IDN
[09:41:40] --- alexeymelnikov has joined
[09:42:22] <alexeymelnikov> Hmm, I thought that something was wrong with my system. We seem to loose all history :(
[09:42:26] <rjs3> we are futzing with the projector
[09:43:26] <alexeymelnikov> Sorry, one more question about ACL: Does it mean that I should or should not add more text on legacy systems?
[09:43:57] <rjs3> you should probably update the document with the notes from the last round of comments and see where we are afterwords
[09:44:23] <rjs3> Chris is presenting about recent changes to the i18n document
[09:44:42] <rjs3> did a s/comparator/collation/ to the draft
[09:44:55] <alexeymelnikov> There was a discussion about new command in ACL2 that shows different server settings. Do we have an agreement that this is useful?
[09:44:56] <kmurchison> fwiw, the log on xmpp.org has all of the traffic
[09:45:28] <rjs3> Made comparator names more compatible with URLs
[09:46:03] --- arnt has joined
[09:46:06] <rjs3> registration template is now XML
[09:46:49] <alexeymelnikov> Ken: thanks
[09:48:05] <rjs3> once all the changes are done there will be reviews by unicode and W3C
[09:49:01] <arnt> leg: which underlying issue? (my client too died)
[09:49:02] <rjs3> ted: I appreciate the early coordination with W3C and Unicode, concerns over IANA URLs
[09:49:53] --- resnick has joined
[09:50:27] <rjs3> (as in referencing the documents in perpetuity)
[09:50:48] <alexeymelnikov> Arnt: talking about ACL, I believe
[09:51:31] <arnt> in that case I'm not terribly surprised
[09:52:29] <rjs3> collation open issues
[09:52:39] <rjs3> nameprep processing for basic collation? (no)
[09:52:42] --- NFreed has joined
[09:52:49] <rjs3> way to download unicode collation customizations? (yes)
[09:53:23] <arnt> whose customizations? server vendor, server site, client?
[09:53:37] <rjs3> [parens indicate chris's gut instinct, he recommends that concern parties check the specs]
[09:54:39] <rjs3> chris: customization the registration template would have a url template to point to the customization
[09:54:59] <arnt> ok
[09:55:12] <rjs3> the syntax would be a semi-standardized one if unicode comes up with one, if there isn't one, we will punt
[09:56:30] --- dcrocker has joined
[09:56:37] --- arnt has left
[09:56:47] --- arnt has joined
[09:58:54] <rjs3> concerns about Collation/CAPABILITY responses
[09:59:16] <rjs3> Phillip suggests using unsolicited responses to indicate a change in default instead (for example, on SELECT -leg)
[10:00:08] --- randy has joined
[10:00:24] --- randy has left
[10:00:28] --- randy has joined
[10:00:50] <rjs3> leg didn't propose a numeric collation
[10:01:34] <rjs3> back to lemonade stuff
[10:01:39] --- ams has joined
[10:02:11] <rjs3> pete: idea for compose: APPEND can append literal text of pieces from the currently selected mailbox
[10:02:41] <alexeymelnikov> I like Cyrus's "expand" idea
[10:02:44] <rjs3> you can compose from multiple mailboxes by copying stuff all into a single mailbox
[10:03:41] <rjs3> suggested other less-grand names: assemble, consolidate, etc...
[10:03:50] <rjs3> engulf
[10:04:43] <rjs3> pete: we'll go with compose for the moment :), I want to keep it as simple as possible
[10:04:58] <rjs3> chair: open issues in urlauth?
[10:05:06] <rjs3> mark: we'd like to have review of the document, thats about it
[10:05:25] <rjs3> chair: if you are in this form and not tracking lemonade, you're probably shirking your responsibilities
[10:05:44] <alexeymelnikov> Question: do we want to consider URLs that have any reasonable persistence in time?
[10:05:53] <rjs3> chris: URLAUTH is of value to IMAP independent of lemonade
[10:06:51] <rjs3> ted: why does it need to be a url?
[10:07:42] <rjs3> mark: in a compose type situation, urls become much more of an obvious thing
[10:08:05] <rjs3> alexey: "reasonable presistance in time?" I just want to understand your question and ask it
[10:08:55] <alexeymelnikov> Yes. I've asked Mark/Chris the following question: I want to send an URL to 10,000 people and than revoke it for one person.
[10:09:16] <alexeymelnikov> Or alternatively: send 10,000 URLs and revoke access just for one of them.
[10:09:17] <leg> the uri community?
[10:09:17] <rjs3> ted: the authorization mechanism isn't extensible to other URIs automatically
[10:09:29] <alexeymelnikov> The current mechanism will revoke access to ALL of them
[10:09:50] <rjs3> I think that there is an expiration mechanism proposed, I'll ask to confirm though
[10:10:19] <leg> definitely no way to revoke just a single user's access.
[10:10:31] <alexeymelnikov> Expiration is orthogonal. I might not want to restrict access in time.
[10:10:57] <rjs3> ok.
[10:11:40] <kmurchison> Alexey: you can change the key on the mailbox, but that will break ALL outstanding URLs
[10:12:00] <rjs3> yeah, thats the problem.,
[10:12:16] <rjs3> (more discussion in room about URLAUTH outside of lemonade, for example, on mail archives)
[10:12:40] <alexeymelnikov> Ken: exactly. What if I sent something to my boss and changed my mind later on ;-)?
[10:12:47] <leg> mark is coming up with increasingly contorted reasons why URLAUTH is useful beyond forward without download.
[10:15:36] <ams> such as?
[10:16:05] <rjs3> mailing list archives accessable from the web, for example
[10:16:22] <alexeymelnikov> Hmm, I thought about this too
[10:16:33] <rjs3> except anonymous IMAP also really allows that in many ways
[10:17:08] <leg> right. either anonymous imap is the answer, imap's existing authentication is the answer, or maybe one-time use http urls.
[10:17:59] <rjs3> chris: resolving imap urls has historicaly been hard. URLAUTH fixes that to some extent
[10:18:22] <leg> but wouldn't having an HTTP server also solve that problem?
[10:18:25] <alexeymelnikov> Mozilla still uses internal URL schema for IMAP
[10:18:35] <rjs3> chris: "urls are pointers on the internet, I want to point to my message store, without a colocated http server"
[10:18:40] <rjs3> leg: why is this easier?
[10:18:53] <rjs3> chris: this is a scalability / complexity issue
[10:18:57] <rjs3> leg: we know how to scale http
[10:19:08] <rjs3> chris: we don't want to have lots of services on the same box
[10:21:17] <rjs3> alexey -> chris: if that feature is desired, we will look into that, but thats a lot of complexity and we would want a strong reason for it
[10:21:26] <rjs3> leg: but you just gave the reason -> power for users!
[10:22:30] <rjs3> randal: maybe there is a middle ground where we can do the authorization for many users without infinite amounts of tweaks to this access
[10:22:48] <rjs3> randal: maybe we could get rid of acl!
[10:23:04] <rjs3> chair: further comments?
[10:24:16] <rjs3> chris: yeah, we could put lots of the functionality of ACL into this, but I don't think we really want that amount of complexity, and its a balance we need to keep
[10:25:20] <rjs3> randal: targeting forward without download is probably good enough to make something mostly generaly useful, and I don't think we should move the target
[10:25:57] <rjs3> leg: if its supposed to be more useful, we need to know what the use cases are before we understand the security implications.
[10:26:15] <rjs3> leg: unless its really just for fwd w/o download, we really need to think about what the other use cases are, this isn't a trivial change
[10:26:41] <rjs3> chris: I'm going to take away that we really need to look at the use cases for this before going forward...even if it is only for forward without download
[10:27:24] <rjs3> we're done an hour early
[10:27:33] --- rjs3 has left
[10:27:52] <alexeymelnikov> Can I bug (bore?) people about ACL2 once more?
[10:27:58] <kmurchison> when is sieve happening? now or in an hour?
[10:28:18] <resnick> Alexey: Ask before folks leave.
[10:28:32] <alexeymelnikov> Sieve: I suggest we start ASAP, I might have to leave early
[10:28:49] <NFreed> What's the name of the jabber conference for sieve?
[10:29:00] <kmurchison> "sieve"
[10:29:06] <NFreed> Cool.
[10:29:08] <resnick> Alexey?
[10:29:18] <alexeymelnikov> Just a seconds
[10:29:58] <alexeymelnikov> ACL2: There was a proposal about having a new command for returning different ACL2 options, not related to "model", e.g. how many groups are allowed, etc.
[10:30:00] --- dcrocker has left: Replaced by new connection
[10:30:00] --- dcrocker has joined
[10:30:01] --- dcrocker has left
[10:30:23] <alexeymelnikov> Should I add this to a new revision?
[10:30:45] <resnick> cyrus: 1 single ACL capability
[10:30:49] <resnick> rob: problem with that.
[10:31:07] <resnick> leg: objection.....
[10:31:22] <resnick> leg: pick 1
[10:31:39] <resnick> lisa: clients suck in webdav....
[10:32:25] <alexeymelnikov> I think we agreed that picking one is not an option. IMHO, if I am to implement ACL2 from scratch, I will not implement UNION ;)
[10:32:28] <resnick> consensus: alexey post straw man to the list
[10:33:04] <resnick> anything else, alexey?
[10:33:08] <alexeymelnikov> Ok, you just pushing more work to me :( :)
[10:33:30] <alexeymelnikov> No, that is probably it for now
[10:33:40] <resnick> ok meeting ajourned
[10:33:46] --- resnick has left: Disconnected
[10:33:55] --- kmurchison has left
[10:34:30] --- alexeymelnikov has left
[10:34:36] --- arnt has left
[10:34:46] --- mrose has joined
[10:37:50] --- mrose has left
[10:42:13] --- alexeymelnikov has joined
[10:42:28] --- alexeymelnikov has left
[10:42:53] --- NFreed has left
[10:44:15] --- ams has left
[10:54:20] --- randy has left: Replaced by new connection
[10:54:56] --- randy has joined
[11:02:45] --- leg has left: Disconnected
[11:35:21] --- kmurchison has joined
[11:35:27] --- kmurchison has left
[15:00:39] --- resnick has joined
[15:44:25] --- LOGGING STARTED
[15:56:21] --- resnick has joined
[15:59:14] --- resnick has left: Disconnected
[15:59:19] --- resnick has joined
[15:59:29] --- resnick has left: Disconnected
[20:25:18] --- LOGGING STARTED
[20:49:35] --- LOGGING STARTED
[23:39:57] --- LOGGING STARTED