[05:45:55] --- philip.vanhoof has joined
[05:46:13] --- philip.vanhoof has left
[15:19:21] --- ams has joined
[15:19:48] --- ams has left
[15:52:27] --- kmurchison has joined
[15:55:30] --- andrew.daviel has joined
[16:00:28] --- Glenn Parsons has joined
[16:00:42] * Glenn Parsons has set the topic to: IETF 70 - LEMONADE
[16:02:30] <Glenn Parsons> We're about to star
[16:04:03] --- Barry Leiba has joined
[16:04:12] --- Alexey has joined
[16:04:36] --- cnewman@jabber.org has joined
[16:04:59] --- cyrus_daboo has joined
[16:05:01] --- peter has joined
[16:05:10] <cyrus_daboo> Cyrus the scribe...
[16:05:10] --- randy has joined
[16:05:17] --- resnick has joined
[16:05:18] <kmurchison> Thx Cyrus
[16:05:22] <cyrus_daboo> Reviewing agenda.
[16:06:32] <cyrus_daboo> No comments on agenda.
[16:06:41] <cyrus_daboo> Document status...
[16:06:51] <cyrus_daboo> Three new RFCs since last time.
[16:07:02] <cyrus_daboo> Two in rfc ed queue.
[16:07:11] <cyrus_daboo> Two others waiting for AD.
[16:07:17] <cyrus_daboo> They are not WG items.
[16:07:40] <cyrus_daboo> Asking the AD about status of annotatemore and context.
[16:07:47] <cyrus_daboo> Chris has been nagged and will work on them.
[16:07:57] <cyrus_daboo> Done with document status.
[16:08:10] <cyrus_daboo> On to lemonade architecture document.
[16:08:29] <cyrus_daboo> Result of discussion from last time.
[16:08:40] --- aaronstone has joined
[16:08:51] <cyrus_daboo> Moved ascii diagrams etc out of profile bis into this document.
[16:09:00] <cyrus_daboo> Move forward as informational.
[16:09:13] <cyrus_daboo> Also includes OMA requirements.
[16:09:32] <cyrus_daboo> Chairs recommend to move to WG last call.
[16:09:56] <cyrus_daboo> Alexey: Will it distract for LC on other documents?
[16:10:24] <cyrus_daboo> Chairs: no it won't. But we will order docs appropriately.
[16:10:48] <cyrus_daboo> Zoltan: how did this become a WG document?
[16:11:05] <cyrus_daboo> - Came out of two other WG documents.
[16:11:05] --- guenther has joined
[16:11:23] <cyrus_daboo> Zoltan: must be informational.
[16:11:26] <cyrus_daboo> Agreement.
[16:11:56] <cyrus_daboo> Notifications document next.
[16:12:11] <cyrus_daboo> Ready for last call.
[16:12:42] <cyrus_daboo> Randy: agrees. Will address some issues sent by Alexey in one more draft.
[16:12:52] <cyrus_daboo> Next: results from second interop...
[16:13:09] <cyrus_daboo> Report from Alexey:
[16:13:16] <cyrus_daboo> second event in Munich
[16:13:34] <cyrus_daboo> test to see whether previous issues were addressed, new features etc.
[16:13:44] <cyrus_daboo> 2 new clients
[16:13:53] <cyrus_daboo> 2 new servers doing lemonade profile
[16:14:02] <cyrus_daboo> 2 new servers doing partial implementation
[16:14:14] <cyrus_daboo> Some bugs found but they were minor.
[16:15:40] <cyrus_daboo> Some surprises on which features were implemented.
[16:16:08] --- ned.freed@gmail.com has joined
[16:16:23] <cyrus_daboo> Randy: was the "5" servers all the same?
[16:16:37] <cyrus_daboo> Alexey: different sets of 5.
[16:16:52] <cyrus_daboo> Tony: how many clients did LIST-EXTENDED?
[16:17:02] <cyrus_daboo> Alexey: only one I think.
[16:17:33] <cyrus_daboo> Also spent time talking about extensions not yet implemented.
[16:18:12] <cyrus_daboo> Also talked about new extensions needed:
[16:18:18] <cyrus_daboo> - extended error handling
[16:18:26] <cyrus_daboo> - status info in LIST
[16:18:34] <cyrus_daboo> - search on server
[16:18:54] <cyrus_daboo> Thanks to Arnt for hosting.
[16:19:44] <cyrus_daboo> Where are the slides?
[16:19:53] <cyrus_daboo> They are on the meeting presentation site.
[16:20:32] <cyrus_daboo> Phil: question about within interest.
[16:20:45] <cyrus_daboo> Alexey: did a "rating" exercise on each extension.
[16:20:50] <cyrus_daboo> Phil: where is the list?
[16:20:55] <cyrus_daboo> Alexey: secret!
[16:21:03] <cyrus_daboo> Tony: how many clients in total?
[16:21:14] <cyrus_daboo> Alexey: 4 working, 1 planning.
[16:21:32] <cyrus_daboo> On to convert document...
[16:22:04] <cyrus_daboo> Peter: implemented a lot of this:
[16:22:07] <cyrus_daboo> some issues:
[16:22:37] <cyrus_daboo> - could use more wildcarding to reduce the amount of data for image specs.
[16:22:46] --- arnt has joined
[16:22:58] <cyrus_daboo> - extended error handling
[16:23:11] <arnt> oh, I'm 22 minutes late. the agenda bashing will at least have started.
[16:23:17] <cyrus_daboo> Need better error reporting on a per item basis.
[16:24:12] <cyrus_daboo> Other concern: dependency on METADATA
[16:24:26] <guenther> arnt: you were already feted for hosting the interop
[16:25:03] <cyrus_daboo> Peter: we currently have the ability to convert bodies to utf-8, what about headers? Dumb clients can have a hard time with 2047 encoded headers.
[16:25:13] <cyrus_daboo> So why not support header conversion too?
[16:25:27] <cyrus_daboo> Glenn: all headers or just subject?
[16:25:41] <cyrus_daboo> Peter: convert any header that might have 2047.
[16:26:51] --- Lisa has joined
[16:26:57] <resnick> Randy: Is there anything other stuff besides 2047 that gets converted?
[16:27:04] <cyrus_daboo> Randy: curious...all types of header decoded?
[16:27:11] <Alexey> Regarding METADATA: I have a proposal I would like to discuss with people. It looks like only server-level METADATA is needed in the Lemonade Profile Bis, so I would like to suggest that server-level METADATA becomes a separate capability and only that capability is included into the Lemonade Profile Bis
[16:27:11] <arnt> is there an Issue with the audio?
[16:27:14] <resnick> (OK, I tried.)
[16:27:16] <cyrus_daboo> Cyrus: what about all the other MIME header type encodings?
[16:27:20] <arnt> an ah-issue?
[16:27:26] --- eburger has joined
[16:27:33] <resnick> Arnt, are you having trouble hearing?
[16:27:34] <cyrus_daboo> Peter: server should do as much of the work of fixing up these headers.
[16:28:07] <cyrus_daboo> Randy: sounds great. But during EAI discussions issue came up about unrecognized charsets.
[16:28:12] <arnt> I hear absolutely nothing.
[16:28:17] <cyrus_daboo> Peter: do not convert.
[16:28:32] <cyrus_daboo> Randy: this might be better than EAI in that client actually gets an indication of the error.
[16:28:34] <kmurchison> I have good audio, although lacking in volume. I switched to headphones
[16:28:42] * resnick sends IM to Joel to check on the audio...
[16:28:51] <cyrus_daboo> Eric: do we need this for profile bis?
[16:28:58] <cyrus_daboo> Peter: yes we need this.
[16:28:58] <aaronstone> arnt: it's really quiet. i turned off my system beeps to avoid blowing my ears out. i have headphone volume way way up.
[16:29:27] <cyrus_daboo> Alexey: not sure it should be mandatory. We could do this using a new parameter on CONVERT.
[16:29:50] <resnick> Checking on the audio...
[16:29:59] <cyrus_daboo> Phil: only need to relax existing syntax - no need for new parameter.
[16:30:05] <arnt> right. my feed is working, it's just awfully quiet.
[16:30:21] <randy> Do we need louder people?
[16:30:31] <randy> lemnaders are too soft-spoken?
[16:30:39] <cyrus_daboo> Phil: EAI showed that there are some characters that are awkward wrt escaping.
[16:30:54] <cyrus_daboo> Peter: this is still a half-baked idea. We are still working on the concept.
[16:31:19] <cyrus_daboo> Zoltan: client perspective - yes we would like this.
[16:31:42] <arnt> unusably quiet. the white noise from the microphone is louder than the people. I'll turn it off.
[16:31:54] <resnick> Is that better now>?
[16:31:58] <cyrus_daboo> Glenn: we understood that OMA had Chinese charset requirement, is it related?
[16:32:04] <aaronstone> that got a little bit louder
[16:32:07] <Alexey> Zoltan said that OMA needs header conversion
[16:32:12] <resnick> Need more?
[16:32:15] <cyrus_daboo> Zoltan: yes. Want conversion on all headers.
[16:32:27] <aaronstone> pete, yes louder please
[16:32:58] <cyrus_daboo> Zoltan: on chinese question. Do we convert only to utf-8?
[16:33:25] <cyrus_daboo> Peter: requirement is that you must allow conversion to utf-8, but you can use any other charset supproted.
[16:33:45] <cyrus_daboo> But with headers it might cause invalid headers.
[16:34:22] <cyrus_daboo> Phil: prefer to only allow utf-8. Other standards do utf-8 conversion for searching purposes anyway.
[16:34:26] <resnick> Arnt, are you any better?
[16:34:33] <aaronstone> yes, iso 8859 and a few others are really key
[16:34:42] <aaronstone> chinese i think probably throws us for a loop?
[16:34:44] <cyrus_daboo> Glenn: ok to proceed with this?
[16:34:45] <arnt> I can hear now.
[16:34:51] <cyrus_daboo> No objections.
[16:34:56] <resnick> OK, we'll leave it there.
[16:35:02] <arnt> 100% volume, 30dB gain and the loudspeakers at max volume ;)
[16:35:08] <arnt> thanks
[16:35:27] <cyrus_daboo> Peter: need a document on parameters needed during conversion.
[16:35:28] <ned.freed@gmail.com> Yes, the sound is much better now.
[16:35:46] <arnt> what does STI mean? as in STI crap?
[16:35:49] <cyrus_daboo> Glenn: getting this from OMA. They are supposed to give us a smaller list.
[16:36:36] <cyrus_daboo> Zoltan: OMA has not composed the list. Working on pinning down some things. Developing the list, but don't have it right now.
[16:37:15] <cyrus_daboo> Eric: lemonade parameter in IANA, OMA devices will use OMA set.
[16:37:23] --- tonyhansen has joined
[16:37:47] <cyrus_daboo> Alexey: parameters are missing and need to be documented.
[16:37:55] <cyrus_daboo> Glenn: missing in OMA or IANA?
[16:38:03] <cyrus_daboo> Alexey: IANA.
[16:38:31] <cyrus_daboo> Glenn: thinks he was supposed to go comopare them. This is useful but not rewquired.
[16:39:02] <cyrus_daboo> What to do? Ask OMA, or start our own? Get to after profile bis?
[16:39:16] <cyrus_daboo> Alexey: start our own then ask OMA, and after profile bis.
[16:39:34] <cyrus_daboo> Zoltan: agrees with Alexey.
[16:40:14] --- andrew.daviel has left
[16:40:19] <cyrus_daboo> Glenn: Outstanding issues on CONVERT?
[16:40:39] <cyrus_daboo> Alexey: will do a new revision and then see what people will say.
[16:41:09] <cyrus_daboo> New draft will have header conversion in it.
[16:41:16] <cyrus_daboo> Glenn: ready for WG LC after that?
[16:41:22] <cyrus_daboo> Alexey/Peter: yes.
[16:42:04] <cyrus_daboo> On to i18n document:
[16:42:22] <cyrus_daboo> Alexey: lemonmade might care wrt profile bis.
[16:42:55] <cyrus_daboo> Had hallway discussions earlier. Suggestion to replace two capabilities with two different ones with same prefix. Comparator is a superset of casemap.
[16:43:20] <cyrus_daboo> Other pieces discussed: mailbox names and keywords.
[16:43:36] <cyrus_daboo> Mailbox names in EAI draft. Consensus in hallway was to keep it there.
[16:44:18] <cyrus_daboo> Regarding keywords: making IMAP keywords i18n might be more trouble than it is worth. Suggested workaround was to use METADATA - mapping table between ascii keyword and a displayname.
[16:44:37] <cyrus_daboo> keywords won't be part of i18n.
[16:45:08] <cyrus_daboo> Randy: keyword - you mean client defined ones?
[16:45:10] <cyrus_daboo> Alexey: yes.
[16:45:31] <cyrus_daboo> Mark: multiple workarounds were discussed. But overall not worth the effort.
[16:45:59] <cyrus_daboo> Alexey: i18n for username/password. It too is in EAI document. Happy to leave it there.
[16:46:09] <cyrus_daboo> Mark: doesn;t that come from SASL?
[16:46:18] <cyrus_daboo> Alexey: yes, but LOGIN?
[16:46:24] <cyrus_daboo> Mark: deprecate LOGIN?
[16:46:33] <cyrus_daboo> Hum of interest?
[16:46:40] <cyrus_daboo> Deafening silence....
[16:47:10] <cyrus_daboo> Joseph: only allow utf-8 in i18n keywords?
[16:47:16] <cyrus_daboo> Alexey: currently ascii only.
[16:47:23] <arnt> please channel: deprecating login might be okay with real clients, but I've seen _so_ many little hacks that use it that I don't think it's possible. and besides it's the only method that works with telnet.
[16:48:09] <guenther> it's the only one that's _easy_ with telnet
[16:48:22] <guenther> "don't you do base64 encoding in your head?"
[16:48:35] <cyrus_daboo> Mark: not "remove" but "deprecate".
[16:48:48] <cyrus_daboo> Randy: agrees.
[16:49:19] <cyrus_daboo> Alexey: one change then it will be done.
[16:49:30] <cyrus_daboo> (Pete claps).
[16:49:52] <cyrus_daboo> On to notify document...
[16:50:12] <cyrus_daboo> Alexey: extensively discussed at interop.
[16:50:44] <cyrus_daboo> Suggestion to combine mailbox events into one.
[16:51:26] <cyrus_daboo> Mandatory or optional events? How would clients discover optional ones?
[16:52:03] <cyrus_daboo> Zoltan: what does anoptional event mean?
[16:52:43] <cyrus_daboo> Alexey: mandatory that each server support, some may be optionally supported.
[16:54:00] <tonyhansen> randy: a svr may support event, E.g., quota: have other means of implementing quota w/o implementing quota extensions but still support quota events.
[16:54:20] <tonyhansen> randy: is it acceptable for svr to only support some events?
[16:54:31] <cyrus_daboo> Alexey: server could respond to client request.
[16:54:35] <cyrus_daboo> with codes.
[16:55:01] <cyrus_daboo> Peter: wants to talk about notify/context/search/fetch.
[16:55:28] <cyrus_daboo> Based on implementation experience believes there is complexity in handling all these.
[16:55:54] <cyrus_daboo> Extra load on the server is not doing clients much good anyhow.
[16:56:14] --- andrew.daviel has joined
[16:56:41] <cyrus_daboo> Proposal: remove search/fetch programs from notify. But use persistent search within select instead.
[16:57:11] <cyrus_daboo> Context for partial fetches is overkill.
[16:57:28] <arnt> fwiw, I support the proposal to remove search, but oppose the proposal to remove fetch.
[16:57:38] <cyrus_daboo> Suggestion: as part of notify we add the optional fetch program to search and allow a search program to select command.
[16:58:12] <cyrus_daboo> Means little or no additional housekeeping on SELECT. Provides for all the needs of clients.
[16:58:25] <eburger> Arnt: Why oppose removing FETCH?
[16:58:29] <cyrus_daboo> i.e. move some peices from one draft to another but it will be much easier to implement.
[16:59:24] <cyrus_daboo> Peter: not remove fetch entirely - change to only allow on the selected part of notify.
[16:59:59] <cyrus_daboo> Alexey: this took multiple rounds to get to some kind of agreement. Best thing is to write down this latest proposal and send to mailing list and go from there.
[17:00:06] <cyrus_daboo> Peter: agreed.
[17:00:51] <cyrus_daboo> Changes come from experience of implementing much of this. very straight forward to implement this.
[17:01:06] <cyrus_daboo> Confident that we are converging on consensus on this.
[17:01:23] <cyrus_daboo> Peter: "Arnt don't disagree with me'.
[17:02:11] <cyrus_daboo> Chris: explicitly ask implementers to think carefully about this and then give yay or nay...
[17:03:21] <cyrus_daboo> Glenn: yay or nay to the concept itself or specific text?
[17:03:29] <cyrus_daboo> Alexey: yay or nay to specific proposal.
[17:04:08] <cyrus_daboo> Peter: (on otpional events) need response code from server on this.
[17:04:23] <cyrus_daboo> Could be response code or untagged.
[17:04:50] <cyrus_daboo> Phil: response codes have some limitations. Better to use untagged.
[17:05:04] <cyrus_daboo> Alexey: makes no difference as this is a new command.
[17:05:47] <cyrus_daboo> Alexey: will make a proposal.
[17:06:21] <cyrus_daboo> Zoltan: using events from notification msgevents.
[17:06:28] <cyrus_daboo> Why not leave the optional ones out?
[17:06:55] <cyrus_daboo> Alexey: must have mandatory set then use response code.
[17:07:47] <eburger> Zoltan: should this list not be in the MSGEVENTS docuemnt?
[17:08:24] <eburger> Alexey: NOTIFY draft has MSGEVENTS events *plus* extra events.
[17:08:39] <eburger> Glenn: How long is this list of "extra"? Is it useful?
[17:09:13] <eburger> Chris: "extras" were from a SPECIFIC implementation
[17:09:36] <cyrus_daboo> Randy: some were too complicated to do immediately. What are in this deocument not in the other?
[17:09:41] <cyrus_daboo> Alexey: ACLs?
[17:09:52] <cyrus_daboo> Randy: other doc called those out as too complicated.
[17:10:45] <cyrus_daboo> Peter: some will be compulsory but some will be optional.
[17:11:06] <cyrus_daboo> Glenn: OMA using msgevents for out of band. So why aren't notify events in there too.
[17:11:19] <cyrus_daboo> Peter: we need to look at that, but don't think anything is missing.
[17:11:51] <cyrus_daboo> Glenn: other piece is which are mandatory and which are optional.
[17:11:53] <randy> draft-ietf-lemonade-msgevent-05.txt says acl are for future extension
[17:13:42] <cyrus_daboo> Peter: prefer to see notify to state mandatory items.
[17:14:01] <cyrus_daboo> Glenn: make sure two docs event sets are the same.
[17:14:10] <cyrus_daboo> Alexey: will work with Randy.
[17:15:13] <cyrus_daboo> Randy: msgevent has list of events and parameters. Doc says some are useful but too complicated and left for later. So msgevents will need more work to accommodate this.
[17:16:19] <cyrus_daboo> Peter: could implement notify without having events existing except as a concept.
[17:16:37] <cyrus_daboo> e.g. what ACL event carries is private to the server.
[17:16:45] <cyrus_daboo> For notify its "just" an event.
[17:17:12] <cyrus_daboo> This document only needs a list stating which is mandatory which is optional. Not needed to specify parameters.
[17:17:55] <eburger> Cyrus: NOTIFY w.r.t. METADATA: example in document shows METADATA returning value in response. That's wrong.
[17:18:02] <eburger> Alexey: example is wrong
[17:18:21] <eburger> Cyrus: no example for notification if METADATA changes, e.g., MOTD or banner ads
[17:18:33] <eburger> Alexey: "O...K... we'll think of something" Please send text
[17:18:36] --- andrew.daviel has left
[17:18:36] <randy> Peter points out that what is needed for NOTIFY may be simpler than the more general form needed for msgevent
[17:18:49] <cyrus_daboo> On to IMAP sieve...
[17:19:09] <cyrus_daboo> Barry: talked in sieve. Look at sieve minutes.
[17:19:50] <cyrus_daboo> Main thing was it does not need to be in profile.
[17:20:03] <arnt> lovely
[17:20:07] <cyrus_daboo> Alexey: action item is to double check with OMA whether it is required.
[17:20:24] <eburger> Chairs to do liaison to ask OMA to see if multiple SIEVE scripts are required.
[17:20:30] <eburger> (IMAP SIEVE)
[17:20:43] <cyrus_daboo> There is a use case for sieve on deliver, but not imap sieve.
[17:21:32] <cyrus_daboo> On to URLFETCH...
[17:22:03] <cyrus_daboo> Alexey: suggestion - streaming servers would like body part data in binary form.
[17:22:11] <cyrus_daboo> Extension adds:
[17:22:35] <cyrus_daboo> - client can specify output format for body part to download. Can ask for binary.
[17:23:02] <cyrus_daboo> - adding the ability to get bodystructure.
[17:24:26] <cyrus_daboo> Eric: no comment on list. Dependency of streaming draft. Do last call here?
[17:24:41] <cyrus_daboo> Alexey: -00 is ready for last call.
[17:25:16] <cyrus_daboo> Phil: example should be in the document.
[17:25:51] <cyrus_daboo> Eric: lets make it WG document and do 2 week last call. So do another rev.
[17:25:59] <cyrus_daboo> with example.
[17:26:12] <cyrus_daboo> Charter does not need update - its part of streaming media delivery.
[17:26:34] <cyrus_daboo> On to IMAP enable....
[17:27:01] <cyrus_daboo> Alexey: lots of comment on mailing list about this.
[17:27:13] <cyrus_daboo> One open issue only.
[17:27:31] <arnt> enable is so simple that anyone can have opinions, so everyone has.
[17:27:46] <cyrus_daboo> Handling of unrecognized commands had list consensus to ignore.
[17:28:19] <cyrus_daboo> Same for handling of extensions that cannot be enabled - handle the same way.
[17:28:52] <ned.freed@gmail.com> I actually disagree with that. Stuff like enable _appears_ simple. The reality is otherwise.
[17:29:06] <cyrus_daboo> How a client learns what was enabled - list consensus to add response.
[17:29:12] <eburger> Ned: Anything I can channel?
[17:29:46] <cyrus_daboo> Two other minor points to clarify.
[17:29:57] <cyrus_daboo> - Enabled itself cannot be disabled.
[17:29:58] <arnt> ned.freed@gmail.com: enable is a great deal simpler than e.g. rfc 4551.
[17:30:06] <cyrus_daboo> - multiple use is additive.
[17:30:51] <cyrus_daboo> Phil: question about states in which enable can be allowed.
[17:30:54] <aaronstone> we should seek to avoid mutually exclusive extensions.
[17:31:10] <cyrus_daboo> Alexey: this is the problem about which state to allow enable.
[17:31:30] <cyrus_daboo> If we have extension allowed in unauthenticated state then ENABLE has to work unauthenticated.
[17:32:16] <cyrus_daboo> Randy: swayed by argument for simplicity wrt states - get one shot at enable after authentication, before select.
[17:32:16] <aaronstone> is it reasonable to say that enable has to be given prior to authenticate, like, "when i finish logging in, i want these features: ... -- ok, and now i log in, and check the capabilities and see what worked"
[17:33:08] <arnt> please channel: someone persuaded me that there won't be ENABLE-like extensions in unauthenticated state. it may have been dan karp, but don't hold me to that. the big argument was: enable is about things where the server can somehow send untagged/unsolicited responses. those things had better not happen in unauhenticated mode.
[17:33:30] <cyrus_daboo> Alexey: client auths first and gets capability back so no need to do again.
[17:34:32] --- andrew.daviel has joined
[17:34:53] <cyrus_daboo> Alexey: one useful extension is utf8 switch.
[17:35:26] <cyrus_daboo> Peter: not before auth and not after select.
[17:35:27] <arnt> utf8 switch concerns login, password. but it doesn't make much of a difference for server _responses_ before login.
[17:35:55] <ned.freed@gmail.com> I have no problem with disallowing enable in the unauthenticated state.
[17:36:31] <cyrus_daboo> Chris: concerned - ENABLE is a state change - we want as few of these as possible. If allowed in more than one state the more complex the state diagram. So keep it to one state.
[17:36:42] <ned.freed@gmail.com> +1 to what Chris is saying. Enable should be limited to as narrow a set of places as possible.
[17:36:55] <cyrus_daboo> Pete: is there a problem with only unauthenticated state.
[17:37:11] <ned.freed@gmail.com> Pete, it won't work because the necessary capabilities may not be listed.
[17:37:14] <cyrus_daboo> Randy: if you do that state does not change until after authentication.
[17:38:11] <cyrus_daboo> Pete: enable changes state, when doing auth capability changes.
[17:38:33] <ned.freed@gmail.com> Does the implementation know what can even be enabled until you authenticate?
[17:38:34] <cyrus_daboo> Alexey: some servers may have per-user capabilities. Client does not know until after auth what is available.
[17:38:43] <ned.freed@gmail.com> Alexey is making my point for me.
[17:39:08] <cyrus_daboo> Mark: enable in unauth state it can only work if you enable blind.
[17:39:41] <cyrus_daboo> Chris: prior to auth, state can be more expensive (e.g. proxies have to cache state).
[17:39:57] <kmurchison> +1 to what Chris is saying
[17:40:07] <cyrus_daboo> SASL can negotiate security layers at which point all state MUST be reset. That is what the spec says right now.
[17:40:12] <ned.freed@gmail.com> +1 for Chris as well
[17:40:18] <cyrus_daboo> So have to have enable after auth.
[17:40:31] <peter> and before any select
[17:40:35] <cyrus_daboo> Barry: attacker could sneak in before auth.
[17:40:56] <cyrus_daboo> Pete: wants response for enable saying what was enabled.
[17:41:11] <cyrus_daboo> Chris: we had list consensus on new enable so lets go with that.
[17:41:42] <cyrus_daboo> Barry: a clean way to do this is to have a new state - "enable state". Then when you select you can never get back to that state.
[17:41:57] <cyrus_daboo> Alexey: consensus:
[17:42:05] <cyrus_daboo> - enable is only allowed in auth state.
[17:42:31] <cyrus_daboo> - client must not send enable if ever been in selected state, server does not have to check
[17:42:57] <cyrus_daboo> Barry: change the state diagram.
[17:43:06] <cyrus_daboo> Alexey: does not buy much.
[17:43:33] <cyrus_daboo> On to extended error checking...
[17:44:01] <cyrus_daboo> Eric: document was sent to list.
[17:44:29] <cyrus_daboo> Peter: requested by Ned. No way to know what went wrong (url fetch from smtp server).
[17:44:47] <cyrus_daboo> Currently can only indicate via a NO in response.
[17:45:01] <cyrus_daboo> Various different things can go wrong.
[17:45:15] <cyrus_daboo> Doc adds an extended error response.
[17:46:14] <cyrus_daboo> Should have the option to do in fetch and utlfetch.
[17:46:46] <cyrus_daboo> Alexey: (the peace maker).
[17:47:13] <cyrus_daboo> Extensions were for fetch, urlfetch and convert.
[17:47:21] <cyrus_daboo> The convert one can go into convert command.
[17:47:28] <cyrus_daboo> On fetch - no consensus either way.
[17:47:48] <cyrus_daboo> On urlfetch - it is useful for debugging.
[17:47:57] <ned.freed@gmail.com> Another way to address this is to limit URLFETCH to a single URL.
[17:48:08] <ned.freed@gmail.com> Then you can use the NO response.
[17:48:55] <cyrus_daboo> Mark: This helps with debugging, but does it help lemonade to proceed.
[17:49:09] <cyrus_daboo> Debugging extension is a whole other topic.
[17:49:50] <cyrus_daboo> Peter: it is usually just one request. We return error message on OK response to work around this.
[17:50:17] <cyrus_daboo> Phil: That seems like a good way to do it (one at a time).
[17:50:36] <cyrus_daboo> Could pipeline - works just fine.
[17:50:55] <ned.freed@gmail.com> The only way I can see for BURL to send multiple URLs is if you read multiple BURLs from the SMTP input buffer and combined
[17:50:58] <cyrus_daboo> Phil: do not need this. Can roll specific ones into convert.
[17:51:01] <ned.freed@gmail.com> them into a single URLFETCH command.
[17:51:09] <ned.freed@gmail.com> I seriously doubt anyone will do that...
[17:51:43] <cyrus_daboo> On to profile document...
[17:51:51] <peter> can we document somewhere that uputting the error on the OK is the right thing to do?
[17:51:51] --- kmurchison has left
[17:52:00] <cyrus_daboo> Alexey: suggestion to remove WITHIN.
[17:52:23] <arnt> ned.freed@gmail.com: my code might just do that... I haven't checked, but it has a tendency to parse everything, then execute everything.
[17:52:34] <cyrus_daboo> Clients did not find it useful, servers - complex interaction with context (expensive).
[17:52:56] <cyrus_daboo> No support heard to keep it in.
[17:53:39] <cyrus_daboo> METADATA depends on LIST-EXTENDED and COMPARATOR.
[17:54:07] <cyrus_daboo> During interop - only one client used language specific searches. Useful for generic IMAP but maybe not for lemonade.
[17:54:19] <cyrus_daboo> Eric: would China interop affect that?
[17:54:40] <cyrus_daboo> Alexey: need more feedback from OMA on this.
[17:54:51] <ned.freed@gmail.com> Arnt: It's looking like if you do that you won't get errors, and Mark's opinion to the contrary notwithstanding, there are lots of errors that clients need to see which have nothing to do with debugging and present no security risks.
[17:54:57] <cyrus_daboo> Chris: make level 1 comparator mandatory, but level 2 optional.
[17:55:49] <cyrus_daboo> LIST-EXTENDED - is it compelling enough?
[17:55:52] <arnt> oh, I'm _all_ on favour of peter's proposal. I was just pointing out that with perfectly sensible design, urlfetch can retrieve >1 urls at a time.
[17:56:21] <cyrus_daboo> Would be useful if OMA required a list extension - so is there demand for it?
[17:56:28] <arnt> and I quite agree that error reporting is vital in production as well as debugging.
[17:57:02] <cyrus_daboo> METADATA - used by convert right now but could be other uses (stored searches).
[17:57:12] <cyrus_daboo> It is complicated to implement.
[17:57:25] <cyrus_daboo> But current use cases are all server level metadata.
[17:57:53] <cyrus_daboo> Proposal: split metadata to server level and mailbox level as separate capabilities.
[17:58:03] <cyrus_daboo> Again need to check with OMA.
[17:59:01] <eburger> Cyrus: Would be trivial matter to split METADATA into server data and mailbox data. Extra bonus: server data is not dependent on LIST-EXTENDED
[18:00:42] <cyrus_daboo> Alexey: agreement to take quickstart.
[18:01:06] <cyrus_daboo> Suggestions from interop:
[18:01:35] <cyrus_daboo> - urlfetch-binary is easy to add, neutral on whether it should be in profile.
[18:02:09] <cyrus_daboo> - imapext-filters - add to profile bis. Clients at interop were interested.
[18:02:17] --- guenther has left
[18:02:18] <cyrus_daboo> Glenn: no new features.
[18:02:30] --- randy has left
[18:02:40] <cyrus_daboo> Glenn: convince other people on list, then maybe...
[18:02:50] <cyrus_daboo> Alexey: extended errors: not included now.
[18:03:11] <cyrus_daboo> imap sieve: no use cases so far.
[18:03:34] <cyrus_daboo> Do need sieve notify extension though. Suggest to add that to profile bis.
[18:03:57] <cyrus_daboo> Also, how to manage sieve scripts on the server.
[18:04:29] <cyrus_daboo> Support to add IPv6 MUST to servers.
[18:04:57] <cyrus_daboo> Question about use of convert url in catenate etc
[18:05:28] --- Barry Leiba has left
[18:05:33] --- Lisa has left
[18:05:39] <cyrus_daboo> Chris: IPv6 would need a normative reference for IPv6 in MX. Spec does not exist.
[18:06:13] <cyrus_daboo> Peter: concerned about binary with append.
[18:06:22] <cyrus_daboo> Eric: to the list.
[18:06:35] --- cnewman@jabber.org has left
[18:06:36] --- resnick has left
[18:06:40] --- peter has left: Computer went to sleep
[18:06:54] <cyrus_daboo> Eric: (pretty diagram of dependencies on screen).
[18:06:57] --- ned.freed@gmail.com has left
[18:07:17] <cyrus_daboo> Glenn: we don't need to meet at next IETF - we can be done.
[18:07:28] --- eburger has left
[18:07:31] --- arnt has left
[18:07:37] <cyrus_daboo> That's all folks!
[18:07:40] --- aaronstone has left
[18:07:53] --- cyrus_daboo has left
[18:08:12] --- tonyhansen has left
[18:10:31] --- Glenn Parsons has left
[18:38:34] --- andrew.daviel has left
[19:33:24] --- Alexey has left: Logged out
[21:08:59] --- Alexey has joined
[22:15:36] --- Alexey has left: Computer went to sleep
[22:49:50] --- kmurchison has joined
[22:53:07] --- kmurchison has left