[01:54:24] --- kael has joined
[01:54:38] --- kael has left
[08:49:17] --- arnt has joined
[09:42:35] --- pguenther has joined
[10:04:09] --- ams has joined
[10:36:44] --- randy has joined
[12:17:52] --- randy has left: Logged out
[13:11:01] <arnt> anyone here? how long until imapext starts?
[13:11:15] <arnt> I've lost track of timezones.
[13:12:33] <arnt> it's now... 12:11 in dallas?
[13:17:05] <pguenther> 12:17 now, yes
[13:18:57] <arnt> thanks
[13:48:05] --- Lyndon Nerenberg has joined
[13:53:13] <pguenther> has anyone else noticed that the restriction on RECURSIVEMATCH means that extended list can't emulate RLIST entirely?
[13:53:29] --- jonathanclark has joined
[13:53:40] * pguenther finally started updating his listext implementation to the latest draft
[13:54:17] --- kmurchison has joined
[13:54:34] <arnt> I did not notice. don't have rlist anyway.
[13:54:54] --- cyrus_daboo has joined
[13:55:27] <pguenther> you can't even emulate _plain_ LIST with extended list
[13:55:34] <arnt> what is the problem?
[13:55:42] <arnt> what?
[13:55:42] <pguenther> ...if the server supports missing hierarchy members, like Cyrus does
[13:56:20] <arnt> oh...
[13:56:24] <pguenther> if foo/bar exists but foo doesn't, then list "" % will return (\noselect) foo
[13:56:35] <pguenther> but that's banned in listext
[13:56:50] <pguenther> or rather, the sending of that response is banned
[13:57:28] <pguenther> list () "" % must not return foo according to section 3.1
[13:58:05] --- lisaDusseault@jabber.psg.com has joined
[13:58:17] <lisaDusseault@jabber.psg.com> Hello
[13:58:34] <arnt> hi
[13:58:41] <Lyndon Nerenberg> Hi Lisa! How goes?
[13:58:52] --- robsiemb has joined
[13:58:57] --- JeffMc has joined
[13:59:06] <arnt> jeffmc?
[13:59:28] <JeffMc> Jeff McCullough - UC Berkeley
[13:59:30] <lisaDusseault@jabber.psg.com> That's Jeff McCullough, Berkely guy and calendar interop expert :)
[13:59:38] --- Dave Cridland has joined
[13:59:39] <arnt> hi. nice meeting.
[13:59:53] <robsiemb> We're in a huge room, just a few minutes
[13:59:53] <Dave Cridland> Evenin' all.
[14:00:08] --- resnick has joined
[14:00:09] <lisaDusseault@jabber.psg.com> Yes, that's right, good afternoon :)
[14:00:19] <Dave Cridland> Just walked into my office forgetting I'd left the audio setup ready, and got really confused when I heard someone clearly coughing.
[14:00:24] --- doug_trendmicro@jabber.org has joined
[14:00:30] <pguenther> it ain't noon in Dallas
[14:00:39] <cyrus_daboo> Its 1 pm in Dallas
[14:00:56] * pguenther switches the direction of timezones *again*
[14:01:14] <Lyndon Nerenberg> Timezones are evil. Getting up for a 7AM Lemonade session is evil ;-)
[14:01:23] <Dave Cridland> I hear Chris.
[14:01:28] <pguenther> I give up: someone pick a timezone and we can all be on it
[14:01:35] <Lyndon Nerenberg> UTC?
[14:01:40] <robsiemb> the speaker mic works, but the chair mics weren't
[14:01:46] <Dave Cridland> UTC works *very* well for me. :-)
[14:01:51] <Dave Cridland> Pete...
[14:01:52] <robsiemb> can you guys hear pete?
[14:01:56] <Lyndon Nerenberg> yhes
[14:02:01] <Dave Cridland> Yeah, heard Pete.
[14:02:06] --- alexeymelnikov has joined
[14:02:10] <pguenther> quick, before he escapes: let's all hassle Pete about 2822bis!
[14:02:15] <Dave Cridland> Heh.
[14:02:17] <Lyndon Nerenberg> hi pete --lyndon
[14:02:23] --- cnewman@jabber.org has joined
[14:02:36] <robsiemb> Agenda Slide
[14:02:50] <Lyndon Nerenberg> Do we have slides?
[14:03:11] <robsiemb> Agenda is as posted, except comparators/i18n is at end
[14:03:12] <lisaDusseault@jabber.psg.com> Not enough slides to worry aboutr.
[14:03:16] <robsiemb> just the agenda slide
[14:03:21] <Lyndon Nerenberg> ok thx
[14:03:28] <pguenther> put 2822 on the list...
[14:03:30] --- Barry Leiba has joined
[14:03:36] <Dave Cridland> FYI: There's some discussion between me and Phil logged in Sieve's Jabber room.
[14:03:42] <robsiemb> announcement: lisa now AD
[14:03:45] <robsiemb> pete is sole chair
[14:03:47] --- tonyhansen has joined
[14:03:56] <cnewman@jabber.org> Agenda Slide: 1. find minute taker/jabber 2. agenda bash 3. LIST-EXTENDED issue 4. ANNOTATE discussion 5. Comparators/Internationalization
[14:04:03] --- hardie@jabber.psg.com has joined
[14:04:05] <cnewman@jabber.org> Other issues?
[14:04:24] <robsiemb> pete wants people to give him crap if he isn't being a good chair
[14:04:53] <robsiemb> pete expects issues for him to take care of by end of this meeting
[14:04:58] <doug_trendmicro@jabber.org> Local trust database?
[14:05:00] <lisaDusseault@jabber.psg.com> We were load-balancing well I think while Pete was on the IAB and now that I'm on the iESG :)
[14:05:09] <Dave Cridland> More failover.
[14:05:19] <robsiemb> chris: one new issue: eai stuff
[14:06:10] <robsiemb> (added to end of agenda)
[14:06:35] <cnewman@jabber.org> s/ANNOTATE/ANNOTATE,ANNOTATEMORE/
[14:06:36] <robsiemb> (discussion about rearranging agenda)
[14:07:01] <robsiemb> Undoing pete's change, now agenda:
[14:07:16] <robsiemb> LIST-EXT; Comparators/i18n; annotate/annotatemore; eai
[14:08:12] * pguenther is impressed
[14:08:16] --- ben.fersenheim has joined
[14:08:21] <pguenther> 822ter..
[14:08:29] <robsiemb> Pete: yes, I am working on 2822upd
[14:09:10] <resnick> *Not* ter.
[14:09:17] <resnick> upd
[14:09:37] <hardie@jabber.psg.com> Pete: drafts are accepted from Monday of IETF week
[14:09:38] <arnt> does this mean good suggestions, e.g. from djb, are out of scope to start with?
[14:09:39] <robsiemb> Glenn: listext issues: server may ignore the children option
[14:09:45] <hardie@jabber.psg.com> If you have something in an edit buffer, you can sending it in
[14:10:00] <Dave Cridland> Glenn? Barry, isn't it?
[14:10:04] <pguenther> I thought that text was there because the original \children stuff wasn't requested
[14:10:06] <robsiemb> er, yes
[14:10:24] * robsiemb blushes
[14:10:27] <pguenther> that is, it was just because servers were expected to do it unilaterally
[14:10:50] <robsiemb> Right, the discussion is about servers being able to say "no it is too expensive" even if the client requested it
[14:10:59] <robsiemb> Barry: inclination is that it should always go if the client asks for it
[14:11:06] <robsiemb> cyrus: i agree
[14:11:12] <pguenther> agree
[14:11:31] <robsiemb> barry/alexey will iterate that section in next version of the document
[14:11:40] <pguenther> did Barry or Alexey see my comment at the start of this chat?
[14:11:54] <robsiemb> chris: we've already been through WGLC several times, are we ok with this revision being the last, and just IETF last calling
[14:12:09] <pguenther> (regarding list-ext can't emulate plain list/rlist
[14:12:10] <robsiemb> chair/pete: I have no problem with an IETF last call after this change
[14:12:32] <Dave Cridland> Phil: I've not heard that one raised.
[14:12:47] <robsiemb> chris is channeling phil
[14:13:03] --- randy has joined
[14:13:56] * pguenther wishes he was in Dallas
[14:13:57] <robsiemb> barry: phil, can you take that to the mailing list?
[14:13:59] <pguenther> will take to list, yes
[14:14:57] <robsiemb> barry/alexey: some comments from an ancient message of rob's
[14:15:16] <Dave Cridland> Surely the same argument applies - if a server can perform a LIST (SUBSCRIBED), it must be able to perform a LIST (SUBSCRIBED) ... RETURN (CHILDREN).
[14:15:22] <Dave Cridland> By recusion if required.
[14:15:27] <robsiemb> barry: some servers may find it expensive to deal with certain options together
[14:15:31] --- Glenn Parsons has joined
[14:15:37] <robsiemb> barry: what happens with more special cases as time goes by
[14:15:51] <robsiemb> chris: channels dave
[14:15:52] <pguenther> oh, this is a problem with the complexity of the spec
[14:16:05] <pguenther> not that what is specified is too hard
[14:16:12] <robsiemb> barry: we will pull out the special case
[14:16:21] <arnt> good
[14:16:59] <robsiemb> barry: (editorial mumbling)
[14:17:55] <robsiemb> alexey: recent issue, if a server returns HASCHILDREN, by the time you do something there may be no children, so a warning was added saying that a client must cope with this
[14:18:01] <robsiemb> similar situation exists with remote
[14:18:45] <pguenther> the only thing in IMAP that _can't_ change behind the client's back is message numbers
[14:18:47] <robsiemb> barry: "because of acl/status changes the state of the world may differ at access time than at list time"
[14:18:48] <arnt> similar situation exists with SELECT: someone may have deleted every mailbox on the server between LIST-time and SELECT-time.
[14:18:58] <pguenther> this is not a new problem
[14:19:50] <robsiemb> barry: I think we agree with phil
[14:20:17] <robsiemb> alexey: minor comment about how we start talking about access controls without access to acl draft
[14:20:31] <pguenther> chris: I guess I mean that msgnos are the only that can change at all that can't change behind the client's back
[14:20:46] <Dave Cridland> Access permissions are independent of ACL - that merely controls access to them via IMAP.
[14:20:47] <arnt> I suggest toasting alexey for having gotten a draft to RFC. three cheers.
[14:21:05] <robsiemb> pete: possilby we can use an informative reference
[14:21:22] <Dave Cridland> Pete: Not 2086, we've updated that. :-)
[14:21:32] <pguenther> if I think anything, I'll take it to the list
[14:21:51] <robsiemb> pete: channels dave and arnt
[14:21:54] * robsiemb toasts alexey
[14:22:11] <robsiemb> Comparators/i18n
[14:22:14] <alexeymelnikov> To Arnt: When can I collect my beer?
[14:22:19] <robsiemb> pete: arnt is 'the one' now, not chris
[14:22:59] <pguenther> when's the next Europe IETF?
[14:23:39] <arnt> alexey: probably in montreal. easier visa rules there, and sofie's big enough that I can travel. when's pete done with the slide?
[14:23:50] <robsiemb> chris: first issue: specify a UCA version or let server implement what it wants,provided highest-version is default?
[14:24:08] <robsiemb> (is it sensible for an rfc to say "highest version")
[14:24:32] <cnewman@jabber.org> The collation name includes the UCA version so a specific version with specific function can be selected (useful for disconnected operation so the client can behave exactly the same online and offline). But the wildcard mechanism permits the client to ask for the version the server thinks is best. Registering a new variant of the basic collation for a new UCA version should not be difficult if the IANA considerations have been written correctly. And it's general IETF policy to only reference non-mutable specifications when it's important. IDN, for example, refers to a specific Unicode version and that is a deliberate choice because Unicode has a track record of breaking compatibility.
[14:24:33] <robsiemb> (chris is going to paste response)
[14:24:46] <robsiemb> action item: specify a particular UCA version
[14:25:23] <robsiemb> arnt, is this ok?
[14:25:23] <arnt> done. next q, then: rename the collation to include the name? because now we have a collation without a version in its name, so it's "default" for all future
[14:25:34] <arnt> to include the version in the name, I mean.
[14:26:01] <robsiemb> chris: yes, but looks like it was taken out in some revision
[14:26:34] <robsiemb> arnt, are you ok with putting the version # in?
[14:26:49] <robsiemb> [silence]
[14:27:14] <robsiemb> next issue: "muti value attributes"
[14:27:16] <arnt> not really. I accept general IETF policy. I don't like "basic" being UCAv14 and "basic16" being the (upcoming) UCAv16. but sometimes general policy involves specific uglinesses.
[14:28:06] <Dave Cridland> What's the "multi valued attributes" point in full? Somebody paste it?
[14:28:08] <robsiemb> pete: we should lean towards specific ugliness
[14:28:12] <robsiemb> seems like no objection
[14:28:12] <Dave Cridland> (Or point me to a mail.)
[14:28:20] <robsiemb> "I don't understand multi-valuded attributes. At all."
[14:28:31] <Dave Cridland> Ah.
[14:28:42] <arnt> dave: someone asked "what does this thing mean?" about a part of the draft. I couldn't answer.
[14:28:42] <Dave Cridland> This is an ACAP-ism, of course.
[14:28:48] <robsiemb> "how do you compare multi-valued attributes"
[14:28:48] <robsiemb> yes
[14:29:09] <robsiemb> alexey "how do you match a value against a multi-valued attribute? handle errors?"
[14:29:15] <pguenther> ACAP says "if any match, it matches", right?
[14:29:16] <robsiemb> alexey: thinks text was mostly clear
[14:29:34] <Dave Cridland> ACAP did that for EQUAL.
[14:29:46] <Dave Cridland> ACAP for anything else, it's invalid input. Collate equally and at the end.
[14:29:57] <robsiemb> chris: comparator is of general utility, and multi-valued attributes are specific, and we should strike the discussion, and if there is a protocol with multi valued attributes, they have that discussion
[14:29:59] <arnt> action item for dave and alexey: explain it to me until I understand it. if an otherwise cleuful commenter did not understand that seciton, it's not good enough.
[14:30:03] <Dave Cridland> Protocol specific makes sense to me.
[14:30:06] <pguenther> Chris's suggestions works for me
[14:30:07] <robsiemb> lisa: agreed, protocol specific
[14:30:17] <robsiemb> action item: delete section on multi valued attrs
[14:30:18] <pguenther> 3028bis answers the multivalue question for sieve
[14:30:24] <arnt> excellent. lovely.
[14:30:31] <robsiemb> next item:
[14:30:35] <cnewman@jabber.org> Are the table download MUSTs worth it? Pro: Sometimes a collation specifies that tables exist, but leaves the content to l10n. In that case, the client can get exactly what the server uses, and do offline work exactly. Contra: It's a lot of text, a lot of MUSTs, and no protocols support it... could defer all that to when the first protocol wants to do it. And anyway, when the client reconnects the server may have been upgraded with new and better tables ;)
[14:30:46] <pguenther> (the multivalues there are when a header occurs multiple times, of course)
[14:31:20] <robsiemb> chris: the situation here is that the way unicode collation works is that there is a specific algorithm that can be tweeked to be language specific
[14:31:30] <robsiemb> chris: it is possible to have the basic algorithm in an implementation, but no language specific tables
[14:31:43] <robsiemb> chris: so if you could download the tables to tweek the algorithm, that would improve the i18n of the situation
[14:31:55] <robsiemb> [current document says MUST be able to download the tables.... we think]
[14:32:06] <Dave Cridland> This sounds dumb. Surely the tables ought to be downloaded via a different table-downloading-protocol.
[14:32:10] <arnt> but one cannot do that with any specific protocol, so the MUST applies to noone.
[14:33:06] <arnt> dave: you could tunnel tdownloadp over imap using a lemonade extension.
[14:33:09] <robsiemb> chris: the reason it was put in the spec was because when you get people ot register a collation mname for a language variant, you can get the tables in with the registry, you can download stuff really easily from the registry -- I have no religion with this idea
[14:33:45] <pguenther> an server annotation? (annotateless)
[14:33:48] <robsiemb> chris: sometimes I am over ambitions
[14:34:02] <arnt> I also don't have religion. it's a lot of text, makes the draft seem heavier than it really is, and it's all pretty hypothetical as long as no protocol does it ;)
[14:34:18] <arnt> so, pro or contra. a hum would be nice.
[14:35:10] <arnt> intuitive hum ;)
[14:35:22] <robsiemb> chris: hum for doing whatever completes the draft first
[14:35:40] <robsiemb> alexey: make it a may?
[14:35:55] <robsiemb> pete: sees headshaking for making it MAY or non-normative
[14:36:01] <robsiemb> (headnodding?)
[14:36:13] <robsiemb> action items: arnt will fix this section
[14:36:21] <pguenther> that suggests that imap i18n shoud have such a command
[14:36:27] <arnt> sounds good. I'll make it so.
[14:36:41] <arnt> phil: nooooooo.... please not.
[14:36:45] <robsiemb> issue 4: en;ascii-casemap issue
[14:37:09] <pguenther> I brought that up?
[14:37:36] <arnt> phil: you and someone else brought en;ascii-casemap up, independently AFAICT.
[14:37:47] <arnt> AFAICR
[14:38:04] <Dave Cridland> chris: Indeed, this is a *different* can of worms.
[14:38:10] <robsiemb> alexey: "issue here is does ascii-casemap work on octets"
[14:38:28] <arnt> ascii-casemap WORKS on ASCII.
[14:38:29] <pguenther> ascii-casemap is certainly currently defined as working on octets
[14:38:30] <arnt> that's clear.
[14:38:47] <arnt> now, what kinds of data does ascii-casemap IGNORE?
[14:39:03] <robsiemb> ned: we have a large number of deployed implementations that depend on this behavior (on octets) depsite the use of "ascii"
[14:39:05] <Dave Cridland> My view on this issue: Comparators have historically operated on octets. So to make them operate on characters, we encode into UTF-8. (at least, we pretend to).
[14:39:36] <robsiemb> ned: we must retain backwards compatibility
[14:39:42] <pguenther> the choices for non-ascii values are: 1) mark the entire value as invalid 2) just work like i;octet (current behavior) 3) treat as UTF-8
[14:40:05] <robsiemb> chris: I believe both acap and current draft are clear that it operates on octets, and that needs to remain the case
[14:40:38] <robsiemb> chris: it is ok to define comparators that work on unicode, but this is an octet comparator
[14:40:44] <Dave Cridland> No, no need to define "character comparators".
[14:41:15] <pguenther> not a question, just a list of choices
[14:41:36] <pguenther> I'm in favor of leaving things alone
[14:41:38] <Dave Cridland> Phil: There's only option 2.
[14:42:09] <robsiemb> ned: things that cause errors on input you don't control are BAD
[14:42:30] <Dave Cridland> Ned: Not so, i;ascii-numeric is useful for detecting if a number is valid or not.
[14:43:00] <Dave Cridland> Ned: You do a relational test to see if the string collates later than "0" with "-i;ascii-numeric".
[14:43:24] <robsiemb> chris: adding a new "right thing" comparator this late isn't productive, we can add it later
[14:43:38] <pguenther> hmm, yeah, I guess I was thinking of (3) as being a subset of (1) in altering what was considered invalid
[14:44:04] <pguenther> invalid input doesn't actually cause a sieve script to bomb
[14:44:04] --- NFreed@jabber.org has joined
[14:44:06] <robsiemb> alexey: there is a question about error case is if "all non-ascii is allowed"
[14:44:08] <pguenther> it just doesn't match
[14:44:31] <pguenther> invalid-input collates before all valid input and doesn't match
[14:44:36] <robsiemb> pete: non-ascii comparason just is treated as an octet
[14:44:43] <robsiemb> chris: we should clarify that the comaprison throws no errors
[14:44:52] <NFreed@jabber.org> Dave: By error I mean "sieve script falls over"
[14:44:52] <Dave Cridland> I have to disagree, if you define basic to operate on UTF-8 encoded unicode, it's fine.
[14:45:01] <robsiemb> pete asks arnt: is that it with the list of document issues?
[14:45:16] <pguenther> there's the question of whether en;ascii-casemap should be renamed back
[14:45:24] <arnt> there is a 4b of sorts, and some outstanding issues that don't need discussion
[14:45:32] <robsiemb> pete: even if it isn't a WG item we need a WGLC, I think...
[14:45:38] <arnt> the 4b is en;ascii-casemap, yes. I wanted to hear a hum ;)
[14:45:49] <robsiemb> lisa: we did a WG hum to accept it into the charter at one point, but never updated the charter
[14:46:12] <pguenther> someone please bring the issue to Pete's attention
[14:46:21] <NFreed@jabber.org> In regards to the comparator names. the old ones are there forever for backwards compatibility. I can't get
[14:46:21] <arnt> the case for "en;"ascii-casemap is: ASCII is sort of english, certainly not any other language.
[14:46:33] <NFreed@jabber.org> excited about whether or not there are new names added for them.
[14:46:48] <robsiemb> will channel once this finishes
[14:47:01] <robsiemb> pete: this will be a WG item
[14:47:14] <arnt> the case for "i;"ascii-casemap is: compatibility with existing code, works primarily for internet protocols, whuch are i rather than en, and ascii doesn't _really_ work for english anyway.
[14:47:36] <arnt> both choices are wrong and will attract flames.
[14:47:47] <arnt> which is preferable? my vote is for i;.
[14:47:58] <robsiemb> alexey: this also matters to sieve, remember (just post the last call to sieve)
[14:48:26] <robsiemb> cyrus: wait, this was through IETF last call already....
[14:48:33] <cnewman@jabber.org> The backwards compatibility for Sieve is a compelling reason to use "i;".
[14:48:49] <robsiemb> alexey, pete: too many changes, we should have another last call type thing if not a formal last call
[14:48:55] <Dave Cridland> Chris: And backwards compatibility for ACAP, too. Hey, it matters to me if nobody else.
[14:49:22] <pguenther> look for "the case for..."
[14:50:11] <robsiemb> (discussion of 4b)
[14:50:28] <robsiemb> pete: action item is to change it back to i;
[14:50:35] <robsiemb> no objections from the room
[14:50:35] <pguenther> correct
[14:50:39] <robsiemb> we love it!
[14:50:39] <randy> Why doesn't ascii work for English?
[14:50:42] <arnt> that quickly? happy.
[14:50:47] <pguenther> re'sume'
[14:50:58] <Dave Cridland> Randy: It works for US english, but other strains keep diacriticals on loan words.
[14:51:01] <pguenther> English is not without accents
[14:51:01] <alexeymelnikov> Randy: naive has 2 dots over "i"
[14:51:06] <robsiemb> pete will put this out for a 2 week WGLC after next draft pushed, then re-writeup re-iesg
[14:51:07] <randy> that's a French word. In English it's spelled without the accents.
[14:51:09] <arnt> randy: some words, lots of typography.
[14:51:12] <Dave Cridland> randy: Like resumé and naïve
[14:51:18] <pguenther> it's in my English dictionary
[14:51:32] <randy> ok
[14:51:34] <Dave Cridland> randy: Although résumé is the French, and possibly the en_ca.
[14:51:51] <robsiemb> pete: anything on i18n document, or is it already done?
[14:52:01] <arnt> randy: minus, hash and hyphen aren't _really_ the same, even though ASCII treats them the same.
[14:52:03] <robsiemb> alexey: [cringes], there was some thought about splitting off i18n for usernames
[14:52:28] <robsiemb> (semantic issue over if this is the same as eai work)
[14:52:29] <Dave Cridland> randy: British English keeps accents and other diacriticals where it alters pronunciation, basically. Not all of them.
[14:52:36] <pguenther> arnt: the punctuation aren't a problem for ascii-casemap
[14:52:40] <arnt> there were a truly easy update on i18n, because some document or other was done.
[14:53:16] <robsiemb> chris: it is possible to log in with utf-8 using PLAIN, which raises the issue of ACLs
[14:53:19] <arnt> someone suggested mandating utf-8 mailbox names, user names, the lot in i18n. I forget who.
[14:53:33] <robsiemb> alexey: ACL has that names are utf-8, so it is fixed already
[14:53:45] <robsiemb> chris: so the issue is that LOGIN command doesn't specify a character set
[14:53:48] <Dave Cridland> But do we keep normalization for ACL names, login names, etc.
[14:53:56] <robsiemb> (there is thext in the eai document to deal with this)
[14:54:12] <randy> Dave -- I always forget about British English -- sorry :-)
[14:54:14] <pguenther> there's an eai draft for IMAP? where?
[14:54:15] <robsiemb> alexey: "like saslprep?"
[14:54:26] <robsiemb> chris: can we wait on this until eai/imap is actually published?
[14:54:27] <Dave Cridland> Randy: I try to forget about en_US. :-)
[14:54:31] <pguenther> ah, not yet published
[14:54:33] <robsiemb> (there is a document, but it isn't published yet)
[14:55:04] <robsiemb> pete: we'll do the i18n last call at the same time as comparator last call, we'll send them on as a pair
[14:55:07] <robsiemb> we love it
[14:55:08] <arnt> should imap i18n bite over utf-8 user names and mailbox names? /users/pëtë?
[14:55:15] <Dave Cridland> Do we need to float open issues about the COMPARATOR extension?
[14:55:25] <Dave Cridland> (Before we move on from i18n)
[14:55:26] <pguenther> arnt: ACL already tackled that
[14:55:44] <Dave Cridland> Thanks Pete.
[14:56:20] <robsiemb> chirs: the eai draft will fix this
[14:56:45] <arnt> so basically, I have an action item to follow where alexey led, and there will be no controversy?
[14:56:48] <robsiemb> pete: restating: this is either taken care of by: sasl, base imap, or eai, so the imap i18n doc doesn't need to say anything
[14:57:08] <robsiemb> pete: [to arnt] yes, I believe so (but I don't know where alexey led)
[14:57:29] <robsiemb> chris: [to dave] now is the time to raise
[14:57:43] <robsiemb> pete: we aren't yet time crunched, bring up what you have
[14:57:54] <Dave Cridland> I didn't think we'd reached much concsensus over the use of comparators in i18n.
[14:58:06] <Dave Cridland> Specifically, switching comparators needs a round-trip.
[14:58:31] <robsiemb> chris: can't you pipeline switching comparators
[14:58:32] <Dave Cridland> Arnt proposed various options on the list.
[14:58:43] <Dave Cridland> No, you need to wait for the response to see which one you got.
[14:58:53] <arnt> my options were just for SEARCH. few people cared, noone really minded my preferred option.
[14:59:17] <arnt> dave: you can pipeline switching, but you can't pipeline with just anything.
[14:59:28] <arnt> setting comparators and then sending some FETCH commands work.
[14:59:33] <robsiemb> barry: you can probably pipeline in many cases
[14:59:35] <robsiemb> [what arnt said
[14:59:38] <robsiemb> ]
[14:59:44] <arnt> setting comparator and then sending some command that uses it won't work.
[14:59:59] <Dave Cridland> Right, so that short discussion ont he list actually reached a sort of silent consensus?
[15:00:04] <robsiemb> pete [to dave]: do you think we need to worry about this? not much support for doing anything in the room
[15:00:17] <robsiemb> barry: does dave have any other suggestions?
[15:00:28] <arnt> the only question after the thread is: is it worth doing at all?
[15:00:32] <Dave Cridland> Well, short of a complete redesign.
[15:00:38] <arnt> is SEARCH COMPARATOR x search-key worth doing?
[15:00:57] <robsiemb> pete: doesn't see any stomach for it in the room
[15:00:58] <Dave Cridland> I'd like to be able to mix comparators, but the simplest method would be a search key with a payload of a Sieve text command.
[15:01:09] <robsiemb> cyrus: how often will comaprators really be changed?
[15:01:09] <pguenther> Chris had previous said that that option was _really_ ugly to implement
[15:01:21] <pguenther> (per-search key comparators)
[15:01:40] <arnt> huh? I thought the opposite.
[15:01:43] <Dave Cridland> Well, searching text means a localized comparator, searching body parts might need i;octet.
[15:01:47] <robsiemb> pete: dave / arnt: if you want to do something about this, generate text _quickly_ since we want to do WGLC quickly
[15:01:48] <arnt> as to how often: I don't know.
[15:02:05] <robsiemb> pete: if we don't see something quickly, we'll punt. dave/arnt are you ok?
[15:02:09] <robsiemb> ...with that....
[15:02:15] <arnt> very much ok with that.
[15:02:19] <Dave Cridland> Yeah, I'm okay.
[15:02:26] <Dave Cridland> ... with that.
[15:02:28] <arnt> good is better than best, say I.
[15:02:29] <robsiemb> moving on to ANNOTATE
[15:02:57] <robsiemb> cyrus: have been through WGLC, and done most comments, need to improve abstract
[15:03:06] <robsiemb> ...some inconstancy with the use of the term metadata
[15:03:33] <robsiemb> ...issue of content-language attribute came up today... if we need it there are data consistency issue (client updates value but not language)
[15:03:56] <robsiemb> cyrus: client would always need to set content-language together with value always, and the setting of one erases the other
[15:04:28] <robsiemb> randy: if we can remove content-language, then we are only left with value and size, and we might even be able to get rid of size, which would leave us with just value
[15:04:39] <robsiemb> randy: the goal is to make it easier for servers to implement here
[15:04:55] <robsiemb> pete: we can always just define a second annotation which is the language of the first for any of these
[15:05:06] <robsiemb> chris: or decorate the attribute
[15:05:08] <Dave Cridland> Speaking as someone who's "done" ACAP, I've never used "size" ever. Not once.
[15:05:38] <robsiemb> cyrus: server might want to use the language for collation... but can't think of a use case
[15:05:52] <robsiemb> ted: size doesn
[15:05:56] <robsiemb> doesn't matter dave?
[15:06:03] <arnt> does ACAP too allow substring searches on size?
[15:06:05] <Dave Cridland> Not what *I* have been told. :-)
[15:06:11] <Dave Cridland> Arnt; Nope. :-)
[15:06:42] <robsiemb> pete: I am much more comfortable with changes if we do this as Experimental
[15:06:44] <arnt> I implemented that. rather made the backend server cry for mercy.
[15:07:04] <robsiemb> cyrus: experimental is ok with me if it is ok with implementers
[15:07:19] <robsiemb> chris: fine as long as there is a capability name change after publishing
[15:07:24] --- kael has joined
[15:07:24] <pguenther> it can't be any more in flux than it's already been through
[15:07:25] <robsiemb> any incompatible changes
[15:07:47] <arnt> are there implementers other than me?
[15:07:57] * cnewman@jabber.org: fine as long as there's a name change _if_ incompatible changes are made after publication.
[15:08:04] <Dave Cridland> Arnt; I have half an implementation. No server to test against.
[15:08:04] <robsiemb> pete: we could use one capability for annotate and one for annotate-experimental
[15:08:27] <Dave Cridland> Arnt: So in particular, there's no UI to it. Not sure it even interacts properly with my CONDSTORE stuff.
[15:08:37] <robsiemb> cyrus: has anyone deployed annotate capability to date
[15:08:38] <pguenther> crickets...
[15:08:43] <randy> "EXANNOTATE" for the exp. one?
[15:08:49] <robsiemb> alexey: arnt has server, dave has client
[15:09:04] <arnt> I've deployed the server, but AFAIK noone uses annotations.
[15:09:04] <robsiemb> (mostly)
[15:09:13] <Dave Cridland> Deployed? Not as such. THe only thing my client will do when it sees ANNOTATE is add (ANNOTATE) to a SELECT.
[15:09:17] <pguenther> that was in reference to the silence on jabber
[15:09:28] <pguenther> (audio is fine)
[15:09:50] <Dave Cridland> But if Arnt gives me access to a server, I might be tempted to make it do something.
[15:09:54] <robsiemb> pete: we will go to experimental and play a game with the capability for the experimental document
[15:10:41] <robsiemb> barry: the problem here is that the feature seems to not be that compelling, maybe it is too late
[15:11:17] <Dave Cridland> I think given the multiple-client situation being on the increase, it'll become *more* compelling, rather than less.
[15:11:17] <robsiemb> cyrus: what is the lemonade dependency on annotate
[15:11:25] <robsiemb> pete: I think there is just an optional one, alexey?
[15:11:41] <Dave Cridland> No ANNOTATE mentioned in Profile, nor Profile Bis, IIRC.
[15:12:33] <robsiemb> pete: we can just move this to proposed standard if lots of people start implementing
[15:12:48] <robsiemb> randy: there will almost certainly be time to switch it
[15:13:01] <arnt> can randy elaborate?
[15:13:38] <randy> elaborate on switching?
[15:13:52] <robsiemb> discussion of modifications...
[15:13:55] <arnt> switching from what to what?
[15:13:56] <pguenther> so with .size and .content-language going away, will the entire attribute syntax go away?
[15:14:08] <robsiemb> chris: we should drop them now, and always add them back if they are needed
[15:14:13] <robsiemb> sorry, experimental to proposed
[15:14:30] * cnewman@jabber.org: I'd leave enough of a framework for the attribute syntax so we can put it back later.
[15:14:32] <pguenther> or do we keep the syntax just in case
[15:14:36] <Dave Cridland> Phil: No, we need attribute syntax, because otherwise we'll lose that extension space.
[15:14:41] <randy> My point is that we can start out pushing ANNOTATE for publication as EXP, but if lemonade turns out to need it, we can go for publication as P.S. instead.
[15:14:47] <robsiemb> lisa: we can avoid experimental stigma by posting an "encouragment to implement"
[15:15:01] <arnt> randy: good point.
[15:15:09] * pguenther isn't convinced that _additional_ level of extension is necessary
[15:15:18] <robsiemb> cyrus: not sure we need to dump size
[15:15:42] <robsiemb> cyrus: clients may want to know the size of an annotation before downloading it
[15:15:43] <resnick> Concern about large ones and wanting to know up front
[15:15:49] <robsiemb> chris: for voice annotations, size does matter
[15:15:52] <arnt> tell cyrus that doing string matching on the size was a nasty job.
[15:16:09] <Dave Cridland> I think that ANNOTATE should be about storing small data, and large data can be indirected via a URL.
[15:16:20] <pguenther> if clients don't ask for size from the start, it ain't gonna help
[15:16:27] <robsiemb> cyrus: I will remove sorting on size as well
[15:16:48] <robsiemb> pete: to dave: sure, but we know what people will do
[15:17:03] <robsiemb> pete: any other open issues
[15:17:39] <robsiemb> (discussion about last call needs)
[15:17:41] <cnewman@jabber.org> I agree with Pete. People will put voice annotations if the server lets them, and will want to "auto-cleanup" when the message is deleted.
[15:18:16] <robsiemb> (lots of votes to support ietf wide last call)
[15:18:46] <Dave Cridland> Chris: So stick in a note to the document to tell them they should be using WebDAV or just another IMAP message to store huge stuff.
[15:19:27] <robsiemb> pete: so do we need another wg last call?
[15:19:34] <robsiemb> cyrus: only limited editorial changes
[15:19:45] <robsiemb> pete: probably go straight to ietf last call provided no argument on list
[15:19:59] <pguenther> also, annotatemore is implemented by Cyrus, no?
[15:20:03] <Dave Cridland> I think ANNOTATEMORE has a lot more implementations available or in progress.
[15:20:15] <robsiemb> pete/cyrus/alxesy: annotatemore going to propsoed, because it has more need and more implementations
[15:20:22] <robsiemb> it is implemented by cyrus
[15:20:23] <robsiemb> mostly
[15:20:36] <arnt> _mostly_? what's not implemented?
[15:20:37] <randy> Funny that ANNOTATEMORE is ahead of ANNOTATE. Maybe ANNOTATE should become ANNOTATEMORER.
[15:20:42] --- doug_trendmicro@jabber.org has left
[15:20:44] <robsiemb> writable arbitrary vendor attributes
[15:20:50] <robsiemb> er, entries
[15:20:56] --- doug_trendmicro@jabber.org has joined
[15:21:24] <robsiemb> private/shared annotation discussion: cyrus suggests making private annotatemores optional
[15:21:28] <arnt> randy: isn't it ahead because someone went off and used annotatemore to store per-message annotations in a huge mailbox xml annotation?
[15:21:54] <randy> Who did that?
[15:21:55] <resnick> Rob: SELECT attribute isn't good enough
[15:22:03] * pguenther agrees with Rob
[15:22:18] <Dave Cridland> LIST-EXTENDED attribute or something?
[15:22:32] --- doug_trendmicro@jabber.org has left: Logged out
[15:22:33] <arnt> I m ay be blathering too much. it's what I heard, I didn't look at the code myself. kolab.
[15:22:57] --- doug_trendmicro@jabber.org has joined
[15:23:53] <robsiemb> cyrus: should we use listext vs getannotation for retreiving values.... (server level annotations are a problem)
[15:24:18] <pguenther> what's the benefit of doing it in listext?
[15:24:56] <resnick> We'll channel you in a moment.
[15:25:11] <robsiemb> chris: I have a slight preference for fetching mailbox annotations as part of listext (don't care about server). Client's shouldn't need multiple commands to get metadata about mailboxes. I have no religion about the issue
[15:25:11] <Dave Cridland> Phil: I'm keener to get all the data at once, without having to "pipeline back" a bunch of other commands as I receive the LIST.
[15:25:34] <Dave Cridland> It's kind of like wanting to avoid the STATUS-splurge, or LSUB/LIST splurge.
[15:25:53] <robsiemb> alexey: lemonade needs listext already anyway
[15:26:40] <Dave Cridland> Chris: Careful, syntax has changed *anyway*.
[15:26:41] <robsiemb> chris: we can have a historical ANNOTATEMORE=getannotation, and the main extension is a listext extension
[15:26:56] --- ben.fersenheim has left
[15:27:15] <robsiemb> cyrus: suggested new name "metadata"
[15:27:36] <Dave Cridland> Chris: SPecifically, ANNOTATEMORE uses quoted or literals, whereas ANNOTATEMORE2 (or whatever) uses astrings (I think).
[15:27:57] <pguenther> well, if the extension is changing to go to listext
[15:27:58] <pguenther> ...
[15:28:37] <Dave Cridland> Phil: Yeah, but I'm saying there's no point in glueing on a backwards compatible thing onto it.
[15:28:42] <pguenther> perhaps annotatemore should be the old with quoted-or-literals
[15:28:51] <robsiemb> chris: we have also implemented [in additon to CMU] as X-annotatemore
[15:28:52] <pguenther> then 'metadata' is new with astring and listext
[15:29:04] <pguenther> hmm
[15:29:05] <robsiemb> pete: chris should post new draft with new name
[15:29:42] <robsiemb> cyrus: should this be added to the charter?
[15:30:10] --- avel has joined
[15:30:23] <robsiemb> pete: it might be simpler to make it a lemondae charter item
[15:31:10] <pguenther> so this is just about gaming the process?
[15:31:31] <Dave Cridland> Phil: Yes. Makes you so happy we have such a sensible process, doesn't it?
[15:31:34] <robsiemb> (discussion that there is no real need to game)
[15:31:50] <resnick> :)
[15:32:12] <randy> By way of analogy, OS-level locks often bump the priority of the process holding the lock to the highest level of any process waiting on it.
[15:32:50] <robsiemb> rob: what is the solution for getting server annotations?
[15:32:58] <robsiemb> cyrus: getmetadata is a command with no mailbox argument
[15:33:06] <pguenther> what was Chris's comment in response to?
[15:33:06] <Lyndon Nerenberg> Lyndon violently agrees with Chris!
[15:33:10] <robsiemb> someone: we could also extend listext syntax
[15:33:17] <pguenther> oooh
[15:33:17] <robsiemb> chris: extending syntax is evil, adding commands isn't
[15:33:25] <Dave Cridland> Cyrus: Seems sensible. After all, you can't make semantic sense out of LISTing the server.
[15:33:50] <resnick> Last agenda item: EAI (i.e., UTF-8 headers in mail messages)
[15:33:53] <robsiemb> Wchris: summarizes eai WG (utf-8 everyhwere...)
[15:33:59] <resnick> ;)
[15:34:15] <robsiemb> chris: pete will be editing the imap eai document
[15:34:22] <robsiemb> pete: I need to keep my mind off 2822upd
[15:34:27] <pguenther> hey!
[15:34:33] <resnick> :)
[15:34:35] <robsiemb> chris: 2 major problems for imap:
[15:34:38] * Dave Cridland passes Phil a baseball bat
[15:34:44] <robsiemb> - clearly needs to be per-mailbox that hte mailbox is utf-8 aware
[15:35:02] <pguenther> please understand this hurts me more than it hurts you, Pete
[15:35:06] <robsiemb> - imap base spec is clear about 8bit not allowed unless charset is labled, so we need an implicit way of doing utf-8 in strings
[15:35:12] <Dave Cridland> Why not have an ENVELOPE8, BODYSTRUCTURE8?
[15:35:14] <robsiemb> e.g. *"utf-8 goes here"
[15:35:43] <Dave Cridland> Which decodes RFC2047 as required, I mean.
[15:36:00] <robsiemb> chris: my approach is a switch at the mailbox level (select "foo" special-eai-option) or similar
[15:36:27] <robsiemb> chris; if you walk down the path of things-that-need-to-be-8 then you need every fetch keyword with an 8 suffix, that a mode switch becomes cleaner
[15:36:36] <robsiemb> chris: I still have no religion
[15:36:46] <robsiemb> chris: there is lots of design debate still to be had
[15:36:46] <Dave Cridland> Oh... You're suggesting transcoding character sets for body parts as well?
[15:37:43] <robsiemb> chris: [to dave]: no, my reason is that if you have a utf-8 clean mailstore there is nothing stopping the MDA from converting everything to utf-8 and upgrading everything to 8bit cte
[15:37:58] <robsiemb> chris: in my experience, the body parts haven't had interop problems
[15:38:09] <robsiemb> chris: this is mostly 2047 encoding in headers
[15:38:23] <robsiemb> chris: we don't need to be excessive, it is part of a migration, but this could still be debated
[15:38:44] <robsiemb> pete: I like this as a switch just for the headers, since the more transforming the server does, the more likely it is to screw it up
[15:39:00] <robsiemb> chris: I do message headers and mime headers (filename on attachments is a huge interop problem)
[15:39:09] <Dave Cridland> Right, not sure why you need a quoted8 syntax if we then know that any 8-bit is going to be UTF-8.
[15:39:09] <robsiemb> pete: that's the heads up on eai
[15:39:20] <Dave Cridland> But we can take this offline, anyway.
[15:39:40] <robsiemb> LOGIN command?
[15:39:43] <pguenther> Dave: because quoted doesn't allow 8bit characters
[15:39:55] <robsiemb> alexey: ACL2? "If we miss this milestone, we'll forget ablot ut"
[15:39:59] <robsiemb> er, about it
[15:40:00] <Dave Cridland> Phil: It doesn't? Oh. Okay.
[15:40:05] <robsiemb> alexey: is there any interest?
[15:40:24] <Dave Cridland> I've implemented MYRIGHTS for ACL2 (LIST-EXTENDED thing)
[15:40:28] <pguenther> I haven't heard any customer requests for it
[15:40:33] <pguenther> RIGHTS was the big thing
[15:40:41] <pguenther> already implemented RIGHTS
[15:41:01] <Dave Cridland> I have RIGHTS/ACL as well, MYRIGHTS support only.
[15:41:15] <robsiemb> cyrus: this might be another candidate for experimental, since there has been so much contention
[15:41:21] <robsiemb> alexey: is there energy for this?
[15:41:28] <pguenther> ...or is the energy sucked over to lemonade...
[15:41:28] <robsiemb> pete: I don't think so, we should leave this on the runway
[15:41:29] <arnt> why was RIGHTS big? it was easy IIRC.
[15:41:42] <Dave Cridland> Arnt: It was pretty messy, I thought.
[15:41:50] <pguenther> "big thing" in the "most important and best part" sense
[15:41:58] <robsiemb> pete: let's finish the WG and not do acl, but I'm open to hear other people's ideas
[15:42:02] <arnt> low-hanging fruit, then.
[15:42:09] <robsiemb> alexey: I'll do an individual submission if I am _really_ bored
[15:42:11] <Lyndon Nerenberg> I agree with dropping from WG. Indicidual experimentals sounds good. We really need to do more research on this problem.
[15:42:32] <arnt> let's ignore ACL2.
[15:42:34] <robsiemb> pete: anything else?
[15:42:51] <robsiemb> (sounds like we're going to drop it as a WG item)
[15:42:52] <pguenther> the splitting to right-for-CREATE and right-for-DELETE was something multiple customers had asked us for
[15:43:10] <robsiemb> pete: asking people about getting next versions of their drafts
[15:43:24] <robsiemb> phil: that was the major problem for CMU as well
[15:43:49] <cnewman@jabber.org> arnt: can you do the comparator draft in next two weeks?
[15:43:58] <robsiemb> (really, ACL2 started as ACLbis, IIRC, which was just to finese the major acl problems)
[15:44:04] <Lyndon Nerenberg> Phil, do you mean they wanted to equivalent of the UNIX sticky bit on directories?
[15:44:09] <arnt> not entirely sure. I have some other stuff that absolutely has to be done by april 1.
[15:44:16] <Dave Cridland> :-)
[15:44:47] <arnt> I'll try to submit it on april 5 or so. whichever day is wednesday.
[15:44:49] <robsiemb> cyrus: there's some random imap draft that just showed up... wcorr something
[15:45:08] --- doug_trendmicro@jabber.org has left
[15:45:16] <robsiemb> draft-szego-wcor-overview-00.txt, and some others (pop, smtp)
[15:45:37] <robsiemb> pete: are we set then?
[15:45:48] * pguenther signs the bluesheet
[15:45:52] <robsiemb> pete: I hope to see noone in this room in montreal
[15:46:05] --- hardie@jabber.psg.com has left
[15:46:16] * Dave Cridland merely hopes to be able to come to Montreal.
[15:46:19] --- alexeymelnikov has left
[15:46:22] <arnt> davew: why?
[15:46:32] <pguenther> Lyndon: sorta
[15:46:41] <Dave Cridland> Arnt: I prefer being about in person. Paris was fun.
[15:47:04] <arnt> person is better. I'll almost certainly go to montreal.
[15:47:12] <pguenther> "User needs right to create subfolder. Oops, they deleted the folder itself"
[15:47:16] <Lyndon Nerenberg> Phil, it's interesting you mention it, as I've had some people ask for sticky-bit like behaviour.
[15:47:33] --- Barry Leiba has left
[15:47:34] <pguenther> What part of sticky-bit? Delete only the stuff you create?
[15:47:40] <Lyndon Nerenberg> Yes.
[15:47:48] <Dave Cridland> Lyndon: Which implementation do you do?
[15:47:48] <Lyndon Nerenberg> But without all the ACL overhead.
[15:47:58] --- randy has left
[15:48:06] --- JeffMc has left: Logged out
[15:48:07] <Lyndon Nerenberg> I have a somewhat hacked on Cyrus v1.x
[15:48:12] <Dave Cridland> Lyndon: And far more importantly, can I have an account?
[15:48:50] <pguenther> yeah, if the full ACL isn't needed, a sticky-bit kinda behavior would be nice
[15:49:00] <Lyndon Nerenberg> Dave, ya I should be able to set something up. Send me an email so I don't forget,
[15:49:20] --- kmurchison has left
[15:49:27] <arnt> food time. I need food. solyanka soup waiting, I think.
[15:49:39] --- cyrus_daboo has left
[15:50:15] * pguenther wanders off to get back to ugly work stuff
[15:50:18] <Lyndon Nerenberg> ARnt is right, it's lunch time ... see (some of) you guys in DKIM.
[15:50:19] <Dave Cridland> Lyndon: In return you can have a free copy of my free email client. Stunning offer, eh?
[15:50:20] --- avel has left
[15:50:25] --- pguenther has left
[15:50:31] <Lyndon Nerenberg> Does it run on FreeBSD?
[15:50:42] <Dave Cridland> Lyndon: Should do. Python and wxPython.
[15:50:51] <Lyndon Nerenberg> Cool. Gotta run ...
[15:50:59] --- Lyndon Nerenberg has left
[15:53:25] --- cnewman@jabber.org has left: Logged out
[15:53:40] --- resnick has left
[15:53:46] --- Dave Cridland has left
[16:04:48] --- jonathanclark has left
[16:05:42] --- lisaDusseault@jabber.psg.com has left: Logged out
[16:07:21] --- NFreed@jabber.org has left: Logged out
[16:08:09] --- robsiemb has left
[16:16:05] --- kael has left
[16:19:39] --- Glenn Parsons has left
[17:16:35] --- tonyhansen has left
[17:37:58] --- ams has left