[09:46:47] --- Fan Xiaohui has joined
[10:01:48] <Fan Xiaohui> 9:00 am (pst) is mid night for me.
[10:02:15] <Fan Xiaohui> 9:00am (PST) is midnight for me.
[10:02:48] <Fan Xiaohui> :( I am afraid I cannot join it.
[10:03:06] --- Fan Xiaohui has left
[10:47:11] --- Dave Cridland has joined
[10:49:13] --- cyrus_daboo has joined
[10:49:40] <Dave Cridland> Afternoon, Cyrus.
[10:49:57] <cyrus_daboo> Hi Dave - its not quite afternoon here.
[10:50:28] <Dave Cridland> Yes, I'm assuming it's early morning for you. Just getting dark here.
[10:52:47] <cyrus_daboo> Actually I'm in Pittsburgh on EST so its ten minutes to midday here. I don't know if there is a way in jabber to indicate what timezone you are in. That might be useful to know somtimes.
[10:53:45] <Dave Cridland> Ah, good, I got the right audio channel. :-)
[10:53:59] --- Glenn Parsons has joined
[10:54:23] <Glenn Parsons> So is the aduo OK today?
[10:54:33] --- eburger has joined
[10:54:51] <Dave Cridland> Sounded it just now.
[10:56:11] <eburger> I am going to do a mike check. I want to make sure ALL the microphones work. I'll be calling out "Portable", "Chairs", and "Audience." Wait 1 and give me my 10's.
[10:56:30] <Dave Cridland> Portable good.
[10:56:35] <Dave Cridland> Chairs good.
[10:56:52] <Dave Cridland> Audience good.
[10:56:56] <Glenn Parsons> Excellent
[10:57:12] <Glenn Parsons> It is much easier to prepare when you are first in the day
[10:57:25] <eburger> Thanks!
[10:57:40] <Dave Cridland> And more especially, when you're not rushing in after a ten minute break between sessions...
[10:58:22] <eburger> test
[11:01:06] --- resnick has joined
[11:01:57] * resnick will be in TECHSPEC, right across the hall in Salon C
[11:02:20] --- pguenther has joined
[11:02:35] --- Barry Leiba has joined
[11:02:38] <resnick> I'll try to keep an eye on the Jabber room. Yell if you need me.
[11:02:41] --- NFreed has joined
[11:02:44] --- shmaes has joined
[11:03:09] --- kmurchison has joined
[11:03:52] --- pguenther is now known as starts to scribe, or something
[11:04:18] <starts to scribe, or something> chairs: welcome again, still hosted by flipper
[11:04:22] <starts to scribe, or something> note well...
[11:04:25] --- eburger has left: Disconnected
[11:05:01] --- dcrocker has joined
[11:05:03] <starts to scribe, or something> continuing from monday:
[11:05:05] --- tonyhansen has joined
[11:05:25] <starts to scribe, or something> (agenda bashing)
[11:05:31] <starts to scribe, or something> - OMA liason statement
[11:05:43] <starts to scribe, or something> - profile phase 2
[11:05:55] <starts to scribe, or something> document list
[11:06:01] --- starts to scribe, or something is now known as guenther
[11:06:04] * guenther sighs
[11:06:43] <guenther> in document list, notifications first
[11:06:48] <resnick> Who is "starts to scribe"
[11:06:50] <resnick> ?
[11:06:53] <guenther> it was me
[11:07:04] <guenther> (I used /nick when I meant to use /me)
[11:07:19] <guenther> OMA MEM liason:
[11:07:43] --- eburger has joined
[11:07:47] <guenther> agreed to publish draft before next OMA meeting, giving view of how to meet requirements in OMA arch doc
[11:08:05] <guenther> (_we_ agreed to pulblish...)
[11:09:10] --- cnewman@jabber.org has joined
[11:09:13] <guenther> slide about that draft on on the proceedings website
[11:09:40] <guenther> <pause to fumble for that URL>
[11:09:54] <Glenn Parsons> https://onsite.ietf.org/public/meeting_materials.cgi?meeting_num=64
[11:10:11] <Dave Cridland> Lemonade is now pink. Exciting.
[11:10:57] <resnick> Jabber slide numbers every so often. I'm not on audio.
[11:11:09] <eburger> http://tools.ietf.org/proceedings/05nov/slides/lemonade-3.ppt
[11:11:11] <guenther> slide 3
[11:11:20] <eburger> slide 3
[11:11:29] <guenther> jinx, you owe me a coke!
[11:11:30] <resnick> Try that URL again.
[11:11:30] <eburger> BTW, audio works, if you have headphones in TECSPEC :)
[11:11:43] <resnick> I can't do that much parallel processing.
[11:11:48] <resnick> :)
[11:12:49] <guenther> OMA model groups the store and submit parts which are clearly split looked at from the IETF perspective
[11:13:10] <resnick> slide 3 is note well?
[11:13:21] <guenther> wrong slides
[11:13:27] <resnick> URL again?
[11:13:33] <resnick> (the one above didn't work)
[11:13:53] <eburger> oops; meant http://onsite.ietf.org/proceedings/05nov/slides/lemonade-1.ppt
[11:14:04] <eburger> (tools.ietf.org for those not on site)
[11:14:06] --- Anil Srivastava has joined
[11:14:23] <resnick> thx.
[11:14:49] <guenther> slide 7
[11:15:38] <guenther> <diagram showing where various forms of filter appear in the architecture>
[11:16:38] <cyrus_daboo> Can you explain exactly what AF is supposed to do?
[11:16:43] <guenther> pete, when did you want to be flagged?
[11:17:08] <eburger> I'll ask for Cyrus
[11:17:25] <resnick> You mean when do I want to be asked to come into the room?
[11:17:56] <guenther> lisa: don't rule out notification magic that is not tied to mobile stuff
[11:17:57] <cyrus_daboo> I agree with Lisa that we should not restrict this just to mobile clients - desktop clients/tools can benefit from some of this too!
[11:17:58] <guenther> pete: yes
[11:18:35] <resnick> Only if I'm asked for. Otherwise, I'll just keep an eye on the slides and the jabber room and decide if I need to give input to something.
[11:19:12] <Anil Srivastava> can someone give me the audio URL. I am using http://videolab.uoregon.edu/events/ietf/ietf647.m3u (channel 7) and that is some other WG
[11:19:32] <resnick> Use the audio for DNA.
[11:19:37] <resnick> The room changed.
[11:19:47] <Anil Srivastava> thx..
[11:20:59] <guenther> AF to fulfill requirement for random admin filtering, wiretap, censoring, spam filter, content conversion
[11:21:00] <guenther> etc
[11:21:01] <cyrus_daboo> Does OPES SMTP stuff fit into AF?
[11:21:19] <Dave Cridland> And is there an AF-a-like on the outbound SMTP as well?
[11:21:37] <tonyhansen> cyrus: hmmm, possibly
[11:21:38] --- Randy has joined
[11:21:49] <guenther> corby: AF will never be standardized
[11:21:52] <cyrus_daboo> Dave: yes that would make sense - AF on outbound as well.
[11:22:25] --- lisa has joined
[11:22:51] <Dave Cridland> Also, it's not the boxes that are coloured, it's the lines.
[11:22:56] <guenther> greg: change slide key to note that green boxes are non-lemonade, not non_IETF
[11:23:04] --- alexeymelnikov has joined
[11:24:06] <eburger> slide 8
[11:24:07] <guenther> corby: we _could_ do draft on how to do notifications over some mobile setup
[11:24:17] --- corby has joined
[11:24:40] <eburger> why not let that (mobile notifications) be done in OMA?
[11:24:50] <guenther> glenn: OMA MEM arch doc on snowshore site, still evolving
[11:25:36] --- yjs has joined
[11:26:02] <guenther> description of color key...
[11:26:24] --- hardie@jabber.psg.com has joined
[11:26:35] <hardie@jabber.psg.com> AD is still evolving?
[11:26:42] <hardie@jabber.psg.com> hmmm.
[11:27:17] --- yjs has left
[11:27:17] <resnick> You seem very evolved to me, Ted.
[11:27:23] <resnick> Now Scott....... ;)
[11:27:43] <hardie@jabber.psg.com> Actually, I was thinking it was the other way around.
[11:27:50] <resnick> :)
[11:27:53] <shmaes> AD is still evolving
[11:27:54] <eburger> AD is still evolving "a little bit" :)
[11:28:00] <shmaes> It' sstabilizing though
[11:28:15] <guenther> glenn: many docs from OMA: requirements doc is done, architecture doc still evolving
[11:28:26] <resnick> Stephane: AD == "Area Director" for some values of AD. :)
[11:28:38] <shmaes> I expect it to become stable after ARCH review in Athens (Dec 11 - 17)
[11:28:54] <shmaes> AD in my explanation: Arch Doc
[11:28:59] <shmaes> :)
[11:29:02] <guenther> (slide 9...)
[11:29:41] <dcrocker> what is the url for the audio?
[11:29:47] --- corby has left: Replaced by new connection
[11:30:03] --- corby has joined
[11:30:05] <Dave Cridland> http://videolab.uoregon.edu/events/ietf/ietf644.m3u
[11:30:07] <hardie@jabber.psg.com> Try the audio stream marked for DNA; there was a late switch of the rooms, and I suspect it didn't get updated
[11:30:18] <Dave Cridland> It didn't.
[11:30:35] <Anil Srivastava> which slides/pdf are we looking at in the room?
[11:30:59] <guenther> http://onsite.ietf.org/proceedings/05nov/slides/lemonade-1.ppt
[11:31:00] <guenther> slide 9
[11:31:26] <Dave Cridland> EMN is a teeny-tiny XML thing that gets WAP-pushed to the device.
[11:32:09] <guenther> stephane: OMA EMN is widely supported by phones
[11:32:40] <guenther> ted ponders
[11:33:10] <guenther> ted: need to cope with lost or delayed notifications; what's mandatory to implement to get that?
[11:33:48] <guenther> or is reliability not required?
[11:34:46] <guenther> perhaps should push back on notification requirement to have OMA clarify what "needs to cope with loist or delayed notifications" means
[11:34:51] <Dave Cridland> Ted: Grabbing a complete state update *is* coping with a lost notification, though.
[11:35:22] <guenther> lisa: don't tie to mobile protocols to meet that requirement, want to work with desktops, etc
[11:35:51] <guenther> lisa: how to authorize notifications?
[11:35:56] <Dave Cridland> Phil: You should bring up the wacky hacky URLAUTH stuff now.
[11:37:38] <guenther> stephane: authorization + encryption is a concern, yes, could be solved by underlying protocol in some cases
[11:37:52] * guenther wonders how close his paraphrases are
[11:38:05] <Dave Cridland> Pretty close by my reckoning.
[11:39:30] <shmaes> OMA provides way to authenticate / encrypt for its n otification enablers
[11:40:34] <shmaes> also to Ted's comment on coping with losses, we can design so that if notification is lost it does not matter. Client may get later to server but will receive all the new stuff when it does that that it got the notification or not
[11:41:39] <Dave Cridland> Stéphane: I agree - that's the best way to handle things anyway, since you'll never know whether an EMN received by the device was fully processed or not.
[11:45:56] <guenther> <more discussion>
[11:46:09] <Dave Cridland> That paraphrase was pretty vague. :-)
[11:46:12] <guenther> eric; liason responses going out soon
[11:46:28] <guenther> as part of that, we will ask for clarification
[11:47:03] <guenther> lisa: hope this all will be in draft that goes to RFC, preferably standards track
[11:48:27] <Randy> Ted: ldap did work recently to allow for notifications to be lost; keep state and detect when client missed notifications; only resynch from last good point, no need for full resynch. This would be useful for us to pick up.
[11:49:08] <guenther> lisa: in some notification systems, the notification hub can do fan out, sending to multiple agents for a given user
[11:49:29] <guenther> on top of only a single subscription to the underlying source
[11:50:00] --- mmealling has joined
[11:51:11] <guenther> stephane: don't require, won't work when multiple transports are used
[11:51:33] <guenther> next slide <whew>
[11:51:47] <guenther> (slide 10)
[11:52:20] <guenther> <stuff that belongs in DF, VF, and NF boxes)
[11:53:06] <guenther> - client-side download and storage prefs
[11:53:21] <guenther> next slide
[11:53:32] <guenther> client-side event filtering
[11:53:42] <guenther> client impl, except for remote delete
[11:54:33] <guenther> - media conversion for 'static' conversion (non-streaming)
[11:54:48] <guenther> reponse: use CONVERT (decided in London)
[11:55:33] <guenther> stephane: three ways to request conversion:
[11:56:25] <guenther> - direct request - request overriden by server - default conversion chosen by server
[11:56:54] --- Julian Reschke has joined
[11:57:28] <guenther> Randy: "local delete" (in previous item) is unclear, please indicate that it's delete of cache in client, not altering of message in server
[11:57:33] <cyrus_daboo> Absolutely agree with Randy!
[11:57:59] <alexeymelnikov> I agree with Randy as well
[11:58:13] <Dave Cridland> I agree with Randy as well. But I follow that for the OMA, they might be a little stuck, since they have to deal with the DS stuff as well.
[11:58:46] <alexeymelnikov> Dave: Randy has suggested to at least put new terms in ()
[11:59:33] <Dave Cridland> Ah. I just lost audio for a bit, so missed that.
[11:59:46] <guenther> eric: will indicate to OMA our perspective in the liason response
[11:59:52] <guenther> s/eric/glenn/
[11:59:58] --- Julian Reschke has left
[12:00:06] <eburger> thanks!
[12:00:27] <cyrus_daboo> 'Local delete' is a purge of the local cache only, but with some persistent marker to ensure the next server->client sync does not bring it down again. POP clients have typically been able to do that in conjunction with the 'leave on the server' option.
[12:00:43] <Dave Cridland> Alexey/Stéphane: Did you get that suggestion I had for address list extraction via URLs?
[12:01:38] <guenther> greg: would like generate envelope from extract address list
[12:01:53] --- resnick has left: Replaced by new connection
[12:01:53] --- resnick has joined
[12:01:55] --- ThOr101 has joined
[12:02:07] <guenther> Dave, should someone stand up here and mention something you wrote?
[12:02:17] <guenther> (slide 12)
[12:02:30] <resnick>
[12:02:40] <Dave Cridland> No, not really. I just had a pie in the sky idea in private mail to Alexey/Stéphane.
[12:03:01] <cyrus_daboo> Greg: of course multiple clients against the same mail work. It has done for years.
[12:03:27] <Dave Cridland> Of course, if someone wants to stand up and mention ACAP, that would amuse me greatly. ;-)
[12:04:01] <cyrus_daboo> I have been able to manage multiple (different) client views on the same mailbox at the same time. It really is not a problem.
[12:04:21] * guenther kicks Dave in the shins
[12:04:22] <Barry Leiba> Want to elaborate, Cyrus, and I'll read it here?
[12:04:44] <cyrus_daboo> Client-specific info like local deleted messages should be local to that client and thus stored locally.
[12:04:52] <Barry Leiba> I think Greg's point is that you don't want to save this state on the mobile phone.
[12:05:14] <guenther> Roy: each VFOLDER has separate config/metadata
[12:06:21] <guenther> greg: OMA has requirement for querying of capabilities of sieve impl
[12:06:21] <Dave Cridland> ManageSieve does list Sieve capabilities.
[12:06:28] <guenther> alexey: managesieve supports this
[12:07:22] * guenther notes that managesieve protocol is _not_ currently a sieve WG charter item
[12:07:22] <eburger> .
[12:07:30] <guenther> slide 13
[12:08:20] <guenther> glenn: HTTP binding still an open issue, undecided
[12:08:42] <guenther> (for the "mechansisms to support the different deployment models in appendix)
[12:09:20] <Dave Cridland> TLS with DIGEST-MD5 does a pretty good job of mutual auth.
[12:10:04] <guenther> Chis: mutual auth can be done by some mechs, so just say SASL w/TLS and pick your mech
[12:10:28] <Dave Cridland> The problem with TLS is that most users have no idea at all what to do with the plethora of self-signed and expired certificates.
[12:10:55] <guenther> stephane: just need to point OMA the right direction
[12:10:55] <Dave Cridland> Plus, you have to license a monopoly to act as CAs approved by the mobile device people.
[12:11:55] <guenther> chris: message tracking as base for providing message recall
[12:12:26] <Dave Cridland> I would not like to open the can of worms that is message recall.
[12:12:34] <Anil Srivastava> this is a rathole
[12:13:13] <Barry Leiba> Agreed: rathole
[12:13:17] <Dave Cridland> Cancelling a future delivery I'd be perfectly happy to work on. Recalling a message actually sent just strikes me as a scary can of worms.
[12:13:28] --- ThOr101 has left
[12:13:57] <Anil Srivastava> except for the case that is being dicussed now. So future submission and recall is fine
[12:13:57] <cyrus_daboo> Note that 'recall' is not the proper term - you can never remove copies of messages in-route. A better description would be 'supress delivery' - i.e. stop it getting any further than its got.
[12:14:44] <Dave Cridland> Cyrus: True, "recall" isn't the right term, "utterly screwing up the global email system" is the correct term, but it's too long.
[12:15:27] <Anil Srivastava> even exchange does it only on the same server. It does not work across a deployment of exchange servers.
[12:15:47] <guenther> Ted: yes, this is rathole; perhaps having a draft would let us clarify the requirement
[12:16:02] <Barry Leiba> Dave: :-)
[12:16:13] <corby> When u try in on exchange, even it pukes half the time and fails to recall most of the messages.
[12:16:14] <Dave Cridland> On thing that Chris said, though - if people are going to do this anyway whatever we think is best, then it'd be better to write a mechanism that does least damage.
[12:16:39] <Barry Leiba> But we can't, so they'll have to ignore anything we write and do it wrong anyway.
[12:18:01] <Randy> I think recalling a messaging is a great way of getting the recipient to actually read it.
[12:18:23] <shmaes> Agreed
[12:18:23] <Randy> Nothing makes people curious about a mail like getting a recall notice for it.
[12:18:24] <Anil Srivastava> I believe the intent is stop being spammed by unsolicited notifications. This was dicussed in London..
[12:18:29] <hardie@jabber.psg.com> I confess, that's true for me too.
[12:18:32] <Dave Cridland> Randy: You're suggesting that if we create a message recall mechanism, it'll be used primarily by spammers?
[12:18:43] <shmaes> if somebody tells me "recall this" first thing I do is read it...
[12:18:51] <Randy> Dave, good point!
[12:20:56] <guenther> glenn: propose finishing draft; _not_ a profile
[12:21:16] <guenther> stephane: intent is what? prompt response from OMA?
[12:21:54] <guenther> glenn: key output doc is profile, not this doc
[12:22:09] <Dave Cridland> SO it's an OpEd piece...
[12:22:28] <hardie@jabber.psg.com> Maureen Dowd on MEM
[12:23:48] <cyrus_daboo> FYI Some of the folks in the mobile calendaring space have also been looking at lemonade/OMA work to help define similarities/differences between mobile email and calendaring.
[12:25:14] --- corby has left: Replaced by new connection
[12:25:23] --- corby has joined
[12:26:50] <guenther> stephane: making this a doc to be a normative ref for OMA would make stuff easier to adopt on that end, so they can start filling in around it
[12:26:59] <cnewman@jabber.org> I've seen friends who use message recall all the time on AOL. They sent the message, but it has a typo or something so AOL allows them to determine it hasn't been read yet, recall the message, edit it and resend it. Within an email server deployment and perhaps even within an enterprise, this is implementable, a nice feature and necessary to suppliant proprietary crap with Internet goodness for VPs and CEOs who got used to this feature. Of course once they're on the Internet and email crosses administrative boundaries, attempts to recall through the message tracking protocol will almost always return failure. It will also be problematic, ironically, if the server performs notifications to update the client immediately on delivery. :-) So putting this feature in the MEM profile is ridiculous, but since OMA has lots of telcos with many VPs and CEOs in the relevant target market, I understand why the feature is on the list.
[12:27:13] --- gustafr has joined
[12:29:26] <Dave Cridland> What slide (and set of them) are we on right now?
[12:29:41] <guenther> done with OMA response doc
[12:29:49] <cyrus_daboo> slide 22 in lemonade-0.ppt
[12:29:54] <guenther> right
[12:30:12] <eburger> 22 of chairs' slides
[12:30:21] <Glenn Parsons> draft-newman-lemonade-msgevent is being introduced
[12:30:35] <Dave Cridland> Gotcha, thanks.
[12:30:47] <guenther> chris: would like to compare event lists with other store vendors
[12:30:54] <lisa> yay chris!
[12:30:57] --- eburger has left
[12:31:18] --- eburger has joined
[12:31:20] --- hardie@jabber.psg.com has left: Logged out
[12:32:11] <guenther> barry: on todo list to write spec describing tying of store to sieve
[12:32:30] <Dave Cridland> Sort of Sieve triggers, I suppose.
[12:32:39] <guenther> chris: not sure how this fits together
[12:33:33] <guenther> barry: should IMAP actions trigger sieve scripts?
[12:33:43] <guenther> chris: doubt the scalability of that
[12:33:54] --- dcrocker has left: Disconnected
[12:35:03] --- corby has left
[12:35:04] <cyrus_daboo> Is SIEVE on mailboxes only being used to generate notifications, or do you anticipate using e.g. fileinto to move a message to trash when the delete flag changes?
[12:35:20] <Dave Cridland> Yikes.
[12:35:43] <guenther> chris: making sieve complicated to do this may not be good choice
[12:35:59] <guenther> barry: so, do his draft? <nods in room>
[12:36:39] <guenther> glenn: should this be a working group doc (chris's)
[12:37:08] <Dave Cridland> I'm happy with that as well.
[12:37:26] <Barry Leiba> Cyrus: that was something I wanted to discuss as my draft develops. Obviously, REJECT, for instance, doesn't fit, but FILEINTO and DISCARD are ... questionable.
[12:37:28] <guenther> eric: event set sufficient for OMA requirements?
[12:37:36] <guenther> greg: they only require two
[12:38:03] <guenther> glenn: people for making a WG doc, will confirm on list
[12:38:12] <Anil Srivastava> I don't believe it is complete as yet.
[12:38:19] <guenther> profile phase 2
[12:39:05] <Glenn Parsons> We are now on Stephane's slides -- that are on the proceedings server
[12:39:11] <Glenn Parsons> slide 4
[12:39:23] <Barry Leiba> Cyrus: I can see that someone might want to have a "drop-in" mailbox, that would cause NOTIFY and DISCARD -- seems to make sense to me.
[12:39:55] <guenther> S2C notification filters: some comments, being updated
[12:40:18] <guenther> event-based synchronizations:
[12:40:40] <guenther> - draft notificaitons-server-to-client-01 describes how to do it
[12:40:45] <guenther> - inband via IDLE
[12:42:03] <gustafr> Is audio working? I am lost on channel 7. Might be other reasons...
[12:42:14] <Dave Cridland> http://videolab.uoregon.edu/events/ietf/ietf644.m3u
[12:42:20] <Dave Cridland> Room change.
[12:43:09] <guenther> this is a description doc, not a spec
[12:43:30] <Glenn Parsons> Audio on Channel 4
[12:43:58] <guenther> we're on slide 6 of http://onsite.ietf.org/proceedings/05nov/slides/lemonade-2.ppt
[12:44:13] <guenther> slide 7
[12:44:39] <guenther> page 8: next steps
[12:45:08] <guenther> - sieve to be extended to generate notifications in chris's doc
[12:47:09] <guenther> (slide 10)
[12:47:30] * guenther marvels at his own consistency of notes
[12:47:57] <guenther> slide 11: out of scope items
[12:48:11] <guenther> <stuff that OMA is doing or planning on doing>
[12:48:29] <Dave Cridland> What's XDM? A SyncML derivative?
[12:49:51] <Dave Cridland> Oh dear.
[12:49:52] <guenther> XCAP based management of XML docs
[12:50:54] <guenther> glenn: next step?
[12:50:59] <Dave Cridland> I think XCAP has finally been pulled from the RFC editor's queue, now.
[12:54:59] <guenther> glenn: to become WG draft; will take to list
[12:55:09] <guenther> depends on Barry's draft?
[12:57:11] <cyrus_daboo> I disagree with Alexey in that I think this should be done in lemonade. SIEVE WG should concentrate right now on taking sieve to draft.
[12:58:31] <guenther> I agree, Alexey seems to be changing his mind
[12:58:34] <cyrus_daboo> Note that one of my original goals for mailbox SIEVE was to provide a standard format for client-side filtering as well. i.e. desktop clients could import/export cleint-side filters between different vendor's products.
[12:58:45] <guenther> lisa: new WG may be an interesting exercise
[12:59:40] <guenther> chris: separate list by itself may be sufficient
[12:59:52] --- NFreed has left
[13:00:00] <Dave Cridland> I think we do Chris's suggestion, and if other people come on board for notifications for other stuff, then a WG can be born from it.
[13:00:23] <guenther> next up: VFOLDER
[13:00:48] <cyrus_daboo> VFOLDER glosses over all the problems we found when doing IMAPext VIEW: namely the dynamic/semi-dynamic/static issues. In particular as written VFOLDER breaks the IMAP model since a change in message state in the backing folder can result in a message being 'inserted' into the middle of the vfolder. Regular IMAP clients will likely fail with that.
[13:01:30] <Dave Cridland> As they should - I looked into designing something similar, and always appended messages. But \Seen got me a bit.
[13:02:49] <cyrus_daboo> All these problems were looked at in IMAPext VIEW - I would encourage VFOLDER authros to take a look at that. I can send out a copy isince its probably expired.
[13:03:43] <Dave Cridland> Yes, I can believe that. I didn't know about VIEW, and instead did my own vfolder. I can equally well dig that out, but I suspect that VIEW will be better.
[13:03:54] <eburger> Cyrus - send me a copy and I'll post it on flyingfox.
[13:04:48] <eburger> .
[13:05:54] <Anil Srivastava> is the last version of VIEW: http://quimby.gnus.org/internet-drafts/draft-daboo-imapext-view-02.txt
[13:06:54] <cyrus_daboo> Eric: I've just sent you copies of the last VIEW draft and the WINDOW draft Chris and I had been working on as an alternative.
[13:07:15] <cyrus_daboo> Last version of VIEW was -03. Eric has a copy of that and will post links.
[13:08:00] <cyrus_daboo> The simplest view you can do is a fixed static view where the client has to explicitly update each time to refresh.
[13:08:30] <guenther> Mark: problem for mobile clients could be solved by proxy; problem for them not as big as for VIEW
[13:09:14] <guenther> Corby: VFOLDER-like things ugly to implement; also, usability was poor, as users don't like having different views on mobile and desktop
[13:09:36] <eburger> got drafts
[13:09:46] <eburger> thanks
[13:10:16] <guenther> Ray: perhaps per-client metadata would be a better approach?
[13:10:45] <guenther> chris: sounds good
[13:10:45] <cyrus_daboo> PS ACAP had the concept of per-host preferences. No reason why something similar could not be done for ANNOTATEMORE etc.
[13:11:20] <cyrus_daboo> Can we have a separate mailing list for VFOLDER too?
[13:11:25] <guenther> stop saying that "A" word!
[13:11:41] <eburger> because of IMAP folks?
[13:11:48] <cyrus_daboo> Yes.
[13:11:50] <guenther> moving on to convert/content-transformation
[13:11:54] <Dave Cridland> Cyrus: ACAP still has that concept, but that was preferences for the host, as I understood things. Not quite the same thing. There's no dynamic inheritance.
[13:12:13] <eburger> I'll look into it.
[13:12:23] <eburger> Another option is to use topics in the Subject header.
[13:12:36] * resnick 's ears perk up for convert/content-transformation....
[13:12:55] <guenther> stephane nudges chairs on streaming conversion
[13:13:26] <guenther> nothing for streaming conversion here
[13:13:47] <guenther> Randy: that's to use URLAUTH, right? <nods>
[13:14:13] <guenther> conversion has had some comments
[13:14:25] <guenther> they're beginning an impl
[13:14:30] <guenther> moving on to lideliver
[13:14:32] <guenther> ldeliver
[13:14:55] <guenther> stephane: implementing ldeliver functionality via trio
[13:15:16] <guenther> (or maybe "providing it")
[13:15:27] <guenther> byte-ranges in IMAP urls may cover that
[13:15:37] <Dave Cridland> Phil: Slide 19?
[13:15:47] <guenther> bingo
[13:15:55] <Dave Cridland> Sorry, the video quality is lousy.
[13:16:28] --- shmaes has left: Replaced by new connection
[13:16:30] --- shmaes has joined
[13:16:43] <guenther> two requirements involved, one for editting text without dowloading it all, one for editting rcpt lists similarly
[13:17:05] <Dave Cridland> Yes, it was me.
[13:18:03] <guenther> later not solved, is use case too rare?
[13:19:27] --- resnick has left
[13:19:39] <guenther> Randy: templated composition would have covered this, sorta, but there was no interest in it then
[13:19:49] <guenther> Randy: and is this really that much data?
[13:20:01] <guenther> Chris: better for arch if we _don't_ solve this problem
[13:20:35] <guenther> chris: using mailing lists are better choice for most cases, no?
[13:20:46] --- dcrocker has joined
[13:20:55] <guenther> chris: SMTP extension would be doable but completely bletcherous
[13:20:57] <Dave Cridland> Does Chris mean "distribution lists" rather than "mailing lists"?
[13:22:06] --- GregWhite has joined
[13:23:44] <cyrus_daboo> If you have a server-based address book, then URLAUTH could be used to access that for filling out an SMTP transaction without needing to send the addresses
[13:24:02] <Dave Cridland> Cyrus: Right.
[13:24:23] <Dave Cridland> Cyrus: My ugly URL suggestion was just bypassing the creation of the distribution list.
[13:24:37] <cyrus_daboo> This brings the whole realm of server-based contacts into play: ACAP, CARDDAV, LDAP etc
[13:24:57] --- resnick has joined
[13:25:05] <Dave Cridland> Cyrus: After all, if I had my way, I'd have the SMTP server expand via ACAP /addressbook dataset. :-)
[13:26:03] <resnick> Would someone identify the problem that Stephane thinks this solves (coming in late)?
[13:26:31] <resnick> (i.e., what is the "header problem"?)
[13:26:46] <Dave Cridland> It's an OMA requirement to patch address lists, basically, for PHBs that don't understand mailing lists.
[13:27:08] <resnick> on sending?
[13:27:09] <alexeymelnikov> Pete: construct a list of RCPT TO addresses from headers of a message.
[13:27:17] <resnick> OK. Got it.
[13:27:19] <Dave Cridland> Well, RCPT TO and headers.
[13:28:06] <Dave Cridland> I think it's a relatively real problem, albeit one that is a lamentable situation.
[13:28:06] <alexeymelnikov> Pete: we can already construct headers using URLAUTH.
[13:28:46] <Dave Cridland> Alexey: Not address headers, we can't. We could copy them from a message, but not generate patched address fields.
[13:28:54] <cyrus_daboo> Q is: Are per-body part annotations required? VPIM/Lemonade originally had requirement for per-body part flags. Is that still the case and if so why is ANNOTATE not part of lemonade profile?
[13:28:59] <guenther> Pete: IMAPEXT considering pulling per-bodypart ANNOTATIONS; does LEMONADE what that?
[13:29:19] <guenther> Pete: i.e., is this in the lemonade profile?
[13:30:14] <cyrus_daboo> Pete: we still need to discuss in IMAPext. Its not a done deal that we pull it out.
[13:30:50] <guenther> Randy: don't pull yet
[13:31:53] <Randy> My understanding of the discussion yesterday was that, with everything else gone, it's not bad to leave this in, so we may want to
[13:32:04] <Dave Cridland> Pete could also say "streamline", or even "optimize".
[13:32:27] <Randy> As we've already removed a lot of stuff from annotate, which makes it much simpler
[13:32:36] --- Barry Leiba has left
[13:32:44] <cyrus_daboo> Randy: at this point I want to leave it up to those doing implementations right now. Most seemed to indicate yesterday that it was not a burden to do, but I would like confirmation on the list for that.
[13:33:18] <resnick> cyrus: understood.
[13:33:21] <Randy> Cyrus, I'd agree with that. I just didn't want us to take it out prematuraley
[13:33:50] <alexeymelnikov> I think per bodypart annotations might be useful.
[13:34:23] <Anil Srivastava> need one to keep the progress...
[13:35:46] --- Randy has left: Logged out
[13:36:41] <Dave Cridland> I thought Stéphane promised us Hawaii when we were in London... :-)
[13:37:00] <shmaes> never Hawaii
[13:37:50] --- kmurchison has left
[13:37:52] --- resnick has left
[13:37:59] --- alexeymelnikov has left
[13:38:03] --- eburger has left
[13:38:19] --- lisa has left
[13:38:23] --- Anil Srivastava has left
[13:38:36] <guenther> adjourned
[13:38:39] --- guenther has left
[13:38:55] --- Dave Cridland has left
[13:39:22] --- dcrocker has left
[13:40:00] --- cyrus_daboo has left
[13:40:09] --- cnewman@jabber.org has left: Logged out
[13:40:12] --- Anil Srivastava has joined
[13:41:11] --- gustafr has left
[13:47:08] --- Anil Srivastava has left
[13:59:27] --- Glenn Parsons has left: Disconnected
[14:00:51] --- shmaes has left
[14:53:04] --- mmealling has left
[15:08:29] --- hardie@jabber.psg.com has joined
[15:09:47] --- hardie@jabber.psg.com has left
[15:12:35] --- tonyhansen has left
[15:19:53] --- dcrocker has joined
[15:50:17] --- dcrocker has left
[15:52:33] --- GregWhite has left
[20:31:23] --- Fan Xiaohui has joined
[20:33:36] --- Fan Xiaohui has left